i think it really depends on your use case. typically i would prefer to use the native splunk scheduling, but 150+ near identical reports reports being run on the first of each month, interfering with interactive splunk users, and occasionally exhausting cluster resources was not ideal.  im using a scheduled ci-cd process that executes this job in a docker container. ... View more

We have our httpd logs in /var/log/httpd, but some are of a different format. However, they do have consistent naming options, so we have: in /opt/splunkforwarder/etc/apps/search/local/inputs.conf: [monitor:///var/log/httpd/*_log] disabled = false so all files named "*_log" in the folder are monitored, but they might not get the right sourcetype. Within props.conf, we have: [source::/var/log/httpd/http...error_log] sourcetype=apache_error [source::/var/log/httpd/http...access_log] sourcetype=access_common [source::/var/log/httpd/...track_log] sourcetype=track_log That sets the appropriate sourcetype on each. Note that props.conf uses "..." as a wildcard, NOT "*" which might be your problem. ... View more

OK, I've found a workaround now. Basically, setting the options on the dashboard (as well as or instead of in the saved report) means it works on both web and PDF dashboards. In the XML: <option name="numberPrecision">0.000</option> <option name="unit">s</option> It's a bit of a pain to have to define the settings both in the saved search/report and the dashboard, but at least it's a working solution. This seems to work fine for savedsearch, inline search and loadjob within the dashboard. ... View more