AzureDiagnostics

[アーティクル]
11/23/2024

Azure Diagnostics モードを使用する Azure サービスのリソースログが格納されます。リソースログには、Azure リソースの内部操作が記述されています。

各 Azure サービスのリソースログには、固有の列のセットがあります。 AzureDiagnostics テーブルには、Azure サービスによって使用される最も一般的な列が含まれています。リソースログに AzureDiagnostics テーブルにまだ存在しない列が含まれている場合は、データが初めて収集されたときにその列が追加されます。 500 列の最大数に達すると、追加の列のデータが動的列に追加されます。

リソース固有モードを使用する Azure サービスは、そのサービスに固有のテーブルにデータを格納し、AzureDiagnostics テーブルを使用しません。違いの詳細については、 Azure リソースログを参照してください。 Azure Diagnostics を使用するサービスについては、「 Azure Diagnostics モードを使用したリソース」を参照してください。

Note

AzureDiagnostics テーブルは、Azure リソースが初めて Azure Diagnostics モードでログの送信を開始するときに、Azure Monitor パイプラインによって排他的に作成されたカスタムログテーブルです。他のテーブルとは異なり、ARM テンプレートまたはテーブル API を使用して AzureDiagnostics テーブルを作成することはできません。そのため、作成前にテーブルの既定の保持値を変更することはできません。

AdditionalFields 列

他のテーブルとは異なり、 AzureDiagnostics は、このテーブルにデータを送信できるさまざまな Azure リソースがあるため、Log Analytics ワークスペース内の任意のテーブルに対して課される 500 列の制限を超える可能性がはるかに高くなります。アクティブな列の数がこの 500 列の制限を超えたためにデータが失われないようにするために、AzureDiagnostics 列の作成は他のテーブルとは異なる方法で処理されます。

すべてのワークスペースの AzureDiagnostics テーブルには、少なくとも同じ 200 列が含まれています。 2021 年 1 月 19 日より前に作成されたワークスペースの場合、テーブルには、この日付より前に既に配置されていた列も含まれています。データがまだ配置されていない列に送信される場合:

現在のワークスペースの AzureDiagnostics の列の合計数が 500 を超えない場合は、他のテーブルと同様に新しい列が作成されます。
列の合計数が 500 以上の場合、余分なデータは、プロパティとして AdditionalFields という動的プロパティバッグ列に追加されます。

例

この動作を説明するために、ワークスペース内の AzureDiagnostics テーブルが (デプロイ日) の時点で次のようになります。

列 1	列 2	列 3	...	列 498
abc	def	123	...	456
...	...	...	...	...

AzureDiagnostics にデータを送信するリソースNewInfo1を呼び出すデータに新しいディメンションを追加します。テーブルの列数は 500 未満であるため、この新しいディメンションのデータを含むイベントが初めて発生すると、テーブルに新しい列が追加されます。

列 1	列 2	列 3	...	列 498	NewInfo1_s
abc	def	123	...	456	xyz
...	...	...	...	...	...

この新しいデータは、単純なクエリで返すことができます。

AzureDiagnostics | where NewInfo1_s == "xyz"

後日、別のリソースがデータを AzureDiagnostics に送信し、 NewInfo2 および NewInfo3 という名前の新しいディメンションを追加します。テーブルはこのワークスペースで 500 列に達したため、新しいデータは AdditionalFields 列に入ります。

列 1	列 2	列 3	...	列 498	NewInfo1_s	AdditionalFields
abc	def	123	...	456	xyz	{"NewInfo2":"789","NewInfo3":"qwerty"}
...	...	...	...	...	...	...

このデータのクエリは引き続き実行できますが、KQL の動的プロパティ演算子のいずれかを使用してプロパティバッグから抽出する必要があります。

AzureDiagnostics
| where AdditionalFields.NewInfo2 == "789" and AdditionalFields.NewInfo3 == "qwerty"

`AdditionalFields`列の使用に関するヒント

クエリの最初の句として常に時間でフィルター処理するなどのクエリのベストプラクティスに従う必要がありますが、AdditionalFields を使用する場合は、他にもいくつかの推奨事項を考慮する必要があります。

データに対してさらに操作を実行する前に、データを型キャストする必要があります。たとえば、 Perf1Sec_i という名前の列があり、 AdditionalFields Perf2Sec と呼ばれるプロパティがあり、両方の値を追加して合計パフォーマンスを計算する場合は、次の AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | ....を使用できます。
where句を使用して、パフォーマンスを大幅に向上させるために複雑なロジックを記述する前に、データボリュームをできるだけ小さくします。 TimeGenerated は、常に可能な限り小さいウィンドウに縮小する必要がある 1 つの列です。 AzureDiagnostics の場合は、ResourceType 列を使用してクエリを実行するリソースの種類に関するクエリの先頭に追加のフィルターを常に含める必要があります。
大量のデータに対してクエリを実行する場合、解析するのではなく、 AdditionalFields 全体でフィルターを実行する方が効率的な場合があります。たとえば、大量のデータの場合、多くの場合、 AzureDiagnostics | where AdditionalFields has "Perf2Sec" は AzureDiagnostics | where isnotnull(toint(AdditionalFields.Perf2Sec))よりも効率的です。