Provides basic syntax and sanity checking for Splunk’s .conf
files. Use Splunk’s built-in
btool check for a more robust
validation of attributes and values.
Consider using this utility as part of a pre-commit hook.
usage: ksconf check [-h] [--quiet] FILE [FILE ...]
|FILE||One or more configuration files to check. If ‘-’ is given, then read a list of files to validate from standard input|
|--quiet, -q||Reduce the volume of output.|
See Pre-commit hooks for more information about how the
check command can be easily
integrated in your git workflow.
How ‘check’ differs from btool’s validation¶
Keep in mind that idea of valid in ksconf is different than within Splunk. Specifically,
- Ksconf is more picky syntactically. Dangling stanzas and junk lines are picked up by ksconf in general (the ‘check’ command or others), but silently by ignored Splunk.
- Btool handles content validation. The btool check mode does a great job of checking stanza names, attribute names, and values. Btool does this well and ksconf tries to not repeat things that Splunk already does well.
Why is this important?¶
Can you spot the error in this
1 2 3 4 5 6 7 8
[myapp:web:access] TIME_PREFIX = \[ SHOULD_LINEMERGE = false category = Web REPORT-access = access-extractions [myapp:total:junk TRANSFORMS-drop = drop-all
That’s right, line 7 contains the stanza
myapp:total:junk that doesn’t have a closing
How does Splunk handle this? It ignores the broken stanza header completely and therefore
TRANSFORMS-drop gets added
myapp:web:access sourcetype, which will likely result in the loss of data.
Splunk also ignores entries like this:
Of course here there’s no
= anywhere on the line, so Splunk just assumes it’s junk and silently
If you want to see how different this is, run ksconf check against the system default files:
ksconf check --quiet $SPLUNK_HOME/etc/system/default/*.conf
There’s several files that ship with the core product that don’t pass this level of validation.