Quote:
Originally Posted by
Peasant
As for Prometheus, give it a shot, it's not that hard
But i think we already discussed that in past, as long as <insert monitoring> works for you, that is what is most important.
But sometimes drill down is necessary when problem is less obvious and cannot be deduced from graphs.
Regards
Peasant.
Prometheus uses HTTP on the same server where HTTP is the main application under observation. This is from the Prometheus docs:
- a multi-dimensional data model with time series data identified by metric name and key/value pairs
- PromQL, a flexible query language to leverage this dimensionality
- no reliance on distributed storage; single server nodes are autonomous
- time series collection happens via a pull model over HTTP
- pushing time series is supported via an intermediary gateway
- targets are discovered via service discovery or static configuration
- multiple modes of graphing and dashboarding support
I'm not inclined to install an application which relies on HTTP at the data transport layer to monitor a LAMP application where HTTP and apache2 are at the core of the problem. However, for a different scenario, an HTTP-transport based monitoring system might be "just the ticket".
Thanks for the ideas, but I'm sticking with MQTT and Node-RED for the time being. MQTT is very lightweight on the server and it does not use HTTP; but instead uses a light-weight TCP connection, which I prefer, but that is just me.
I complete agree with you that:
- As long as <insert monitoring> works for you, that is what is most important.
- Sometimes drill down is necessary when problem is less obvious and cannot be deduced from graphs.
Except I would change your second comment to read more like:
For all but the most trivial problems, we need to drill down into the system. Time series graphs and charts are only indicators. The story continues past indicators for all but the most trivial issues we encounter .......
I'm pretty sure you agree. After all, if we only needed third party time series graphing tools to solve problems, we could hire 12 year old kids to manage our networks and servers , and we could do other tasks more fun and interesting tasks
But on the other hand, when we work in network and system management (whatever we are doing or where ever we are working), we always encounter new and very interesting problems and the more complex networks become, the more interesting the problems are.