3 ms·

Prometheus is absolutely the way you should be going. All of the other systems I'm seeing mentioned here — Nagios, Icinga, check_mk, Zabbix, Sensu — are host-ce

Prometheus is absolutely the way you should be going. All of the other systems I'm seeing mentioned here — Nagios, Icinga, check_mk, Zabbix, Sensu — are host-centric and are very awkward when you try to bend them to fit modern (containerized, etc.) workloads.

falcolas 10y ago
There's always a server. Regardless of how far away you've abstracted it away, there's always a server which should probably be monitored (even if to know when it's about to fail and should have work shunted off it prior to its failure). Icinga and others make it easy to programmatically add and remove servers as they enter and leave your environment. Even if you don't have access to the server so you can monitor it, you can use the "host" concept as containers for your services: "api.mycorp.com", "tasks.mycorp.com", "backups.mycorp.com" are great starting points.
- dozzie 10y ago
  > There's always a server. Actually, no. When you monitor state of a cluster (e.g. node count), you don't have a server, you have plenty of servers and a cluster (completely different thing). When you monitor temperature in your server room, you don't have a server, you have a server room. When you monitor exchange rate, you don't have a server. When you monitor a website, you still don't have a server. And now add all the AWS Lambdas and other serverless rage. Notion that everything works on a (single!) server was never valid, and today it's even more visible than it was twenty years ago, when Nagios was state of the art.
  - athenot 10y ago
    True but in practice it doesn't really matter. With sensu, you have offbox checks, and you just pick some internal server (there's always some "misc" server hanging around). What matters is that the alert about the issue is raised and relayed to the proper notification channels. Since sensu doesn't concern itself with a fancy dashboard, it doesn't really matter if the alert pertains to the host or not. Any decent monitoring will have customized the alert handling based on what's alerting, so there's some amount of post-processing possible.
    - dozzie 10y ago
      > True but in practice it doesn't really matter. In practice it doesn't matter if you name a file handle "juju" and a database query "peach" in your code. It's a matter of calling things what they are instead of forcing them into a mismatched data scheme by creating artificial hosts.
mspaulding06 10y ago
Yeah, containerization is a good point. We've been starting to deploy apps on Docker within the last 6 months. What does Prometheus offer that makes it better for containerization?
- jrv 10y ago
  Mostly, it has great support for service discovery for many major cloud and container platforms (Kubernetes, Marathon, EC2, Azure, Zookeeper, Consul, ...). So it can not only go out and pull metrics data directly from instances as they float around your dynamic cluster scheduler, but also attach identity metadata (as provided by the service discovery) to the time series collected from each instance. For example, you may map EC2 tags or Kubernetes labels into your Prometheus time series labels to give you more useful metrics. There's also a way to plug in your own custom service discovery. Also, Kubernetes exports native Prometheus metrics since quite a while already. Borg inspired Kubernetes. Borgmon inspired Prometheus. So naturally it works well together with a dynamically scheduled world.

falcolas 10y ago

There's always a server. Regardless of how far away you've abstracted it away, there's always a server which should probably be monitored (even if to know when it's about to fail and should have work shunted off it prior to its failure). Icinga and others make it easy to programmatically add and remove servers as they enter and leave your environment. Even if you don't have access to the server so you can monitor it, you can use the "host" concept as containers for your services: "api.mycorp.com", "tasks.mycorp.com", "backups.mycorp.com" are great starting points.

dozzie 10y ago
> There's always a server. Actually, no. When you monitor state of a cluster (e.g. node count), you don't have a server, you have plenty of servers and a cluster (completely different thing). When you monitor temperature in your server room, you don't have a server, you have a server room. When you monitor exchange rate, you don't have a server. When you monitor a website, you still don't have a server. And now add all the AWS Lambdas and other serverless rage. Notion that everything works on a (single!) server was never valid, and today it's even more visible than it was twenty years ago, when Nagios was state of the art.
- athenot 10y ago
  True but in practice it doesn't really matter. With sensu, you have offbox checks, and you just pick some internal server (there's always some "misc" server hanging around). What matters is that the alert about the issue is raised and relayed to the proper notification channels. Since sensu doesn't concern itself with a fancy dashboard, it doesn't really matter if the alert pertains to the host or not. Any decent monitoring will have customized the alert handling based on what's alerting, so there's some amount of post-processing possible.
  - dozzie 10y ago
    > True but in practice it doesn't really matter. In practice it doesn't matter if you name a file handle "juju" and a database query "peach" in your code. It's a matter of calling things what they are instead of forcing them into a mismatched data scheme by creating artificial hosts.

mspaulding06 10y ago

Yeah, containerization is a good point. We've been starting to deploy apps on Docker within the last 6 months. What does Prometheus offer that makes it better for containerization?

jrv 10y ago
Mostly, it has great support for service discovery for many major cloud and container platforms (Kubernetes, Marathon, EC2, Azure, Zookeeper, Consul, ...). So it can not only go out and pull metrics data directly from instances as they float around your dynamic cluster scheduler, but also attach identity metadata (as provided by the service discovery) to the time series collected from each instance. For example, you may map EC2 tags or Kubernetes labels into your Prometheus time series labels to give you more useful metrics. There's also a way to plug in your own custom service discovery. Also, Kubernetes exports native Prometheus metrics since quite a while already. Borg inspired Kubernetes. Borgmon inspired Prometheus. So naturally it works well together with a dynamically scheduled world.