クラウド監視ガイド: 適切なデータの収集Cloud monitoring guide: Collect the right data

この記事では、クラウド アプリケーションで監視データを収集する際の考慮事項について説明します。This article describes some considerations for collecting monitoring data in a cloud application.

クラウド ソリューションの正常性と可用性を監視するには、予測可能な障害状態に基づくシグナル レベルを収集するように監視ツールを構成する必要があります。To observe the health and availability of your cloud solution, you must configure the monitoring tools to collect a level of signals that are based on predictable failure states. これらのシグナルは、障害の原因ではなく、症状です。These signals are the symptoms of the failure, not the cause. 監視ツールでは、メトリックを使用します。また、高度な診断と根本原因分析のためには、ログを使用します。The monitoring tools use metrics and, for advanced diagnostics and root cause analysis, logs.

監視と移行を慎重に計画してください。Plan for monitoring and migration carefully. 計画フェーズで監視サービスの所有者、運用の管理者、その他の関係者を含めることから始めて、開発とリリースのサイクルを通して継続的に全員を関与させます。Start by including the monitoring service owner, the manager of operations, and other related personnel during the Plan phase, and continue engaging them throughout the development and release cycle. その焦点は、次の基準に基づいた監視構成を開発することです。Their focus will be to develop a monitoring configuration that's based on the following criteria:

  • サービスの構成はどのようなものですか。What is the composition of the service? それらの依存関係は現在監視されていますか。Are those dependencies monitored today? そうである場合、複数のツールが関与していますか。If so, are there multiple tools involved? リスクを生じさせずに統合できる可能性はありますか。Is there an opportunity to consolidate, without introducing risks?
  • そのサービスの SLA はどのようなものですか。また、測定とレポートはどのように行いますか。What is the SLA of the service, and how will I measure and report it?
  • インシデントが発生したときに、サービス ダッシュボードにはどのように表示しますか。What should the service dashboard look like when an incident is raised? サービス所有者、またサービスをサポートするチームにとって、ダッシュボードはどのような外観であるべきですか。What should the dashboard look like for the service owner, and for the team that supports the service?
  • リソースから生成されるメトリックのうち、監視する必要があるものは何ですか。What metrics does the resource produce that I need to monitor?
  • サービス所有者、サポート チーム、その他の担当者はどのような方法でログを検索しますか。How will the service owner, support teams, and other personnel be searching the logs?

これらの質問への回答や、アラートの条件に基づいて、監視プラットフォームの使用方法が決まります。How you answer those questions, and the criteria for alerting, determines how you'll use the monitoring platform. 既存の監視プラットフォームまたは一連の監視ツールから移行する場合は、収集するシグナルを再評価する機会として移行を使用してください。If you're migrating from an existing monitoring platform or set of monitoring tools, use the migration as an opportunity to reevaluate the signals you collect. Azure Monitor のようなクラウドベースの監視プラットフォームを移行または統合する際に考慮すべきコスト要因がいくつかあるため、このことが特に当てはまります。This is especially true now that there are several cost factors to consider when you migrate or integrate with a cloud-based monitoring platform like Azure Monitor. 監視データはアクションにつながるものでなければならないことに注意してください。Remember, monitoring data needs to be actionable. サービスの正常性の全体像がわかる "10,000 フィートからの眺め" を提供するために収集された、最適化されたデータが必要です。You need to have optimized data collected to give you "a 10,000 foot view" of the overall health of the service. 実際のインシデントを特定するために定義されるインストルメンテーションは、可能な限り単純さ、予測可能性、信頼性の高いものにします。The instrumentation that's defined to identify real incidents should be as simple, predictable, and reliable as possible.

監視構成を開発するDevelop a monitoring configuration

監視サービスの所有者とチームは、通常、監視構成を策定するために、一般的な一連の活動を行います。The monitoring service owner and team typically follow a common set of activities to develop a monitoring configuration. これらの活動は、初期の計画段階から開始され、非運用環境でのテストと検証の間も継続し、運用環境へのデプロイへと続きます。These activities start at the initial planning stages, continue through testing and validating in a nonproduction environment, and extend to deploying into production. 監視構成は、既知の障害モード、シミュレートされた障害のテスト結果、および組織内の複数の担当者 (サービス デスク、運用担当者、エンジニア、開発者など) の経験から導き出されます。Monitoring configurations are derived from known failure modes, test results of simulated failures, and the experience of several people in the organization (the service desk, operations, engineers, and developers). このような構成では、サービスが既に存在し、クラウドに移行され、再設計されていないことが前提とされています。Such configurations assume that the service already exists, it's being migrated to the cloud, and it hasn't been rearchitected.

サービスレベルの品質結果を得るために、開発プロセスの早い段階でこれらのサービスの正常性と可用性を監視してください。For service-level quality results, monitor the health and availability of these services early in the development process. そのサービスまたはアプリケーションの設計を後付けで監視しても、良い結果は得られません。If you monitor the design of that service or application as an afterthought, your results won't be as successful.

インシデントをより迅速に解決するには、次の推奨事項を考慮してください。To drive quicker resolution of the incident, consider the following recommendations:

  • サービス コンポーネントごとにダッシュボードを定義します。Define a dashboard for each service component.
  • 根本原因を明らかにできない場合は、メトリックを使用して詳細な診断を導き出し、問題の解決策または回避策を特定します。Use metrics to help guide further diagnosis and to identify a resolution or workaround of the issue if a root cause can't be uncovered.
  • ダッシュボードのドリルダウン機能を使用するか、ビューのカスタマイズをサポートして調整します。Use dashboard drill-down capabilities, or support customizing the view to refine it.
  • 詳細ログが必要な場合は、メトリックが検索基準のターゲット設定に役立つはずです。If you need verbose logs, metrics should have helped target the search criteria. メトリックが役に立たなかった場合は、次のインシデントのために改善します。If the metrics didn't help, improve them for the next incident.

この指針となる一連の原則を利用することで、ほぼリアルタイムの分析情報が得られ、適切にサービスを管理できるようになります。Embracing this guiding set of principles can help give you near-real-time insights, as well as better management of your service.

次のステップNext steps