Azure Monitor アラートのベスト プラクティス
この記事では、Azure Monitor アラート、アラート処理ルール、およびアクション グループのアーキテクチャのベスト プラクティスについて説明します。 このガイダンスは、Azure Well-Architected Framework で説明されているアーキテクチャ エクセレンスの 5 つの柱に基づいています。
アラートと通知の詳細については、「Azure Monitor アラートの概要」を参照してください。 大規模なソリューションのアラートの詳細については、「大規模な警告」を参照してください。
信頼性
クラウドでは、障害が発生することを認識しています。 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。 Azure Monitor アラート ルール コンポーネントの障害を最小限に抑えるには、次の情報を使用します。
Azure Monitor アラートは、設計上の決定なしに高度な信頼性を提供します。 アラート データ損失の一時的な損失が発生する可能性がある条件は、多くの場合、他の Azure Monitor コンポーネントの機能によって軽減されます。
設計チェック リスト
- サービス正常性アラート ルールを構成する。
- リソース正常性アラート ルールを構成する。
- 大規模な通知を生成するアラート ルールのサービス制限を回避する。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| サービス正常性アラート ルールを構成する。 | サービス正常性アラートは、停止、サービス中断、計画メンテナンス、セキュリティ アドバイザリに関する通知を送信します。 「アラート ルールを作成または編集する」を参照してください。 |
| リソース正常性アラート ルールを構成する。 | Resource Health アラートでは、これらのリソースの正常性状態が変化すると、ほぼリアルタイムで通知できます。 「アラート ルールを作成または編集する」を参照してください。 |
| 大規模な通知を生成するアラート ルールのサービス制限を回避する。 | 大量の通知を送信するアラート ルールがある場合は、メールまたは SMS 通知の送信に使用するサービスのサービス制限に達する可能性があります。 プログラムによるアクションを構成するか、大規模な通知を処理する別の通知方法またはプロバイダーを選択します。 「通知のサービス制限」を参照してください。 |
セキュリティ
セキュリティは、あらゆるアーキテクチャの最も重要な側面の 1 つです。 Azure Monitor は、最小限の特権の原則と多層防御の両方を採用する機能を提供します。 Azure Monitor アラートのセキュリティを最大化するには、次の情報を使用します。
設計チェック リスト
- ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマー マネージド キーを使用します。
- アクセス許可を制御してマネージド ID を使用してセキュリティを強化する
- 構成特権を必要としないすべてのユーザー用の監視閲覧者ロールを割り当てる
- セキュリティで保護された Webhook アクションを使用する
- プライベート リンクを使用するアクション グループを使用する場合は、イベント ハブ アクションを使用します
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマー マネージド キーを使用します。 | Azure Monitor により、Microsoft マネージド キー (MMK) を使用して、すべてのデータおよび保存されたクエリが保存時に暗号化されるようになります。 独自の暗号化キーを必要とし、専用クラスターに十分なデータを収集する場合は、カスタマー マネージド キーを使用して、柔軟性とキーのライフサイクル制御を強化します。 Microsoft Sentinel を使用している場合は、「Microsoft Sentinel のカスタマー マネージド キーの設定」の考慮事項をよく理解しておいてください。 |
| ログ検索アラート ルールのアクセス許可を制御するには、ログ検索アラート ルールにマネージド ID を使います。 | サービス間の通信をセキュリティで保護するために使用されるシークレット、資格情報、証明書、キーの管理は、開発者にとって共通の課題です。 マネージド ID により、開発者はこれらの資格情報を管理する必要がなくなります。 ログ検索アラート ルールにマネージド ID を設定すると、アラート ルールの正確なアクセス許可を制御および把握できます。 いつでも、ルールのクエリ アクセス許可を表示し、マネージド ID に対するアクセス許可を直接追加または削除できます。 さらに、ルールのクエリが Azure Data Explorer (ADX) または Azure Resource Graph (ARG) にアクセスしている場合は、マネージド ID を使用する必要があります。 マネージド ID に関するページを参照してください。 |
| 構成特権を必要としないすべてのユーザー用の監視閲覧者ロールを割り当てます。 | ユーザーにロールに必要な最小限の特権を付与することで、セキュリティを強化します。 「Azure Monitor でのロール、アクセス許可、セキュリティ」を参照してください。 |
| 可能な場合は、セキュリティで保護された Webhook アクションを使用します。 | アラート ルールに Webhook アクションを使用するアクション グループが含まれている場合は、セキュリティで保護された Webhook アクションを使用して追加の認証を行います。 「セキュリティで保護された Webhook の認証を構成する」を参照してください。 |
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法のことです。 さまざまな構成オプションと、収集するデータの量を減らす機会を理解することで、Azure Monitor のコストを大幅に削減できます。 「Azure Monitor のコストと使用量」を参照して、Azure Monitor が請求するさまざまな方法と、毎月の請求書を表示する方法を理解しておいてください。
注意
Azure Monitor のすべての機能にわたるコスト最適化の推奨事項については、「Azure Monitor でコストを最適化する」を参照してください。
設計チェック リスト
- アクティビティ ログ アラート、サービス正常性アラート、リソース正常性アラートは無料です。
- ログ検索アラートを使用する場合は、ログ検索アラートの頻度を最小限に抑えます。
- メトリック アラートを使用する場合は、監視するリソースの数を最小限に抑えます。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| アクティビティ ログ アラート、サービス正常性アラート、リソース正常性アラートは無料です。 | Azure Monitor アクティビティ アラート、サービス正常性アラート、リソース正常性アラートは無料です。 監視対象をこれらのアラートの種類で実現できる場合は、それらを使用します。 |
| ログ検索アラートを使用する場合は、ログ検索アラートの頻度を最小限に抑えます。 | ログ検索アラートを構成するときは、ルールの評価の頻度が高いほどコストが高くなることに注意してください。 それに応じてルールを構成します。 |
| メトリック アラートを使用する場合は、監視するリソースの数を最小限に抑えます。 | 一部のリソースの種類では、同じ種類の複数のリソースを監視できるメトリック アラート ルールがサポートされています。 これらのリソースの種類については、ルールによって多くのリソースが監視される場合、ルールのコストが高くなる場合があることに注意してください。 コストを削減するには、メトリック アラート ルールのスコープを減らすか、ログ検索アラート ルールを使用します。これは、多数のリソースを監視した場合にコストが低くなります。 |
オペレーショナルエクセレンス
オペレーショナル エクセレンスとは、運用環境でサービスを確実に実行するために必要な運用プロセスを指します。 Azure Monitor アラートをサポートするための運用要件を最小限に抑えるには、次の情報を使用します。
設計チェック リスト
- 必要に応じて、メトリック アラート ルールで動的しきい値を使用します。
- 可能な限り、1 つのアラート ルールを使用して複数のリソースを監視します。
- 大規模な動作を制御するには、アラート処理ルールを使用します。
- カスタム プロパティを活用して診断を強化する
- Logic Apps を活用してさまざまなシステムをカスタマイズ、強化、統合する
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| 必要に応じて、メトリック アラート ルールで動的しきい値を使用します。 | 動的しきい値は機械学習を使用して正しいしきい値を判断するため、構成する正しいしきい値を把握する必要はありません。 動的しきい値は、複数のリソースを監視するルールにも役立ちます。また、すべてのリソースに対して 1 つのしきい値を構成することはできません。 「メトリック アラートでの動的しきい値」を参照してください。 |
| 可能な限り、1 つのアラート ルールを使用して複数のリソースを監視します。 | 複数のリソースを監視するアラート ルールを使用すると、1 つのルールを管理して多数のリソースを監視できるため、管理オーバーヘッドが軽減されます。 |
| 大規模な動作を制御するには、アラート処理ルールを使用します。 | アラート処理ルールを使用して、作成および管理する必要があるアラート ルールの数を減らすことができます。 |
| カスタム プロパティを使用して診断を強化します。 | アラート ルールでアクション グループが使用される場合は、アラート通知ペイロードに含める独自のプロパティを追加できます。 これらのプロパティは、Webhook、Azure 関数、ロジック アプリのアクションなど、アクション グループによって呼び出されるアクションで使用できます。 |
| Logic Apps 使用して、通知ワークフローをカスタマイズし、さまざまなシステムと統合します。 | Azure Logic Apps を使用すると、統合のためにワークフローをビルドおよびカスタマイズできます。 Logic Apps を使用してアラート通知をカスタマイズします。 次のことを実行できます。 - 独自のメールの件名と本文の形式を使用して、アラート メールをカスタマイズします。 - 影響を受けるリソースのタグを検索するか、ログ クエリ検索結果をフェッチして、アラート メタデータをカスタマイズします。 Outlook、Microsoft Teams、Slack、PagerDuty などの既存のコネクタを使用して、外部サービスと統合します。 独自のサービス用にロジック アプリを構成することもできます。 |
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 アラートでは、設計上の決定なしに高度な信頼性が実現されます。