AzureDiagnostics

[アーティクル]
11/13/2023

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

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

リソース固有モードを使用する Azure サービスは、そのサービスに固有のテーブルにデータを格納し、AzureDiagnostics テーブルを使用しません。各メソッドを使用するサービスについては、以下の「リソースの種類」を参照してください。相違点の詳細については、「 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"

後日、別のリソースは、NewInfo2 と NewInfo3 という新しいディメンションを追加するデータを AzureDiagnostics に送信します。テーブルがこのワークスペースで 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 と呼ばれる列と Perf2Sec という AdditionalFields のプロパティが存在し、両方の値を追加して合計パフォーマンスを計算する場合は、次のように使用します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))効率的です。