4 ms·

oh boy rrdtool and perl, I feel like I'm in 2002 again

by walrus01 6y ago

Faaak 6y ago
Yeah, I don't really get the point of Munin now that we have things like Zabbix (coupled to grafana) or LibreNMS ?
- oblio 6y ago
  Systems that are already configured and up and running for years have to be maintained and updated.
- tommek4077 6y ago
  Yeah, why would you use a tested system that just "works" if you could add some npm dependencies, node.js and a 3 month old database that is out of support already if you are not upgrading every week?
  - jodrellblank 6y ago
    Zabbix dates back to 2001 and is written in C, PHP and Java. [and in my experience of it, has the typical monitoring system problem where the design seems to be "the more panicky alerts it spews, the more value it's creating"]. https://en.wikipedia.org/wiki/Zabbix https://en.wikipedia.org/wiki/Zabbix
- lotsofcows 6y ago
  It's lightweight, it's flexible, it's hackable and it's very orchestrate-able. I've had dashboards showing summary stats for IoT devices, the VMs they're talking to and the hypervisors the VMs are running on with very little effort.
- maeln 6y ago
  It just work, it is easy to deploy and easy to write plugin for. A combo like prometheus+grafana and other is very good too and definitely more modern. But, having used both, I often didn't need the extra feature that the more modern solution offer and I was more than happy to use munin, which was definitely easier to run and maintain (for me).
- progval 6y ago
  I use(d) both. While I appreciated Zabbix's configurability, it just takes too many clicks to add a basic probe with an alert or a new system. Meanwhile Munin has everything in flat config files (easy to deploy with ansible or equivalent), and has reasonable alerts configured by default. And creating a munin plugin is as simple as writing a script that writes values to stdout (in whichever language you like), and copying it to /etc/munin/plugins/.
  - cduzz 6y ago
    The advantage of zabbix is the templating and service discovery. You shouldn't have to add a new system to anything, it should just be found and monitored. The same goes for prometheus. Monitoring new things with zabbix is also "write a value to stdout". Using telegraf and prometheus you have the same flexibility. I think these days you can even scrape prometheus exposition with zabbix. There are plenty of footguns with prometheus and zabbix, but they take big scale to run into. But at the end of the day use what you're comfortable with.
- jeltz 6y ago
  Because it just works. Grafana requires a lot of work to set up, especially if you want to do it in a secure way and provision it programmatically. Munin on the other hand is just an apt-get install plus some minor configuration. Yes, it is not as powerful but on the other hand it is much eaiser to set up correctly.
goodpoint 6y ago
I LOVE munin. It's the only system that you can: - deploy with an apt-get install - publish to the whole Internet as static pages without any security risk - maintain with OS package updates and zero additional effort In a world of resume-driven development, simplicity and security are the first victims. I wish we had more tools like Munin.
- thesnide 6y ago
  Well, in the upcoming version of Munin, I move away from the static site, as it is very wasteful IMHO. But, I agree that for a couple of servers, the security it procures might overtake the performance boost. Let's add it again: https://github.com/munin-monitoring/munin/issues/1395 https://github.com/munin-monitoring/munin/issues/1395
  - mfontani 6y ago
    I have a munin server for a fleet of a bit more than a dozen servers, and I'd be very sad if the ability to create a static site were to go. That, and the ability to create "overall" charts (same metric for all servers in a group) as well as per-server per-metric charts is what keeps me solidly using munin.
  - pjungwir 6y ago
    Thanks for your work on munin. I love it! And I appreciate your responsiveness here. Personally I don't care if my server wastes time generating HTML I never see. It's not enough work to make any difference. But I care a lot about seeing the HTML instantly when I want it, not waiting for anything to render.

oh boy rrdtool and perl, I feel like I'm in 2002 again

Faaak 6y ago

Yeah, I don't really get the point of Munin now that we have things like Zabbix (coupled to grafana) or LibreNMS ?

oblio 6y ago
Systems that are already configured and up and running for years have to be maintained and updated.
tommek4077 6y ago
Yeah, why would you use a tested system that just "works" if you could add some npm dependencies, node.js and a 3 month old database that is out of support already if you are not upgrading every week?
- jodrellblank 6y ago
  Zabbix dates back to 2001 and is written in C, PHP and Java. [and in my experience of it, has the typical monitoring system problem where the design seems to be "the more panicky alerts it spews, the more value it's creating"]. https://en.wikipedia.org/wiki/Zabbix https://en.wikipedia.org/wiki/Zabbix
lotsofcows 6y ago
It's lightweight, it's flexible, it's hackable and it's very orchestrate-able. I've had dashboards showing summary stats for IoT devices, the VMs they're talking to and the hypervisors the VMs are running on with very little effort.
maeln 6y ago
It just work, it is easy to deploy and easy to write plugin for. A combo like prometheus+grafana and other is very good too and definitely more modern. But, having used both, I often didn't need the extra feature that the more modern solution offer and I was more than happy to use munin, which was definitely easier to run and maintain (for me).
progval 6y ago
I use(d) both. While I appreciated Zabbix's configurability, it just takes too many clicks to add a basic probe with an alert or a new system. Meanwhile Munin has everything in flat config files (easy to deploy with ansible or equivalent), and has reasonable alerts configured by default. And creating a munin plugin is as simple as writing a script that writes values to stdout (in whichever language you like), and copying it to /etc/munin/plugins/.
- cduzz 6y ago
  The advantage of zabbix is the templating and service discovery. You shouldn't have to add a new system to anything, it should just be found and monitored. The same goes for prometheus. Monitoring new things with zabbix is also "write a value to stdout". Using telegraf and prometheus you have the same flexibility. I think these days you can even scrape prometheus exposition with zabbix. There are plenty of footguns with prometheus and zabbix, but they take big scale to run into. But at the end of the day use what you're comfortable with.
jeltz 6y ago
Because it just works. Grafana requires a lot of work to set up, especially if you want to do it in a secure way and provision it programmatically. Munin on the other hand is just an apt-get install plus some minor configuration. Yes, it is not as powerful but on the other hand it is much eaiser to set up correctly.

goodpoint 6y ago

I LOVE munin. It's the only system that you can: - deploy with an apt-get install - publish to the whole Internet as static pages without any security risk - maintain with OS package updates and zero additional effort In a world of resume-driven development, simplicity and security are the first victims. I wish we had more tools like Munin.

thesnide 6y ago
Well, in the upcoming version of Munin, I move away from the static site, as it is very wasteful IMHO. But, I agree that for a couple of servers, the security it procures might overtake the performance boost. Let's add it again: https://github.com/munin-monitoring/munin/issues/1395 https://github.com/munin-monitoring/munin/issues/1395
- mfontani 6y ago
  I have a munin server for a fleet of a bit more than a dozen servers, and I'd be very sad if the ability to create a static site were to go. That, and the ability to create "overall" charts (same metric for all servers in a group) as well as per-server per-metric charts is what keeps me solidly using munin.
- pjungwir 6y ago
  Thanks for your work on munin. I love it! And I appreciate your responsiveness here. Personally I don't care if my server wastes time generating HTML I never see. It's not enough work to make any difference. But I care a lot about seeing the HTML instantly when I want it, not waiting for anything to render.