AzureDiagnostics

[アーティクル]
07/01/2024

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

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

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

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))よりも効率的です。