Software Design 202505
オブザーバビリティ
基本
オブザーバビリティはモニタリングの進化系。
テレメトリーデータとはシステムの状態を示すデータの総称で、以下の4つからなる。
- メトリクス
- 時系列で「どのリソースがどれだけ」使われたかを計測する
- ログ
- 個々のイベントを詳細に記録する
- トレース
- リクエスト経路を可視化する
- プロファイル
- どの関数でどれだけ CPU 時間やメモリを消費しているかを継続的に収集する
モニタリングではこれらの情報間の紐付けや連携は手動だったが、 オブザーバビリティでは自動で行われる。
オブザーバビリティの実現には、計装/収集/蓄積/活用の4ステップが必要である。
ツールの選択
オブザーバビリティの基盤を作るツールは以下のようなものがある。
商用だと、計装から活用までの必要な道具がすべて用意されていることが多い。
- New Relic
- Datadog
- Honeycomb
- Dynatrace
- AWS - CloudWatch
- Google Cloud - Cloud Operations
OSSでこれらと同じような基盤を作れないこともない。 ただ、メトリクス・ログ・トレースは同じシステムで管理しないと オブザーバビリティが実現できないので注意。
- メトリクス: Prometheus, Victoria metrics
- ログ: Elasticsearch, Grafana Loki, Victoria Logs
- トレース: Tempo, Jaeger, Zipkin
計装・収集だけをOSSで行うこともできる。
- メトリクスの計装 -> Prometheusのクライアントライブラリ
- ログの計装 -> 各種言語のライブラリ
- ログの収集 -> Fluentd, Logstash
最近はOpenTelemetryという選択もある。 OpenTelemetry Protocol (OTLP) をやりとりするSDKやツールの総称。 これが常に正解というわけではなく、技術制約、コスト、運用などさまざまな観点から検討が必要。
メトリクス
メトリクスは定量的・時系列なデータである。 いつ問題が起き始めたのか、それがどう変化したのかをみることができる。 種類は以下の4つである。
- カウンター:
- 増加し続ける
- e.g. エラー数など
- ゲージ
- 現在の状態を表す絶対値
- e.g. CPU使用率など
- ヒストグラム
- あらかじめ定義したバケット(範囲)ごとに数を記録する
- e.g. リクエスト処理時間とその数など
ラベル(e.g. Status code, HTTP Methodなど)をつけることでさらに詳細な分析ができる。 ただしカーディナリティに注意。これはラベルが取りうる値の種類の数のこと。 高いとコストが爆発したり分析が重くなったりする。 本当に必要なものに限って使用すると良い。
ログ
アプリケーションログ、システムログ、監査ログ、パフォーマンスログ、アクセスログなど色々ある。
- 暗号めいた文章ではなく、人間に優しい文章で出す
- 分析に役に立ちそうな具体的な情報を含める
- トレースIDやスパンIDを含める
- センシティブな情報を取り除く
- 過剰な量のログを出さない
- JSONやlogfmt形式など、構造化ログで出す
- 1つのイベントのログは1つのログで出す(複数あると前後入れ替わるよ)
- ログレベルを適切に設定する