3 ms·
> Graphing is not useful for monitoring, its useful for postmortems and planning. I'm sorry, I have to completely disagree with this point. Graphing is a fanta
by deathcakes 13y ago
> Graphing is not useful for monitoring, its useful for postmortems and planning.
I'm sorry, I have to completely disagree with this point. Graphing is a fantastic way of visualising information to show trends, such as disk space growth, or memory usage, which can and have, in our company's case, led to diagnosis of problems that hadn't yet manifested in a complete crash. I realise you add in a comment saying that Nagios should be doing these things internally, which it also should, but what about situations you haven't planned for? Or intermittent events that don't look like anything individually, but when graphed over 6 months turn out to reveal the subtle failure of an aircon unit in a server room?
- falcolas 13y agoMy apologies if I wasn't clear. My intention was to say, with regards to graphing: Graphing should be part of your overall tooling for monitoring boxes, but it should not be part of process monitoring. It should be a separate component (which should in turn be monitored by Nagios), for use in post-mortems and future planning. It should not be built into Nagios, since the graph itself is completely irrelevent to whether Nagios should alert about a problem. I also think that graphing is different from heueristic rate monitoring; graphs are for humans to spot trends/correlations. Alerting on rate changes is a binary alert/don't alert. I.E. Cacti/Graphite should be creating graphs about services for human consumption, Nagios should be watching for problems with services.