まず見るべき資料

Amazon CloudWatch 概要

(2023/03) Amazon CloudWatch の概要と基本【AWS Black Belt】
- スライドリンク

Amazon CloudWatch RUM 概要

（今回はここまで使うかわかんない）

AWS CloudTrail

監視システムの目的

ユーザ体験を損なわないようにすること
-サービスの健全性の
- システムのダウンタイムを短縮する

監視システムの設計の要件

運用者（オペレータ）がシステムの異常にすぐに気付けること
システムの異常の検知場所が 1 ヶ所に集約されていること
システムの異常がどこで起きているか追えること
緊急性の高いエラーが開発者、エンドユーザにリアルタイムに連携されること

nukopy

Amazon CloudWatch の全体像

引用元：https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_AmazonCloudWatch_0330_v1.pdf

オブザーバビリティ（可観測性）とは

オブザーバビリティ、可観測性、observability
- システムで何がなぜ起こっているのかといった動作状況を、把握できている状態のこと
- 多く場合、システムを計測してメトリクス、ログ、トレースを収集することによって行われる
監視
- 監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である（入門監視）

オブザーバビリティの例：メトリクス

このサービスでは、メソッドの 90% が 200 ミリ秒以下で完了している
この API は 1 秒間に 203 の HTTP リクエストを処理している
IoT デバイスから IoT ゲートウェイに送られてくるセンサーデータの単位時間あたりの受信レートが約 30 FPS である

システムの状態把握に必要な 3 本柱：ログ、メトリクス、トレース

イベント

ここでの「イベント」はどういう立ち位置なんだろう？アプリケーション間で例えば MQ を介してやりとりするような「イベント」と、サービスとして観測したい重要な「イベント」など、システム ~ サービスまで観測したい「イベント」を定義してそれをモニタリングするサービスって感じなのかな。

ユーザ体験の監視

nukopy

監視・オブザーバビリティアーキテクチャ

各社のアーキテクチャ

nukopy

サイボウズの例

実践オブザーバビリティ（Observability Conference 2022）

監視基盤への「アクセス契機」って観点は運用する上で「監視システムは誰が使うものか」を考える上で参考になる。結局アプリケーション開発者や運用担当者に使ってもらわないと意味がないし、それが運用時のどのタイミングで起きるのかを明示しておくのは大事。ダッシュボードかっこいい嬉しいねじゃなくて、運用上どう有効活用できるか / されるのかを考えたうえで作り込む必要がある。

有事の際に通知：Slack 通知 → ダッシュボード見る → トラブルシューティング（ログ、メトリクスを見る）
定期的なダッシュボード確認
- 前回確認時以降、変わったところがないか確認
- 「何が正常か」を知るのに役立つ

ダッシュボードの例

nukopy

監視とオブザーバビリティの違い

資料 1：New Relic 監視からオブザーバビリティへ

New Relic の資料が良かったが、結局明確な境界はなくグラデーションなのではという感想。まだ本質的な理解ができてないのかも。

監視からオブザーバビリティへ〜オブザーバビリティの成熟度/From Monitoring to Observability - Maturity of Observability（2023/5/23開催「オブザーバビリティ最前線〜事例LTから学ぶ、オブザーバビリティの成熟度〜」）

近年の IT システムにおける監視の問題点

監視からオブザーバビリティへ

監視はアクティブ（「必要に応じて」の部分）でオブザーバビリティがパッシブなのかな。

監視は個々のデータを必要に応じて収集するが、オブザーバビリティは全てを収集する

Observability 成熟度モデル

nukopy

資料 2: 監視とオブザーバビリティ ~ 悩む前に確認しておくべきこと ~

正直こっちの方がわかりやすかったかも。「監視者」と「観測者」という観点で見る。

結局明確な境界はなく、二項対立するものではなく、監視→オブザーバビリティというシステムの進化のグラデーションなのでは、という感想。まだ本質的な理解ができてないのかもしれない。

従来の監視でもメトリクスだけじゃなくログ（監視対象の内部状態）も収集してたと思うけど。この図の書き方あまり良くない気がする。

異論はあるとしても、この図で監視とオブザーバビリティが意図することは掴めた。そして今自分がやりたいのは監視だなと。

自分の考え

結局監視とオブザーバビリティに明確な境界はなく、かつ二項対立するものではなく、監視からオブザーバビリティというシステムの進化（監視という概念の拡張？）のグラデーションなのでは、と考えた。

視点として「監視は過去 ~ 今、オブザーバビリティは過去 ~ 将来」というフォーカスの違いはたしかにと思った。監視は障害の検知の自動化、障害からの復旧時間の短縮、つまりシステムの安定稼働が主目的で、オブザーバビリティはそれは大前提として、さらに将来に向けた障害やその原因の予測、そして継続的なサービスの改善をしていくことに焦点を当てているのかなと。

nukopy

Amazon CloudWatch における監視とオブザーバビリティの違いの説明。

※モニタリング（監視）との違い
明確な定義があるわけではなく、様々な解釈がある。
監視はエラーに対応するためにシステムが機能しているかを検知・把握することを主⽬的としている場合が多い。
オブザーバビリティはシステムでの計測項⽬を継続的に追加し、新たなインサイトを得ることで、未知の障害の対処、ダウンタイムの短縮に活かし、システム障害以外のビジネス⽬標達成の⽤途にも役⽴てる。