Configuration¶

Core Configuration¶

Kafka Receivers¶

Define one or more Kafka receivers. All standard Kafka receiver configuration options are supported. See the SOC4Kafka design documentation for details.

kafkaReceivers:
  - name: main
    brokers:
      - "kafka-broker-1:9092"
      - "kafka-broker-2:9092"
    logs:
      topics:
        - "application-logs"
        - "error-logs"
      encoding: text
    group_id: "soc4kafka-main"

Chart-specific: The name field is required and used to reference the receiver in pipelines.

Note

Kafka authentication passwords (plain_text, SASL, or Kerberos) can reference existing Kubernetes secrets using the secret field. See Secret Management for details.

TLS: For TLS-enabled Kafka brokers (e.g. port 9093), add a tls block. See TLS Configuration for full details and examples.

Splunk HEC Exporters¶

Define one or more Splunk HEC exporters. All standard Splunk HEC exporter configuration options are supported. See the SOC4Kafka design documentation for details.

splunkExporters:
  - name: primary
    endpoint: "https://splunk-hec:8088/services/collector"
    token: "your-splunk-hec-token"
    source: "soc4kafka"
    sourcetype: "otel:logs"
    index: "main"
    tls:
      insecure_skip_verify: false
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 10000
      block_on_overflow: true
      sizer: items
      batch:
        min_size: 1000

Chart-specific: The name field is required and used to reference the exporter in pipelines.

Note

Instead of providing token directly, you can reference an existing Kubernetes secret using the secret field. See Secret Management for details.

TLS: Use https:// in the endpoint for TLS. The same tls options as for Kafka apply. See TLS Configuration.

Queueing and batching: The chart applies HEC exporter defaults from defaults.exporters.splunk_hec. The default queue uses block_on_overflow: true so the collector applies backpressure when Splunk HEC is slow instead of immediately rejecting data at queue capacity. Batching is configured under sending_queue.batch; the default pipelines no longer use the processor batch.

Pipelines¶

Connect receivers to exporters. See the SOC4Kafka design documentation for details.

Chart-specific: You can omit processors; the chart then uses defaults.pipelineProcessors (default: ["resourcedetection"]). Override per pipeline or change the default in values.yaml.

pipelines:
  - name: main-logs
    type: logs
    receivers:
      - main  # Must match a receiver name from kafkaReceivers
    exporters:
      - primary  # Must match an exporter name from splunkExporters
    # processors is optional; defaults to ["resourcedetection"] (see defaults.pipelineProcessors)
    processors:
      - resourcedetection

Advanced Configuration¶

See values.yaml for all available configuration options. Key areas:

TLS (tls.md): Configure TLS for Kafka receivers and Splunk HEC exporters.
Component Defaults (defaults): Override default OpenTelemetry component settings
Config Override (configOverride): Provide complete OpenTelemetry config override
Resources (resources): Set CPU and memory limits/requests
Autoscaling (autoscaling): Configure Horizontal Pod Autoscaler
Pod Disruption Budget (podDisruptionBudget): Configure PDB for high availability
Service Account (serviceAccount): Configure service account with workload identity annotations for cloud environments (AWS EKS, GCP GKE, Azure AKS)
Collector Logs (collectorLogs): Enable collection of the collector’s own logs to files and stdout/stderr
Collector Metrics (collectorMetrics): Enable collection of collector internal metrics and system metrics (CPU, memory, disk, network)

Collector Logs¶

Enable collection of the OpenTelemetry Collector’s own logs. When enabled, logs are written to files in /var/log/otelcol (using an emptyDir volume) and also to stdout/stderr for Kubernetes log aggregation.

By default, when collectorLogs.enabled is true, the chart also forwards these logs to Splunk using a filelog receiver. This allows you to centrally monitor collector logs from multiple instances.

collectorLogs:
  enabled: true
  level: info  # Options: debug, info, warn, error
  outputPaths:
    - /var/log/otelcol/otel-collector.log
    - stdout
  errorOutputPaths:
    - /var/log/otelcol/otel-collector-errors.log
    - stderr
  # Forward collector logs to Splunk (enabled by default when collectorLogs.enabled is true)
  forwardToSplunk:
    enabled: true
    # Reference to an existing splunkExporter by name (uses it directly, no overrides)
    # If not specified, uses the first splunkExporter
    exporter: ""  # Optional: name of splunkExporter to use (e.g., "primary")
  # File storage extension for checkpointing (prevents re-reading logs on restart)
  fileStorage:
    directory: /var/log/otelcol/checkpoint
    createDirectory: true

Features:

Logs are written to files and stdout/stderr
Logs are automatically forwarded to Splunk via filelog receiver
file_storage extension tracks read position to prevent re-reading logs on restart
Internal logs are sent using the referenced Splunk exporter (by default the first one); you can use a dedicated exporter to send them to a separate index for easier analysis
Uses the first splunkExporter’s endpoint and secret by default (can be overridden)

Note

Log files are stored in an emptyDir volume, which means they are ephemeral and will be lost when the pod is deleted. However, logs are forwarded to Splunk, so they are preserved there.

Metrics Collection¶

Enable collection of collector internal metrics and system metrics. When enabled, the chart automatically configures:

Prometheus receiver - Scrapes the collector’s internal telemetry endpoint (exposed on port 8888)
Hostmetrics receiver - Collects system metrics (CPU, memory, disk, network, filesystem, process)
Telemetry service - Exposes collector metrics via Prometheus endpoint
Metrics pipeline - Forwards metrics to Splunk using the first splunkExporter

collectorMetrics:
  enabled: true
  exporter: ""  # Optional: name of splunkExporter to use (e.g., "primary")
  # If not specified, uses the first splunkExporter

Features:

Collector internal metrics exposed via Prometheus endpoint (port 8888)
System metrics collected via hostmetrics receiver (CPU, memory, disk, network, filesystem, process)
Metrics forwarded to Splunk using the referenced splunkExporter (or first if not specified)
Service exposes metrics port for Prometheus scraping
All metrics go through the resourcedetection processor for host filtering

Note

Make sure you have a metrics-type index in Splunk for the metrics data. See the Splunk Dashboard documentation for details.

Advanced Configuration: For custom metrics configuration (different exporter, scrapers, intervals, etc.), use configOverride to override the generated configuration.

Configuration Precedence¶

The chart merges configuration in the following order (highest to lowest priority):

configOverride - Highest priority. Completely overrides any generated configuration. Use this for advanced customizations that can’t be achieved through other means.
Explicit configuration - Values specified directly in kafkaReceivers and splunkExporters override defaults. For example:

kafkaReceivers:
 - name: main
   group_id: "custom-group"  # This overrides defaults.receivers.kafka.group_id

defaults - Lowest priority. Provides default values for receivers, processors, and exporters. These are used when not explicitly specified.

Merge behavior:

mustMergeOverwrite is used, which means values are deeply merged, and explicit values completely replace defaults at the same path
For nested objects, only the specified keys are replaced; other keys from defaults are preserved
configOverride is applied last and can override any part of the generated configuration

Example precedence:

defaults:
  exporters:
    splunk_hec:
      sending_queue:
        enabled: true
        num_consumers: 10
        queue_size: 10000
        block_on_overflow: true
        sizer: items
        batch:
          min_size: 1000

# If you specify in defaults but also in configOverride:
configOverride:
  exporters:
    splunk_hec:
      sending_queue:
        num_consumers: 20  # This wins - configOverride has highest priority

Automatic Pod Restarts¶

The chart includes automatic pod restart triggers:

ConfigMap changes: Pods restart when the OpenTelemetry configuration changes (via checksum/config annotation)
Secret changes: Pods restart when:
Token values in values.yaml change (for auto-created secrets)
Secret references change (via checksum/secrets annotation)

This ensures your collector always runs with the latest configuration and secrets.