Ses_01_いまさら聞けない監視＆流行りのオブザーバビリティ

いまさら聞けない 監視＆流行りのオブザーバビリティ 2025/10/31(金) yamapan 20分 2

スライドのみ撮影可＆SNS投稿可（人物はNG） #すきやねんAzure

Azure の監視と言えば Azure Monitor  Azure Monitor は Azure の監視系サービスの総称  Azure Monitor Agent  Log Analytics Workspace  Container Insights  Network Insights  VM Insights  Network Watcher などなど これ全部 Azure Monitor 4

おしながき  そもそも、なんで今このテーマ？？  監視とは  オブザーバビリティとは  Appendix : Azure における監視とオブザーバビリティ 5

監視とオブザーバビ リティの違いって？ シグナル？ アラート発報的 なやつやろ！ そもそもメトリック とログってなんやね ん？ メトリックとログっ て？あとテレメト リってなんやねん？ Azure Monitor って Zabbix みたいなや つやろ！しらんけど 6

そもそも、なんで今このテーマ？？  システムの変化 モノリシックからマイクロサービスへ Kubernetes、クラウドネイティブ環境の複雑化 要するに、最近旬 なテーマの１つ。  運用課題 従来型監視では「エラーが出たこと」はわかるが「なぜそうなったか」が見えにくい アラートの氾濫による「アラート疲れ」  ビジネス要請 サービスの継続性・信頼性が直接売上や顧客満足に影響する SREやDevOps文化の普及で「迅速なトラブルシュート」が必須になった  トレンド OpenTelemetry など標準化の進展 AI/ML を活用した異常検知の実用化 7

監視とは 8

監視とは 監視とは？ •システムやサービスが「正常に動いているか」を確認する活動 •あらかじめ決めた指標や閾値で状態をチェックし、異常を早期に検知する仕組み 例：CPU使用率 > 80% → アラート発報 監視は「症状の早期発見」に強いが、なぜ起きたかまでは見えにくい。 監視対象例 • インフラ（サーバー/VM/コンテナ）：CPU、メモリ、ディスク、ネットワーク帯域 • アプリケーション：レスポンスタイム、エラー率、スループット、ユーザー操作ログ • ネットワーク：レイテンシ、パケットロス、帯域利用率、接続可否 • サービス：全体SLA 達成率、稼働率、依存サービスの稼働状況 昔は「サーバー監視」が中心 → 今は「アプリ・ネットワーク・クラウドサービス全 体」まで広がっている。 9

代表的な監視指標 リソース系  CPU 使用率  メモリ使用量  ディスク I/O / 空き容量 パフォーマンス系  レイテンシ（応答時間）  スループット（処理件数/秒） SLIやSLO にもつながる指標 SLI は「利用者の体験やサービスの健全性を測るための 実際の具体的な数値」 監視の中で使うメトリック（CPU使用率やエラー率など） のうち、ユーザーにとって意味があるものを指す。 ※SLOは目標値、SLAは契約 信頼性系  エラー率（HTTP 5xx, DBエラー数）  稼働率（Uptime）  可用性（Ping/ヘルスチェックの応答） 10

ログとメトリック ➢ Logs（ログ） システムやアプリで発生した 個々のイベントの記録 例：エラー発生時の詳細、ユーザー操作履歴、状態遷移な ど 特徴：トラブル時に「何が起きたのか」を細かく追跡できる ➢ Metrics（メトリック） 数値化された指標 を一定間隔で収集したもの 例：CPU使用率、メモリ消費量、ネットワーク遅延時間 特徴：グラフ化しやすく、傾向やパターンの把握に強い 11

(従来型)監視の限界- Limitations of Monitoring サイロ化（インフラ・アプリの監視） 障害が起きたときに「どこが原因か」を突き止めるの に時間がかかる 運用負荷とアラート疲れ 閾値を細かく設定するとアラートが大量に発生 運用者がアラートメールに慣れてしまい、本当に重大 な通知を見逃すリスク 異常検知はできるが「なぜ？」がわからない はい！！！！ そんなあなたに オブザーバビリ ティ！！！ 閾値監視で検知可能しかし「なぜCPUが急増したか」 「どの操作が原因か」という因果関係までは追えない 12

クイズ  なぜオブザーバビリティが必要になってきたか、正しい理由 はどれか？ 1. 監視が常にすべての原因を自動特定できるようになったため 2. 従来監視では異常検知はできても「なぜか」が分かりにくいから 3. アラートが減りすぎて運用者の仕事がなくなったため 4. インフラとアプリが一体化し監視が単純になったため 5. AIの発達した現代では監視が不要になったため 理想的な 未来 13

クイズ  SLA, SLO, SLI それぞれについて正しいのはどれか？ 1. SLI は契約書に記載されるサービス保証内容のことを指す 2. SLO は監視で収集された生データそのものを意味する 3. SLA はサービス提供者と利用者の契約、SLO は目標、SLI は指標を示す 4. SLA, SLO, SLI はすべて同じ意味で使われている 5. SLI はサービスの目標値、SLO は実測データである 逆 14

クイズ  ログとメトリックについて正しい記述はどれか。 1. ログは必ず数値データとして保存され、グラフ化前提で扱われる 2. メトリックは障害の詳細原因を特定できる高精度データである 3. ログはイベントや処理内容の記録、メトリックはCPUやメモリ使用率などの時系 列サンプリング数値 4. メトリックは必ずストレージに長期間保存される履歴データである 5. ログは決められた間隔(1秒など)ごとの数値を必ず時系列で収集するデータで ある 15

オブザーバビリティとは 16

オブザーバビリティとは- Observability  可観測性ともよばれる。英語でいうと、Observability！  かっこよく書くと O11y 「システムがどのような状態になったとしても、それがどんなに斬 新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺 度です。」（by オブザーバビリティ・エンジニアリング) 「オブザーバビリティ」という言葉の起源は、1960年代の制御理論まで さかのぼる。1960年代初頭に、ルドルフ・カルマンは動的なシステムの 内部状態を外部からの観測データに基づいて推定する概念を提唱。 この概念が「可観測性（Observability）」と呼ばれ、「オブザーバビリ ティ」の語源。その後、システム工学、情報科学、社会科学など、様々な分 野に広がる。 17

オブザーバビリティとは- Observability オブザーバビリティの定義： システム内部の状態を、外部から得られるデータ（テレメトリ）を通じ把握できる性質 → 「ただ監視する」ではなく「なぜそうなっているか」を理解できるようにする 監視との違い： 監視：症状を見張る（CPU高い、エラーが出ている） オブザーバビリティ：原因を理解する（どのコンポーネントが遅延を引き起こしているか テレメトリの３本柱！ • Metrics（メトリック）：数値化されたデータ（CPU使用率、レイテンシなど） • Logs（ログ）：個別イベントの記録（エラー、操作、状態遷移など） • Traces（トレース）：分散システム内でリクエストが辿った経路を可視化（どこで遅延 や失敗が起きたかを追跡） この3つを統合して原因がわかるようになる 18

ログとメトリックとトレースとテレメトリとシグナル ➢ Logs（ログ） ➢ Telemetry（テレメトリ） システムやアプリで発生した 個々のイベントの記録 システムから収集される 観測データ全般 を指す総称 例：エラー発生時の詳細、ユーザー操作履歴、状態遷移な Logs / Metrics / Traces をすべて含む広い概念 ど 特徴：監視やオブザーバビリティを支える「生データ」 特徴：トラブル時に「何が起きたのか」を細かく追跡できる ➢ Metrics（メトリック） 数値化された指標 を一定間隔で収集したもの 例：CPU使用率、メモリ消費量、ネットワーク遅延時間 特徴：グラフ化しやすく、傾向やパターンの把握に強い ➢ Signals（シグナル） Telemetry の中で 分析・解釈に使う代表的なデータの 種類（軸） 主に Logs / Metrics / Traces の3つを指す。 テレメトリに比べてあんまり有名じゃないかも。 特徴：オブザーバビリティの「三本柱」 ➢ Traces（トレース） 分散システム内でリクエストが どの経路を通ったか を追 跡したデータ 例：ユーザーリクエストがフロント → API → DB へ到達 する流れと遅延 特徴：「どこで遅延や失敗が起きたか」を明確にできる ➢Telemetry は「集めたデータ全体」 ➢Signals は「Telemetryを分類する主要な軸（Logs / Metrics / Traces）」 ➢実際は同じような意味で使われている場面もある 19

オブザーバビリティのメリット ➢因果関係の把握 例)CPU使用率上昇とDBクエリ遅延の関連を発見できる ➢根本原因分析（RCA: Root Cause Analysis） 単なる「エラー発生」から「どのサービスが原因か」まで掘り下げ可能 ➢予測・予防 過去データや傾向をもとに将来の障害や性能劣化を予測 アラート疲れの軽減にもつながる 20

3rd Party オブザーバビリティ製品を使うメリット （Elastic , Datadog, New Relic, Dynatrace , AppDynamics, Grafana など） ➢ マルチクラウド / ハイブリッド環境対応の一元監視 Azureだけ、AWSだけではなく、オンプレや複数クラウドを横断して一元的に可視化できる（しやすい） ➢ 高度な可視化と分析 ダッシュボードやトレース解析のUIが洗練されている APM（Application Performance Monitoring）の機能が強力で、コードレベルまで深掘りできる ➢ AI/MLを活用した異常検知 しきい値ではなく「普段と違う動き」を自動で検知する機能がある アラート疲れの軽減や予兆検知に有効 ➢ SRE / DevOps向け機能の充実 SLA/SLI/SLO のモニタリング機能が整備されている チームコラボレーション機能（アラートをSlackやTeamsに連携、TEL、インシデント管理ツールと統合な ど） 21

オブザーバビリティとSREの関係 そもそも SRE → Google が提唱した「ソフトウェアエンジニアリングの手法を運用に適用する考え方」 ➢ SREのないとき：開発チームが作ったものを運用チームが「動かし続ける」 ➢ SREのあるとき：SREエンジニアが「信頼性を設計・構築・改善する」 ➢ SREエンジニアは、単にサーバーを監視するだけでなく、コードを書いて自動化し、システムアーキテク チャを改善し、障害を予防する仕組みを作る。 ➢ 目的はサービスの信頼性(Reliability)を高めること。 重要な概念として SLI/SLO/SLA がある。 SRE の核となる考え方(余談) ➢ エラーバジェット 例えば99.9%の可用性目標(SLO)なら、月約43分のダウンタイムが「予算」として許容される。 この内なら新機能リリースを積極的に行い、予算を超えそうなら信頼性向上を優先する、というバランス 感覚が重要です。 ➢ トイル（Toil）の削減 手動での繰り返し作業を「トイル」と呼び、これを自動化で削減することに力を入れます。「夜中にアラート で起こされる」ような運用から脱却することを目指します。 22

オブザーバビリティ が SRE を支える理由 SLI の測定に必須 ➢ SLI（例：可用性99.9%、レイテンシ95%<200ms）を数値化 するには Logs / Metrics / Traces などのテレメトリが必要 SLO の達成度確認に活用 オブザーバビ リティなしに SREなし！ ➢ 「SLOを守れているか？」を可視化し、違反リスクを早期に発見 エラーバジェットの運用 ➢ SLOを満たせなかった期間を「エラーバジェット」として管理 → 開発スピードと安定性のバランス調整に利用 インシデント対応 ➢ オブザーバビリティ があることで、根本原因分析（RCA）が迅速 にできる 23

クイズ  オブザーバビリティの定義として正しいものはどれか？ 1. 2. 3. 4. 5. システムを監視しCPUが高いかどうかを見るための仕組み 監視対象を自動修復する仕組み 監視対象をサーバーのみにフォーカスした考え方 セキュリティアラートのみを対象とする仕組み システム内部の状態を外部から得られるデータ（テレメトリ）を通じて理解する性質 24

クイズ  オブザーバビリティのメリットとして正しいものはどれか？ 1. 監視アラートをすべて無効化できる 2. 因果関係の把握や根本原因分析、将来の障害予測につながる 3. すべての障害を事前に99%以上防止できる 4. 監視対象を必ずサーバーのみに絞り込める 5. 通知をメール以外に制限できる 25

クイズ  次のうち、Logs / Metrics / Traces / シグナル / テレメトリ について 誤って説明しているものはどれか？ 1. Logs: アプリケーションやシステムのイベント・エラー情報をテキスト形式で記録 2. Metrics: CPUやメモリ使用率など、数値データを時系列で収集・保存 3. Traces: マイクロサービス間のリクエストフローを追跡し、分散システムの処理経路を可視化 1. 2. テレメトリ: 監視対象システムから自動収集される全ての観測データの総称 2. シグナル: テレメトリの中でも特定の意味を持つ構造化されたデータ （Logs/Metrics/Traces など） 3. Metrics: システムの状態を数値で表現し、時系列で保存される定量的データ 1. 3. Traces: 分散システムでのリクエスト追跡に使用される重要なデータ 2. シグナル: 監視システムにおけるアラート通知機能の総称 3. テレメトリ: システムから自動収集されるデータだが、主にダッシュボード表示に特化した形式 1. 26

Appendix: Azure における監視・オブザーバビリティ 27

Azure におけるオブザーバビリティ概要 Azure Monitor： 全体の監視プラットフォーム（メトリック/ログ収集、アラート、ワークブック） ログ Log Analytics メトリック Azure Monitor Metrics  KQLによるログ分析  標準リソースメトリクス Container Insights Managed Prometheus  K8sのログ/メトリクス収集  Kubernetesネイティブメトリック収集  Prometheus互換の完全マネージドサービス VM Insights  VMのパフォーマンス＋依存関係ログ/メトリクス ダッシュボード Azure Workbooks トレース Application Insights  インタラクティブなカスタムレポート  パラメータ化による動的ダッシュボード  分散トレーシングでマイクロサービス間の処理フロー可視化  エンドツーエンドのリクエスト追跡 /ボトルネック自動検出 Azure Managed Grafana  高度な可視化・豊富なテンプレート,プロフェッショナルな見た目  データ相関分析: 異なるシステムのメトリックを関連付けて表示  Prometheus / Azure Monitor 統合表示 これらの組合せで 「最新トレンドのオブザーバビリティ」 を Azure 上で実現 28

Azure Monitor における AIOps Azure Monitor にも AI を駆使した機能が実装されつつある 例） ➢ アプリケーション マップのインテリジェントビュー: サービス間の依存関係をマッピングし、パフォーマンスのボトルネックや障害のホットスポットを特定。 ➢ スマート検出（Smart Detection） Application Insights がアプリのパフォーマンスを監視し、通常と異なる遅延や失敗率を自動検出 ➢ アラートの動的しきい値（Dynamic Thresholds） 固定値ではなく、AIが適切な値を設定 ➢ インシデントの相関分析(Azure Monitor の問題と調査 ) バラバラに出るアラートをまとめて、「根本的な原因はこれかも」と関連づけてくれる ➢ VMSS予測自動スケーリング 過去の使用率パターンに基づいてCPU要件を予測し自動的にスケールアウト Azure Monitor での AIOps と機械学習 - Azure Monitor | Microsoft Learn Azure Application Insights のアプリケーション マップ - Azure Monitor | Microsoft Learn Application Insights のスマート検出 - Azure Monitor | Microsoft Learn Azure Monitor issues and investigations (preview) 29

• https://learn.microsoft.com/ja-jp/azure/azure-monitor/aiops/aiops-machine-learning
• https://learn.microsoft.com/en-us/azure/azure-monitor/aiops/aiops-issue-and-investigation-overview
• https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/app-map?tabs=net
• https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/proactive-diagnostics

余談）生成 AI アプリケーションを監視したい  Azure AI Foundry Observability ってものがあります！ Generative AI アプリケーションを監視する - Azure AI Foundry | Microsoft Learn Microsoft も Opentelemetry に結構コントリビュート！ Application Insights × Opentelemetry が今後熱そう！ 30

• https://learn.microsoft.com/ja-jp/azure/ai-foundry/how-to/monitor-applications

参考  【Azure のアラート設計ベースライン】Azure Monitor Baseline Alerts の紹介  Azure Monitor と Prometheus の概要 - Azure Monitor | Microsoft Learn  Azure Workbooks の概要 - Azure Monitor | Microsoft Learn  Azure Monitor での AIOps と機械学習 - Azure Monitor | Microsoft Learn  Generative AI アプリケーションを監視する - Azure AI Foundry | Microsoft Learn 31

• https://zenn.dev/microsoft/articles/introduce-amba
• https://learn.microsoft.com/ja-jp/azure/azure-monitor/metrics/prometheus-metrics-overview
• https://learn.microsoft.com/ja-jp/azure/azure-monitor/visualize/workbooks-overview
• https://learn.microsoft.com/ja-jp/azure/azure-monitor/aiops/aiops-machine-learning
• https://learn.microsoft.com/ja-jp/azure/ai-foundry/how-to/monitor-applications

監視とオブザーバビ リティの違いって？ シグナル？ アラート発報的 なやつやろ！ そもそもメトリック とログってなんやね ん？ メトリックとログっ て？あとテレメト リってなんやねん？ Azure Monitor って Zabbix みたいなや つやろ！しらんけど 32