Collect logs with the Collector for Kubernetes

Configure logs and events for the Splunk Distribution of OpenTelemetry Collector for Kubernetes.

Note: See how to configure the Collector for Kubernetes at Configure the Collector for Kubernetes with Helm and Advanced configuration for Kubernetes.

Starting with version 0.86.0, the Splunk Distribution of the Collector for Kubernetes collects native OpenTelemetry logs by default.

The following applies:

  • Use version 0.80.0 (or higher) of the Splunk OpenTelemetry Collector to correlate logs and traces in Istio environments.

  • The Collector cannot collect Journald logs natively.

  • Log collection is not supported in GKE Autopilot.

  • See also other rules and limitations for metrics and dimensions. For instance, you can have up to 36 dimensions per MTS, otherwise the data point is dropped.

Add log files from Kubernetes host machines or volumes

To add additional log files to be ingested from Kubernetes host machines and Kubernetes volumes, use agent.extraVolumes, agent.extraVolumeMounts, and logsCollection.extraFileLogs in the values.yaml file used to deploy the Collector for Kubernetes.

The following example shows how to add logs from Kubernetes host machines:

YAML
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

Process multi-line logs

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.

To process multi-line logs, add the following section to your values.yaml configuration:

YAML
logsCollection:
  containers:
    multilineConfigs:
      - namespaceName:
          value: default
        podName:
          value: buttercup-app-.*
          useRegexp: true
        containerName:
          value: server
          firstEntryRegex: ^[^\s].*

Use regex101 to find a Golang regex that works for your format and specify it in the config file for the config option firstEntryRegex.

Manage log ingestion using annotations

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.

For example, to send logs from the kube-system namespace to the k8s_events index, use the command:

BASH
kubectl annotate namespace kube-system splunk.com/index=k8s_events
Note: A pod annotation takes precedence over a namespace annotation when both are annotated.

Filter logs using pod or namespace annotations

If logsCollection.containers.useSplunkIncludeAnnotation is false (default value), set the splunk.com/exclude annotation to true on pods or namespaces to exclude their logs from being ingested. For example:

BASH
# 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

If logsCollection.containers.useSplunkIncludeAnnotation is true, set the splunk.com/include annotation to true on pods or namespaces to only ingest their logs. All other logs will be ignored. For example:

BASH
# 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

Filter source types

Use the splunk.com/sourcetype annotation on a pod to overwrite the sourcetype field. If not set, it will default to kube:container:CONTAINER_NAME.

BASH
kubectl annotate pod -n <my-namespace> <my-pod> splunk.com/sourcetype=kube:apiserver-audit

Review performance benchmarks

Configurations set using the Collector for Kubernetes Helm chart might have an impact on overall performance of log ingestion. The more receivers, processors, exporters, and extensions you add to any of the pipelines, the greater the performance impact.

The Collector for Kubernetes can exceed the default throughput of the HTTP Event Collector (HEC). To address capacity needs, monitor the HEC throughput and back pressure on the Collector for Kubernetes deployments and, if necessary, add additional nodes.

The following table provides a summary of performance benchmarks run internally:

Log generator count

Event size (byte)

Agent CPU usage

Agent 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

The data pipelines for these test runs involved reading container logs as they are being written, then parsing filename for metadata, enriching it with Kubernetes metadata, reformatting the data structure, and sending logs (without compression) to the Splunk HEC endpoint.