cacti icon indicating copy to clipboard operation
cacti copied to clipboard

Improve logging for up/down events

Open bmfmancini opened this issue 5 years ago • 12 comments

Hey Guys

One thing that would be good to see is a new log for Up/Down events currently, when a device goes down it shows up in the error log which can be misleading thinking the system has tons of errors I believe cacti related errors should go in the cacti.log and a new log i.e device_status should be created that hold these events to make log searching more clear

Thanks !

bmfmancini avatar Apr 27 '20 13:04 bmfmancini

I kinda agree, kinda disagree. If you look at the installer, I have separate sections for different areas of the installer all going to install-*.log when it's enabled. However, the only log file I ever ask for is install-complete.log which has everything.

So, I think if you want that separate log, it should go in both places but there would need to be again some house keeping for that. Under OS packages, debian-based and redhat-based systems tend to use logrotate, so the packagers would need to be notified, and we would also have to create our own inhouse entries for when people use our sources rather than OS packages.

This then has the best of both worlds. You can see the status' via the entire log (I have customers who continually check for green logs only!), and you can also get the "clean" version for the status log in its own right.

netniV avatar Apr 27 '20 13:04 netniV

Interesting point never considered the package level dependencies

bmfmancini avatar Apr 27 '20 14:04 bmfmancini

yeah looking at it more what's missing is when you filter the error section you will see the site down but not the restore stamp in the same view you would have to switch views so if we have a different category/file you would see all the pertinent info for that sites up/down timestamp in the same view this makes it easier I think to see all the events in one view

bmfmancini avatar Apr 27 '20 17:04 bmfmancini

All those logs are included in the Monitor plugin. Next one to merge into Core I'm guessing (along with Notification Lists). But monitor is dependent on Thold. So, it's complicated.

TheWitness avatar Apr 28 '20 23:04 TheWitness

Parts of monitor are. But basic functionality is not.

netniV avatar Apr 29 '20 13:04 netniV

I think that monitor should be part of core the functions it has are what you would expect from a monitoring system out of the box without adding an additional plugin my opinion of course I feel the same way about THOLD as well but I know that adds to the complexity of the code base and issue tracking all from one repo could be messy

but from a feature set monitor and thold are what you would expcect out of the box

bmfmancini avatar Apr 29 '20 14:04 bmfmancini

Technically, it's a graphing system not a monitoring system but hard to tell that these days 👍

netniV avatar Apr 29 '20 15:04 netniV

Yea I think cacti has grown passed just a graphing system I would say the vast majority of users use cacti to monitor their devices rather than just get a graph

Hope your keeping well

bmfmancini avatar Apr 29 '20 15:04 bmfmancini

Ya, I don't want to merge Thold in as is, as I was planning a complete rewrite of it. Long ago I had started it, so we had completely dynamic alerts with escalation paths (and other plugins could add their own alert types), but I never finished. With the current world situation, we will see if I have a bit of extra free time to start on it.

cigamit avatar Apr 29 '20 15:04 cigamit

Monitor itself was just suppose to be a display of Up / Down with audio alert. I think any alerting on up / down in it should be striped out and added to the core (along with notification lists). Leave Monitor itself out of the core though.

cigamit avatar Apr 29 '20 15:04 cigamit

That sounds reasonable.

netniV avatar Apr 29 '20 19:04 netniV

Agreeing whole hartedly.

TheWitness avatar Apr 29 '20 23:04 TheWitness