Observability とは

Observability とは何か

Observability(オブザーバビリティ) ってなんだろう？と思い考えてみる。と、思ったが、他の方のブログが、割としっくり来てしまったので、そちらに任せたいので、ざっくり↓の大きく2つについて、個人的な考察も交えて、まとめておこうと思う。

  1. Observability と Monitoring の違い
  2. Metrics・Logs・Traces について

1. Observability と Monitoring の違い

これもまたいろんなところで論じられているので、詳しくはそちらを参考にしてほしいが、基本的な考え方としては、以下のような違いがあるように感じています。

  1. 問題の理解・解決がしたいのか？発見がしたいのか？
  2. プロアクティブか？リアクティブか？

当然、Observability が「問題の理解・解決」を目的とした「プロアクティブ」なアプローチ・考え方であり、その「手段」の1つとして Monitoring があるという捉え方をするのが良さそうです。続いて、Observability といえば、必ず出てくる Metrics・Logs・Traces について、まとめます。

2. Metrics・Logs・Traces について

まず、この3要素は、順序関係を意識して捉えるのが良いとされており、ざっくり、以下のような流れで使い分けることが多いようです。

  1. Metrics - 異常値を検知して（いわゆる、監視をして）
  2. Logs - 特定システムにおける詳細な事象の把握・直接原因を特定し
  3. Traces - システム全体横断・リクエストベースで、ボトルネックの特定・根本原因を特定する

前提として、そもそも Observability という考え方は、Observability at Twitterにもあるように「分散型のシステム」「マイクロサービス」が背景にあるので、極論、そういったシステムでなければ、Observability は必要ないかもしれません。（少なくとも、Tracesとかは不要とかはあるかなと思います。）

その他にもたくさんの記事・ブログが公開されているので、探してみるといいですが、↓あたりがパッと見良さそうかなと感じました。

以下では、3要素それぞれをシステムに適用していく際の個人的に指針としていることについてつらつらと書いていこうと思います。

Metrics

システムの正常とは何か？

Metrics 自体は「定量化」「計測」などの意味しか持たないかとは思いますが、「プロアクティブ」的に考えると、計測結果をどう取り扱うべきかとセットで議論すべきかなと感じております。そう捉えた場合、大事だなと感じることは、上でも書きましたが 異常を検知することだと考えています。そのためにはまず、 異常とは を定義するにはどうすれば良いかでいうと、正常とは から考え始める必要があるかなと思います。

例を挙げて説明すると「任意の API リクエスト成功率が、80%である」=「異常」は、正しいか。この質問に対する答えとしては「正しい」とも「正しくない」とも言えないと思います。なぜなら「正常」な状態がわからないから。乱暴な言い方をすると「いつも75%」なのであれば、「正常」となるかもしれません。

上記は、比較的わかりやすい例でしたが、日々扱っている複雑なシステムでは、そう簡単ではないケースもあるかと思います。しかし「正常とは何か」という問いが出発点になるのには変わりはないのではなかろうかと思っています。まずは「正常の定義」をしてから、その表現方法の1つとして “threshold(閾値)” を利用するのが良いかなと思います。後の細かい How に関しては、いろんな記事があるので、省略したい。

Logs

Logs で大事にしている・したいことは大きく2つ。

  1. ログフォーマット
  2. ログのライフサイクル

1. ログフォーマット

そのログ1行で、デバッグしてリリースできるか？

ここは、最初の方にもあげた他の方のブログの中にあった「システムの出力からある時点でのシステムの内部状態を一意に知ることが出来る」が全てという感じですが、ログ1行に対して、どれだけ意味が込められるかは大事にしたいと考えています。例えばでのあるあるは

ref. https://newrelic.com/resources/white-papers/log-management-best-practices

2. ログのライフサイクル

今目の前にあるログは、正しいか？

何かインシデントやエラーが発生して調査する際、CloudWatch Logs や Cloud Logging などのIaaSに統合されたサービスを利用したり、ELK Stack などのSaaSを利用したり、様々なツールを使うことが一般的かなと思います。では、“目の前にあるログは、正しい"でしょうか？これに対して「正しい」と答えるためには、ログが生成されてから人間が認識するまでのライフサイクルを理解することが大事だと考えます。

Traces

よく出てくる参考文献としては以下のようなところがあるので、載せておきます。

Observability の今後について

本投稿を書くにあたって、改めて Observability についていろいろ調べてましたが、今後は主に、トレーシングに関して「より広く」「より深く」拡張していくんだろうなという感覚を感じました。今後はそれを見据えて、トレーシングに関しても本格的にやっていきたい。

  1. より広く

    • OpenTelemetry などによる統一規格の浸透
    • 外部サービスとも統合されたトレーシングの実現 etc…

  2. より深く

    • eBPF を利用した Linux カーネルのパケットも含めたトレーシング etc…