hi,
I use Nagios today to monitor "problem" related things, like servers downtime, apps that stopped responding, etc, and all this monitorings fire alerts on Nagios and trigger Jira tickets to the support team.
but would it be possible to tell Nagios to record things that are not problems, and keep the information so I could see it in the reports and timelines?
for example, I use Jenkins to make my deploys, and so, Jenkins jobs connects to my servers, stop my apps services, uploads the new version, and starts the app service back. I would like to notify Nagios things like: "jenkins stopped app1 service on serverX", "jenkins uploaded app1 version 1.1.x to serverX", "jenkins started app1 service on serverX", or... "Jira ticket NNN closed related to Database team group", or... "sensitive application configuration changed by user via web console".
none of those "events" were problems. they happed as demanded, and they finished with success. but I wanted they shown along with other Nagios alerts, so it could help the alerts analysis. for example, imagine Nagios detect and app crash minutes after a redeploy, of a CPU overload after a configuration change. that could be a helping clue, right?
but as long as I could find, Nagios only records "problems", "alerts", "incidents", and there is no way to tell him things that happened sucessfully. I know I could just store good-events as "problems" with a nice prefix name like "[EVENT-INFO]" or something,... but I think there is a better way to do this.
any suggestions?
thanks in advance.
use Nagios to record arbitrary (non-problem) events?
-
cesardevera
- Posts: 2
- Joined: Wed Nov 26, 2014 7:47 am
Re: use Nagios to record arbitrary (non-problem) events?
When you say "record", do you mean send out an email? If you want an email for every check, you may want to look at Volatile Services:
http://nagios.sourceforge.net/docs/3_0/ ... vices.html
You may need to combine this with passive checks to get it working exactly how you want, but this is a good start in the right direction.
http://nagios.sourceforge.net/docs/3_0/ ... vices.html
You may need to combine this with passive checks to get it working exactly how you want, but this is a good start in the right direction.
Former Nagios employee
-
cesardevera
- Posts: 2
- Joined: Wed Nov 26, 2014 7:47 am
Re: use Nagios to record arbitrary (non-problem) events?
no. by "record" I meant store those "non-problem events" along with the alerts so they would appear in the alert reports or timeline.
what I need is to know what else happened in a certain time-frame beyond the alerts/problems.
today, when I check the alert history, I just see that there was a service slowdown, or a cpu overload. but I need to know IF there was a new deploy/release right before the alert, for example. the deploy itself was a sucessful operation, not a problem. but it may have caused a problem later. I wanted to see in the same web report (alert history, timeline, whatever), both alerts/problems and "non-problem events".
and to have this, I was thinking I could use Nagios to store both problems and non-problems information (because it already have reports to query such data).
today, I could just send this non-problem events as "problem events" to nagios, and everything would show up in the reports together. but a sucessful deploy is not a problem. should not raise alerts, emails, etc. what would be perfect is if nagios could have an INFO type of alert. today it has only "warning" or "critical", and both are expected to be fixed. my "info" alerts would just be "informational" and would not trigger anything, nor be expected to be handled. they should only have to be stored along with the other alerts and appear nicelly in the reports.
what I need is to know what else happened in a certain time-frame beyond the alerts/problems.
today, when I check the alert history, I just see that there was a service slowdown, or a cpu overload. but I need to know IF there was a new deploy/release right before the alert, for example. the deploy itself was a sucessful operation, not a problem. but it may have caused a problem later. I wanted to see in the same web report (alert history, timeline, whatever), both alerts/problems and "non-problem events".
and to have this, I was thinking I could use Nagios to store both problems and non-problems information (because it already have reports to query such data).
today, I could just send this non-problem events as "problem events" to nagios, and everything would show up in the reports together. but a sucessful deploy is not a problem. should not raise alerts, emails, etc. what would be perfect is if nagios could have an INFO type of alert. today it has only "warning" or "critical", and both are expected to be fixed. my "info" alerts would just be "informational" and would not trigger anything, nor be expected to be handled. they should only have to be stored along with the other alerts and appear nicelly in the reports.
Re: use Nagios to record arbitrary (non-problem) events?
It would take a bit of overhaul to add in and account for a fifth state in Nagios, but you could probably get away with making those "informational" states into UNKNOWN states. That way they will still show up but don't have to be treated specifically as problems.
Former Nagios employee
Re: use Nagios to record arbitrary (non-problem) events?
I don't know if there is an easy way to do this with Nagios by itself.
NDOUtils could be an option if you are wiling to write custom reports. ndo2db can store all check results to a DB, but you need to think about storage since the tables can grow quickly.
If you don't want the DB, the ndomod (the part of NDOUtils in core) can write to a file, and it can be configured to only write check results. The text data format may be harder to write reports against.
NDOUtils could be an option if you are wiling to write custom reports. ndo2db can store all check results to a DB, but you need to think about storage since the tables can grow quickly.
If you don't want the DB, the ndomod (the part of NDOUtils in core) can write to a file, and it can be configured to only write check results. The text data format may be harder to write reports against.