Container insights でログ収集をフィルター処理する

この記事では、Container insights で使用できるさまざまなフィルター処理オプションについて説明します。 Kubernetes クラスターでは、Container Insights によって収集される大量のデータが生成されます。 このデータの取り込みと保持に対して課金されるため、不要なデータをフィルターで除外することで、監視コストを大幅に削減できます。

重要

この記事では、監視対象クラスターの DCR または ConfigMap を変更する必要がある、さまざまなフィルター処理オプションについて説明します。 この構成の実行の詳細については、「Container insights でのログ収集の構成」を参照してください。

コンテナー ログのフィルター処理

コンテナー ログは、Kubernetes クラスター内のコンテナーによって生成される stderr および stdout ログです。 これらのログは、Log Analytics ワークスペースの ContainerLogV2 テーブルに格納されます。 既定では、すべてのコンテナー ログが収集されますが、特定の名前空間からログを除外したり、コンテナー ログの収集を完全に無効にしたりできます。

データ収集ルール (DCR) を使用すると、stdout ログと stderr ログを有効または無効にしたり、それぞれの特定の名前空間をフィルター処理したりできます。 コンテナー ログと名前空間のフィルター処理の設定は、Azure portal で構成されたコスト プリセットに含まれており、他の DCR 構成方法を使用してこれらの値を個別に設定できます。

ConfigMap を使用すると、クラスターごとに stderr ログと stdout ログの収集を個別に構成できるため、一方を有効にして他方は無効にするといった選択が可能です。

次の例は、kube-system 名前空間および gatekeeper-system 名前空間を除く stdout と stderr を収集する ConfigMap 設定を示しています。

[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]

    [log_collection_settings.stderr]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]

    [log_collection_settings.enrich_container_logs]
        enabled = true

プラットフォーム ログのフィルター処理 (System Kubernetes 名前空間)

既定では、Log Analytics のコストを最小限に抑えるために、システム名前空間のコンテナー ログはコレクションから除外されます。 特定のトラブルシューティング シナリオでは、システム コンテナーのコンテナー ログが重要になる場合があります。 この機能は、kube-system、gatekeeper-system、calico-system、azure-arc、kube-public、kube-node-lease の各システム名前空間に制限されます。

collect_system_pod_logs 設定で ConfigMap を使用してプラットフォーム ログを有効にします。 また、システム名前空間が exclude_namespaces 設定に含まれていないことも確認する必要があります。

次の例は、kube-system 名前空間の coredns コンテナーの stdout ログと stderr ログを収集する ConfigMap 設定を示しています。

[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = true
        exclude_namespaces = ["gatekeeper-system"]
        collect_system_pod_logs = ["kube-system:coredns"]

    [log_collection_settings.stderr]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]
        collect_system_pod_logs = ["kube-system:coredns"]

ワークロードの注釈ベースでのフィルター処理

注釈ベースのフィルター処理を使用すると、ポッドに注釈を付けることで、特定のポッドとコンテナーのログ収集を除外できます。 これにより、ログの取り込みコストが大幅に削減され、ノイズを処理することなく関連情報に集中できます。

次の設定で、ConfigMap を使用して注釈ベースのフィルター処理を有効にします。

[log_collection_settings.filter_using_annotations]
   enabled = true

必要な注釈をワークロード ポッドの仕様に追加する必要があります。次の表では、考えられるさまざまなポッドの注釈を示します。

注釈	説明
fluentbit.io/exclude: "true"	ポッド内のすべてのコンテナーで stdout ストリームと stderr ストリームの両方を除外します
fluentbit.io/exclude_stdout: "true"	ポッド内のすべてのコンテナーで stdout ストリームのみを除外します
fluentbit.io/exclude_stderr: "true"	ポッド内のすべてのコンテナーで stderr ストリームのみを除外します
fluentbit.io/exclude_container1: "true"	ポッド内の container1 に対してのみ stdout ストリームと stderr ストリームの両方を除外します
fluentbit.io/exclude_stdout_container1: "true"	ポッド内の container1 に対してのみ stdout のみを除外します

Note

これらの注釈は Fluent Bit ベースです。 独自の Fluent Bit ベースのログ収集ソリューションを Kubernetes プラグインのフィルター処理と注釈ベースの除外とともに使用すると、Container Insights とそのソリューションの両方でログの収集が停止されます。

ポッド仕様での fluentbit.io/exclude: "true" 注釈の例を次に示します。

apiVersion: v1 
kind: Pod 
metadata: 
 name: apache-logs 
 labels: 
  app: apache-logs 
 annotations: 
  fluentbit.io/exclude: "true" 
spec: 
 containers: 
 - name: apache 
  image: edsiper/apache_logs 

環境変数のフィルター処理

次の設定で ConfigMap を使用して、クラスター内のすべてのポッドおよびノードにわたる環境変数の収集を有効にします。

[log_collection_settings.env_var]
    enabled = true

環境変数の収集がグローバルに有効になっている場合は、特定のコンテナーに対してその収集を無効にすることができます。そのためには、Dockerfile 設定を使用して、またはポッドの構成ファイルの env: セクションで、環境変数 AZMON_COLLECT_ENV を False に設定します。 環境変数の収集がグローバルで無効になっている場合、コレクションを特定のコンテナーで有効にすることはできません。 コンテナー レベルで適用できる唯一のオーバーライドは、コレクションが既にグローバルで有効になっている場合に無効にすることです。

視覚化とアラートに対する影響

Container insights データを使用するカスタム アラートまたはワークブックがある場合は、データ収集の設定を変更すると、それらのエクスペリエンスが低下する可能性があります。 名前空間を除外したり、データ収集の頻度を減らしたりする場合は、このデータを使用して既存のアラート、ダッシュボード、ブックを確認します。

これらのテーブルを参照するアラートをスキャンするには、次の Azure Resource Graph クエリを実行します。

resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "Perf" or properties  contains "InsightsMetrics" or properties  contains "ContainerInventory" or properties  contains "ContainerNodeInventory" or properties  contains "KubeNodeInventory" or properties  contains"KubePodInventory" or properties  contains "KubePVInventory" or properties  contains "KubeServices" or properties  contains "KubeEvents" 
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc

次のステップ

• 詳細な条件に基づいてデータをさらにフィルター処理する変換を DCR に追加するには、「Container insights でのデータ変換」を参照してください。