![]() It is mainly used to gather metrics.Īn example of what you would get back from a “Metrics” endpoint would be:. the Nagios-style approach) to check on the status of a server/application. It is not the kind of monitoring tool that you’d use to kick off a Bash/Perl/Python/other language script (i.e. Rather than doing checks based upon scripts returning status codes, it gathers metrics from endpoints and stores them in a Time Series Database (TSDB). Prometheus?Īnyone who’s looked into monitoring for the past few years will likely have heard of Prometheus. Not to say it was bad at it, but it is the kind of monitoring tool I would have killed for in my previous career (i.e. Zabbix was good, but I found it did a much better job of networking gear than it did Linux or generic blackbox-style monitoring. Besides, the minimum requirements to run it were more than all the devices in my house combined. I liked the idea of Sensu, but there was no way I could standup Redis and RabbitMQ just for this. I wondered about Icinga2, Check_MK and other Nagios-based tools, but they either added more resource requirements or would still have some of the same issues as Nagios. I looked around to see if anything else could do the job, but I couldn’t realistically just rip down a monitoring stack and plug in a new one, in the hope it was better. Increasing the frequency of the checks would probably tax the little RPI too much. The Firestick would drop out, but by the time Nagios was ready to do another check, the Firestick would have come back (or it would have been rebooted so the kids can see Grampy Rabbit or Chase again). While I had more visibility of what was happening in my home network, the default check times on Nagios made it so I’d actually not see the problems quick enough. Having it flash up in a monitoring system made me put time into actually fixing the issues. I was getting some useful statistics, and it helped me fix a few underlying issues I had either not noticed, and half-ignored to deal with another day. I had monitored all my internal network, as well as my VPS. Using anything more demanding (which given I’ve seen Observium bring a fairly decent spec’d Dell server to its knees) was out of the question. The only “host” I had spare was a Raspberry Pi 2. At least by doing this, I could get more of a handle on Zabbix itself. Other than adding a couple of graphs, I’d had little to no involvement in using or configuring it. We do use Zabbix at my workplace, but it isn’t a primary monitoring tool. However I know it well enough to be able to get an instance up and running, and monitoring all elements of my home network in a couple of hours at most. Also I had to use Debian Buster (well, Raspbian Buster) for my monitoring host as Nagios was pulled from the Debian archives in Debian Stretch, with Debian pushing people to use Icinga2 instead. It has a number of shortcomings, including not being very dynamic and the configuration takes a lot of getting used to. ![]() Nagios is the primary monitoring tool at my current workplace. I used Nagios and Zabbix for three reasons. ![]() This is all in dire need of an update, but not really feasible currently. My home “network” mostly consists of a few Raspberry Pis, a couple of other random ARM boards, and a mish mash of cheap switches (see: unmanaged low end TP Link/Netgear, not old enterprise kit) and routers. This usually happened in the middle of the kids watching Peppa Pig or Paw Patrol. This was in part due to frequent dropouts of an Amazon Firestick. A couple of months ago I decided to start monitoring my home network.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |