{"id":180,"date":"2017-05-13T12:33:32","date_gmt":"2017-05-13T11:33:32","guid":{"rendered":"https:\/\/www.octamis.com\/octamis-blog\/?p=180"},"modified":"2017-05-15T00:48:22","modified_gmt":"2017-05-14T23:48:22","slug":"monitoring-system-load-average-with-nmon-performance","status":"publish","type":"post","link":"https:\/\/www.octamis.com\/octamis-blog\/monitoring-system-load-average-with-nmon-performance\/","title":{"rendered":"Monitoring system load average with Nmon Performance"},"content":{"rendered":"

For my own development purposes, I am using a great Linux VPS server from vpsdime.com, their offer is great and cheap, 4 vCPUS, 6GB of memory and 30 GB of disk for 7$ per month, nice.<\/p>\n

Cool isn’it ? But… there is a “but”, yesterday\u00a0I received this kind of message:<\/p>\n

\n

Excessive load on your virtual machine,\u00a0your VM has been running above acceptable load limits for an extended period of time<\/h2>\n<\/blockquote>\n

Oops\u00a0! Ok, so let’s have a detailed look at the terms of service:<\/p>\n

To ensure the best performance for all of our customers, we enforce the following limits:<\/p>\n

– Your VPS should not have a load average of 4 for more than one hour, or Your VPS will get restarted.<\/p>\n

– Your VPS should not have a load average of 2 for more than two hours, or Your VPS will get restarted.<\/p>\n

–\u00a0Our system will automatically suspend VPSs with 5 minute load average more than 30.0<\/p><\/blockquote>\n

All right, that’s a job for Nmon and Splunk no ? Let’s have some amazing monitoring and be warmed before they shutdown my server !<\/p>\n

SYSTEM LOAD AVERAGE<\/span><\/h2>\n

vpsime reports in my client area an RRD chart of my system load average:<\/p>\n

\"\"<\/a><\/p>\n

We can see the famous peak of load at the beginning of the chart, when I received the ticket issue, I got an attached file with the current situation:<\/p>\n

\"\"<\/a><\/p>\n

Nmon Performance application reports the system load average using the “nmon external” features, this allows integrating any non nmon metric in the nmon processing, such that the data is naturally parsed with the nmon metrics and easily made available to Splunk.<\/p>\n

See:<\/strong>\u00a0http:\/\/ta-nmon.readthedocs.io\/en\/latest\/external.html<\/a><\/p>\n

The “NMON SUMMARY OVERVIEW”\u00a0dashboard exposes the load average statistics:<\/strong><\/p>\n

\"\"<\/a><\/p>\n

Cool \ud83d\ude09<\/p>\n

We also have the picture in the “NMON DARK MONITORING” dashboard:<\/strong><\/p>\n

\"\"<\/a><\/p>\n

Let’s have a look at the SPL search behind those dashboards:<\/strong><\/p>\n

eventtype=nmon:performance type=UPTIME (host=\"splunkdev\")\r\n| timechart `nmon_span` avg(load_average_1min) as load_average_1min, avg(load_average_5min) as load_average_5min, avg(load_average_15min) as load_average_15min\r\n<\/pre>\n
Pretty simple.<\/p>\n
The terms of service have a notion of duration, so my alerting must be able to fire\u00a0not only if I have an excess in the load average, but as well if the duration of that peak exceeds the terms of service.<\/p>\n
Nmon Performance embeds various alerting features that use the “transaction” commands to provide smart monitoring, not only if have a peak, but if that peak excesses a given amount of time.<\/p>\n
That’s cool, and this is what I need, having a look at the “HOWTO Interface”, an pre-built example is provided using over the CPU usage statistics:<\/strong><\/p>\n
\"\"<\/a><\/p>\n
All right, more or less what I need but we have the logic here, so let’s start to work on our search.<\/strong><\/p>\n
BUILDING OUR ALERT<\/span><\/h2>\n
Let’s start by searching for our events, and filtering out any event with a load average lower than 2, which is our first level of condition:<\/strong><\/p>\n
eventtype=nmon:performance type=UPTIME (host=\"splunkdev\")\r\n| where load_average_5min>=2\r\n<\/pre>\n
\"\"<\/a><\/p>\n
Not too bad, let’s add some streamstats stuff to compute the hourly load average and creating a “state” field on it:<\/strong><\/p>\n
| streamstats avg(load_average_5min) as average_load_per_hour time_window=60m\r\n| eval average_load_state=case(average_load_per_hour>=4, \"excess_load_4\", average_load_per_hour>=2, \"excess_load_2\" )\r\n<\/pre>\n
\"\"<\/a><\/p>\n
 <\/p>\n
So far so good, what if we use some transaction stuff to compute our duration and groups our events:<\/strong><\/p>\n
| transaction host average_load_state maxpause=60m\r\n<\/pre>\n
\"\"<\/a><\/p>\n
 <\/p>\n
This starts to look nice isn’t it ?<\/p>\n
Let’s add some conditions to respect our 2 main conditions for alerting:<\/strong><\/p>\n
| table _time host average_load_state duration\r\n| where ( average_load_state=\"excess_load_2\" AND duration>(60*60*2) ) OR ( average_load_state=\"excess_load_4\" AND duration>(60*60*1) )\r\n<\/pre>\n
\"\"<\/a><\/p>\n
And some improvements to understand the duration value:<\/strong><\/p>\n
| eval duration_nb_hours=round(duration\/3600, 2), duration_string=tostring(duration, \"duration\")\r\n<\/pre>\n
\"\"<\/a><\/p>\n
That looks good ! Let’s make an alert that will run every 5 minutes over last 4 hours, send me an email in case of an excess\u00a0load average:<\/strong><\/p>\n
\"\"<\/a>
\n\"\"<\/a>
\nEt voila ! I should be warmed before they shutdown my server !<\/p>\n
What the about last critical condition when the load excesses 30 ?<\/strong><\/p>\n
Well, this one is a quite simple condition and has no duration notion, a simple dedicated alert based on the value would do the job:<\/strong><\/p>\n
eventtype=nmon:performance type=UPTIME (host=\"splunkdev\")\r\n| where load_average_5min>=30\r\n| stats latest(_time) as _time, latest(load_*) AS \"load_*\" by host\r\n| fields host, _time, load_average_1min, load_average_5min, load_average_15min\r\n<\/pre>\n
However, as they would instantly suspend the service, I would probably be keen to reduce the value and get an alerting starting half of this value, ending with a 15 load average for instance:<\/strong><\/p>\n
eventtype=nmon:performance type=UPTIME (host=\"splunkdev\")\r\n| where load_average_5min>=30\r\n| stats latest(_time) as _time, latest(load_*) AS \"load_*\" by host\r\n| fields host, _time, load_average_1min, load_average_5min, load_average_15min\r\n<\/pre>\n
Enjoy \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
For my own development purposes, I am using a great Linux VPS server from vpsdime.com, their offer is great and cheap, 4 vCPUS, 6GB of memory and 30 GB of disk for 7$ per month, nice. Cool isn’it ? But… there is a “but”, yesterday\u00a0I received this kind of message: Excessive load on your virtual […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,9,6,3,2,5],"tags":[19,17,14,13,12,11,10,18,15],"_links":{"self":[{"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/posts\/180"}],"collection":[{"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/comments?post=180"}],"version-history":[{"count":8,"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/posts\/180\/revisions"}],"predecessor-version":[{"id":215,"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/posts\/180\/revisions\/215"}],"wp:attachment":[{"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/media?parent=180"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/categories?post=180"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.octamis.com\/octamis-blog\/wp-json\/wp\/v2\/tags?post=180"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}