Collect logs and events for the Collector for Kubernetes 🔗
注釈
Collector for Kubernetes の設定方法は、Helmで Collector for Kubernetes を設定する および Kubernetesの高度な設定 を参照してください。
Starting on version 0.86.0, the Splunk Distribution of the Collector for Kubernetes collects native OpenTelemetry logs by default.
以下が該当します:
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
複数行のログを処理する 🔗
The Splunk Distribution of the OpenTelemetry Collector for Kubernetes supports parsing of multi-line logs to help read, understand, and troubleshoot the multi-line logs in a better way.
複数行ログを処理するには、values.yaml設定に以下のセクションを追加します:
logsCollection:
containers:
multilineConfigs:
- namespaceName:
value: default
podName:
value: buttercup-app-.*
useRegexp: true
containerName:
value: server
firstEntryRegex: ^[^\s].*
regex101 を使って、フォーマットに合うGolang正規表現を見つけ、設定ファイルの設定オプション firstEntryRegex
で指定します。
アノテーションを使ってログの取り込みを管理する 🔗
Send logs to different indexes 🔗
The Collector for Kubernetes uses main
as the default Splunk platform index. Use the splunk.com/index
annotation on pods or namespaces to indicate which Splunk platform indexes you want to send logs to.
例えば、kube-system
名前空間から k8s_events
インデックスにログを送信するには、コマンドを使用します:
kubectl annotate namespace kube-system splunk.com/index=k8s_events
注釈
A pod annotation takes precedence over a namespace annotation when both are annotated.
ポッドまたは名前空間アノテーションを使用してログをフィルターリングする 🔗
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 エンドポイントに送信します。
Use Fluentd to collect Kubernetes logs 🔗
Alternatively, you can use Fluentd to collect Kubernetes logs and send them through the Collector, which does all of the necessary metadata enrichment.
ログを収集するためにFluentdを使用する設定に次の行を追加します。
logsEngine: fluentd
イベントを収集する 🔗
Kubernetesイベントの収集 🔗
Kubernetesイベントをチャートの Events Feed セクションの一部として表示するには、splunkObservability.infrastructureMonitoringEventsEnabled
を true
に設定します。クラスターレシーバーは、kubernetes-events
モニターを使用してカスタムイベントを送信するSmart Agentレシーバーで設定されます。
To collect Kubernetes events as logs for Log Observer Connect using the Collector, you need to add clusterReceiver.k8sObjects
to your configuration file, and set logsEnabled
to true
in either splunkObservability
or splunkPlatform
. Events are processed in the logs
pipeline.
clusterReceiver.k8sObjects
has the following fields:
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]
For more information, see Kubernetes オブジェクトレシーバー and the Github documentation for the cluster receiver Helm chart deployment at Kubernetes objects collection using OpenTelemetry Kubernetes Object Receiver .
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: ""