Live data from Hacker News

μMon: Stupid simple monitoring (2022)

tomscii.sig7.se

41–50 of 110 posts

Re: μMon: Stupid simple monitoring (2022)

#42
post #40

I 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.…

When i read that they thought docker was outdated I figured i would open the repo to find go code and pre built binaries… when i found c++ i was left thinking the same as you.

Re: μMon: Stupid simple monitoring (2022)

#43
post #9

I 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.

The article's complaints include complexity of JS web interfaces and "eye candy", while netdata's UI requires JS, is quite laggy and jerky, very interactive. I think munin fits better (uses the same RRDtool graphs, too), though possibly its configuration is too lengthy for the requirements.

Re: μMon: Stupid simple monitoring (2022)

#44
post #14

I 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…

Simple means simple for the end users. Not necessarily simple for the developers. The end users do not care if the dev has to spend a couple of minutes recompiling, as long as the result is fast and simple to use.

Re: μMon: Stupid simple monitoring (2022)

#45
post #40

I 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 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)

#46
Monitoring 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)

#49
post #46

Monitoring 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 ?

You can easily put together something that will send UDP packets with stats at regular intervals. I’ve done that a number of times - https://github.com/rcarmo/raspi-cluster/blob/master/tools/se...

Re: μMon: Stupid simple monitoring (2022)

#50
post #40

I 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…

Both of those are based on old OSI protocols, which were terrifying in their complexity. LDAP mostly subsetted DAP and X.500 and added Internet concepts. SMNP leveraged ASN.1 with some ideas from CMIP but using Internet concepts and attention paid to operations when the network is marginal (unlike CMIP)

"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."

Post reply on HN