Container Insights でのデータ変換
この記事では、Container Insights でデータ変換を実装する方法について説明します。 Azure Monitor の変換を使用すると、Log Analytics ワークスペースに取り込まれる前にデータを変更またはフィルター処理できます。 クラスターから収集されたデータをフィルター処理してコストを抑えたり、受信データを処理してデータ クエリを支援したりするなどのアクションを実行できます。
重要
「Container insights でのログ収集の構成」、「Container insights でのログ収集のフィルター処理」記事は、Container insights のデータ収集を構成およびフィルター処理するための標準的な構成設定について説明しています。 変換を使用する前に、これらの機能を使用して必要な構成を実行する必要があります。 変換を使用して、標準の構成設定では実行できないフィルター処理またはその他のデータ構成を実行します。
データ収集ルール
データ収集ルール (DCR) に変換を実装し、Azure Monitor でのデータ収集を構成するために使用します。 DCR を使用してデータ収集を構成では、クラスターで Container Insights を有効にしたときに自動的に作成される DCR について説明します。 変換を作成するには、次のいずれかのアクションを実行する必要があります:
- 新しいクラスター。 既存の ARM テンプレートを使用して、AKS クラスターを Container Insights にオンボードします。 次のいずれかのサンプルのような変換を含め、必要な構成でそのテンプレートの DCR を変更します。
- 既存の DCR。 クラスターが Container Insights にオンボードされ、データ収集が構成されたら、その DCR を編集して、「データ収集ルールの編集」のいずれかの方法を使用して変換を含めます。
Note
現在、変換を追加するために必要な DCR を編集するための UI は最小限です。 ほとんどの場合、DCR を手動で編集する必要があります。 この記事では、実装する DCR 構造体について説明します。 その構造の実装方法のガイドについては、「Azure Monitor でデータ収集規則 (DCR) を作成および編集する」を参照してください。
データ ソース
DCR の [データ ソース] セクションには、DCR で処理するさまざまな種類の受信データが定義されます。 Container insights の場合、これは Container insights 拡張機能であり、Microsoft- のプレフィックスで始まる 1 つ以上の定義済みの streams が含まれています。
DCR の Container Insights ストリームの一覧は、クラスターに対して選択したコスト プリセットによって異なります。 すべてのテーブルを収集する場合、DCR は Microsoft-ContainerInsights-Group-Default ストリームを使用します。これは、Stream 値に一覧表示されているすべてのストリームを含むグループ ストリームです。 変換を使用する場合は、これを個々のストリームに変更する必要があります。 その他のコスト プリセット設定では、既に個々のストリームが使用されるようになっています。
次のサンプルは Microsoft-ContainerInsights-Group-Default ストリームを示しています。 個々のストリームを使用するサンプルについては、サンプル DCR を参照してください。
"dataSources": {
"extensions": [
{
"streams": [
"Microsoft-ContainerInsights-Group-Default"
],
"name": "ContainerInsightsExtension",
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"namespaces": null,
"enableContainerLogV2": true
}
}
}
]
}
データ フロー
DCR の [データ フロー] セクションは、DCR の destinations セクションに定義された宛先を持つストリームと一致します。 データが既定のテーブルに送信される場合、既知のストリームに対してテーブル名を指定する必要はありません。 変換を必要としないストリームは、ワークスペースの宛先のみを含む 1 つのエントリにまとめることができます。 それぞれが既定のテーブルに送信されます。
変換を必要とするストリーム用に個別のエントリを作成します。 これには、ワークスペースの変換先と transformKql プロパティが含まれている必要があります: 代替テーブルにデータを送信する場合は、変換先テーブルの名前を指定する outputStream プロパティを含める必要があります。
次のサンプルは、変換を含む 1 つのストリームの dataFlows セクションを示しています。 1 つの DCR 内の複数のデータ フローについては、「サンプル DCR」を参照してください。
"dataFlows": [
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where PodNamespace == 'kube-system'"
}
]
サンプル DCR
データのフィルター処理
最初の例では、LogLevel 列に基づいて ContainerLogV2 からデータを除外します。 error または critical の LogLevel を持つレコードのみが収集されます。これらは、クラスター内の問題のアラートと特定に使用できるエントリであるためです。 info や debug などの他のレベルを収集して格納すると、大きな価値なしでコストが発生します。
これらのレコードは、次のログ クエリを使用して取得できます。
ContainerLogV2 | where LogLevel in ('error', 'critical')
このロジックを次の図に示します。
変換では、受信データを表すためにテーブル名 source が使用されます。 変換で使用する変更されたクエリを次に示します。
source | where LogLevel in ('error', 'critical')
次の例は、Container insights DCR に追加されたこの変換を示しています。 変換を適用する必要があるのはこれが唯一の受信ストリームであるため、Microsoft-ContainerLogV2 には個別のデータ フローが使用されることに注意してください。 他のストリームには別のデータ フローが使用されます。
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
}
],
},
}
さまざまなテーブルにデータを送信する
上記の例では、error または critical の LogLevel を持つレコードのみが収集されます。 これらのレコードをまったく収集しない代わりに、基本ログ用に構成された代替テーブルに保存する方法があります。
この戦略には、2 つの変換が必要です。 最初の変換では、error または critical の LogLevel を持つレコードを既定のテーブルに送信します。 2 番目の変換では、他のレコードを ContainerLogV2_CL という名前のカスタム テーブルに送信します。 前の例で説明したように、受信データの source を使用して、それぞれのクエリを次に示します。
# Return error and critical logs
source | where LogLevel in ('error', 'critical')
# Return logs that aren't error or critical
source | where LogLevel !in ('error', 'critical')
このロジックを次の図に示します。
重要
このサンプルで DCR をインストールする前に、 と同じスキーマを持つ新しいテーブルを作成するContainerLogV2必要があります。 ContainerLogV2_CL と名前を付け、基本的なログ用に構成します。
次の例は、Container insights DCR に追加されたこの変換を示しています。 この DCR には、変換ごとに 1 つずつ、Microsoft-ContainerLogV2 用の 2 つのデータ フローがあります。 最初のは、テーブル名を指定する必要がない既定のテーブルに送信します。 2 つ目は、変換先テーブルを指定するために outputStream プロパティが必要です。
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel !in ('error','critical')",
"outputStream": "Custom-ContainerLogV2_CL"
}
],
},
}