クラウド監視ガイド: アラートCloud monitoring guide: Alerting

何年もの間、IT 組織は、企業に展開された監視ツールから生成されるアラート疲れとの戦いに苦労してきました。For years, IT organizations have struggled to combat the alert fatigue that's created by the monitoring tools deployed in the enterprise. 多くのシステムからはアラートが大量に生成され、意味がないと考えられるものも多いのですが、関連性があるにもかかわらず見過ごされたり、無視されたりするアラートもあります。Many systems generate a high volume of alerts often considered meaningless, while other alerts are relevant but are either overlooked or ignored. その結果、IT と開発者の業務においては苦労して、社内や社外の顧客に約束したサービスレベル品質を満たしてきました。As a result, IT and developer operations have struggled to meet the service-level quality promised to internal or external customers. 信頼性を確保するためには、インフラストラクチャとアプリケーションの状態を理解することが不可欠です。To ensure reliability, it's essential to understand the state of your infrastructure and applications. サービスの低下や中断を最小限に抑える、インシデントの影響を軽減する、またはインシデント数を減らすには、原因をすばやく特定する必要があります。To minimize service degradation and disruption, or to decrease the effect of or reduce the number of incidents, you need to identify causes quickly.

適切なアラート戦略Successful alerting strategy

知らないものが壊れても直すことはできません。You can't fix what you don't know is broken.

重要なことについてアラートを発することが欠かせません。Alerting on what matters is critical. 適切なメトリックとログの収集と測定を行うことが、その土台となります。It's underpinned by collecting and measuring the right metrics and logs. また、格納、集計、視覚化、分析、および条件が満たされたときの自動応答の開始が可能な監視ツールが必要です。You also need a monitoring tool capable of storing, aggregating, visualizing, analyzing, and initiating an automated response when conditions are met. サービスとアプリケーションの監視を改善できるのは、その構成を完全に理解している場合に限られます。You can improve the observability of your services and applications only if you fully understand its composition. その構成を、監視プラットフォームによって適用される詳細な監視構成にマップします。You map that composition into a detailed monitoring configuration to be applied by the monitoring platform. この構成には、アラートの対象とする意味がある、予測可能な障害状態 (障害の原因ではなく、現象) が含まれます。This configuration includes the predictable failure states (the symptoms, not the cause of the failure) that make sense to alert for.

ある症状がアラートの適切な候補であるかどうかを判断するには、以下の原則を考慮します。Consider the following principles for determining whether a symptom is an appropriate candidate for alerting:

  • 重要ですか。Does it matter? それは実際の問題の症状を示している問題ですか、それともアプリケーションの全体的正常性に影響している問題ですか。Is the issue symptomatic of a real problem or issue influencing the overall health of the application? たとえば、リソースでの CPU 使用率が高いかどうかは重要ですか。For example, do you care whether the CPU utilization is high on the resource? または、そのリソースの SQL データベース インスタンスで実行されている特定の SQL クエリの CPU 使用率が長時間にわたって高いかどうかが重要ですか。Or that a particular SQL query running on a SQL database instance on that resource is consuming high CPU utilization over a sustained period? CPU 使用率の状態は実際の問題であるため、それに対してアラートを発行する必要があります。Because the CPU utilization condition is a real issue, you should alert on it. しかし、チームに通知する必要はありません。そもそも何がその状態を引き起こしているかを知る助けにはならないためです。But you don't need to notify the team, because it doesn't help point to what is causing the condition in the first place. SQL クエリ プロセスの使用率の問題に関する警告と通知は、関連性があり、かつ実用的です。Alerting and notifying on the SQL query process utilization issue is both relevant and actionable.
  • 緊急ですか。Is it urgent? 問題が現実のもので、緊急の注意を必要としていますか。Is the issue real, and does it need urgent attention? もしそうであれば、担当チームにすぐに通知する必要があります。If so, the responsible team should be immediately notified.
  • 顧客は影響を受けますか。Are your customers affected? 問題の結果として、サービスまたはアプリケーションのユーザーは影響を受けますか。Are users of the service or application affected as a result of the issue?
  • 他の依存システムは影響を受けますか。Are other dependent systems affected? 相互に関係がある依存関係に起因するアラートのうち、異なるチームに通知が行われ、全チームが同じ問題に取り組むことを避けるために対応付けが可能なものはありますか。Are there alerts from dependencies that are interrelated, and that can possibly be correlated to avoid notifying different teams all working on the same problem?

監視構成を最初に開発しようとしているときに、これらの疑問に答えます。Ask these questions when you're initially developing a monitoring configuration. 前提条件は、非運用環境でテストおよび検証してから運用環境に展開します。Test and validate the assumptions in a nonproduction environment, and then deploy into production. 監視構成は、既知の障害モード、シミュレートされた障害のテスト結果、およびチームのさまざまなメンバーの経験から得られます。Monitoring configurations are derived from known failure modes, test results of simulated failures, and experience from different members of the team.

監視構成のリリース後は、何が機能していて何が機能していないかについて多くのことを突き止めることができます。After the release of your monitoring configuration, you can learn a lot about what's working and what's not. 量が多いアラート、監視では認識されていないがエンド ユーザーが気付いた問題、およびこの評価の一環として実行することが最善であった措置について考察してください。Consider high alert volume, issues unnoticed by monitoring but noticed by end users, and what were the best actions to have taken as part of this evaluation. 継続的監視を改善する進行中のプロセスの一環として、サービスの提供を改善するための実装に対する変更を特定します。Identify changes to implement to improve service delivery, as part of an ongoing, continuous monitoring improvement process. アラート ノイズやアラートが発生しない状況について評価するだけでなく、ワークロードの監視方法の有効性についても評価します。It's not just about evaluating alert noise or missed alerts, but also the effectiveness of how you're monitoring the workload. アラートのポリシー、プロセス、および改善が進んでいるかどうかを判断するための全体的訓練に関する有効性が、その対象です。It's about the effectiveness of your alert policies, process, and overall culture to determine whether you're improving.

System Center Operations Manager と Azure Monitor はどちらも、静的しきい値または動的しきい値に基づくアラートと、それらに基づいて設定されたアクションをサポートしています。Both System Center Operations Manager and Azure Monitor support alerts based on static or even dynamic thresholds and actions set up on top of them. 例として、メール、SMS、音声通話のアラートで簡単に通知を受け取れます。Examples include alerts for email, SMS, and voice calls for simple notifications. これらのサービスはどちらも IT Service Management (ITSM) 統合もサポートしており、インシデント レコードの作成の自動化と、適切なサポート チーム、または Webhook を使用するその他のアラート管理システムへのエスカレートを行います。Both of these services also support IT Service Management (ITSM) integration, to automate the creation of incident records and escalate to the correct support team, or any other alert management system that uses a webhook.

可能なときには、いくつかのサービスのいずれかを使用して回復操作を自動化できます。When possible, you can use any of several services to automate recovery actions. エラスティック ワークロードの場合は、System Center Orchestrator、Azure Automation、Azure Logic Apps、自動スケールが含まれます。These include System Center Orchestrator, Azure Automation, Azure Logic Apps, or autoscaling in the case of elastic workloads. 担当チームにアラートを通知することが最も一般的な操作ですが、是正措置を自動化することが適切な場合もあります。While notifying the responsible teams is the most common action for alerting, automating corrective actions might also be appropriate. この自動化は、インシデント管理プロセス全体の合理化に役立ちます。This automation can help streamline the entire incident management process. これらの回復タスクを自動化すると、人的エラーのリスクも軽減できます。Automating these recovery tasks can also reduce the risk of human error.

Azure Monitor のアラートAzure Monitor alerting

Azure Monitor のみを使用している場合は、速度、コスト、およびストレージ容量について検討する際に、次のガイドラインに従ってください。If you're using Azure Monitor exclusively, follow these guidelines as you consider speed, cost, and storage volume.

使用している機能と構成に応じて、次の 6 つのリポジトリのいずれかに監視データを保存できます。Depending on the feature and configuration you're using, you can store monitoring data in any of six repositories:

  • Azure Monitor メトリック データベース: 主に Azure Monitor プラットフォームのメトリックに使用される時系列データベースですが、Application Insights メトリック データも反映されています。Azure Monitor metrics database: A time-series database used primarily for Azure Monitor platform metrics, but also has Application Insights metric data mirrored into it. このデータベースに入力される情報は、最も速いアラート時間です。Information entering this database has the fastest alert times.

  • Application Insights リソース: ほとんどの Application Insights テレメトリをログ形式で格納するデータベース。Application Insights resource: A database that stores most Application Insights telemetry in log form.

  • Azure Monitor Log Analytics ワークスペース: Azure ログデータのプライマリ ストア。Azure Monitor Log Analytics workspace: The primary store for Azure log data. その他のツールで、データをルーティングし、Azure Monitor ログで分析することができます。Other tools can route data to it and can be analyzed in Azure Monitor Logs. インジェストとインデックス作成のために、ログ アラート クエリの待機時間は長くなります。Because of ingestion and indexing, log alert queries have higher latency. この待機時間は通常 5 ~ 10 分ですが、状況によってはより長くなることがあります。This latency is generally 5-10 minutes, but can be higher under certain circumstances.

  • アクティビティ ログ: すべてのアクティビティ ログとサービス正常性イベントに使用されます。Activity log: Used for all activity log and service health events. 専用のアラートを使用できます。Dedicated alerting is possible. サブスクリプション内のオブジェクトの外側から見て、それらのオブジェクトで発生するサブスクリプション レベルのイベントを保持します。Holds subscription level events that occur on objects in your subscription, as seen from the outside of those objects. たとえば、ポリシーが設定されたり、リソースのアクセスや削除が行われたりしたときです。An example might be when a policy is set or a resource is accessed or deleted.

  • Azure Storage: Azure Diagnostics やその他の監視ツールでサポートされている汎用ストレージ。Azure Storage: General-purpose storage that's supported by Azure Diagnostics and other monitoring tools. これは、監視テレメトリの長期保持に適した低コストの選択肢です。It's a low-cost option for long-term retention of monitoring telemetry. このサービスに保存されているデータからのアラートはサポートされていません。Alerting isn't supported from data that's stored in this service.

  • Event Hubs: 一般に、オンプレミスまたは他のパートナーの監視または ITSM ツールにデータをストリーミングするために使用されます。Event Hubs: Generally used to stream data into on-premises or other partners' monitoring or ITSM tools.

Azure Monitor には 4 種類のアラートがあり、それぞれ、データが保存されているリポジトリとある程度関連性があります。Azure Monitor has four types of alerts, each somewhat tied to the repository that the data is stored in:

  • メトリック アラート:Azure Monitor のメトリック データに関するアラート。Metric alert: Alerts on metric data in Azure Monitor. アラートは、監視対象の値がユーザー定義のしきい値を超えたとき、そしてその後、値が "通常" 状態に戻るときに発生します。Alerts occur when a monitored value crosses a user-defined threshold, and then again when it returns to "normal" state.

  • ログ クエリ アラート:Application Insights または Azure Monitor ログのログ データに関するアラートに使用できます。Log query alert: Available to alert on log data from Application Insights or Azure Monitor Logs. クロスワークスペース クエリに基づいて警告することもできます。It can also alert based on cross-workspace queries.

  • アクティビティ ログ アラート:Azure Service Health データを除く、アクティビティ ログ内の項目に関するアラート。Activity log alert: Alerts on items in the activity log, with the exception of Azure Service Health data.

  • Azure Service Health アラート:停止や予定されている計画メンテナンスなど、アクティビティ ログからの Azure Service Health の問題に対してのみ使用される特別な種類のアラートです。Azure Service Health alert: A special type of alert that's used only for Azure Service Health issues that come from the activity log, such as outages and upcoming planned maintenance. この種類のアラートは、Azure Monitor するコンパニオン サービスである Azure Service Health を使用して構成されることに注意してください。Note that this type of alert is configured through Azure Service Health, a companion service to Azure Monitor.

パートナー ツールによるアラートを有効にするEnable alerting through partner tools

外部のアラート ソリューションを使用する予定の場合は、できるだけ多くのアラートを Azure Event Hubs 経由でルーティングします。これは、Azure Monitor から出る最速のパスです。If you're using an external alerting solution, route as much as you can through Azure Event Hubs, which is the fastest path out of Azure Monitor. Event Hub へのインジェスト料金を支払う必要があります。You'll have to pay for ingestion into Event Hub. コストが問題で、速度はそうでない場合は、より低コストの代替策として Azure Storage を利用できます。If cost is an issue and speed isn't, you can use Azure Storage as a less expensive alternative. 監視ツールや ITSM ツールが Azure Storage を読み取ってデータを抽出できるようにするだけです。Just make sure that your monitoring or ITSM tools can read Azure Storage to extract the data.

Azure Monitor には、他の監視プラットフォームや、ServiceNow などの ITSM ソフトウェアとの統合のサポートが含まれています。Azure Monitor includes support for integrating with other monitoring platforms, and ITSM software such as ServiceNow. Azure のアラートを使用しても、インシデント管理や DevOps プロセスの要件に従って、Azure の外部でアクションをトリガーできます。You can use Azure alerting and still trigger actions outside of Azure, as required by your incident management or DevOps process. Azure Monitor でアラートを出して応答を自動化する場合は、実際のシナリオと要件に基づいて Azure Functions、Azure Logic Apps、または Azure Automation を使用することで、自動化されたアクションを開始できます。If you want to alert in Azure Monitor and automate the response, you can initiate automated actions by using Azure Functions, Azure Logic Apps, or Azure Automation, based on your scenario and requirements.

特殊な Azure 監視オファリングSpecialized Azure monitoring offerings

管理ソリューションは一般に、データを Azure Monitor ログに格納します。Management solutions generally store their data Azure Monitor Logs. 2 つの例外は、Azure Monitor for VMs と Azure Monitor for Containers です。Two exceptions are Azure Monitor for VMs and Azure Monitor for containers. 次の表では、特定のデータ型とその格納場所に基づくアラートのエクスペリエンスについて説明します。The following table describes the alerting experience based on the particular data type and where it is stored.

解決策Solution データ型Data type アラート動作Alert behavior
コンテナーに対する Azure MonitorAzure Monitor for containers ノードとポッドの計算された平均パフォーマンス データは、メトリック データベースに書き込まれます。Calculated average performance data from nodes and pods are written to the metrics database. 一定期間にわたって集計される、使用量の測定済みパフォーマンスの変動に基づいてアラートを受け取る必要がある場合は、メトリック アラートを作成します。Create metric alerts if you want to be alerted based on variation of measured utilization performance, aggregated over time.
ノード、コントローラー、コンテナー、およびポッドからのパーセンタイルを使用する計算後のパフォーマンス データは、ワークスペースに書き込まれます。Calculated performance data that uses percentiles from nodes, controllers, containers, and pods are written to the workspace. コンテナー ログとインベントリ情報もワークスペースに書き込まれます。Container logs and inventory information are also written to the workspace. クラスターおよびコンテナーの測定済み使用量の変動に基づいてアラートを受け取る必要がある場合は、ログ クエリ アラートを作成します。Create log query alerts if you want to be alerted based on variation of measured utilization from clusters and containers. ログ クエリ アラートは、ポッドフェーズ数と状態ノード数に基づいて構成することもできます。Log query alerts can also be configured based on pod-phase counts and status node counts.
VM に対する Azure MonitorAzure Monitor for VMs 正常性基準は、メトリック データベースに格納されているメトリックです。Health criteria are metrics stored in the metrics database. 正常性状態が正常から異常に変化すると、アラートが生成されます。Alerts are generated when the health state changes from healthy to unhealthy. このアラートは、SMS またはメール通知を送信するように構成されたアクション グループのみをサポートします。This alert supports only Action Groups that are configured to send SMS or email notifications.
マップおよびゲスト オペレーティング システムのパフォーマンス ログ データは Log Analytics ワークスペースに書き込まれます。Map and guest operating system performance log data is written to the Log Analytics workspace. ログ クエリ アラートを作成します。Create log query alerts.

コストによる最高速度Fastest speed driven by cost

サービスに影響を与える問題のアラートと迅速な解決を促進する最も重要な決定の 1 つは待機時間です。Latency is one of the most critical decisions driving alerting and a quick resolution of issues affecting your service. 5 分未満でのほぼリアルタイムのアラートが必要な場合は、テレメトリに関するアラートが既定の保存場所にあるか、そこで取得できるかを最初に評価します。If you require near-real-time alerting under five minutes, evaluate first if you have or can get alerts on your telemetry where it is stored by default. 一般的に、使用中のツールは既にその場所にデータを送信しているため、この戦略は最もコストが低い選択肢でもあります。In general, this strategy is also the cheapest option, because the tool you're using is already sending its data to that location.

とは言え、この原則にはいくつかの重要な注意事項があります。That said, there are some important footnotes to this rule.

ゲスト OS テレメトリには、システムに取得するパスが複数あります。Guest OS telemetry has multiple paths to get into the system.

  • このデータに対してアラートを発する最速の方法は、それをカスタム メトリックとしてインポートすることです。The fastest way to alert on this data is to import it as custom metrics. これは、Azure Diagnostics 拡張機能を使用し、次にメトリック アラートを使用することで行います。Do this by using the Azure Diagnostics extension and then using a metric alert. ただし、カスタム メトリックは現在プレビュー段階であり、他の選択肢よりもコストが高くなりますHowever, custom metrics are currently in preview and are more expensive than other options.

  • 多少のインジェスト待機時間を伴うものの、最も安価なのは、Log Analytics ワークスペースに送信することです。The least expensive, but with some ingestion latency, is to send it to a Log Analytics workspace. VM 上で Log Analytics エージェントを実行することは、すべてのゲスト オペレーティング システムのメトリックとログ データをワークスペースに取り込む方法として最適です。Running the Log Analytics agent on the VM is the best way to get all guest operating system metric and log data into the workspace.

  • 診断の拡張機能と Log Analytics エージェントの両方を同じ VM 上で実行すると、Azure Monitor でそれをメトリックとログしてストレージに送信できます。You can send it for storage as a metric and a log in Azure Monitor by running both the Diagnostic extension and the Log Analytics agent on the same VM. その後はより迅速にアラートを送信できますが、ゲスト オペレーティング システムのデータは、他のテレメトリと組み合わせると、より複雑なクエリの一部としても使用することもできます。You can then alert quicker, but also use the guest operating system data as part of more complex queries when you combine it with other telemetry.

オンプレミスのデータのインポート: Azure とオンプレミスで実行されている複数のコンピューターにわたってクエリと監視を行おうとしている場合は、Log Analytics エージェントを使用してゲスト オペレーティング システムのデータを収集できます。Importing data from on-premises: If you're trying to query and monitor across machines running in Azure and on-premises, you can use the Log Analytics agent to collect guest operating system data. その後、Azure Monitor で "ログからメトリックへ" と呼ばれる機能を使用して、メトリックとして収集して保存できます。You can then use a feature called logs to metrics to collect and store as metrics in Azure Monitor. この方法によって、Azure Monitor ログへのインジェスト プロセスの一部がバイパスされるため、データがすぐに利用可能になります。This method bypasses part of the ingestion process into Azure Monitor Logs, and the data is thus available sooner.

アラートを最小限に抑えるMinimize alerts

Azure Monitor for VMs などのソリューションを使用していて、パフォーマンスの使用率を監視する既定の正常性基準を受け入れられる場合は、同じパフォーマンス カウンターに基づく重複するメトリックを作成したり、クエリ アラートをログに記録したりしないでください。If you use a solution such as Azure Monitor for VMs and find the default health criteria that monitors performance utilization acceptable, don't create overlapping metric or log query alerts based on the same performance counters.

Azure Monitor for VMs を使用していない場合は、以下の機能について検討することで、アラートの作成と通知の管理の仕事を簡単にします。If you aren't using Azure Monitor for VMs, make the job of creating alerts and managing notifications easier by exploring the following features:

注意

これらの機能は、メトリック アラート、つまり Azure Monitor のメトリック データベースに送信されるデータに基づくアラートにのみ適用されます。These features apply only to metric alerts, alerts based on data that's being sent to the Azure Monitor metric database. 他の種類のアラートには機能は適用されません。The features don't apply to the other types of alerts. 前述のように、メトリック アラートの主な目的は速度です。As mentioned previously, the primary objective of metric alerts is speed. 5 分未満でアラートを受け取ることが主な関心事でなければ、代わりにログ クエリ アラートを使用できます。If getting an alert in less than five minutes isn't of primary concern, you can use a log query alert instead.

  • 動的しきい値:動的しきい値では、一定期間にわたってリソースのアクティビティを調べ、"通常動作" と見なすしきい値の上限と下限を作成します。Dynamic thresholds: Dynamic thresholds look at the activity of the resource over a time period, and create upper and lower "normal behavior" thresholds. 監視対象のメトリックがこれらのしきい値の範囲外になると、アラートを受け取ります。When the metric being monitored falls outside of these thresholds, you get an alert.

  • マルチシグナル アラート:2 つの異なるリソースの種類からの 2 つの異なる入力の組み合わせを使用するメトリック アラートを作成できます。Multisignal alerts: You can create a metric alert that uses the combination of two different inputs from two different resource types. たとえば、VM の CPU 使用率が 90 パーセントを超え、その VM をフィードしている特定の Azure Service Bus キュー内のメッセージ数が一定量を超えたときにアラートを生成する場合は、ログ クエリを作成せずにそれを実行できます。For example, if you want to fire an alert when the CPU utilization of a VM is over 90 percent, and the number of messages in a certain Azure Service Bus queue feeding that VM exceeds a certain amount, you can do so without creating a log query. この機能は、2 つのシグナルに対してのみ機能します。This feature works for only two signals. より複雑なクエリがある場合は、メトリック データを Log Analytics ワークスペースにフィードして、ログ クエリを使用します。If you have a more complex query, feed your metric data into the Log Analytics workspace, and use a log query.

  • マルチソース アラート:Azure Monitor では、すべての VM リソースに適用される単一のメトリック アラート ルールを使用できます。Multiresource alerts: Azure Monitor allows a single metric alert rule that applies to all VM resources. VM ごとに個別のアラートを作成する必要がないため、この機能によって時間を節約できます。This feature can save you time because you don't need to create individual alerts for each VM. この種類のアラートのコストは同じです。Pricing for this type of alert is the same. 50 台の VM の CPU 使用率を監視するために 50 のアラートを作成する場合でも、50 台すべての VM の CPU 使用率を監視する 1 つのアラートを作成する場合でも、かかるコストは同じです。Whether you create 50 alerts for monitoring CPU utilization for 50 VMs, or one alert that monitors CPU utilization for all 50 VMs, it costs you the same amount. 動的しきい値と組み合わせてこれらの種類のアラートを使用することもできます。You can use these types of alerts in combination with dynamic thresholds as well.

これらの機能を併用すると、アラート通知と基になるアラートの管理を最小限に抑えることで時間を節約できます。Used together, these features can save time by minimizing alert notifications and the management of the underlying alerts.

アラートに関する限度Limits on alerts

作成できるアラート数の限度に注意してください。Be sure to note the limits on the number of alerts you can create. 一部の限度 (すべてではありません) は、サポートに連絡して高めることができます。Some limits (but not all of them) can be increased by calling support.

最適なクエリ エクスペリエンスBest query experience

すべてのデータにわたる傾向を探そうとしている場合は、既にデータが Application Insights にある場合を除き、すべてのデータを Azure ログにインポートすることが理にかなっています。If you're looking for trends across all your data, it makes sense to import all your data into Azure Logs, unless it's already in Application Insights. 両方のワークスペースにまたがるクエリを作成できるので、それらの間でデータを移動する必要はありません。You can create queries across both workspaces, so there's no need to move data between them. アクティビティ ログと Azure Service Health データを Log Analytics ワークスペースにインポートすることもできます。You can also import activity log and Azure Service Health data into your Log Analytics workspace. このインジェストとストレージに対して料金が発生しますが、分析とクエリのためにすべてのデータが 1 か所で取得されます。You pay for this ingestion and storage, but you get all your data in one place for analysis and querying. このアプローチにより、複雑なクエリ条件と、それらに対するアラートを生成できるようにもなります。This approach also gives you the ability to create complex query conditions and alert on them.