Live data from Hacker News

μMon: Stupid simple monitoring (2022)

tomscii.sig7.se

71–80 of 110 posts

Re: μMon: Stupid simple monitoring (2022)

#71
post #20

I was recently looking for an ultra minimal monitoring solution for OpenWrt and other lightweight systems (Pi’s, etc.) and was disappointed not to find one that met my needs (negligible CPU, disk space and RAM). I ended up hacking together a shell script to send data to Home Assistant (via MQTT) which runs on pretty much any system that has at least netcat: https://github.com/roger-/hass-sysmon

why not use https://collectd.org/ which is in C and used by openwrt's luci already along with rrdtool, small in size, low on resource, and has so many plugins already?

I wanted something that would run anywhere with no dependencies. This might work on OpenWrt, but would be trickier to setup on Debian.

Re: μMon: Stupid simple monitoring (2022)

#72
post #60

Earlier quoted context omitted.

> Docker feels contrarian for no reason No, Docker is a mess.

What is it more specifically that you think is a mess? Do you mean the OCI Image Format, Docker Inc, Docker Engine, something else…?

I couldn’t get Docker to run with WSL backend on a freshly installed Windows 11 Pro, a very common use case.

I’m not sure if they even test their own software.

Re: μMon: Stupid simple monitoring (2022)

#73
https://collectd.org/ does the gathering (and writing to RRDTool database, if you so desire) part very well. Many plugins, easy to add more (just return one line of text)

Still need RRD viewere but that's not a huge stack

And it scales all the way to hundreds of hosts, as on top of network send/receive of stats it supports few other write formats aside from just RRD files.

Re: μMon: Stupid simple monitoring (2022)

#74
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.…

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

Oh you sweet summer child that's fucking easiest part of this utter abomination!

Adding anything that's not covered by standard OIDs is a fucking chore. And it is just a string of numbers so you either have to write your own custom OID files and distribute them everywhere OR operate by numbers alone.

And there is no fucking key-value or even fucking labels. If you want to have say distribute a list of arbitrary keys with arbitrary values under hierarchy, the OID will look like

    .1.1.1.1.1: key1
    .1.1.1.1.2: key2
    .1.1.1.1.3: key3
    .1.1.1.2.1: val1
    .1.1.1.2.2: val2
    .1.1.1.2.3: val3
It was created for devices with tens or hundreds kB of RAM that couldn't handle caring about descriptive protocol but it should be dead 20 years ago

Re: μMon: Stupid simple monitoring (2022)

#75
post #11
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…

From my experience, no silver bullets. Let metric software do metric and log software do logs.

At the very least at the database level. Maybe we will get visualisation engine that merges both nicely but database wise the type of data couldn't be any different.

Re: μMon: Stupid simple monitoring (2022)

#76
post #34

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

VictoriaMetrics have all-in-one binary that is pretty easy setup for simple one node install.

Re: μMon: Stupid simple monitoring (2022)

#77
post #11
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…

hey - I work on ML at Netdata (disclaimer).

We have a big PR open and under review at moment that brings in a lot more logs capabilities: https://github.com/netdata/netdata/pull/13291

We also have some specific logs collectors too - i think in here might be best place to look around at the moment, should take you to the logs part of the integrations section in our demo space (no login needed, sorry for the long horrible url, we adding this section to our docs soon but at moment only lives in the app)

https://app.netdata.cloud/spaces/netdata-demo/rooms/all-node...

Re: μMon: Stupid simple monitoring (2022)

#78
post #18

Earlier quoted context omitted.

Back in 2017 when I had a bunch of physical machines and unmanaged VMs we ended up putting netdata on the servers. The reason why was because most of the team was used to manually logging onto servers and diagnosing the issue manually. The reason I liked it was because it exposes a standard Prometheus endpoint I can scrape and then view using something like Grafana. There are only about 20,000 Grafana dashboard modul…

you don't need to scap anything if you use netdata cloud see https://blog.netdata.cloud/introducing-netdata-source-plugin...

we are in process of getting the plugin signed at the moment: https://github.com/netdata/netdata-grafana-datasource-plugin

Re: μMon: Stupid simple monitoring (2022)

#79
post #72
post #60

Earlier quoted context omitted.

What is it more specifically that you think is a mess? Do you mean the OCI Image Format, Docker Inc, Docker Engine, something else…?

I couldn’t get Docker to run with WSL backend on a freshly installed Windows 11 Pro, a very common use case. I’m not sure if they even test their own software.

Windows and WSL are a mess. Run docker on Linux instead. There is no reason to run docker on windows, except if you are planning to build windows containers.

Re: μMon: Stupid simple monitoring (2022)

#80
post #25
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!

Apparently this is possible. I didn't know. Didn't mean to mislead you. Sorry.
Post reply on HN