Hello everyone,
I'm introducing in splunk, and I have a question about Timecharts, it is possible to create a timechart per every single device?
For example, I created a timechart with this:
| datamodel release_management_info flat
| search Location=* AND Model=*
| timechart span=month distinct_count(Name) by Category
But this doesn't cover all devices as some of them haven't created events in a few months.
No. Splunk search has its range. So if you're searching "from last thursday till today", Splunk will not return events from two months ago. It's simply not in the scope of the search. And how would Splunk know that there are supposed to be events from some source? It's not in the index so it's not found. Hence the lookup trick in the article which @richgalloway pointed you to.
If a device has not created an event within the search window then Splunk will not find the device and timechart cannot display it. Finding something that is not there is not Splunk's strong suit. See this blog entry for a good write-up on it.
https://www.duanewaddle.com/proving-a-negative/
But, is there any way to do this condition?: if there is no event from this device this month, take an event from last month and get all data from this month as a copy, using eval with tstats
To know what devices are missing, Splunk needs a list of known device names. It will not seek names out automatically. That is why the linked article uses a lookup table. You also could use another search to collect the names.
<<your current search that produces a 'deviceName' field>>
| eval found = 1
| append [ index=foo earliest=-2mon latest=-1mon
| fields + deviceName
| dedup deviceName
]
| stats values(*) as * by deviceName
| where found == 1
No. Splunk search has its range. So if you're searching "from last thursday till today", Splunk will not return events from two months ago. It's simply not in the scope of the search. And how would Splunk know that there are supposed to be events from some source? It's not in the index so it's not found. Hence the lookup trick in the article which @richgalloway pointed you to.