Azure Monitor ログのベスト プラクティス
この記事では、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 冗長ストレージ アカウントを使用します。
このエクスポート メカニズムでは、インジェスト パイプラインまたはエクスポート プロセス自体に影響を与えるインシデントからの保護はできません。
Note
ストレージ アカウント内のデータに 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 ワークスペースに結合するかどうかを決定します。
- 組織内のさまざまなロールに必要な、ワークスペース内のさまざまな種類のデータへのアクセスを構成します。
- Azure プライベート リンクを使用して、パブリック ネットワークからワークスペースへのアクセスを削除することを検討してください。
- ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマー マネージド キーを使用します。
- 長期保有または不変性のために監査データをエクスポートします。
- ログ クエリの監査を構成して、クエリを実行しているユーザーを追跡します。
- ワークスペース内の機密データをフィルター処理または難読化する戦略を決定します。
- 誤って収集された機密データを消去します。
- Microsoft Azure のカスタマー ロックボックスを有効にし、Microsoft データ アクセス要求を承認または拒否します。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。 | このデータを結合するかどうかの決定は、特定のセキュリティ要件によって異なります。 それらを 1 つのワークスペースに結合すると、すべてのデータの可視性が向上しますが、セキュリティ チームには専用のワークスペースが必要になる場合があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース戦略を設計する」を参照してください。 トレードオフ: ワークスペースで Sentinel を有効にするためにコストがかかる可能性があります。 「Log Analytics ワークスペース アーキテクチャを設計する」で詳細をご覧ください。 |
| 組織内のさまざまなロールに必要な、ワークスペース内のさまざまな種類のデータへのアクセスを構成します。 | ワークスペースの [アクセス制御モード] を [リソースまたはワークスペースのアクセス許可を使用] に設定すると、リソース所有者はワークスペースへの明示的なアクセスを許可されなくても、[リソース コンテキスト] を使用してデータにアクセスすることができます。 これにより、ワークスペースの構成が簡素化され、ユーザーがアクセスしてはならないデータにアクセスできないようにすることができます。 適切な組み込みロールを割り当てて、管理者の責任範囲に応じて、サブスクリプション、リソース グループ、またはワークスペース レベルで管理者にワークスペースのアクセス許可を付与します。 複数のリソースにまたがる一連のテーブルにアクセスする必要があるユーザーには、テーブル レベルの RBAC を活用します。 テーブルのアクセス許可を持つユーザーは、リソースのアクセス許可に関係なく、テーブル内のすべてのデータにアクセスできます。 ワークスペース内のデータへのアクセスを許可するためのさまざまなオプションの詳細については、「Log Analytics ワークスペースへのアクセスを管理する」を参照してください。 |
| Azure プライベート リンクを使用して、パブリック ネットワークからワークスペースへのアクセスを削除することを検討してください。 | パブリック エンドポイントへの接続は、エンドツーエンドの暗号化で保護されます。 プライベート エンドポイントが必要な場合は、Azure プライベート リンクを使用して、承認されたプライベート ネットワーク経由でのみ、リソースが Log Analytics ワークスペースに接続できるようにします。 プライベート リンクを使用して、ExpressRoute または VPN 経由でワークスペース データを強制的に取り込むこともできます。 環境に最適なネットワークと DNS トポロジを決定するには、「Azure Private Link の設定を設計する」を参照してください。 |
| ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマー マネージド キーを使用します。 | Azure Monitor により、Microsoft マネージド キー (MMK) を使用して、すべてのデータおよび保存されたクエリが保存時に暗号化されるようになります。 独自の暗号化キーを必要とし、専用クラスターに十分なデータを収集する場合は、カスタマー マネージド キーを使用して、柔軟性とキーのライフサイクル制御を強化します。 Microsoft Sentinel を使用している場合は、「Microsoft Sentinel のカスタマー マネージド キーの設定」の考慮事項をよく理解しておいてください。 |
| 長期保有または不変性のために監査データをエクスポートします。 | 長期保有を義務付ける規制の対象となるワークスペースで監査データを収集した可能性があります。 Log Analytics ワークスペース内のデータは変更できませんが、消去することはできます。 データ エクスポートを使用して、データの改ざんから保護するための不変性ポリシーを持つ Azure ストレージ アカウントにデータを送信します。 すべての種類のログがコンプライアンス、監査、またはセキュリティと同じ関連性を持っているわけではないため、エクスポートする必要がある特定のデータ型を決定します。 |
| ログ クエリの監査を構成して、クエリを実行しているユーザーを追跡します。 | ログ クエリの監査では、ワークスペースで実行される各クエリの詳細が記録されます。 この監査データをセキュリティ データとして扱い、LAQueryLogs テーブルを適切にセキュリティで保護します。 各ワークスペースの監査ログがローカル ワークスペースに送信されるように構成するか、オペレーショナル データとセキュリティ データを分離している場合は専用のセキュリティ ワークスペースに統合します。 Log Analytics ワークスペースの分析情報を使用して、このデータを定期的に確認し、認可されていないユーザーがクエリを実行しようとしている場合に事前に通知するログ検索の警告ルールを作成することを検討します。 |
| ワークスペース内の機密データをフィルター処理または難読化する戦略を決定します。 | 機密情報を含むデータを収集している可能性があります。 特定のデータ ソースの構成を使用して、収集すべきでないレコードをフィルター処理します。 データ内の特定の列のみを削除または難読化する必要がある場合は、変換を使用します。 元のデータを変更しないことを要求する標準がある場合、KQL クエリで 'h' リテラルを使用して、ブックに表示されるクエリ結果を難読化できます。 |
| 誤って収集された機密データを消去します。 | ワークスペースで誤って収集された可能性のあるプライベート データを定期的に確認し、データ消去を使用して削除します。 |
| Microsoft Azure のカスタマー ロックボックスを有効にし、Microsoft データ アクセス要求を承認または拒否します。 | Microsoft Azure 用カスタマー ロックボックスには、顧客データへのアクセス要求を確認し、承認または拒否するインターフェイスが用意されています。 顧客が開始したサポート チケットまたは Microsoft によって特定された問題に応答する場合、Microsoft のエンジニアが顧客データにアクセスする必要がある場合に使用されます。 カスタマー ロックボックスを有効にするには、 専用クラスターが必要です。 ロックボックスは現在、Auxiliary プランを使用したテーブルには適用できません。 |
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法のことです。 さまざまな構成オプションと、収集するデータの量を減らす機会を理解することで、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 でログ クエリを最適化する」を参照してください。 |