Need advice about which tool to choose?Ask the StackShare community!
Nagios vs Prometheus: What are the differences?
Key Differences between Nagios and Prometheus
Nagios and Prometheus are both popular monitoring tools used in IT infrastructure management, but they differ in various aspects. Let's explore the key differences between Nagios and Prometheus.
Architecture: Nagios is a traditional monolithic monitoring tool, where a single central server collects data from various monitored hosts. In contrast, Prometheus follows a modern microservices-based architecture, where each monitored host runs a Prometheus exporter that exposes metrics to be collected by the Prometheus server. This distributed approach in Prometheus allows for easier scalability and better fault tolerance.
Data model: Nagios uses a passive check approach, where checks are initiated by the central Nagios server, and external plugins or scripts are executed on the monitored hosts to collect data. On the other hand, Prometheus follows a pull-based model, where the Prometheus server periodically scrapes metrics from the exporters on the monitored hosts. This pull-based approach in Prometheus provides real-time monitoring and better flexibility in data collection.
Monitoring language: Nagios primarily uses the Nagios Object Configuration Language (NagiosQL) for defining hosts, services, and their checks. Prometheus, on the other hand, relies on Prometheus Query Language (PromQL) for querying and manipulating collected metrics. PromQL offers a rich set of functions and operators to perform complex queries and aggregations on the collected data.
Data storage: Nagios uses flat file storage for storing monitoring data, which can lead to performance limitations and scalability issues in large-scale deployments. In contrast, Prometheus uses a powerful time-series database to store collected metrics efficiently. The TSDB in Prometheus allows for efficient querying and retention of large volumes of time-series data, making it suitable for long-term monitoring and analysis.
Alerting system: Nagios comes with built-in alerting capabilities, where users can define thresholds and notification rules for triggering alerts. Prometheus, on the other hand, relies on its Alertmanager component for managing alerts. The Alertmanager integrates seamlessly with Prometheus and provides advanced features like deduplication, grouping, and silencing of alerts.
Ecosystem and integrations: Nagios has been in the market for a longer time and has a large community supporting it. It has a wide range of plugins and addons available, making it highly extensible. Prometheus, although relatively newer, has gained significant traction and has a growing ecosystem. It has native integrations with other popular tools like Grafana for data visualization and Kubernetes for monitoring containerized environments.
In summary, Nagios and Prometheus differ in their architecture, data model, monitoring language, data storage, alerting systems, and ecosystem/integrations. While Nagios follows a monolithic design and uses a passive check approach, Prometheus adopts a microservices architecture with a pull-based model for data collection. It also leverages a time-series database, PromQL for querying, and Alertmanager for managing alerts.
Looking for a tool which can be used for mainly dashboard purposes, but here are the main requirements:
- Must be able to get custom data from AS400,
- Able to display automation test results,
- System monitoring / Nginx API,
- Able to get data from 3rd parties DB.
Grafana is almost solving all the problems, except AS400 and no database to get automation test results.
You can look out for Prometheus Instrumentation (https://prometheus.io/docs/practices/instrumentation/) Client Library available in various languages https://prometheus.io/docs/instrumenting/clientlibs/ to create the custom metric you need for AS4000 and then Grafana can query the newly instrumented metric to show on the dashboard.
Hi, We have a situation, where we are using Prometheus to get system metrics from PCF (Pivotal Cloud Foundry) platform. We send that as time-series data to Cortex via a Prometheus server and built a dashboard using Grafana. There is another pipeline where we need to read metrics from a Linux server using Metricbeat, CPU, memory, and Disk. That will be sent to Elasticsearch and Grafana will pull and show the data in a dashboard.
Is it OK to use Metricbeat for Linux server or can we use Prometheus?
What is the difference in system metrics sent by Metricbeat and Prometheus node exporters?
Regards, Sunil.
If you're already using Prometheus for your system metrics, then it seems like standing up Elasticsearch just for Linux host monitoring is excessive. The node_exporter is probably sufficient if you'e looking for standard system metrics.
Another thing to consider is that Metricbeat / ELK use a push model for metrics delivery, whereas Prometheus pulls metrics from each node it is monitoring. Depending on how you manage your network security, opting for one solution over two may make things simpler.
Hi Sunil! Unfortunately, I don´t have much experience with Metricbeat so I can´t advise on the diffs with Prometheus...for Linux server, I encourage you to use Prometheus node exporter and for PCF, I would recommend using the instana tile (https://www.instana.com/supported-technologies/pivotal-cloud-foundry/). Let me know if you have further questions! Regards Jose
We're looking for a Monitoring and Logging tool. It has to support AWS (mostly 100% serverless, Lambdas, SNS, SQS, API GW, CloudFront, Autora, etc.), as well as Azure and GCP (for now mostly used as pure IaaS, with a lot of cognitive services, and mostly managed DB). Hopefully, something not as expensive as Datadog or New relic, as our SRE team could support the tool inhouse. At the moment, we primarily use CloudWatch for AWS and Pandora for most on-prem.
this is quite affordable and provides what you seem to be looking for. you can see a whole thing about the APM space here https://www.apmexperts.com/observability/ranking-the-observability-offerings/
I worked with Datadog at least one year and my position is that commercial tools like Datadog are the best option to consolidate and analyze your metrics. Obviously, if you can't pay the tool, the best free options are the mix of Prometheus with their Alert Manager and Grafana to visualize (that are complementary not substitutable). But I think that no use a good tool it's finally more expensive that use a not really good implementation of free tools and you will pay also to maintain its.
Grafana and Prometheus together, running on Kubernetes , is a powerful combination. These tools are cloud-native and offer a large community and easy integrations. At PayIt we're using exporting Java application metrics using a Dropwizard metrics exporter, and our Node.js services now use the prom-client npm library to serve metrics.
The objective of this work was to develop a system to monitor the materials of a production line using IoT technology. Currently, the process of monitoring and replacing parts depends on manual services. For this, load cells, microcontroller, Broker MQTT, Telegraf, InfluxDB, and Grafana were used. It was implemented in a workflow that had the function of collecting sensor data, storing it in a database, and visualizing it in the form of weight and quantity. With these developed solutions, he hopes to contribute to the logistics area, in the replacement and control of materials.
- free open source
- modern interface and architecture
- large community
- extendable I knew Nagios for decades but it was really outdated (by its architecture) at some point. That's why Icinga started first as a fork, not with Icinga2 it is completely built from scratch but backward-compatible with Nagios plugins. Now it has reached a state with which I am confident.
Pros of Nagios
- It just works53
- The standard28
- Customizable12
- The Most flexible monitoring system8
- Huge stack of free checks/plugins to choose from1
Pros of Prometheus
- Powerful easy to use monitoring47
- Flexible query language38
- Dimensional data model32
- Alerts27
- Active and responsive community23
- Extensive integrations22
- Easy to setup19
- Beautiful Model and Query language12
- Easy to extend7
- Nice6
- Written in Go3
- Good for experimentation2
- Easy for monitoring1
Sign up to add or upvote prosMake informed product decisions
Cons of Nagios
Cons of Prometheus
- Just for metrics12
- Bad UI6
- Needs monitoring to access metrics endpoints6
- Not easy to configure and use4
- Supports only active agents3
- Written in Go2
- TLS is quite difficult to understand2
- Requires multiple applications and tools2
- Single point of failure1