適切な監視データを収集する
クラウド ソリューションの正常性と可用性の監視は、システムで期待されるシグナルの理解を確立することに役立つので、収集する必要があるデータを決定できるようになります。
この記事は、クラウド監視ガイドのシリーズの一部です。
データ収集に関する考慮事項
監視構成の基準を確立するために、次の質問を自問してください。
サービス構成: サービスの構成はどうなっていますか? それらの依存関係は現在監視されていますか。 そうであり、複数のツールが含まれている場合、追加のリスクを持ち込むことなく統合を行える機会はありますか?
予測可能な失敗状態の定義: これらのシグナルは、"失敗" の原因ではなく、症状です。 監視ツールでは、高度な診断と根本原因分析のために、メトリックとログを使用します。
サービス SLA: サービスのサービス レベル アグリーメント (SLA) はどのようなものですか、また、それをどのように測定して報告しますか?
サービス ダッシュボードの設計: インシデントを確認する際の、サービス ダッシュボードはどのような外観にする必要がありますか? サービス所有者、サービスをサポートするチームなどのために、ダッシュボードはどのような外観であるべきですか。
リソース メトリック: 監視する必要があるソリューションによってどのようなリソース メトリックが生成されますか?
ログ検索: サービス所有者、サポート チーム、その他の職員はどのようにログを検索しますか?
利害関係者の関与: 計画フェーズ中に、監視サービスの所有者、IT 運用のマネージャー、その他の利害関係者を関与させます。 監視ソリューションの開発サイクルとリリース サイクル全体を通してこれらの人達を引き続き関与させます。
機密データ: オペレーターに公開したくないアプリケーションの収集を避けるべき機密データは何ですか。
これらの質問への回答や、アラートの条件に基づいて、監視プラットフォームの使用方法が決まります。
必要な監視シグナルを評価する
新しい監視ソリューションで新しいワークロードをデプロイする場合でも、既存の監視プラットフォームや一連の監視ツールから移行する場合でも、必要な監視シグナルを評価することが不可欠です。 必要なシグナルを慎重に設計することは、期待される結果をもたらすこととノイズの低減に役立ちます。
以下、具体例に沿って説明します。
- アクションにつながる: 監視データは、ノイズと誤検知を減らすためにアクションにつながるものである必要があります。
- 最適化: 収集されたデータを最適化して、サービスの全体的な正常性を総合的に把握します。
- インシデント インストルメンテーション: 実際のインシデントを特定するために定義されるインストルメンテーションは、可能な限り簡潔で、予測可能で、信頼性が高いものにする必要があります。
監視構成を開発する
通常、監視サービスの所有者とそのチームは、監視構成を作成するためにアクティビティの標準セットに従います。 これらのアクティビティは初期の計画段階、非運用環境でのテストと検証、運用環境へのデプロイを含むものです。
監視構成を開発するために、チームは既知の失敗モード、シミュレートされた失敗からのテスト結果、組織内のさまざまな個人 (サービス デスク、運用担当者、エンジニア、開発者など) の経験を頼りとします。
これらの構成は、サービスが既に存在し、クラウドへの移行中であり、再構築が行われていないという前提の下で設計されます。 サービス レベルの品質結果を確実に達成するには、開発プロセスの早い段階でこれらのサービスの正常性と可用性を監視することが不可欠です。 サービスまたはアプリケーションの設計の監視が後から行われるものと見なされる場合、結果的にあまり成功しない可能性が高くなります。
インシデントをより迅速に解決するには、次の推奨事項を考慮してください。
個別コンポーネントのダッシュボード: アプリケーションとインフラストラクチャの特定の領域の既知の問題のすべてをすばやく特定できるように、各サービス コンポーネントのダッシュボードを定義します。
メトリックの使用: さまざまなコンポーネントに組み込まれているメトリック シグナルを利用して、根本原因を特定できない場合の解決策や回避策の診断と特定に役立てます。
ダッシュボード カスタマイズの有効化: 監視ダッシュボードからデータまで簡単にドリル ダウンできるようにダッシュボードを設計します。 ビューの動的なカスタマイズをサポーターし、フィルター処理とトラブルシューティングを簡単に行えるようにしてください。
この指針となる一連の原則を利用することで、ほぼリアルタイムの分析情報が得られ、適切にサービスを管理できるようになります。