Hi, It is possible to generate these types of custom command line metrics using the "smartagent/exec" receiver. https://docs.splunk.com/observability/en/gdi/monitors-databases/exec-input.html It can be tricky to get the format and approach just right, so here are some tips: 1) Put your command in an external script so it's easier to format the output in an acceptable format and it's also easier to format the call from your receiver. The default format is "influx", so an example of the output you want to generate would look like this: printerqueue,printer=myprinter length=5 That output would generate a metric named "printerqueue.length" with a value of 5 and a tagname of "printer" and a tagvalue of "myprinter". Your external script might look like this: #!/bin/sh echo printerqueue,printer=myprinter length=$(lpstat -o | wc -l) 2) You'll need to define a receiver in your OTel config (e.g. agent_config.yaml) receivers: smartagent/exec: type: telegraf/exec command: "/PATH/TO/printerqueue_script.sh" telegrafParser: dataFormat: "influx"   3) Don't forget to place your new receiver in your metrics pipeline and restart your OTel collector: service: pipelines: metrics: receivers: [hostmetrics, otlp, signalfx, smartagent/signalfx-forwarder, smartagent/exec]  

Add the operating system to the list of values returned by stats rather than as one of the group-by options. | stats sparkline(sum(event_count)) AS event_count_sparkline sum(event_count) AS total_events, values(operatingSystem as operatingSystems BY host  

Changing the threshold will restore indexing, but is just kicking the can down the road.  As @PickleRick said, you should find out where the space is being used.  It may be necessary to add storage or reduce the retention time on one or more of the larger indexes. Make sure indexed data is on a separate mount point from the OS and from Splunk configs.  That will keep a huge core dump or lookup file from blocking indexing.

It's typically enough to have 1) Well configured timezone on the server itself 2) You must have the TA_windows on the HF for proper index-time parsing (of course you also need it on SHs - in your case - in your Cloud instance for search-time extractions, eventtypes and so on but that's another story).