μMon: Stupid simple monitoring (2022)
41–50 of 110 posts
Re: μMon: Stupid simple monitoring (2022)
#42I like the focus on simplicity of uMon, and agree with author's criticism of behemoths like Grafana. But looking at the installation instructions[1], I can't help but think that their reluctance to use Docker feels contrarian for no reason (and the quip about it being "out of fashion" completely misguided). This whole procedure could be automated in a Dockerfile, and actually running uMon would be vastly simplified.…
Re: μMon: Stupid simple monitoring (2022)
#43I like the concept of simple monitoring. Simple means it is simple to install, simple to maintain and simple to use. For me, this is netdata. Netdata could be much more, but I just install it on whatever machine and never think about it again. And when something is strange on that machine, I go to http://localhost:19999 and look around.
Re: μMon: Stupid simple monitoring (2022)
#44I like the idea of simplicity and doing exactly what you need. And the single executable. The words "stupid simple" and "C++" together make me scratch my head though. C++ itself is not simple, and you have to recompile if you need to change something (and sometimes you inevitably do), which is slow. I'd likely go with a relatively simple C program that embeds the FFI for RRDtool and other stuff, and embeds Lua, or, b…
Re: μMon: Stupid simple monitoring (2022)
#45I like the focus on simplicity of uMon, and agree with author's criticism of behemoths like Grafana. But looking at the installation instructions[1], I can't help but think that their reluctance to use Docker feels contrarian for no reason (and the quip about it being "out of fashion" completely misguided). This whole procedure could be automated in a Dockerfile, and actually running uMon would be vastly simplified.…
My impression is that it's less about contrarianism and more about
1. the developer opting for installation instructions being consistent across both of the intended targets (Linux and (Open)BSD); and/or
2. μMon being allegedly tiny and simple enough that you're probably best off stuffing it into every one of your containers anyway (i.e. so that said containers can expose their own monitoring interfaces) instead of having a dedicated container for it
> There's an argument to be made that the "Simple" Network Management Protocol they're a fan of is far from being simple either[2]. Configuring the security features of v3 is not a simple task, and entire books have been written about SNMP as well. They conveniently ignore this by using v2c and making access public, which might not be acceptable in real-world deployments.
Agreed here. If SNMP is supposed to be "simple", I'd hate to see what the Complex Network Management Protocol looks like!
(I have a similar peeve about LDAP, on that note; I guess compared to wrappers around it like Active Directory and FreeIPA it's "lightweight", but I dread imagining what a heavyweight directory access protocol would entail)
Re: μMon: Stupid simple monitoring (2022)
#46If I have to deploy this on each machine than it makes no sense. I know SNMP is able to be used like this, but is μMon ?
Re: μMon: Stupid simple monitoring (2022)
#47Anyway, I might still deploy this in a Proxmox homelab where I don't want to fight with the complexity of a grafana dashboard.
Re: μMon: Stupid simple monitoring (2022)
#48Re: μMon: Stupid simple monitoring (2022)
#49Monitoring should be: "central" location with GUI/graphs + agents per bunch of servers. Let me chose from dropdown what I want to see. If I have to deploy this on each machine than it makes no sense. I know SNMP is able to be used like this, but is μMon ?
Re: μMon: Stupid simple monitoring (2022)
#50I like the focus on simplicity of uMon, and agree with author's criticism of behemoths like Grafana. But looking at the installation instructions[1], I can't help but think that their reluctance to use Docker feels contrarian for no reason (and the quip about it being "out of fashion" completely misguided). This whole procedure could be automated in a Dockerfile, and actually running uMon would be vastly simplified.…
> I can't help but think that their reluctance to use Docker feels contrarian for no reason My impression is that it's less about contrarianism and more about 1. the developer opting for installation instructions being consistent across both of the intended targets (Linux and (Open)BSD); and/or 2. μMon being allegedly tiny and simple enough that you're probably best off stuffing it into every one of your containers a…
"What do you get when you cross a mobster with an OSI standard?
You get someone who makes you an offer you can't understand."