次の方法で共有


信頼性の高い監視およびアラート戦略を設計するための推奨事項

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

RE:10 ソリューションの正常性インジケーターを測定して公開します。 アップタイムやその他の信頼性データを、ワークロード全体だけでなく、個々のコンポーネントと主要なフローからも継続的に取り込みます。

このガイドでは、信頼性の高い監視およびアラート戦略を設計するための推奨事項について説明します。 この戦略を実装することで、運用チームに環境の正常性状態を常に通知し、ワークロードに対して確立された信頼性目標を確実に満たすようにします。

定義

相談 定義
メトリック 一定の間隔で収集される数値。 メトリックは、特定の時点におけるシステムの何らかの側面を表すものです。
リソース ログ システムによって生成されるデータ。 システムの状態に関する情報が提供されます。
トレース 要求がサービスとコンポーネントを経由するパスに関する情報を提供するデータ。

主要な設計戦略

監視およびアラート戦略を作成する前に、信頼性計画の一環としてワークロードに対して次のタスクを実行します。

ワークロードが確実に機能するように、監視およびアラート戦略を作成します。 運用チームがワークロードの状態の変化について通知を受け、問題に迅速に対処できるように、監視およびアラート戦略で認識を提供します。 重大なフローとこのような重大なフローが構成するコンポーネントの正常性モデルを作成することで、堅牢で信頼性の高い監視戦略を構築します。 正常性モデルでは、正常、低下、異常の各状態を定義します。 これらの状態の変化を即時にキャッチできるように運用体制を設計します。 正常性状態が正常から低下または異常に変化すると、アラート メカニズムによって自動修正措置がトリガーされ、適切なチームに通知されます。

ビジネスの要件を満たす監視およびアラート戦略を設計するには、次の推奨事項を実装します。

全体的な監視戦略を実装する

  • メトリックログトレースの違いを理解します。

  • すべてのクラウド リソースのログを有効にします。 デプロイにオートメーションとガバナンスを使用して、環境全体で診断ログを有効にします。

  • すべての診断ログを、Log Analytics ワークスペースなどの一元化されたデータ シンクおよび分析プラットフォームに転送します。 リージョンのデータ主権要件がある場合は、それらの要件の対象となるリージョンでローカル データ シンクを使用する必要があります。

トレードオフ: ログの保存とクエリにはコストがかかります。 ログの分析と保持が予算にどのような影響を与えるかに注目し、要件を満たす最適な使用バランスを決定します。 詳細については、「コスト最適化のためのベスト プラクティス」を参照してください。

  • ワークロードが 1 つ以上のコンプライアンス フレームワークの対象となる場合、機密情報を処理するコンポーネント ログの一部もそれらのフレームワークの対象になります。 関連するコンポーネント ログを、Microsoft Sentinel などのセキュリティ情報イベント管理 (SIEM) システムに送信します。

  • コンプライアンス フレームワークがワークロードに課す長期保有要件を組み込んだログ保持ポリシーを作成します。

  • すべてのログ メッセージに構造化ログを使用して、ログ データのクエリを最適化します。

  • 正常性モデルの状態変化 (緑から黄色または赤へなど) に関連する重要なしきい値を値が超えたときにトリガーされるようにアラートを構成します。

    しきい値の構成は、継続的な改善のプラクティスです。 ワークロードが進化するにつれて、定義したしきい値も変わる可能性があります。 場合によっては、動的しきい値が監視戦略に適したオプションとなります。

  • アラートは、状態が改善したとき (赤から黄色、または赤から緑など) に使用することを検討してください。こうすることで、運用チームは将来の参考のためにこれらのイベントを追跡できます。

  • 環境のリアルタイムの正常性を視覚化します。

  • インシデント時に収集されたデータを使用して、正常性モデリングと監視およびアラート戦略を継続的に改善します。

  • 次のようなクラウド プラットフォームの監視およびアラート サービスを組み込みます。

  • Azure Monitor の分析ツールなど、クラウド プロバイダーが提供する専用の高度な監視と分析を組み込みます。

  • バックアップと回復の監視を実装して、以下を取り込みます。

    • ターゲットとする回復ポイントの目標 (RPO) 内でワークロードが確実に回復できるようにするためのデータ レプリケーション状態。

    • バックアップと回復の成功と失敗。

    • ディザスター リカバリー計画に必要な復旧期間。

アプリケーションの監視

  • 正常性プローブまたはチェック機能を作成し、アプリケーションの外部から定期的にそれらを実行します。 顧客に地理的に近い複数の場所からテストするようにします。

  • アプリケーションが運用環境で実行されている間のデータをログします。 運用状態での問題の原因を診断できるだけの十分な情報が必要です。

  • サービスの境界でイベントのログを記録します。 フローがサービス境界をまたがる関連付け ID を含めます。 トランザクション フローが複数のサービスを経由し、そのいずれかが失敗した場合、関連付け ID は、アプリケーション全体で要求を追跡し、トランザクションが失敗した理由を特定するのに役立ちます。

  • 非同期のログ記録を使用します。 同期ログ操作では、アプリケーションのコードがブロックされることがあり、その結果、ログが書き込まれると、バックアップが要求されます。 アプリケーションのログ記録の間に可用性を維持するには、非同期のログ記録を使います。

  • アプリケーションのログと監査を分けます。 一般に、監査レコードはコンプライアンスまたは法的要件のために保持され、完全なものである必要があります。 トランザクションが破棄されるのを避けるには、診断ログとは別に監査ログを維持します。

  • テレメトリの相関関係を使用して、エンドツーエンドのアプリケーションと重大なシステム フローを通じてトランザクションを確実にマップできるようにします。 このプロセスは、障害の根本原因分析 (RCA) を実行するために不可欠です。 正常性モデルを通知し、問題の検出と予測を行うには、プラットフォームレベルのメトリックとログ (CPU 使用率、ネットワーク受信、ネットワーク送信、ディスク操作数/秒) をアプリケーションから収集します。 このアプローチは、障害の一時的なものと非一時的なものを区別するのに役立ちます。

  • ホワイトボックス監視を使用して、セマンティック ログとメトリックでアプリケーションをインストルメント化します。 正常性モデルに通知し、問題の検出や予測を行うには、アプリケーションレベルのメトリックとログ (現在のメモリ消費量や要求の待機時間など) をアプリケーションから収集します。

  • ブラック ボックスの監視機能を使用して、プラットフォーム サービスと、結果として得られるカスタマー エクスペリエンスを測定します。 ブラックボックスの監視では、システムの内部構造に関する知識がなくても、外部から参照できるアプリケーションの動作をテストします。 顧客中心のサービスレベル インジケーター (SLI)、サービスレベル目標 (SLO)、サービスレベル アグリーメント (SLA) を測定する場合、このアプローチが一般的です。

Note

アプリケーション監視の詳細については、「正常性エンドポイントの監視パターン」を参照してください。

データとストレージを監視する

  • ストレージ コンテナーの可用性メトリックを監視します。 このメトリックが 100% を下回ると、書き込みが失敗したことを示します。 クラウド プロバイダーが負荷を管理しているときに、可用性の一時的な低下が発生することがあります。 可用性の傾向を追跡して、ワークロードに問題があるかどうかを判断します。

    場合によっては、ストレージ コンテナーの可用性メトリックの低下は、ストレージ コンテナーに関連付けられたコンピューティング レイヤーのボトルネックを示しています。

  • データベースを監視するメトリックは多数あります。 信頼性のコンテキストで、監視すべき重要なメトリックには次のようなものがあります。

    • クエリ実行時間

    • Timeouts

    • 待機時間

    • メモリ不足

    • Locks

Azure ファシリテーション

  • Azure Monitor は、クラウドとオンプレミスの環境からの監視データを収集し、分析し、それに対応するために使用される包括的な監視ソリューションです。

  • Log Analytics は、Azure portal のツールであり、Log Analytics ワークスペース内のデータに対するログ クエリの編集と実行に使用されます。

  • Application Insights は、Azure Monitor の拡張機能です。 アプリケーション パフォーマンス監視 (APM) 機能が用意されています。

  • Azure Monitor の分析情報は、仮想マシン、アプリケーション サービス、コンテナーなどの Azure サービスの監視に役立つ高度分析ツールです。 分析情報は、Azure Monitor と Log Analytics の上に構築されています。

  • Azure Monitor for SAP solutions は、Azure で実行している SAP ランドスケープ向けの Azure ネイティブの監視製品です。

  • Azure Policy は、組織の標準を適用し、コンプライアンスを大規模に評価するのに役立ちます。

  • Azure ビジネス継続性センターは、ビジネス継続性資産に関する分析情報を提供します。 事業継続とディザスター リカバリー (BCDR) のためのアプローチを適用する場合は、Azure ビジネス継続性センターを使用して、Azure とハイブリッド ワークロード全体にわたる事業継続保護の管理を一元化します。 Azure ビジネス継続性センターは、(バックアップまたはディザスター リカバリーによって) 適切な保護が不足しているリソースを特定し、是正措置を講じます。 このツールを使用すると、統合監視が容易になり、Azure Policy を通じてガバナンスと監査コンプライアンスを確立して、すべてに 1 か所から簡単にアクセスできるようになります。

  • 複数のワークスペースのベスト プラクティスについては、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。

実際の監視ソリューションの例については、Azure 上の Web アプリケーションの監視Azure Kubernetes Service クラスターのベースライン アーキテクチャに関する記事を参照してください。

  • Azure Monitor Baseline Alerts (AMBA) はアラート定義の中央のリポジトリです。お客様とパートナーはこれを使い、Azure Monitor の導入を通じて監視エクスペリエンスを向上させることができます。

信頼性チェックリスト

レコメンデーションの完全なセットを参照してください。