Thank you for all the time you spent helping with this! ... View more

So I would like to mark all of these as answers because I learned something in each bit, then you could mark me as a poor explainer for not being crisp on the challenge!  If you are up for it I wanted to take one more shot. There are agents across machines that bring in data every day, multiple times a day.  There are also scans that take place across the environment that bring back similar data, but only occur every few days.  A view of any one system is the aggregate of the distinct data for a system associated with the information collected from both the host and network.  All of this data is organized in the same manner in splunk.  Because data comes in different groupings, an accurate view at any moment in time requires that you look back several days.  This is so you can make sure and count those issues that show up in the data less frequently.   As example – data for 4 days might look like (using a 3 day look back to make the amount of data less): Day 1 – just information from host scans are fed in, data from splunk would contain: System A (e.g. system name), issue A (e.g. vuln xxx), severity (e.g. high/medium/low), status (e.g. opened, closed etc..) System B, issue A, severity, status System C, issue C, severity, status System A, issue A, severity, status System B, issue A, severity, status System C, issue C, severity, status   ** Note that the data is collected multiple times   Day 2 – similar result with systems reporting in multiple times a day System A, issue A, severity, status System B, issue A, severity, status System C, issue C, severity, status System A, issue A, severity, status System B, issue A, severity, status System C, issue C, severity, status   Day 3 – Similar but we now have something introduced from the network scan (All in Blue) System A, issue A, severity, status System B, issue A, severity, status System C, issue C, severity, status System A, issue A, severity, status System B, issue A, severity, status System C, issue C, severity, status System A, issue D, severity, status System A, issue E, severity, status System B, issue F, severity, status System C, issue G, severity, status   Day 4 – similar result with systems reporting in multiple times a day System A, issue A, severity, status System B, issue A, severity, status System C, issue C, severity, status System A, issue A, severity, status System B, issue A, severity, status System C, issue C, severity, status   The goal is to go across 3 days to get the number of distinct issues on a system then aggregate the issue counts across all systems into counts by severity.  On any one system you should end up with an issue counted only once, but across systems the issue may show multiple times.   I can accomplish this with no problem when I am looking back to create an output for any single day.  But my skills quickly deteriorate if I want to show a historical view of open issues in the environment in a time chart.  Your first answer: index=_internal sourcetype=splunkd source=*/splunkd.log* earliest=-14d@d latest=@d | timechart fixedrange=f span=1d count as subtotal by log_level | untable _time log_level subtotal | streamstats time_window=7d sum(subtotal) as total by log_level | timechart span=1d max(total) as total by log_level | where _time>relative_time(relative_time(now(), "@d"), "-7d@d") worked beautifully, with the one exception that it would count a single issue on a host multiple times as it rolled back across the days.  I did some digging and did not see a way to deduplicate later in the process so that for any one set of days you are counting each open system issue only once.  So in the new example: Day one would be a lookback of days 1-3.  For each system you would only count issue xx once across that time span.  You would then count each individual systems issues and group that by severity.  So System A would only show Issue A once even though it appeared 3 times.  System B might also have issue A, in which case it would be counted once as well.  Day two would be a lookback of days 2-4. Etc…. ... View more

I slightly misspoke in the last post.  While it would be a count of 5 total, it would actual be a subcount by severity.  So for instance: a=critical b= high c=high d=medium f=low Would then actually give me a single set for that view across the 7 days (which would be an accurate picture of the current state) of 1 (critical), 2 (high), 1 (medium), 1 (low)  ... View more

Thank you for the help and introducing me to the untable command.  This was very close and I am playing with it to see if I can solve the one remaining issue.  The summary over the 7 days is perfect, but I need to dedup within that 7 days and then aggregate.  For instance: Day1: a,b,c Day 2: a,b,c,d Day 3: a,b,f Day 4-7: a,b,c I should end up across those 7 days with a distinct count of 5 (a,b,c,d,f).  I don't think I can reduce after the timechart so am playing with eventstats there.  Much appreciated if you have further time/guidance.   ... View more