Version 3 introduces a new search analytic to Logscape’s arsenal, the Post-Aggregate function. This feature is designed to give the user more control over each individual search, allowing them to perform multiple functions on a value by aliasing the result of one function, into another value which can be given as an argument for another function. Allowing you to chain a value through several analytics to obtain your desired effect.
Today I’m going to walk through an example of how to use Post-Aggregate functions inside Logscape, hopefully it will be both insightful, and show you how Post-Aggregates can be used to improve your own dashboards. We’re already using them inside the Univa Grid Engine app, and some of our own monitoring workspaces.
Aliasing a result.
Post-Aggregate functions rely entirely upon aliased fields, that is to say the output of one function, which has had a name mapped to it.
I perform a search for the max _minute in each bucket, over the past 30minutes. You can see on the right that this value is being displayed as _minute
* | _minute.max() buckets(1m)
I add an alias to the _minute.max() function, changing it to _minute.max(,maxMinute), you can see on the right that the value is now being displayed as maxMinute.
* | _minute.max(,maxMinute) buckets(1m)
Modifying my search yet again, I now add a new function call, this time I’m calling .gt(10), but rather than using a discovered, synthetic or system field, I’m using the new aliased field I just created. maxMinute.gt(10).
* | _minute.max(,maxMinute) buckets(1m) maxMinute.gt(10)
While it’s likely you’re thinking of your own scenarios where post-aggregates could be useful to your organization, here’s a run through of a couple used in our office.
One of the searches used on our development environments monitoring dashboard is quite simple, it maps the average cpu utilisation across the environment, we’ve found that when glancing at a chart it was easier to see an environment wide statistic, and drill down if anything caught our eye. That search looks like this.
The issue with a chart like this, is something is continually happening, and we have to use 50 and 100 percent lines in order to give scale to the data. In reality we’re not all that interested in CPU values when they’re this low. While low CPU can be an indicator of an issue, in this case we’re looking for high CPU values, using Post-Aggregates we can transform this search, so we only need one bar for scale, and it only shows data when it’s matching the criteria of “The processor is on fire”.
As it turns out, our environment is quite healthy, and environment wide CPU hasn’t exceeded the 80% limit implemented through avgCpu.gt(80), for the sake of demonstration let’s drop that down to 15%.
You can now see a single blip on the chart, and taking a look, you can see that at 14:22 the environment wide average reached 18% CPU utilization.
In this scenario Post-Aggregate functions mean we only see data on our monitoring dashboards when it’s relevant to us. Post-Aggregates are great for removing data we’re not interested in from a search, for another example, take the UnixApp homepage.
The system load chart gives plenty of information about the load throughout our environments. However there is lots of noise. The search used in this chart is
* | _type.equals(unx-load) 1m.max(_host) chart(c3.line-zero)
However, using post-aggregate functions we can remove the unnescary noise. Say we’re only interested in seeing the load when it is in excess of 1.5, we can change the search to.
* | _type.equals(unx-load) 1m.max(_host,maxLoad) chart(c3.line-zero) maxLoad.gt(1.5)
Now our search only shows data when it reaches a threshold we’re interested in.
We believe that Post-Aggregates are going to provide you with plenty of opportunity to modify your searches and workspaces. We look forward to hearing how they’re being used in your environments. Post aggregates are part of Logscape 3, click here to download Logscape for free.