1 オブザーバビリティ（可観測性）
Observe （観察する）+ ability （能力）
システムやアプリケーションの状態や挙動を監視、分析し、理解する能力
2 オブザーバビリティ（可観測性）３つの観点
3種類のテレメトリデータ
2-1. ロギング（Logging）:
システムやアプリケーションが生成するログデータを収集し、分析することで、問題発生時に原因を特定しやすくします。
2-2. モニタリング（Monitoring）:
システムやアプリケーションのパフォーマンス指標やリソース使用状況を監視し、異常が発生した場合に通知を行うことで、問題を早期に検出・対処できるようにします。
2-3. トレーシング（Tracing）:
リクエストや処理の流れを追跡することで、システム全体の挙動や相互作用を把握し、パフォーマンスやエラーの原因を特定できるようにします。
3 従来のモニタリング(監視)とオブザーバビリティの違い
- モニタリング
「システム単体ごとに異常があるかどうかずっとみている」 - オブザーバビリティ
「既存のシステム全体を常に観測、可視化できており原因特定までできる状態」
モニタリングはオブザーバビリティの要素の一つ
CPUやメモリなどメトリクスの閾値超過だけをモニタリング(監視)すれば良いという考え方ではなく。
システムのアキレス腱となる、メトリクスやログを可視化ダッシュボードで経時的に見ていく。
システムの可視性を高める事が、オブザーバビリティという考え方
日常に落とし込んで、モニタリング(監視)とオブザーバビリティの違いを考えてみる。
【従来のモニタリング(監視)を、医療に置き換える】
病院） Aさん最近お元気ですか？
↓
Aさん） はい元気です！
↓
Aさん） 年に一回健康診断受けてA判定だし大丈夫だろ
↓
Aさん） 最近飲みすぎだな
↓
Aさん） 最近忙しいな
↓
Aさん） 最近寝れていないな
↓
【Aさん倒れる】
↓
病院) Aさんが倒れたって！大丈夫?
↓
【治療】
↓
x回繰り返し
【オブザーバビリティを、医療に置き換える】
病院） Aさん最近お元気ですか？
↓
Aさん） はい元気です！
↓
Aさん） 年に一回健康診断受けてA判定だし大丈夫だろ
↓
病院） Aさん！AppleWatch持っておられますよね！それでヘルスケア情報を病院に送ってくださいね毎日
↓
Aさん） はい
↓
Aさん） 最近飲みすぎで運動もしてないな
↓
病院） あれAさん最近活動量少ないな
↓
Aさん） 最近忙しいな
↓
病院） あれAさん最近脈拍早いな
↓
Aさん） 最近寝れていないな
↓
病院） あれAさん最近睡眠時間も短いし、ヤバそうだな。訪問しよう！
↓
Aさん倒れる前に、発見できる！
↓
【治療】
↓
x回繰り返し
これがオブザーバビリティが実現できるという事かなと思います。
つまり医療であってもシステムであっても、監視する側が能動的な体制でいる事
またそれらを発見できるようにメトリクス、ログ、トレースを常に収集し見れるように可視性を高めることも重要→ダッシュボード化
4 もともとの監視設計も大事
適切なモニタリングをしよう
例えばこんな背景があった場合：
・開発環境でEC2を動作させている
・費用削減のため、T系インスタンスを使いたいので採用
・でもリソース超過するのであればC系に切り替える事も考慮にある
※T系とは100%のCPUリソースを超過した性能を発揮できるバーストが可能。
しかし、バーストできる量には制限がある。これをバーストクレジットという形で消費される。
【問題のある監視設計】
CPUが高いのでアラート発報→サービスURL閲覧→OK→問題なし！（x繰り返し)
このモニタリングでは原因にたどり着けない＋意味のないアラートが多発してしまう。
【適切な監視設計】
CPUが高いけどアラート発報させない→バーストクレジット0を監視→0に近くなったらアラート発報→クレジットないからタイプ変更しよう
これだと意味のあるアラート発報が可能。
可視化ツールの選定
ダッシュボードで一元管理する方法が情報も多く構築しやすそう。
Grafana,Datadog,Newrelic...etc
オブザーバビリティを高めるために、まずやる事
・既存システムの概要を把握する
・既存システムのアキレス腱となる、メトリクスやログ取得タイミングの把握する
これらはダッシュボードなどペライチで見れる可視性が必要
・既存システムの満足度調査→実際に使用されているツールにオブザーバビリティを導入するべき。使用されていないツールは優先度を下げるとか?
参照：