この記事では、Azure Monitor ログのアーキテクチャに関するベスト プラクティスについて説明します。 このガイダンスは、Azure Well-Architected Framework で説明されているアーキテクチャ エクセレンスの 5 つの柱に基づいています。
信頼性
信頼性とは、障害から回復して動作を続行する、システムの能力を指します。 目標は、単一のコンポーネントの障害による影響を最小限に抑えることです。 次の情報を使用して、Log Analytics ワークスペースの障害を最小限に抑え、収集したデータを保護します。
Log Analytics ワークスペースは、高い信頼性を提供します。 インジェスト パイプラインによって、収集されたデータが Log Analytics ワークスペースに送信されますが、このパイプラインでは各ログ レコードが Log Analytics ワークスペースによって正常に処理されたことが検証された後に、そのレコードがパイプから削除されます。 このインジェスト パイプラインが使用できない場合は、データを送信するエージェントがログをバッファーに入れて、送信を何時間も再試行します。
回復性を高める Azure Monitor ログの機能
Azure Monitor ログには、さまざまな種類の問題に対するワークスペースの回復性を高める多数の機能があります。 これらの機能は、ニーズに応じて個別に使うことも、組み合わせて使うこともできます。
このビデオでは、Log Analytics ワークスペースで使用できる信頼性と回復性のオプションの概要について説明します。
可用性ゾーンを使用するリージョン内保護
可用性ゾーンをサポートする Azure リージョンのそれぞれに一連のデータセンターがあり、これらは独立した電源、冷却、およびネットワークのインフラストラクチャを備えています。
Azure Monitor ログの可用性ゾーンは冗長です。つまり、Microsoft はサポートされているリージョン内のさまざまなゾーンにサービス要求を分散させるとともに、データをこれらのゾーン間でレプリケートしています。 インシデントが 1 つのゾーンに影響を与える場合は、Microsoft はリージョン内の別の可用性ゾーンを自動的に使用します。 ゾーン間の切り替えはシームレスであるため、アクションを実行する必要はありません。
ほとんどのリージョンの Azure Monitor ログ可用性ゾーンでデータの回復性がサポートされています。つまり、お客様が保存したデータは、ゾーンレベルの障害に関連するデータ損失から保護されます。ただしこの場合も、サービス オペレーションはリージョンレベルのインシデントの影響を受ける可能性があります。 サービスがクエリを実行できない場合は、その問題が解決されるまでお客様はログを見ることができません。
データの回復性がサポートされる可用性ゾーンでは、サービスの回復性もサポートされます。つまり、Azure Monitor ログのサービス オペレーション、たとえばログ インジェスト、クエリ、アラートなどは、ゾーン障害が発生した場合でも続行できます。
可用性ゾーンによる保護の対象は、インフラストラクチャ関連のインシデント (たとえばストレージ障害) です。 障害のあるコードのデプロイや証明書の障害など、リージョン全体に影響を与えるアプリケーション レベルの問題から保護されません。
連続エクスポートを使用して特定テーブルからのデータをバックアップする
Log Analytics ワークスペース内の特定のテーブルに送信されたデータを Azure ストレージ アカウントに連続エクスポートすることができます。
データのエクスポート先となるストレージ アカウントは、Log Analytics ワークスペースと同じリージョンに存在している必要があります。 取り込み済みのログを保護して、ワークスペースのリージョンがダウンしている場合でもアクセスできるようにするには、構成の推奨事項で説明している geo 冗長ストレージ アカウントを使用します。
エクスポート メカニズムでは、インジェスト パイプラインまたはエクスポート プロセス自体に影響を与えるインシデントからの保護は提供されません。
注
ストレージ アカウント内のデータに Azure Monitor ログからアクセスするには、externaldata 演算子を使用します。 ただし、エクスポートされたデータは 5 分間の BLOB に格納され、複数の BLOB にまたがるデータの分析には手間がかかることがあります。 したがって、データをストレージ アカウントにエクスポートすることはデータ バックアップのメカニズムとして優れているものの、バックアップ済みのデータをストレージ アカウントで保存しておくことは、そのデータが Azure Monitor ログでの分析に必要な場合は理想的とはいえません。 大量の BLOB データに対してクエリを実行するには、Azure Data Explorer、Azure Data Factory、またはその他の任意のストレージ アクセス ツールを使用できます。
ワークスペース レプリケーションを使用したリージョン間のデータ保護とサービスの回復性
ワークスペース レプリケーションは、Log Analytics ワークスペースと受信ログを別のリージョンにレプリケートするため、最も広範な回復性ソリューションです。
ワークスペース レプリケーションによって、ログとサービス オペレーションの両方が保護されます。また、インフラストラクチャまたはアプリケーション関連の、リージョン全体に影響するインシデントが発生した場合でもシステムの監視を続行できます。
Microsoft がエンドツーエンドで管理する可用性ゾーンとは対照的に、お客様自身でプライマリ ワークスペースの正常性を監視して、いつワークスペースをセカンダリ リージョンに切り替えていつ戻すかを決定する必要があります。
設計チェックリスト
- リージョン全体に影響するインシデントに対するサービスとデータの回復性を確実にするには、ワークスペース レプリケーションを有効にしてください。
- データセンターの障害に対するリージョン内保護を確実にするには、可用性ゾーンをサポートするリージョン内にワークスペースを作成します。
- 特定のテーブル内のデータのクロスリージョン バックアップを行うには、連続エクスポート機能を使用して、geo レプリケートされるストレージ アカウントにデータを送信します。
- Log Analytics ワークスペースの正常性を監視します。
構成に関する推奨事項
| 勧告 | メリット |
|---|---|
| 回復性を最大限に高めるには、ワークスペース レプリケーションを有効にします。 | ワークスペースのデータとサービス オペレーションに対するクロスリージョン回復性。 ワークスペース レプリケーション では、別のリージョンにワークスペースのセカンダリ インスタンスを作成し、両方のワークスペースにログを取り込むことで、高可用性が確保されます。 必要に応じて、プライマリ ワークスペースに影響する問題が解決するまでの間、セカンダリ ワークスペースに切り替えます。 ログの取り込み、データに対するクエリ実行、ダッシュボード、アラート、Sentinel の使用は引き続きセカンダリ ワークスペースで行うことができます。 また、リージョン切り替え前に取り込まれたログにもアクセスできます。 これは有料機能であるため、受信したログすべてと一部のデータ ストリームのみの、どちらのレプリケートが必要かを検討してください。 |
| 可能であれば、Azure Monitor サービス回復性をサポートするリージョン内にワークスペースを作成します。 | データセンターの問題が発生した場合のワークスペース データとサービス オペレーションのリージョン内回復性。 サービスの回復性をサポートする可用性ゾーンでは、データの回復性もサポートされます。 つまり、あるデータセンター全体が使用不可になった場合でも、ゾーン間で冗長であるため、Azure Monitor のサービス オペレーション (インジェストやクエリ実行など) は引き続き機能し、取り込み済みのログも引き続き使用可能になります。 可用性ゾーンによってリージョン内保護が可能になりますが、リージョン全体に影響を与える問題からの保護はできません。 どのリージョンでデータの回復性がサポートされているかについては、「可用性ゾーンを使用して Azure Monitor ログのデータとサービスの回復性を強化する」を参照してください。 |
| データの回復性がサポートされるリージョン内にワークスペースを作成します。 | リージョン内保護によって、データセンターの問題の発生時にワークスペース内のログの損失を防ぎます。 データの回復性がサポートされるリージョン内にワークスペースを作成すれば、データセンター全体が使用不可になった場合でも、取り込み済みのログに影響が及ぶことはありません。 サービスがクエリを実行できない場合は、その問題が解決されるまでお客様はログを見ることができません。 どのリージョンでデータの回復性がサポートされているかについては、「可用性ゾーンを使用して Azure Monitor ログのデータとサービスの回復性を強化する」を参照してください。 |
| 特定のテーブルからストレージ アカウントへのデータ エクスポートを構成し、このアカウントをリージョン間でレプリケートします。 | ログ データのバックアップ コピーを別のリージョン内に保持します。 Azure Monitor のデータ エクスポート機能を使用すると、特定のテーブルに送信されたデータを Azure ストレージに継続的にエクスポートして、長期間保持することができます。 geo 冗長ストレージ (GRS) または geo ゾーン冗長ストレージ (GZRS) アカウントを使用すると、あるリージョン全体が使用不可になった場合でもデータの安全を保つことができます。 データを他のリージョンから読み取れるようにするには、セカンダリ リージョンに対する読み取りアクセス権を持つようにストレージ アカウントを構成します。 詳細については、Azure Storage のセカンダリ リージョンでの冗長性と Azure Storage のセカンダリ リージョンのデータへの読み取りアクセスに関するページを参照してください。 連続データ エクスポートがサポートされていないテーブルについては、他のデータ エクスポート方法、たとえば Logic Apps を使用してデータを保護できます。 これは主に、データの分析とワークスペースへの復元が困難な場合があるため、データ保持のコンプライアンスを満たすためのソリューションです。 データ エクスポートは、リージョン内の Azure Monitor インジェスト パイプラインの安定性に依存するため、リージョン インシデントの影響を受けやすくなります。 リージョンインジェスト パイプラインに影響を与えるインシデントに対する回復性は提供されません。 |
| Log Analytics ワークスペースの正常性を監視します。 | Log Analytics Workspace Insights を使用して障害が発生したクエリを追跡し、正常性状態アラートを作成してデータセンターまたはリージョンの障害が原因でワークスペースが利用できなくなった場合に事前に通知されます。 |
Azure Monitor ログの回復性機能の比較
| 特徴 | サービスの回復性 | [データ バックアップ] | 高可用性 | 保護の範囲 | 設定 | 費用 |
|---|---|---|---|---|---|---|
| ワークスペース レプリケーション | ✅ | ✅ | ✅ | リージョン全体のインシデントに対するクロスリージョン保護 | ワークスペースのレプリケーションと、関連するデータ収集ルールを有効にします。 必要に応じてリージョンを切り替えます。 | レプリケートされる量 (GB) とリージョンに基づきます。 |
| 可用性ゾーン | ✅ サポートされているリージョンで |
✅ | ✅ | データセンターの問題に対するリージョン内保護 | サポートされているリージョンでは自動的に有効になります。 | コストなし |
| 継続的データ エクスポート | ✅ | リージョン障害が原因のデータ損失からの保護1 | テーブルごとに有効にします。 | データ エクスポート + ストレージ BLOB または Event Hubs のコスト |
1 データ エクスポートによってクロスリージョン保護が可能になるのは、geo レプリケートされるストレージ アカウントにログをエクスポートする場合です。 インシデントが発生した場合、以前にエクスポートされたデータがバックアップされ、すぐに使用できるようになります。ただし、インシデントの性質によっては、追加のエクスポートが失敗する可能性があります。
安全
セキュリティは、あらゆるアーキテクチャの最も重要な側面の 1 つです。 Azure Monitor は、最小限の特権の原則と多層防御の両方を採用する機能を提供します。 次の情報を使用して、Log Analytics ワークスペースのセキュリティを最大限に高め、許可されているユーザーのみが収集されたデータにアクセスできるようにします。
ニーズに基づいてワークスペース内のデータへのアクセスを許可する
- ワークスペースのアクセス制御モードを [ リソースまたはワークスペースのアクセス許可を使用 する] に設定すると、リソース所有者は、ワークスペースへの明示的なアクセス権を付与されることなく 、リソース コンテキスト を使用してデータにアクセスできるようになります。 これにより、ワークスペースの構成が簡略化され、ユーザーが必要なデータにのみアクセスできるようになります。
手順: Log Analytics ワークスペースへのアクセスを管理する - 適切な組み込みロールを割り当てて、責任の範囲に応じて、サブスクリプション、リソース グループ、またはワークスペース レベルで管理者にワークスペースのアクセス許可を付与します。
手順: Log Analytics ワークスペースへのアクセスを管理する - 複数のリソースにまたがる一連のテーブルへのアクセスを必要とするユーザーに対して、テーブル レベルの RBAC を適用します。 テーブルのアクセス許可を持つユーザーは、リソースのアクセス許可に関係なく、テーブル内のすべてのデータにアクセスできます。
手順: Log Analytics ワークスペースへのアクセスを管理する
トランスポート層セキュリティ (TLS) 1.2 以降を使用してワークスペースにデータを送信する
エージェント、コネクタ、またはログ API を使用してワークスペースにデータを 照会 または 送信 する場合は、トランスポート層セキュリティ (TLS) 1.2 以降を使用して転送中のデータのセキュリティを確保します。 以前のバージョンの TLS と Secure Sockets Layer (SSL) には脆弱性があり、下位互換性を実現するために引き続き機能する可能性はありますが、 推奨されておらず、業界はこれらの古いプロトコルのサポートをすぐに中止するように移行しました。
PCI Security Standards Council は、古いバージョンの TLS/SSL を無効にし、より安全なプロトコルにアップグレードするために、2018 年 6 月 30 日の期限を設定しました。 Azure がレガシ サポートを削除すると、エージェントが TLS 1.2 以上で通信できない場合、Azure Monitor ログにデータを送信できなくなります。
必要な場合を除き、TLS 1.2 のみを 使用するようにエージェント、データ コネクタ、または API アプリケーションを明示的に構成しないでください。 将来のセキュリティ標準を自動的に検出、ネゴシエート、利用できるようにすることをお勧めします。 そうしないと、新しい標準によるセキュリティ強化が使用できなくなり、TLS 1.2 が廃止され、新しい標準が採用されたときに、問題が発生する可能性があります。
重要
2025 年 7 月 1 日に、 Azure 全体のレガシ TLS の廃止に合わせて、Azure Monitor ログの TLS 1.0/1.1 プロトコル バージョンが廃止されます。 クラス最高の暗号化を提供するために、Azure Monitor ログでは、選択した暗号化メカニズムとしてトランスポート層セキュリティ (TLS) 1.2 および 1.3 が使用されます。
従来の TLS の問題に関する一般的な質問や、サポートされている暗号スイートのテスト方法については、 TLS の問題の解決 と Azure Resource Manager TLS サポートに関するページを参照してください。
ログ クエリの監査を設定する
- ログ クエリ監査を構成して、ワークスペースで実行される各クエリの詳細を記録します。
手順: Azure Monitor ログのクエリを監査する - ログ クエリ監査データをセキュリティ データとして扱い、 LAQueryLogs テーブルへの安全なアクセスを適切に処理します。
手順: ニーズに基づいてワークスペース内のデータへのアクセスを構成します。 - 運用データとセキュリティ データを分離する場合は、各ワークスペースの監査ログをローカル ワークスペースに送信するか、専用のセキュリティ ワークスペースに統合します。
手順: ニーズに基づいてワークスペース内のデータへのアクセスを構成します。 - Log Analytics ワークスペースの分析情報を使用して、ログ クエリの監査データを定期的に確認します。
手順: Log Analytics ワークスペースの分析情報。 - 承認されていないユーザーがクエリを実行しようとしている場合に通知するログ検索アラート ルールを作成します。
手順: ログ検索アラート ルール。
監査データの不変性を確保する
Azure Monitor は追加専用のデータ プラットフォームですが、コンプライアンスのためにデータを削除するためのプロビジョニングが含まれています。 監査データをセキュリティで保護するには:
Log Analytics ワークスペースにロックを設定して、消去、テーブルの削除、テーブルレベルまたはワークスペース レベルのデータ保有期間の変更など、データを削除できるすべてのアクティビティをブロックします。 ただし、このロックは削除できることに注意してください。
手順: リソースをロックしてインフラストラクチャを保護する完全な改ざん防止ソリューションが必要な場合は、変更 できないストレージ ソリューションにデータをエクスポートすることをお勧めします。
- エクスポートする必要がある特定のデータ型を決定します。 すべてのログの種類が、コンプライアンス、監査、またはセキュリティに同じ関連性を持つわけではありません。
- データ エクスポートを使用して、Azure ストレージ アカウントにデータを送信します。
手順: Azure Monitor での Log Analytics ワークスペースデータのエクスポート - 不変ポリシーを設定して、データの改ざんから保護します。
手順: BLOB バージョンの不変ポリシーを構成する
ワークスペース内の機密データをフィルター処理または難読化する
ログ データに 機密情報が含まれている場合:
- 特定のデータ ソースの構成を使用して、収集すべきでないレコードをフィルター処理します。
- データ内の特定の列のみを削除または難読化する必要がある場合は、変換を使用します。
手順: Azure Monitor での変換 - 元のデータを変更しない必要がある標準がある場合は、KQL クエリで 'h' リテラルを使用して、ブックに表示されるクエリ結果を難読化します。
手順: 難読化文字列リテラル
誤って収集された機密データを消去する
- ワークスペースで誤って収集される可能性のあるプライベート データを定期的に確認します。
- 不要なデータを削除するには、 データ消去 を使用します。 補助プランを持つテーブル内のデータは、現在削除できないことに注意してください。
手順: Azure Monitor ログと Application Insights での個人データの管理
セキュリティ強化のためにワークスペースを専用クラスターにリンクする
Azure Monitor では、Microsoft マネージド キー (MMK) を使用して、すべての保存データと保存済みのクエリが暗号化されます。 専用クラスターに対して十分なデータを収集する場合は、次のような強化されたセキュリティ機能のためにワークスペースを専用クラスターにリンクします。
- 柔軟性とキー ライフサイクル制御を強化するためのカスタマー マネージド キー。 Microsoft Sentinel を使用している場合は、「Microsoft Sentinel のカスタマー マネージド キーの設定」の考慮事項をよく理解しておいてください。
- 顧客データ アクセス要求を確認および承認または拒否するための Microsoft Azure のカスタマー ロックボックス。 カスタマー ロックボックスは、お客様から開始されたサポート チケットまたは Microsoft によって特定された問題に対応しているかどうかにかかわらず、Microsoft のエンジニアが顧客データにアクセスする必要がある場合に使用されます。 ロックボックスは現在、Auxiliary プランを使用したテーブルには適用できません。
手順: Azure Monitor ログで専用クラスターを作成および管理する
Azure プライベート リンクを使用してパブリック ネットワークからのワークスペース アクセスをブロックする
Microsoft は、エンド ツー エンドの暗号化を使用してパブリック エンドポイントへの接続をセキュリティで保護します。 プライベート エンドポイントが必要な場合は、 Azure プライベート リンク を使用して、リソースが承認されたプライベート ネットワークを介して Log Analytics ワークスペースに接続できるようにします。 プライベート リンクを使用して、ExpressRoute または VPN を介してワークスペースデータの取り込みを強制することもできます。
手順: Azure Private Link のセットアップを設計する
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法のことです。 さまざまな構成オプションと、収集するデータの量を減らす機会を理解することで、Azure Monitor のコストを大幅に削減できます。 「Azure Monitor のコストと使用量」を参照して、Azure Monitor が請求するさまざまな方法と、毎月の請求書を表示する方法を理解しておいてください。
注
Azure Monitor のすべての機能にわたるコスト最適化の推奨事項については、「Azure Monitor でコストを最適化する」を参照してください。
設計チェックリスト
- オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。
- 各 Log Analytics ワークスペースで通常収集されるデータ量の価格レベルを構成します。
- データ保持とアーカイブを構成します。
- デバッグ、トラブルシューティング、および監査に使用するテーブルを基本ログとして構成します。
- ワークスペースのデータ ソースからのデータ収集を制限します。
- 収集されたデータを定期的に分析して、傾向や異常を特定します。
- 収集したデータの量が多い場合のアラートを作成します。
- 特定の予算を超えないようにするための予防措置として、日次上限を検討します。
- Log Analytics ワークスペースの Azure Advisor のコストに関する推奨事項に対するアラートを設定します。
構成に関する推奨事項
| 勧告 | メリット |
|---|---|
| オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。 | Sentinel が有効になっている場合、Log Analytics ワークスペース内のすべてのデータは Microsoft Sentinel の価格の対象となるため、このデータを組み合わせるとコストがかかる可能性があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース戦略を設計する」を参照してください。 |
| 各 Log Analytics ワークスペースで通常収集されるデータ量の価格レベルを構成します。 | 既定では、Log Analytics ワークスペースには最低データ量なしの従量課金制の価格が使用されています。 十分なデータを収集する場合は、コミットメントレベルを使用してコストを大幅に削減できます。これにより、より低い料金と引き換えに収集された 1 日の最小データに専念できます。 1 つのリージョン内のワークスペース間で十分なデータを収集する場合は、専用クラスターにリンクし、クラスターの価格を使用して収集されたボリュームを組み合わせることができます。 コミットメント レベルの詳細と、お客様の使用レベルに最も適したものを決定するためのガイダンスについては、「Azure Monitor ログのコストの計算とオプション」を参照してください。 異なる価格レベルでの使用量に応じた推定コストを表示するには、「使用量と推定コスト」を参照してください。 |
| 対話型および長期的なデータ保持を構成します。 | 既定の 31 日 (ワークスペースで Sentinel が有効になっている場合は 90 日、Application Insights データの場合は 90 日) を超えて Log Analytics ワークスペースにデータを保持すると、料金がかかります。 ログ クエリでデータをすぐに使用できるようにするための特定の要件を検討してください。 長期保有を構成することで、最長 12 年間データを保持しながら、検索ジョブを使用したり、データ セットをワークスペースに復元したりして時折アクセスすることができ、コストを大幅に削減することができます。 |
| デバッグ、トラブルシューティング、および監査に使用するテーブルを基本ログとして構成します。 | 基本ログ用に構成された Log Analytics ワークスペース内のテーブルは、制限された機能とログ クエリの料金と引き換えにインジェスト コストが低くなります。 これらのテーブルに対してクエリを実行する頻度が低く、アラートに使用しない場合、このクエリコストはインジェストコストの削減によって十分に相殺することができます。 |
| ワークスペースのデータ ソースからのデータ収集を制限します。 | Azure Monitor のコストの主な要因は、Log Analytics ワークスペースで収集するデータ量であるため、サービスやアプリケーションの正常性とパフォーマンスを評価するために必要なデータ量を超過しないように収集する必要があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。 トレードオフ: コストと監視の要件の間にトレードオフがある場合があります。 たとえば、高サンプル レートの方がパフォーマンスの問題を素早く検出できる可能性がありますが、コスト削減のために低サンプル レートが必要になる場合もあります。 ほとんどの環境では、収集の種類が異なる複数のデータ ソースがあるため、特定の要件とそれぞれのコスト目標のバランスを取る必要があります。 異なるデータ ソースの収集の構成に関する推奨事項については、「Azure Monitor でのコストの最適化」を参照してください。 |
| 収集されたデータを定期的に分析して、傾向や異常を特定します。 | Log Analytics ワークスペースの分析情報を使用して、ワークスペースで収集されたデータの量を定期的に確認します。 さまざまなソースから収集されたデータの量を理解するのに役立つだけでなく、余分なコストにつながる可能性のあるデータ収集の異常や上昇傾向を特定します。 加えて、「Log Analytics ワークスペースでの使用量を分析する」の方法を使用してデータ収集を分析し、使用量をさらに減らすことができる追加の構成があるかどうかを判断します。 これは、一連の新しい仮想マシンや新しいサービスをオンボードするなど、新しく一連のデータ ソースを追加する場合に特に重要です。 |
| 収集したデータの量が多い場合のアラートを作成します。 | 予期しない請求を避けるため、過剰な使用量が発生した場合は、事前に通知される必要があります。 通知により、請求期間が終了する前に、潜在的な異変に対処できます。 |
| 特定の予算を超えないようにするための予防措置として、日次上限を検討します。 | 日次上限を使用すると、構成した上限に達すると、その日の残りの時間、Log Analytics ワークスペース内のデータ収集が無効になります。 これは、日次上限を使用するタイミングに関する記事で説明されているとおり、コストを削減する方法として使用しないでください。 1 日の上限を設定する場合は、上限到達時にアラートを作成するだけでなく、特定の割合 (たとえば 90%) に達したときに通知するアラート ルールも作成してください。 これにより、上限がデータ収集を停止する前に、増加したデータの原因を調査して対処する機会が得まれます。 |
| Log Analytics ワークスペースの Azure Advisor のコストに関する推奨事項に対するアラートを設定します。 | Log Analytics ワークスペースに関する Azure Advisor の推奨事項では、コストを最適化する機会があるときにアラートで事前に通知されます。 これらのコストに関する推奨事項に対する Azure Advisor アラートを作成します。
|
オペレーショナルエクセレンス
オペレーショナル エクセレンスとは、運用環境でサービスを確実に実行するために必要な運用プロセスを指します。 Log Analytics ワークスペースをサポートするための運用要件を最小限に抑えるには、次の情報を使用します。
設計チェックリスト
- ビジネス要件を満たすために、最小限の数のワークスペースでワークスペース アーキテクチャを設計します。
- 複数のワークスペースを管理する場合は、Infrastructure as Code (IaC) を使用します。
- Log Analytics ワークスペースの分析情報を使用して、Log Analytics ワークスペースの正常性とパフォーマンスを追跡します。
- ワークスペース内の運用上の問題を事前に通知するアラート ルールを作成します。
- データの分離のための運用プロセスが明確に定義されていることを確認してください。
構成に関する推奨事項
| 勧告 | メリット |
|---|---|
| ビジネス要件を満たすワークスペース戦略を設計します。 | Log Analytics ワークスペースの作成数や配置場所などの戦略の設計に関するガイダンスについては、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。 1 つまたは少なくとも最小限の数のワークスペースを使用すると、運用データとセキュリティ データの分散が制限され、潜在的な問題の可視性を高め、パターンを特定しやすくし、メンテナンスの必要性を最小限に抑えることができるため、運用効率が最大化されます。 複数のテナントなど、複数のワークスペースが必要な場合や、可用性の要件をサポートするために複数のリージョンにワークスペースが必要な場合があります。 このような場合、増大するこの複雑さを管理するための適切なプロセスがあることを確認してください。 |
| 複数のワークスペースを管理する場合は、Infrastructure as Code (IaC) を使用します。 | Infrastructure as Code (IaC) を使用して、ARM、BICEP、または Terraform でワークスペースの詳細を定義します。 これにより、既存の DevOps プロセスを活用して新しいワークスペースをデプロイし、Azure Policy で構成を適用できます。 |
| Log Analytics ワークスペースの分析情報を使用して、Log Analytics ワークスペースの正常性とパフォーマンスを追跡します。 | Log Analytics Workspace Insights は、すべてのワークスペースの使用状況、パフォーマンス、正常性、エージェント、クエリ、および変更ログの統合ビューを提供します。 この情報を定期的に確認して、各ワークスペースの正常性と操作を追跡します。 |
| ワークスペース内の運用上の問題を事前に通知するアラート ルールを作成します。 | 各ワークスペースには、ワークスペースに影響を与える重要なアクティビティを記録する操作テーブルがあります。 このテーブルに基づいてアラート ルールを作成し、運用上の問題が発生したときに事前に通知されるようにします。 ワークスペースの推奨アラートを使用して、最も重要なアラート ルールの作成を簡素化できます。 |
| データの分離のための運用プロセスが明確に定義されていることを確認してください。 | ワークスペースの格納データの種類によって、要件が異なる場合があります。 ワークスペース戦略を設計し、アクセス許可や長期保有などの設定を構成する場合は、データ保持やセキュリティなどの要件を明確に理解していることを確認してください。 また、誤って収集した個人情報を含むデータを場合によって消去するプロセスを明確に定義しておくことも必要です。 |
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 次の情報を使用して、Log Analytics ワークスペースとログ クエリがパフォーマンスを最大限に高めるために構成されていることを確認します。
設計チェックリスト
- ログ クエリの監査を構成し、Log Analytics ワークスペースの分析情報を使用して、低速で非効率的なクエリを特定します。
構成に関する推奨事項
| 勧告 | メリット |
|---|---|
| ログ クエリの監査を構成し、Log Analytics ワークスペースの分析情報を使用して、低速で非効率的なクエリを特定します。 | ログ クエリの監査では、各クエリの実行に必要なコンピューティング時間と、結果が返されるまでの時間が格納されます。 Log Analytics ワークスペースの分析情報では、このデータを使用して、ワークスペース内の非効率的な可能性のあるクエリを一覧表示します。 これらのクエリを書き直して、パフォーマンスを向上することを検討してください。 ログ クエリの最適化に関するガイダンスについては、「Azure Monitor でログ クエリを最適化する」を参照してください。 |
次のステップ
- Azure Monitor の概要について詳しくは、こちらをご覧ください。