4 ms·

I understand your pain. I used to have sensu, but it was a pain to keep updated (and didn't work that well on old rpis) But what I did find was a good alterna

I understand your pain. I used to have sensu, but it was a pain to keep updated (and didn't work that well on old rpis) But what I did find was a good alternative was telegraph->some sort of time series (I still really like graphite, influxQL is utter horse shit, and prometheus's fucking pull models is bollocks) Then I could create alert conditions on grafana. At least that was simple. However the alerting on grafana moved from being "move the handle adjust a threshold, get a a configurable alert" to craft a query, get loads of unfilterable metadata as an alert. its still good enough.

cyberpunk 1y ago
Why is the pull model bollocks? I’ve been building monitoring for stuff since nagios and zabbix were the new hot tools; and I can’t really imagine preferring the oldschool ways vs the pretty much industry standard of promstack these days…
- KaiserPro 1y ago
  Zabbix is bollocks. so is nagios. Having remote root access to all your stuff is utter shite. Prometheus as a time series DB is great, I even like its QL. What I don't like is pull. Sure there is agent mode or telegraf/grafana agent. But the idea that I need to hold my state and wait for Prometheus to collect it is utterly stupid. The biggest annoyance is that I need to have a webserver somewhere, with a single god instance(s) that can reach out and touch it. Great if you have just one network, but a bollock ache if you have any kind of network isolation. This means that we are using influxdb and its shitty flux QL (I know we could upgrade, but thats hard)
  - cyberpunk 1y ago
    eh in a standard three tier you’re usually okay to pull up and push down aren’t you? Run it in the lower network.. Were all kubernetes these days so i guess i didn’t think about it a lot in recent years.
  - nullify88 1y ago
    AFAIK, you can now send OpenTelemetry directly to Prometheus. So effectively it supports both push and pull models.
    - dengolius 1y ago
      AFAIK, OpenTelemetry has never been effective compared to Prometheus.
- mystifyingpoi 1y ago
  Both models are totally fine, for their specific use cases.

cyberpunk 1y ago

Why is the pull model bollocks? I’ve been building monitoring for stuff since nagios and zabbix were the new hot tools; and I can’t really imagine preferring the oldschool ways vs the pretty much industry standard of promstack these days…

KaiserPro 1y ago
Zabbix is bollocks. so is nagios. Having remote root access to all your stuff is utter shite. Prometheus as a time series DB is great, I even like its QL. What I don't like is pull. Sure there is agent mode or telegraf/grafana agent. But the idea that I need to hold my state and wait for Prometheus to collect it is utterly stupid. The biggest annoyance is that I need to have a webserver somewhere, with a single god instance(s) that can reach out and touch it. Great if you have just one network, but a bollock ache if you have any kind of network isolation. This means that we are using influxdb and its shitty flux QL (I know we could upgrade, but thats hard)
- cyberpunk 1y ago
  eh in a standard three tier you’re usually okay to pull up and push down aren’t you? Run it in the lower network.. Were all kubernetes these days so i guess i didn’t think about it a lot in recent years.
- nullify88 1y ago
  AFAIK, you can now send OpenTelemetry directly to Prometheus. So effectively it supports both push and pull models.
  - dengolius 1y ago
    AFAIK, OpenTelemetry has never been effective compared to Prometheus.
mystifyingpoi 1y ago
Both models are totally fine, for their specific use cases.