Collector for Kubernetes のログとイベントを収集する 🔗
注釈
Collector for Kubernetes の設定方法は、Helmで Collector for Kubernetes を設定する および Kubernetesの高度な設定 を参照してください。
バージョン0.86.0以降、Splunk Distribution of Collector for KubernetesはデフォルトでネイティブのOpenTelemetryログを収集します。
以下が該当します：
Istio 環境でログとトレースを相関させるには、Splunk OpenTelemetry Collector のバージョン 0.80.0 (またはそれ以降) を使用します。
Collectorを必要なバージョンにアップグレードできない場合は、ログ収集に Fluentd を使用し、
autodetect.istio=trueで Helm チャートをデプロイします。詳細は Splunk OpenTelemetry Collector バージョン 0.80.0 を参照してください。
CollectorはJournaldログをネイティブで収集できません。
ログ収集は GKE Autopilot ではサポートされていません。
メトリクスとディメンションのその他のルールと制限 も参照してください。例えば、MTS ごとに最大 36 個のディメンションを持つことができます。
Kubernetesホストマシンまたはボリュームからログファイルを追加する 🔗
KubernetesホストマシンとKubernetesボリュームから取り込むログファイルを追加するには、Collector for Kubernetes のデプロイに使用するvalues.yamlファイルで agent.extraVolumes、agent.extraVolumeMounts、logsCollection.extraFileLogs を使用します。
次の例は、Kubernetesホストマシンからログを追加する方法を示しています：
logsCollection:
extraFileLogs:
filelog/audit-log:
include: [/var/log/kubernetes/apiserver/audit.log]
start_at: beginning
include_file_path: true
include_file_name: false
resource:
com.splunk.source: /var/log/kubernetes/apiserver/audit.log
host.name: 'EXPR(env("K8S_NODE_NAME"))'
com.splunk.sourcetype: kube:apiserver-audit
agent:
extraVolumeMounts:
- name: audit-log
mountPath: /var/log/kubernetes/apiserver
extraVolumes:
- name: audit-log
hostPath:
path: /var/log/kubernetes/apiserver
複数行のログを処理する 🔗
Splunk Distribution of OpenTelemetry Collector for Kubernetesは、複数行ログの解析に対応しており、複数行ログの読み取り、理解、トラブルシューティングをより良い方法で支援します。
複数行ログを処理するには、values.yaml設定に以下のセクションを追加します：
logsCollection:
containers:
multilineConfigs:
- namespaceName:
value: default
podName:
value: buttercup-app-.*
useRegexp: true
containerName:
value: server
firstEntryRegex: ^[^\s].*
regex101 を使って、フォーマットに合うGolang正規表現を見つけ、設定ファイルの設定オプション firstEntryRegex で指定します。
アノテーションを使ってログの取り込みを管理する 🔗
ログを異なるインデックスに送信する 🔗
Collector for KubernetesはデフォルトのSplunkプラットフォームインデックスとして main を使用します。ポッドまたは名前空間の splunk.com/index 注釈を使用して、ログを送信するSplunkプラットフォームインデックスを指定します。
例えば、kube-system 名前空間から k8s_events インデックスにログを送信するには、コマンドを使用します：
kubectl annotate namespace kube-system splunk.com/index=k8s_events
注釈
両方がアノテーションされている場合は、ポッドアノテーションが名前空間アノテーションより優先されます。
ポッドまたは名前空間アノテーションを使用してログをフィルターリングする 🔗
logsCollection.containers.useSplunkIncludeAnnotation が false （デフォルト値） の場合、ポッドまたはネームスペースで splunk.com/exclude アノテーションを true に設定すると、それらのログが取り込まれなくなります。例：
# annotates a namespace
kubectl annotate namespace <my-namespace> splunk.com/exclude=true
# annotates a pod
kubectl annotate pod -n <my-namespace> <my-pod> splunk.com/exclude=true
logsCollection.containers.useSplunkIncludeAnnotation が true の場合、splunk.com/include アノテーションをポッドまたはネームスペースの true に設定すると、それらのログのみが取り込まれます。他のログはすべて無視されます。例：
# annotates a namespace
kubectl annotate namespace <my-namespace> splunk.com/include=true
# annotates a pod
kubectl annotate pod -n <my-namespace> <my-pod> splunk.com/include=true
ソースタイプをフィルターする 🔗
sourcetype フィールドを上書きするには、ポッドで splunk.com/sourcetype アノテーションを使用します。設定されていない場合、デフォルトは kube:container:CONTAINER_NAME になります。
kubectl annotate pod -n <my-namespace> <my-pod> splunk.com/sourcetype=kube:apiserver-audit
パフォーマンス・ベンチマークを確認する 🔗
Collector for Kubernetes Helmチャートを使用して設定された設定は、ログ取り込みの全体的なパフォーマンスに影響を与える可能性があります。パイプラインに追加するレシーバー、プロセッサー、エクスポーター、エクステンションの数が多ければ多いほど、パフォーマンスへの影響は大きくなります。
Collector for Kubernetesは、HTTP Event Collector (HEC) のデフォルトスループットを超える可能性があります。容量のニーズに対処するには、Collector for Kubernetes デプロイメントでHECのスループットと背圧を監視し、必要に応じてノードを追加します。
以下の表は、社内で実施されたパフォーマンス・ベンチマークの概要です：
ログジェネレーター数 |
イベントサイズ（バイト） |
エージェントCPU使用率 |
エージェントEPS |
|---|---|---|---|
1 |
256 |
1.8 |
30,000 |
1 |
516 |
1.8 |
28,000 |
1 |
1024 |
1.8 |
24,000 |
5 |
256 |
3.2 |
54,000 |
7 |
256 |
3 |
52,000 |
10 |
256 |
3.2 |
53,000 |
これらのテスト実行のためのデータパイプラインは、コンテナログが書き込まれるときに読み込み、ファイル名を解析してメタデータを取得し、Kubernetes メタデータでリッチ化し、データ構造を再フォーマットして、ログを (圧縮せずに) Splunk HEC エンドポイントに送信します。
Fluentdを使用してKubernetesのログを収集する 🔗
また、Fluentdを使ってKubernetesのログを収集し、必要なメタデータのエンリッチメントをすべて行うCollectorに送ることもできます。
ログを収集するためにFluentdを使用する設定に次の行を追加します。
logsEngine: fluentd
イベントを収集する 🔗
Kubernetesイベントの収集 🔗
Kubernetesイベントをチャートの Events Feed セクションの一部として表示するには、splunkObservability.infrastructureMonitoringEventsEnabled を true に設定します。クラスターレシーバーは、kubernetes-events モニターを使用してカスタムイベントを送信するSmart Agentレシーバーで設定されます。
Collector を使用してLog Observer ConnectのログとしてKubernetesイベントを収集するには、設定ファイルに clusterReceiver.k8sObjects を追加し、logsEnabled または true のいずれかで splunkObservability を splunkPlatform に設定する必要があります。イベントは logs パイプラインで処理されます。
clusterReceiver.k8sObjects には以下のフィールドがあります：
name。必須.オブジェクトの名前、例：podsまたはnamespaces。mode。このタイプのオブジェクトがどのように収集される（pullまたはwatch）かを定義します。デフォルトではpullです。pullモードでは、リストAPIを使ってこのタイプのオブジェクトをすべて一定間隔で読み込みます。watchモードは、ウォッチAPIを使った長い接続をセットアップし、アップデートのみを取得します。
namespaces。指定すると、Collectorは指定されたネームスペースからのオブジェクトのみを収集します。既定では、すべてのネームスペースの一致するオブジェクトが含まれます。labelSelector。ラベルでオブジェクトを選択します。fieldSelector。フィールドでオブジェクトを選択します。interval。pullモードにのみ適用。オブジェクトが引き出される間隔。デフォルトでは60秒です。
例：
clusterReceiver.k8sObjects:
- name: pods
mode: pull
label_selector: environment in (production),tier in (frontend)
field_selector: status.phase=Running
interval: 15m
- name: events
mode: watch
group: events.k8s.io
namespaces: [default]
詳細は、Kubernetes オブジェクトレシーバー と Kubernetes objects collection using OpenTelemetry Kubernetes Object Receiver のクラスターレシーバーHelmチャートデプロイメントのGithubドキュメントを参照してください。
journald イベントを収集する 🔗
Splunk Distribution of OpenTelemetry Collector for Kubernetes は、Kubernetes 環境から journald イベントを収集できます。journald イベントを処理するには、以下のセクションを values.yaml 設定に追加します：
logsCollection:
journald:
enabled: true
directory: /run/log/journal
# List of service units to collect and configuration for each. Update the list as needed.
units:
- name: kubelet
priority: info
- name: docker
priority: info
- name: containerd
priority: info
# Optional: Route journald logs to a separate Splunk Index by specifying the index
# value. Make sure the index exists in Splunk and is configured to receive HEC
# traffic (not applicable to Splunk Observability Cloud).
index: ""