Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

μMon: Stupid simple monitoring (2022)

tomscii.sig7.se

Post reply on HN
Print view View original

31–40 of 110 posts

Re: μMon: Stupid simple monitoring (2022)

#31

Post by abrookewood »

ahofmann wrote: 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.

Netdata deserves way more attention. It automatically configures itself with all relevant modules, runs very lean and has more information available than most people will ever need.

Re: μMon: Stupid simple monitoring (2022)

#32

Post by abrookewood »

dave8088 wrote: post #6
kburman wrote: post #5

I really like the idea behind μMon. It reminds me of when software was simpler. I remember using a program called "Everything" by voidtools. It was small but could search a lot of files quickly. Nowadays, some projects use big tools like Elasticsearch just to search a few things. Some even use PostgreSQL, a big database, for small tasks. I wish more software would keep things simple.

“Everything” is a must have for me. It’s shocking that Windows doesn’t come with local search that works.

Yep, if you run Windows and don't have that installed, you're just suffering for no reason. Fastest file search you will ever find.

Re: μMon: Stupid simple monitoring (2022)

#33

Post by thinkmassive »

jerrac wrote: post #11
ahofmann wrote: 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.

Not sure I haven't run across it before, but this is the first time I've tried using Netdata. Looks like it is very good for metrics, at least in the 10 minutes I have spent installing it on my local desktop and poking around the ui there. I'm not seeing anything in it for logs, though. I'm guessing it doesn't aggregate or do anything with logs? What do you use for log aggregation and analysis? I'm very interested be…

Prometheus has become ubiquitous for a reason. Exporting metrics on a basic http endpoint for scraping is as simple as you can get.

Service discovery adds some complexity, but if you’re operating with any amount of scale that involves dynamically scaling machines then it’s also the simplest model available so far.

What about it doesn’t work for you?

Edit: I didn’t touch on logging because the post is about metrics. Personally I’ve enjoyed using Loki better than ELK/EFK, but it does have tradeoffs. I’d still be interested to hear why it doesn’t work, so I can keep that in mind when recommending solutions in the future.

Re: μMon: Stupid simple monitoring (2022)

#34

Post by golem14 »

Looks nice. I would like to use something like this to remotely monitor machines. Currently use Prometheus (but without Grafana), since the alerting and built-in graphing is sufficient.

But agree with OP that Prometheus feels more complex than need be for simple use cases. But so does sendmail ;)

Re: μMon: Stupid simple monitoring (2022)

#35

Post by rsyring »

xrd wrote: post #16
ahofmann wrote: 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.

I've been struggling with graphana and netdata looks so much better. Is this a tool where you can boot up the docker app and then connect a bunch of servers into a centralized dashboard? Or, is it better to think of netdata as a dashboard for a single server that permits monitoring of a bunch of processes only on that machine? I'm not sure I understand whether agents can be configured to talk to a dashboard, or if yo…

They have a concept called "Parents":

> A “Parent” is a Netdata Agent, like the ones we install on all our systems, but is configured as a central node that receives, stores and processes metrics data from other Netdata “Child” nodes in our infrastructure...

https://learn.netdata.cloud/docs/streaming/

Re: μMon: Stupid simple monitoring (2022)

#36

Post by doubled112 »

xrd wrote: post #27
xrd wrote: post #25

Earlier quoted context omitted.

Drat. I'm only interested in things I can self host. Back to the drawing board. Thanks for the clarification!

Maybe what I want is nachos? https://www.nagios.org/

Or Zabbix. I’m assuming Nachos is a funny typo.

https://www.zabbix.com/

Re: μMon: Stupid simple monitoring (2022)

#37

Post by pphysch »

This doesn't seem much simpler than Prometheus+Grafana, if it all.

Some pushback:

- SNMP sucks. It's very limited, difficult to secure, etc. I've spent a lot of time with it, and it's more complex than Prometheus' simple HTTP metrics model. I use it where I have to (non-server devices), but I prefer dealing with Prometheus.

- Grafana is not necessarily complex. It's powerful, and you can waste a lot of time overinvesting in dashboard design, but that's not required. It can be used quite elegantly.

μMon does seem like "old school for the sake of old school". SNMP and RRDTool were designed when memory & bandwidth were much more limited. I will happily trade the overheads of HTTP and static Go binaries for the much superior UX they offer.

Re: μMon: Stupid simple monitoring (2022)

#38

Post by lukevp »

xrd wrote: post #25
dizhn wrote: post #21

Earlier quoted context omitted.

If you connect your servers to the netdata cloud, you can manage all of them there. (Put into groups etc). As far as I know there is no self hosted solution for this. https://learn.netdata.cloud/docs/configuring/connect-agent-t...

Drat. I'm only interested in things I can self host. Back to the drawing board. Thanks for the clarification!

You can self host and centralize configuration with netdata parents [1]. It’s extremely lightweight and efficient for metrics collection, and the UI is very good as well. I recommend giving it more in depth analysis.

[1] https://community.netdata.cloud/t/advice-on-self-hosted-self...

Re: μMon: Stupid simple monitoring (2022)

#39

Post by v3ss0n »

kburman wrote: post #5

I really like the idea behind μMon. It reminds me of when software was simpler. I remember using a program called "Everything" by voidtools. It was small but could search a lot of files quickly. Nowadays, some projects use big tools like Elasticsearch just to search a few things. Some even use PostgreSQL, a big database, for small tasks. I wish more software would keep things simple.

Whats wrong is Postgres? It is very simple yet very powerful. Can run on very minimal resources , without hogging your CPU

Re: μMon: Stupid simple monitoring (2022)

#40

Post by imiric »

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. Docker itself is not much more than a wrapper around Linux primitives, and if they dislike it specifically for e.g. having to run a server and run containers as root, there are plenty of other lighterweight container alternatives.

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.

I'm all for choosing "simple" tools and stacks over "complex" ones, for whatever definition of those terms one chooses to use, and I strive to do that in my own projects whenever possible, but simplicity is not an inherent property of old and battle-tested technologies. We should be careful to not be biased for technology we happen to be familiar with, but be pragmatic about picking the right tool for the job that fits our requirements, regardless of its age or familiarity.

[1]: https://tomscii.sig7.se/umon/#Installation%20and%20getting%2...

[2]: I have a pet peeve about tools or protocols with "simple" or "trivial" in their name. They almost always end up being the opposite of that as they mature, and the name becomes an alluring mirage tricking you into its abyss of hidden complexity. I'm looking at you SMTP, TFTP...

Post reply on HN