Time after (Up)time
Time after (Up)time It’s one of the days that an unsung hero gets his chance to make a mark on the world.And who might this be? The floor function , also called the greatest integer function or integer value (Spanier and Oldham, 1987), gives the largest integer less than or equal to x. The floor function is not-normally implemented in the LM perspective – often brushed off, but it got its day when we had a user on chat who was looking on creating a dashboard which has server uptime in days instead of seconds. And so I tried devising a Big Number Widget that would include a virtual datapoint in it with the following calculation to display seconds into days: Fig1. Initial UptimeDays setup without the floor() function. UptimeSeconds/60/60/24 Where UptimeSeconds references a pre-calculated Complex Datapoint from the WinSystemUptime Datasource. Alas – this was not presenting days in a helpful manner. It was displaying days with a decimal point. Quoting from the chat : “that uptime display widget you created would be grand if it showed the days. it says 0,4 at the minute, does that meant 0.4 days?” And so we needed to figure onanother method. A colleague of ours, a wizard from the magical realm of complex datapoints pointed out to us something powerful, that could display seconds, minutes and days even – And, with this, the second hand unwinds... By using the floor() function appended to the original expression – we could actually calculate: The day rounded to the nearest lowest integer. floor(UptimeSeconds/ 60/ 60 /24) For example if we had the result of 2.4 days from the UptimeSeconds/6000/60/24 calculation – it will present us the result as 2 – to the smallest following integer. Fig2. Complex Datapoints for Days, Hours and Minutes with the floor function And on the Hours Datapoint: floor((UptimeSeconds-(days*86400))/3600) Where 86400 represents the number of seconds in a day – 60 * 60 *24 = 86400. and 3600 represents the number of seconds in an hour - 60 * 60 =3600. This calculates the number of total hours (excluding the amount already converted and apportioned into the Days metric) , and again the floor function rounds the number hours to the smallest following integer. For example - 2.4 days- 0.4 is then carried over to the hours, which equates to 9.6 hours, and with the application of the floor function it will reflect 9 hours, with the balance of 0.6 hours to be calculated on the Minutes Datapoint. And lastly on the Minutes Datapoint: floor((UptimeSeconds-(days*86400)-(hours*3600))/60) Where 86400 represents the number of seconds in a day – 60 *60 *24 = 86400. and 3600 represents the number of seconds in an hour - 60 * 60 =3600. and 60 represents the number of seconds in a minute. This does the same again, number of total minutes excluding those previously factored in the days (*24) and and the hours (*60), rounded to the smallest following integer. And therefore, the floor() function has been very useful in this case to catch the Days, Hours and Minutes, have them precisely presented on the Big Number Widget - which the team could display on the dashboard to wait on -- Time after Time. Fig 3. Uptime Days,Hours and Minutes on the Big Number Widget References: https://www.logicmonitor.com/support/datasources/creating-managing-datasources/datapoint-expressions/ http://mathworld.wolfram.com/FloorFunction.html Credits to David Lee for pointing out on the powerful capabilities of the floor function.6Views0likes0Comments
Simple Truth About Complex Datapoints
Logicmonitor can be used in ways that at first glance look too complicated to do without some magical programming powers. A chat that we had recently is summed up below. Quote One of our servers has an application that maxes out the CPU at 100% and brings down everything. This results in subsequent polls returning No Data or NaN (NaN means Not a Number). We have alerts on high cpu usage and we have alerts on No Data, but no combination of the two. If we see a No Data alert we have to look at the CPU Data from before NaN start and determine whether it was at 100% before failure.We would like an alert when the cpu is at 100% and the next poll being NaN (system being unresponsive due to the high CPU usage) At first glance this may look like something Logicmonitor cannot support natively except via a complex script based datasource. But this can be done with just a complex datapoint. Complex datapoints use mathematical formulas to generate the metric required from other regular datapoints in a datasource. if(un(counterA),0,counterA) This expression will return zero if value of counterA is NaN (not a number, such as absence of data, data in non-numerical format, or infinity). If value of counterA is anything other than NaN (some number), then that number will be returned. So if the percentage datapoint was called, cpupercent, wetake this as the counter we are going to look at, create a complex datapoint, "deltacpupercent" with an expression of if(un(cpupercent),-1,cpupercent) Basically this means if the cpupercent is a number return the number otherwise return -1. If the cpu polls at 85 deltacpupercent would be 85. If the cpu polls at 100 deltacpupercent would be 100. If the cpu polls NaN deltacpupercent would be -1. So setting an alert on a delta change of >100 would alert when the system went unresponsive due to a 100% cpu condition, going from 100 to -1 in one poll. However, there's an even easier method in reality. Fromusing the alert threshold wizardhelp page: absolute NaNDelta - works the same as absolute delta, but treats NaN values as 0 Setting this to alert on 100 would alert if the cpu went from 100 to NaN, but I prefer my complex solution as it gives you the opportunity to alert on a variety of things like keeping the current cpu usage alerts. --- Content contributed by David Lee, TSE UK team30Views0likes0Comments