51–60 of 122 posts
So... how does this compare to http://riemann.io/ ? I just re-discovered riemann... and was thinking of pairing it with logstash and have a go. It would seem prometheus does something... similar?
I suppose that there's a simple service that we need to deploy on each server?
Any tips on this use case?
Guys, I've seen the libs for collecting services info, but how do I get OS level info, like load average, disk utilization, ram etc..? I suppose that there's a simple service that we need to deploy on each server? Any tips on this use case?
Guys, I've seen the libs for collecting services info, but how do I get OS level info, like load average, disk utilization, ram etc..? I suppose that there's a simple service that we need to deploy on each server? Any tips on this use case?
We support that use case, here's a guide: http://www.boxever.com/monitoring-your-machines-with-prometh...
Not that I'd do a better job, but every time I further configure our monitoring system, I get that feeling that we're missing something as an industry. It's a space with lots of tools that feel too big or too small; only graphite feels like it's doing one job fairly well.
Alerting is the worst of it. Nagios and all the other alerting solutions I've played with feel just a bit off. They're either doing too much or carve out a role at boundaries that aren't quite right. This results in other systems wanting to do alerting, making it tough to compare tools.
As an example, Prometheus has an alert manager under development: https://github.com/prometheus/alertmanager. Why isn't doing a great job at graphing enough of a goal? Is it a problem with the alerting tools, or is it a problem with boundaries between alerting, graphing, and notifications?
> which organizes sample data in chunks of constant size (1024 bytes payload). These chunks are then stored on disk in one file per time series.
That is concerning, is this going to have the same problem with disk IO that graphite does? i.e. Every metric update requires a disk IO due to this one file per metric structure.
From the storage system docs: > which organizes sample data in chunks of constant size (1024 bytes payload). These chunks are then stored on disk in one file per time series. That is concerning, is this going to have the same problem with disk IO that graphite does? i.e. Every metric update requires a disk IO due to this one file per metric structure.
Combine with the Cacti pull model, and I think a wait-and-see attitude is the best for this for now.
It's great to see new entrants into the monitoring and graphing space. These are problems that every company has, and yet there's no solution as widely accepted for monitoring, notifications or graphing as nginx is for a web server. Not that I'd do a better job, but every time I further configure our monitoring system, I get that feeling that we're missing something as an industry. It's a space with lots of tools tha…
I'd think you've hit the nail on the head, every monitoring system has to do a bit of everything such as alerting, machine monitoring, and graphing; rather than focusing on just doing one thing and doing it well.
Prometheus comes with a powerful data model and query language, few existing systems support the same (e.g. Atlas and Riemann have the notion of a query language and labels) so we have to do a bit of everything to produce a coherent system.
I think a separate common alert manager would be good if we could combine, currently in practice that role isn't being done as you rely on de-duplication in a tool such as Pagerduty with support for silencing alerts not being unified.
Guys, I've seen the libs for collecting services info, but how do I get OS level info, like load average, disk utilization, ram etc..? I suppose that there's a simple service that we need to deploy on each server? Any tips on this use case?
We support that use case, here's a guide: http://www.boxever.com/monitoring-your-machines-with-prometh...
> For machine monitoring Prometheus offers the Node exporter
Is it possible for the frontend to utilize data from the cron-invoked sar/sadc that already covers much of this data?
From the storage system docs: > which organizes sample data in chunks of constant size (1024 bytes payload). These chunks are then stored on disk in one file per time series. That is concerning, is this going to have the same problem with disk IO that graphite does? i.e. Every metric update requires a disk IO due to this one file per metric structure.
Chunks are only written to that one file per time series once they are complete. Depending on their compression behavior, they will contain at least 64 samples, but usually a couple of hundreds. Even then, chunks are just queued for disk persistence. The storage layer operates completely from RAM, only has to swap in chunks if it was evicted from memory previously. Obviously, if you consistently create more sample data than your disk can write, the persist queue will back up at some point and Prometheus will throttle ingestion.