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

オブザーバビリティを高めるために、まずやる事

・既存システムの概要を把握する

・既存システムのアキレス腱となる、メトリクスやログ取得タイミングの把握する
これらはダッシュボードなどペライチで見れる可視性が必要

・既存システムの満足度調査→実際に使用されているツールにオブザーバビリティを導入するべき。使用されていないツールは優先度を下げるとか?

参照：