このAzure Well-Architectedフレームワークのオペレーショナル エクセレンスチェックリストの推奨事項への適用:
| OE:07 | ワークロードのインフラストラクチャとコードから運用テレメトリ、メトリック、ログをキャプチャして、設計上の決定を検証し、将来の改善を導く監視スタックを設計します。 |
|---|
可観測性 (監視) は、ワークロード チームが生成する外部データに基づいてシステムの内部状態を理解できるようにする重要な運用手法です。 ビジネス ロジックとコア機能を実装する機能スタックとは異なり、監視スタックは並列で実行されます。 実際の条件下でのワークロードの動作を示すメトリック、ログ、トレース、イベントを収集して分析します。
監視スタックを設計するには、信頼性、パフォーマンス、セキュリティ、コストなどの横断的な問題を可視化できるため、慎重な計画が必要です。 適切に設計された監視スタックにより、早期の問題検出、効果的なインシデント対応、および情報に基づく運用上の意思決定が可能になります。 プロアクティブな管理と継続的な改善の基盤となります。
このガイドでは、監視、検出、およびアラート機能をサポートする監視スタックを設計するための主要な戦略について説明します。 ステップごとのプロセスやプレイブックを含む実装ガイダンスについては、コンパニオン記事「Azure ワークロード用の監視システムを構築するを参照してください。
定義
| 期間 | 定義 |
|---|---|
| テレメトリ | ログ、メトリック、トレース、およびイベントの集合用語。 テレメトリは、可観測性の基礎を提供します。 |
| ログ | システムで何が起こったかをキャプチャする記録されたシステム イベント。 ログは、タイムスタンプ付きの構造化テキストまたは自由形式のテキストにすることができます。 これらは、異常を検出して調査するのに役立ちます。 |
| Metrics | システムのパフォーマンスを表す一定の間隔で収集される数値。 メトリックは、ワークロードのパフォーマンスと信頼性の傾向を特定するのに役立ちます。 |
| 可観測性 | チームが問題を検出し、パフォーマンスの傾向を追跡し、運用上の意思決定を行うのに役立つプラクティス。 |
| 関連付け ID | 分散システムでのトランザクションのエンドツーエンドのトレースを有効にするために、複数のコンポーネント間で関連するイベントを追跡する一意の識別子。 |
| インストルメンテーション | テレメトリをキャプチャするための監視機能をアプリケーションとインフラストラクチャに追加する。 キャプチャされたテレメトリには、ログ記録、メトリック収集、トレースが含まれます。 |
| ヘルスモデル | ビジネス目標と運用目標を反映するインジケーター、KPI、メトリックを使用してワークロードの正常性を測定するためのフレームワーク。 |
| 主要業績評価指標 (KPI) | ワークロードがビジネス目標と運用目標を達成する効果を示す測定可能な値。 KPI は、テレメトリの収集と分析をガイドします。 |
| アプリケーション パフォーマンス管理 (APM) | アプリケーションのパフォーマンス、可用性、ユーザー エクスペリエンスを監視するためのツールとプラクティス。 APM ツールを使用すると、重要なメトリックをリアルタイムで履歴に可視化できます。 |
| Traces | 分散システムを介した要求のパスを示すレコード。 トレースは、複数のサービスにまたがる問題の診断に役立ちます。 |
テレメトリを正常性モデルと KPI モデルに合わせる
テレメトリ収集戦略にこれらのターゲットが反映されるように、ワークロードの正常性インジケーター、KPI、パフォーマンス メトリックを定義します。 これらのインジケーターを追跡して異常を検出し、是正措置を決定できるようにします。
テレメトリをシステム フローとユーザー フローに関連付け、それらのフローを正常性モデルのエンティティとしてモデル化します。 このアプローチでは、アプリケーション レベルの正常性がリソース レベルのシグナルと全体的なワークロードの正常性に接続されるため、ビジネスへの影響が見えるレベルで依存関係の表面が低下します。
AI の機会: チームは、KPI とテレメトリを手動で定義するのに時間を費やします。 AI 支援ツールは、アーキテクチャ、サービスの依存関係、コードに基づいて、よく使用されるテレメトリを提案できます。 GitHub Copilotや Claude Code などのツールは、インストルメンテーションの追加や、コードとしてのクエリまたはインフラストラクチャ (IaC) テンプレートの生成にも役立ちます。 人間による監視を含め、AI 主導の可観測性が正確で標準に準拠していることを確認します。
ワークロード コンポーネントからテレメトリを出力する
アプリケーション、インフラストラクチャ、運用から意味のあるシグナルをキャプチャします。 重要な例外を十分な詳細でログに記録しますが、詳細度を調整してノイズを制御できるようにします。
データがクエリ可能で検索可能になるように、構造化テレメトリを優先します。 一貫性のあるスキーマを使用し、ソース コンポーネントやタイムスタンプなどのコンテキスト情報を含めます。 これにより、イベントをより正確に分析し、ユーザー要求との相関関係を明確にできるため、一貫性を確保します。 これを実現するには、システム全体で情報をキャプチャする方法を標準化する構成可能なログ記録フレームワークを採用します。
トレードオフ: デバッグと追跡可能性を向上させるためにログの詳細を増やしますが、ストレージと処理のコストが高いことを認識してください。 このトレードオフを管理するには、開発時に詳細なログ記録を使用し、運用環境では詳細度を低下させ、相関関係 ID を使用して、過剰なログ ボリュームなしでエンドツーエンドのトランザクションの可視性を維持します。
監査、セキュリティ、デバッグ、パフォーマンスなどの運用上の問題によってテレメトリを分類し、フィルター処理を簡素化し、適切なアクセス制御を適用する方法があります。 ワークロード データがテレメトリと混在していないことを確認します。 診断に十分なコンテキストを保持しながら、ログ記録の前に機密性の高いシステムまたはユーザー情報をスクラブします。
インストルメンテーション プラクティスが運用上安全であることを確認します。 重要な監査のケースを除き、ログ記録は「ファイア アンド フォーゲット」できるものでなければならず、業務の運用を妨げはなりません。 インストルメンテーションを拡張し、特定のバックエンドから切り離し、テレメトリの障害がアプリケーションの障害に連鎖しないようにします。
インストルメンテーションを反復的な規範として扱います。 システムの進化に合わせて、テレメトリを定期的に確認して調整し、明確さ、関連性、パフォーマンスを維持します。
注
アプリケーション プロファイリングは、実行中のアプリケーションが CPU、メモリ、ディスク I/O、ネットワークなどのシステム リソースを使用する方法を分析するもう 1 つの方法です。 プロファイラーは (開発中または運用環境で) アプリケーションにアタッチし、詳細なランタイム データを収集します。 完全プロファイリングとサンプル ベースの 2 つの方法があります。 完全プロファイルはより正確ですが、大きな負担を増やし、システムの速度を低下させることができます。 n 秒ごとに 1 回、n 個の要求ごとに 1 回など、時間に基づいてデータが収集されるサンプル ベースのデータを選択します。 イベントが頻繁に発生する場合は、サンプリングを使用してオーバーヘッドを削減します。 イベントがまれな場合は、より完全なプロファイリングを使用して見逃さないようにします。
ワークロード全体でテレメトリを収集する
テレメトリ システムでは、2 つの基本的なコレクション モデルが使用されます。 プル モデルでは、コンポーネントはターゲット システムにクエリを実行してテレメトリを収集します。 プッシュ モデルでは、コンポーネントはデータを外部に送信するとテレメトリを出力します。 ワークロードに適用される要因に基づいてモデルを選択します。 たとえば、定期的なスナップショットで十分ですか、それともほぼリアルタイムのデータが必要ですか? 予想されるテレメトリ ボリュームは何ですか? 状態ベースまたはログ、イベント、トレースのデータ型は何ですか?
一般的に、組み合わせたアプローチを使用します。 たとえば、監視エージェントはプル モデルを使用し、各アプリケーション インスタンスと共にローカルで実行して定期的にデータを収集し、共有ストレージに書き込むことができます。 同時に、アプリケーション テレメトリのプッシュ モデルを使用できます。各インスタンスは、イベントが発生したときにログ、トレース、メトリックをメッセージ キューまたはイベントストリームに出力します。
重要度に基づいてデータ転送に優先順位を付けます。 緊急度の低いデータはバッチで転送できますが、時間の機密情報は直ちに送信する必要があります。
データ統合の標準化
ローカル サイロからテレメトリを移動し、中央リポジトリに統合します (組織で義務付けられている場合)。 マルチリージョン ソリューションの場合は、最初にリージョンごとにデータを収集して格納してから、一元的に集計します。 ただし、ビジネスクリティカルなワークロードの場合は、データの自律ストレージをお勧めします。
分析、ダッシュボード、アラート、およびレポートのためにデータにアクセスできるように、一貫性のある形式と収集方法を使用します。 コンポーネントから手動で取得することは避けてください。オーバーヘッドと不整合が発生するためです。
データ統合サービスを使用して、次の処理を行います。
- データの重複除去。
- 関連付け ID を使用して関連イベントをマージします。
- 不要な情報をフィルター処理します。
リスク: リージョンおよび一元化されたデータ ストアを使用することにはコストの影響があることに注意してください。
使用パターンに合わせてストレージとリテンション期間を調整する
主にクエリのニーズとアクセス パターンに基づいてストレージ ソリューションを選択します。 たとえば、アラートを生成するデータにすばやくアクセスする必要があるため、高速データ ストレージに保持し、クエリを最適化するためにインデックスを作成または構造化する必要があります。
ポリグロット永続化を使用して、使用に適したテクノロジにさまざまなデータ型を格納します。
- パフォーマンス カウンター用の SQL データベース
- Azure Monitor のログ、またはトレース ログ用の Azure Data Explorer
- セキュリティ情報のための Hadoop 分散ファイル システム (HDFS)
また、環境ごとにデータ ストレージを分離します。 この分離により、重要でない環境データが運用環境の監視を複雑にするのを防ぐことができます。
データの使用方法に基づいてリテンション期間を計画します。 短期的な分析とデバッグのために高解像度データを保持し、長期的な傾向のために低解像度の集計を保持します。 古いデータやアクセス頻度の低いデータをより安価なストレージに移動し、最新のデータをより高速なシステムに保持して迅速な分析を行います。 これにより、パフォーマンスとコストのバランスが取られます。 必要に応じて不要なストレージ オーバーヘッドなしでデータを使用できるように、運用上のニーズとコンプライアンス要件に合わせて保持期間を設定します。
監視データは、他の重要なデータと同様に扱います。 適切な保護 (アクセス制御、論理的な削除、偶発的な変更からの保護) を適用します。
エンドツーエンドの分析情報のデータを関連付ける
すべてのコンポーネントのメトリック、ログ、トレースからのテレメトリを接続するための可観測性を設計します。 この設計により、複数のレベルにまたがる問題を診断するのに役立つ、サービス間での操作の分散トレースが可能になります。
関連付け ID を一貫して使用して、プレゼンテーション層、中間層、データ層を通じてトランザクションを追跡します。
アプリケーション レベルとリソース レベルのログを集計して、トラブルシューティングを向上させ、問題の検出を高速化します。 Azure Log Analyticsなどの統合ソリューションを検討して、レベル間でデータのクエリと分析を行います。
テレメトリをシステム フローとユーザー フローに合わせて調整し、フローの正常性とワークロードの全体的な正常性を関連付けます。 これらのフローを理解すると、監視戦略でコンポーネント レベルとエンド ツー エンドの両方のシステム動作が確実に反映されます。
分析と視覚化を行って、実行可能な意思決定をサポートする
運用正常性モデルに関するダッシュボードとレポートを設計します。 視覚化を使用すると、チームは問題をすばやく特定し、傾向を理解し、応答に優先順位を付けられます。
正常性モデルは、テレメトリと運用上の決定の間のセマンティック レイヤーを提供します。 メトリックベースのダッシュボードではなく、ワークロード レベルの正常性から個々のリソースにドリルダウンする正常性状態を視覚化します。 Azure Monitor正常性モデルを利用して、エンティティ階層全体の正常性状態の組み込みの視覚化と、正常性データを Grafana などのツールに統合するための API アクセスを取得します。
カスタム実装やアドホック ソリューションではなく、実績のある監視パターンとアーキテクチャを使用します。 ダッシュボードが意味があり、実用的であることを確認します。 アナリストは、パラメーター化されたダッシュボードを使用して、基になるデータを探索できます。
データベース ワークロードの場合は、クラウド サービスが提供する組み込みの監視ダッシュボードを評価します。 たとえば、Azure Database for PostgreSQL 組み込みの Grafana ダッシュボードをAzure ポータルでAzure Monitor統合して提供します。 これらのダッシュボードには、CPU 使用率、ストレージ、アクティブな接続、クエリ スループットとログの相関関係が表示されるため、個別の監視デプロイの必要性が軽減されます。
意味のある運用条件に関するアラートを定義する
任意の値ではなく、ワークロードの正常性に基づいてアラートを設定します。 アラートはアクション可能で、コンテキストを提供する必要があります。 所有者、アクション、スコープを定義する明確で説明責任のあるアラート プロセスを確立します。 重大な問題が迅速に検出されるようにしながら、ノイズを最小限に抑えるために、適切な粒度と詳細度でアラートを構成します。
複数の相関シグナルを正常性状態に集約し、分離されたメトリックしきい値ではなく状態遷移に関するアラートを生成する正常性モデルを使用します。
過去のエクスペリエンスと定期的なテストに基づいてしきい値を検証します。 アラート生成データに高速ストレージを使用して、迅速な通知を有効にします。 明確に定義されたスコープのアラートを構成し、詳細度を調整してノイズを最小限に抑えます。
アラートを自動化し、アラートをチケット システムにリンクします。 クラウド プラットフォーム サービスの正常性、停止、メンテナンス、およびアドバイザリを監視します。
Azure SRE Agent などの AI を利用した運用ツールは、アラート パターンを分析し、ポッドのクラッシュ ループや高いエラー率などの一般的な問題を診断できます。 これらのツールは、推奨されるアクションから始まり、定義済みのガードレール内で自動応答を徐々に有効にして、構成可能な自律性をサポートします。
スケーラブルで永続的なテレメトリ パイプラインを設計する
監視システムでは、ボトルネックやデータ損失を伴わない高スケールの処理が必要です。 負荷の下でテレメトリ フローを維持するために、バッファリング、キュー、スケーラブルなインジェスト パスを含めます。
大規模な環境での負荷急増を処理するために、キューイングメカニズムを使用してください。 冗長性を実装して、重要なデータの損失を防ぎます。 ワークロードの需要に合わせて監視システムが拡大するように、設計時のスケーリングを計画します。
複雑なワークロードの場合は、 少なくとも 1 回 のセマンティクスでメッセージ キューを使用します。 大量のストレージを処理するために、複数のストレージ書き込みサービスを実行します。 Azure Event Hubsを使用してテレメトリ処理を分散し、単一ポイント I/O のボトルネックを防ぐことを検討してください。
可観測性を使用して継続的な改善をサポートする
可観測性をフィードバック ループとして扱います。 運用データを使用して、ワークロードの設計、テレメトリ キャプチャ、監視のしきい値を調整します。
自動化と人間の監視のバランスを取り、精度を確保します。 ワークロードの変化に伴い、監視アプローチを継続的に見直し、進化させます。 テレメトリを使用して最適化の機会を特定し、アーキテクチャの決定を検証し、将来の設計をガイドします。
全体的なワークロード テストに監視とアラートを含めます。 運用上の問題を予測し、容量を計画するための傾向を分析する機能を維持しながら、関数を自動化します。
アンチパターンに注意する
多くの監視エラーは、ツールの制限ではなく、アーキテクチャの選択が不十分な場合に発生します。
症状を修正するだけでなく、アンチパターンが出現した理由を分析し、基になる設計の弱点に対処します。 次に、明確なテレメトリ標準を使用しているか、ビジネスに合わせたメトリックに向かうか、コスト意識を高めるかに関係なく、軽減策を適用します。
コンパニオン実装ガイドの アンチパターンとその回避方法に関するセクションを参照することをお勧めします。
Azureファシリテーション
Azure Monitor は、クラウドおよびオンプレミス環境から監視データを収集、分析、および応答するための監視ソリューションです。
Azure Monitor正常性モデルは、メトリック、ログ、トレースをAzureのリソースとコンポーネント全体で実用的な正常性状態に関連付けることで、ワークロードの正常性を定義、測定、視覚化するのに役立ちます。
Log Analytics は、Azure ポータルのツールであり、Log Analytics ワークスペース内のデータに対するログ クエリを編集および実行するために使用できます。
複数のワークスペースを使用している場合は、ベスト プラクティスについては、Log Analytics ワークスペース architecture ガイドを参照してください。
Application Insights は、Azure Monitorの拡張機能です。 これには APM 機能があります。
Azure Monitor Insights は、特定のAzure テクノロジ (VM、アプリ サービス、コンテナーなど) 用の高度な分析ツールです。 これらのツールは、Azure MonitorとLog Analyticsの一部です。
sap ソリューションのAzure Monitor は、Azureで実行される SAP ランドスケープのAzure監視ツールです。
Azure Policy は、組織の標準を適用し、大規模なコンプライアンスを評価するのに役立ちます。
Azure Network Watcher は、セキュリティ、コンプライアンス、パフォーマンスを確保するために、ネットワークを監視、管理、監査するツールです。
Connection troubleshoot は、Network Watcherの診断ツールです。 接続の問題の調査に役立つオンデマンド診断とパケット キャプチャ (PCAP) を提供します。
Connection モニターは、Network Watcherの監視ツールです。 継続的な合成テストを実行し、接続とパフォーマンスの問題に関するリアルタイムアラートを送信します。
Traffic analytics は、Network Watcherのトラフィック分析ソリューションです。 トラフィックの分布を視覚化し、上位の話者を識別し、帯域幅使用率の傾向を明らかにします。 これらの機能は、ネットワーク正常性の統合ビューを提供します。
仮想ネットワーク フロー ログに、ネットワーク テレメトリを組織の SIEM にエクスポートするネイティブ Microsoft Sentinel コネクタが追加されました。 この統合により、ID およびエンドポイント信号と同じ分析プレーンにフロー データが取り込まれるので、セキュリティ調査中の相関関係が向上します。 インジェストをスケーリングする際に、ログのボリュームと分析のコストを管理します。
Azure Monitor のログ アラートでは、過去の動作に基づく動的なしきい値を使用できます。 それらを使用して、変化するベースライン間で異常検出をスケーリングしますが、季節的なパターンを検証し、応答者が予想されるアクションを認識していることを確認します。
Azure Functionsには、カスタムセットアップなしですぐに正常性ビューを提供する組み込みの Grafana ダッシュボードが含まれています。 これらを使用して初期の可視性を高速化しますが、SLO 主導のアラート、ダッシュボード、Runbook を定義します。
Azure Container Appsは、マネージド統合を通じて外部バックエンドに OpenTelemetry データをエクスポートできます。 テレメトリの分散を広げる前に、宛先を意図的に標準化し、ルーティング、保持、およびインジェストのコストを管理します。
関連リンク
コミュニティ リンク
- Azure Monitor Baseline Alerts (AMBA) は、顧客とパートナーがAzure Monitorの導入を通じて監視エクスペリエンスを向上させるために使用できるアラート定義の中央リポジトリです。
オペレーショナル エクセレンス チェックリスト
レコメンデーションの完全なセットを参照してください。