Skip to content

OBSDOCS-3446: Document Splunk sourceType configuration#114511

Open
johnwilkins wants to merge 1 commit into
openshift:standalone-logging-docs-mainfrom
johnwilkins:OBSDOCS-3446
Open

OBSDOCS-3446: Document Splunk sourceType configuration#114511
johnwilkins wants to merge 1 commit into
openshift:standalone-logging-docs-mainfrom
johnwilkins:OBSDOCS-3446

Conversation

@johnwilkins

@johnwilkins johnwilkins commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Summary

Documents the new configurable sourceType field for Splunk outputs in ClusterLogForwarder.

Enhancement allows users to specify Splunk source types (pretrained or custom) for better log parsing and categorization.

Changes

Modified Modules

  • logging-forward-splunk.adoc: Added sourceType field documentation with examples and validation warning
  • default-splunk-metadata-key-values.adoc: Updated sourceType row to reflect configurable behavior

New Module

  • logging-splunk-sourcetype-pod-labels.adoc: Procedure showing how to configure sourceType dynamically using pod labels

Key Features Documented

Optional field - defaults to _json when not set
Requires payloadKey - can only be set when payloadKey is also defined
Templating support - static values or dynamic per-event values
Default behavior - _json or generic_single_line depending on payload structure
Important limitation - collector does not validate or interpret source type
Colon character handling - allowed in sourceType but not in pod label values

Examples Provided

  1. Static sourceType: sourceType: 'log4j'
  2. Templated sourceType from pod label: sourceType: '{.kubernetes.labels."splunk/sourcetype"||"generic_single_line"}'

Testing

  • ✅ Vale check passed (0 errors, 0 warnings, 3 suggestions)
  • ✅ DITA compliance verified
  • ✅ Examples based on upstream CLO documentation

Related

Signed-off-by: John Wilkins jowilkin@redhat.com

Enhancement allows users forwarding logs to Splunk to specify the
sourceType with custom values or Splunk's pretrained source types.

Changes:
- Updated logging-forward-splunk.adoc: Added sourceType field
  documentation with examples and important note about validation
- Updated default-splunk-metadata-key-values.adoc: Updated sourceType
  row to reflect configurable behavior when payloadKey is defined
- Created logging-splunk-sourcetype-pod-labels.adoc: New procedure
  showing how to configure sourceType dynamically using pod labels

Key points documented:
- sourceType field is optional
- Requires payloadKey to be set when using sourceType
- Accepts both templated and static values
- Default behavior: _json (or generic_single_line with payloadKey)
- Collector has no logic to interpret sourceType from payload
- Colon characters allowed in sourceType but not in pod label values

Vale results: 0 errors, 0 warnings

Signed-off-by: John Wilkins <jowilkin@redhat.com>

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@openshift-ci-robot

openshift-ci-robot commented Jul 1, 2026

Copy link
Copy Markdown

@johnwilkins: This pull request references OBSDOCS-3446 which is a valid jira issue.

Details

In response to this:

Summary

Documents the new configurable sourceType field for Splunk outputs in ClusterLogForwarder.

Enhancement allows users to specify Splunk source types (pretrained or custom) for better log parsing and categorization.

Changes

Modified Modules

  • logging-forward-splunk.adoc: Added sourceType field documentation with examples and validation warning
  • default-splunk-metadata-key-values.adoc: Updated sourceType row to reflect configurable behavior

New Module

  • logging-splunk-sourcetype-pod-labels.adoc: Procedure showing how to configure sourceType dynamically using pod labels

Key Features Documented

Optional field - defaults to _json when not set
Requires payloadKey - can only be set when payloadKey is also defined
Templating support - static values or dynamic per-event values
Default behavior - _json or generic_single_line depending on payload structure
Important limitation - collector does not validate or interpret source type
Colon character handling - allowed in sourceType but not in pod label values

Examples Provided

  1. Static sourceType: sourceType: 'log4j'
  2. Templated sourceType from pod label: sourceType: '{.kubernetes.labels."splunk/sourcetype"||"generic_single_line"}'

Testing

  • ✅ Vale check passed (0 errors, 0 warnings, 3 suggestions)
  • ✅ DITA compliance verified
  • ✅ Examples based on upstream CLO documentation

Related

  • Upstream implementation: cluster-logging-operator commit e5faaa61b
  • Engineering ticket: LOG-9348 / OBSDA-1383

Signed-off-by: John Wilkins jowilkin@redhat.com

🤖 Generated with Claude Code

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 1, 2026
@openshift-ci openshift-ci Bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 1, 2026
@ocpdocs-previewbot

Copy link
Copy Markdown

@openshift-ci

openshift-ci Bot commented Jul 1, 2026

Copy link
Copy Markdown

@johnwilkins: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@jcantrill

Copy link
Copy Markdown

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jul 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants