メトリクス、ログ、トレース をうまく使い分けて 可観測性を高めよう！ オブザーバビリティ再入門 - 大切さと高め方を知ろう！ 2024/06/05 id:masayoshi

自己紹介 ● id:masayoshi ● 株式会社はてな ○ Platform SRE 株式会社はてなでSREとして勤務。 自身の可観測性を高めるために、健康診断に行ったところ、高血圧にひっかかり健康に怯えて生 活をしている。 しかし、エラーバジェットポリシーが設定されていなかったため、食生活の改善は見られない。

今日話すこと ● メトリクス、ログ、トレースの基本的な使い分け ○ 再入門ということで改めて基本を確認していく ● 対象 ○ これから運用、監視設計を実施する方 ○ 基本を改めて復習したい方

可観測性(Observability)について ● 前の発表参照ということで、省略します ○ 「可観測性ガイダンス」(nwiizoさん)

シグナル選択の基本方針

改めてシグナルの3つ ● メトリクス ● ログ ● トレース

https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md

(結論)シグナル選択の基本方針 ● メトリクス ○ サービス全体の把握に必要な定量的な状態の記録に利用 ■ アラート、SLI/SLO、キャパシティプランニング ● ログ ○ 網羅性を重視した重要イベントの記録に利用 ■ エラーやアクセス情報の記録、セキュリティ、監査 ● トレース ○ サンプリングされた詳細なイベントの記録に利用 ■ パフォーマンスチューニング、プロセス間の関係

なぜこの図や結論になるのか

メトリクス ● この時間、この数値だったことを記録 ● タイムスタンプと数値と属性の構造化されたデータ ○ 定量的な状態を記録できる http_requests{status_code="200"} 10 1717336984

メトリクスのメリット ● グラフにできる ● 数値なので計算が可能 ○ 比較演算でアラートにできる ● 構造化されたコンパクトなデータ構造 ○ 長期保存しやすい ○ 参照する際の計算コストも低い

メトリクスのデメリット ● 数値しかわからない ○ HTTP 5xx系エラー数が増えたことはわかる ○ なぜ増えたかをメトリクスだけで判断するのは難 しい ■ 原因の特定が難しい = 調査に不向き

https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md つまり、アラートにできる (=検知を自動化できる) 安い！ 長期保存しやすい 頻繁な集計(=アラート)が現実的！

ログ ● この時間、どこで、何が起こったのか(イベント)を記録 ● 基本はテキストデータ ○ 自由なフォーマット(構造化しても良い) ○ 定性的な状態を記録できる

ログのメリット ● 自然言語で状態、イベントを記録できる ○ エラーの理由などを記述できる = 調査向き ● ログに出すだけなら比較的簡単に実装できる ○ (他の2つと比べて)網羅性が高い ● 時間単位でログを集計するとメトリクスにできる ○ アラートにできる、グラフにできる

ログのデメリット ● コストが高い ○ データ量が多く、保存、取り出しどちらもコストがか かる

https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md ログを集計するとメトリクスになる (=アラートにできる) ただし、コストが高い コストが高い！ 長期間の検索、表示は不向き 頻繁な集計にも不向き 単一のアプリケーションのイベントを記述できる

トレース ● このリクエストで発生したイベントを記録する ○ メトリクス、ログと違い、時間ではなくリクエス トがスコープになる ● トレース用のIDやイベントの時間など構造化された データ構造

{ "name": "hello", "context": { "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", "span_id": "0x051581bf3cb55c13" }, "parent_id": null, "start_time": "2022-04-29T18:52:58.114201Z", "end_time": "2022-04-29T18:52:58.114687Z", "attributes": { "http.route": "some_route1" }, "events": [ { "name": "Guten Tag!", "timestamp": "2022-04-29T18:52:58.114561Z", "attributes": { "event_attributes": 1 } } ] } { "name": "hello-salutations", "context": { "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", "span_id": "0x93564f51e1abe1c2" }, "parent_id": "0x051581bf3cb55c13", "start_time": "2022-04-29T18:52:58.114492Z", "end_time": "2022-04-29T18:52:58.114631Z", "attributes": { "http.route": "some_route3" }, "events": [ { "name": "hey there!", "timestamp": "2022-04-29T18:52:58.114561Z", "attributes": { "event_attributes": 1 } } ] } 参考: https://opentelemetry.io/docs/concepts/signals/traces/

トレースのメリット ● 1リクエスト単位の処理を一括して確認できる ○ 遅い関数などパフォーマンス調査がしやすい ● システム全体の繋がりがわかりやすい ○ マイクロサービス間やDBなど複数のプロセスを跨 いで確認ができる

トレースのデメリット ● 保存すべきデータ量が多いので、サンプリングになる ○ 全てのリクエストをトレースするのはコストが高い ○ 網羅性が低い ● コードにSpanを設定する必要がある ○ 処理を網羅しようとすると実装のコストも高くなる

https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md リクエスト単位でイベントを記述できる ボトルネックやエラー発生場所が見つけやすい コストが高い！ 網羅性を確保するには不向き プロセスを跨いだイベントを紐付けることができる

(結論)シグナル選択の基本方針 ● メトリクス ○ サービス全体の把握に必要な定量的な状態の記録に利用 ■ アラート、SLI/SLO、キャパシティプランニング ● ログ ○ 網羅性を重視した重要イベントの記録に利用 ■ エラーやアクセス情報の記録、セキュリティ、監査 ● トレース ○ サンプリングされた詳細なイベントの記録に利用 ■ パフォーマンスチューニング、プロセス間の関係

チーム内での シグナルの使い方

No content

No content

No content

No content

どの順番に 可観測性を高めていくか

可観測性の強化順序 ● 質問形式で自己判断 ○ 足りないところを自己判断できる人向け ● 私のおすすめ順 ○ 全部できてないから何から始めればいいのかわからない人向け

質問形式で ざっくり診断

サービス全体の把握 ● サービスの正常性 ○ 今現在、あなたのサービスは正常or異常か答えられるか ○ 障害対応を始めたほうが良いか ○ 障害が発生したときにちゃんとアラートは出ていたか ● キャパシティプランニング ○ 今のサーバー台数やスケール設定でパフォーマンスが足りているか ○ 中長期的なリクエスト数の増加やパフォーマンスの遷移を見れるか

正常性判断はメトリクスがベスト ● サービスの正常性はSLOで定め、SLI(つまりメトリクス)を使って判断 ○ エラー率、レスポンスタイム、リクエスト数など ● ログに出して、ログ集計してSLIにしても良い ○ アラートに利用したり、1分毎など高頻度に集計するなら、 カウンターを実装してメトリクス化を検討 ● トレースはSLIには採用しにくい ○ サンプリングとSLOの割合が上手く合致するなら利用できる

キャパシティプランニング はメトリクス ● CPU利用率やメモリなどのリソースメトリクスによって計測する ○ トレースではリクエストのパフォーマンスは見れるが、 全体のリソース使用量は計測が難しい ● 半年など長期間の計測値から推測する必要があるものはメトリクス ○ 定期的にログやトレースの結果を集計してメトリクス化しておくの も良い

障害の原因調査 ● エラー率上昇やレスポンスタイム上昇のアラートが発生したとき ○ なんのエラーが発生したかわかるか ○ どこでエラーが発生したかわかるか ○ どこがボトルネックになっているのか

障害の原因調査 ● どこで起こったか,遅いかの把握はトレースがベスト ○ 様々なグラフやログを検索しにいくよりトレースで解決したい ● トレースだけで把握できない場合もある ○ トレースはサンプリングやSpanの実装次第で取りこぼしがある ● メトリクスだけではエラー内容はわからない ● ログだけではボトルネックはわからない ● 結局のところ、メトリクス、ログ、トレースの総合力勝負

何から力を入れていくか ● 障害に気がつかない、アラートが来ない、正常性判断がつかない ○ メトリクスの強化に力を入れる ■ SLI/SLOを検討し、何をメトリクスにしていくかに時間を使う ● 原因の発生場所の調査に問題がある ○ トレースの強化に力を入れる ● 場所はある程度わかるけど、根本原因が不明で頻発している ○ 基本的にはログの強化、トレースのSpanの実装や専用のメトリク スを用意するなども検討

おすすめの進め方

初級のチーム ● サービスが異常か気づける(判断できる)ようにする ○ メトリクスの使い方(つまりアラーティング)を身につける ○ まずは、サービスの異常は何かを議論し、簡単なSLOを考えよう ■ クラウドサービスのメトリクスを使ってSLIを作る ● 例えば、ALBのメトリクスでSLIを実装してみる ○ 5xx エラー率 ○ 99%tile のレスポンスタイム ○ ログは開発していれば何も出していないことはないと思う ■ まずはログを出しておくでもよい

中級のチーム ● システム内のコンポーネントを横断して紐付けられる仕組みを強化 ○ つまり、障害場所の特定を強化する ○ トレースとログの横断検索を導入する ● トレースはとりあえず入れてみるだけでも価値はある ○ DB周りの処理時間とか対応したWebフレームワークとかの処理時 間がわかることが多い

上級のチーム ● 人間の判断ではなく、自動的に判断できるようにしていく ○ より高度な定量化 ■ ログに出していた定性的なエラー情報から、 定量的なメトリクスにすることで、 自動的にアラーティングできるようにする ○ より詳細な紐付け ■ メトリクスやログからボトルネックを推測するのではなく、 トレースのSpanを実装することで、 遅い箇所が視覚的にわかるようにする

まとめると

最後に ● どのシグナルも重要で、一概には言えないが、 ○ システムが、システムの状態を、人間に通知できるようにする ■ システム障害の検知を強化 ● メトリクス > ログ > トレース ○ 人間が、システムの状態を、調べられるようにする ■ システム障害の調査を強化 ● トレース > ログ > メトリクス ● チームに足りない箇所を把握して、強化していこう