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…?
You enumerated it yourself.
μMon: Stupid simple monitoring (2022)
91–100 of 110 posts
Re: μMon: Stupid simple monitoring (2022)
#92Earlier quoted context omitted.
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. P…
Just my opinion, but I honestly don't think the scraping model makes much sense. It requires you expose extra ports and paths on your servers that the push model doesn't require. I'm not a fan of the extra effort required to keep those ports and paths secure.
Beyond that, promql is an extra learning curve that I didn't like. I still ran into disk space issues when I used a proper data backend (TimescaleDB). Configuring all the scrapers was overly complicated. Making sure to deploy all the collectors and the needed configuration was rather complicated.
In comparison, deploying Filebeat and Metricbeat is super simple, just configure the yaml file via something like Ansible and you're done. Elastic Agent is annoying in that you can't do that when using Fleet, or at least I have yet to figure out how to automate it. But it's still way easier than the Prometheus stack.
I've tried to get Loki to work 2 or 3 times. Never have really succeeded. I think I was able to browse a few log lines during one attempt, I don't think I even got that far in the other attempts... The impression I came away with was that it was designed to be run by people with lots of experience with it. Either that, or it just wasn't actually ready to be used by anyone not actively developing it.
So, yeah, while I figure a lot of people do well with the Prometheus/Grafana/Loki stack, it just isn't for me.
Re: μMon: Stupid simple monitoring (2022)
#93Earlier quoted context omitted.
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 horri…
I'll see if I can figure out the integrations you pointed out. They look more like they are aimed at monitoring the metrics of the tools, not using the tools to aggregate logs. Right?
The way most ops systems treat logs and metrics as completely separate areas has always struck me as odd. Both are related to each other, and having them in the same system should be default. That's why I've put as much effort into the ELK Stack as I have. They've seemed to be the only ones who have really grasped that idea. (Though it's been a year or two since I've really surveyed the space...)
One question not log related, is it required to sign up for a cloud account to get multiple nodes displaying in the same screen? From the docs on streaming, I think you can configure nodes to send data to a parent node without a cloud account, but I either haven't configured it properly yet, or something else is in the way, since the node I'm trying to set up as a parent isn't showing anything from the child node.
Re: μMon: Stupid simple monitoring (2022)
#94Earlier quoted context omitted.
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)
#95Earlier quoted context omitted.
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 horri…
Nice to see that the log analysis is being worked on. I'll see if I can figure out the integrations you pointed out. They look more like they are aimed at monitoring the metrics of the tools, not using the tools to aggregate logs. Right? The way most ops systems treat logs and metrics as completely separate areas has always struck me as odd. Both are related to each other, and having them in the same system should be…
So, the answer to my question is that you can get multiple nodes showing up without a cloud account. Just have to configure it correctly.
Re: μMon: Stupid simple monitoring (2022)
#96Earlier quoted context omitted.
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. P…
Last time I tried Prometheus was years ago. So I don't know how much might have changed... I gave it a good month or two of effort trying to get the stack to do what I needed and never really succeeded. Just my opinion, but I honestly don't think the scraping model makes much sense. It requires you expose extra ports and paths on your servers that the push model doesn't require. I'm not a fan of the extra effort requ…
There used to be a connector called Promscale that was for sending metrics data from Prometheus to Timescale (using Prometheus’ remote_write) but it was deprecated earlier this year.
Re: μMon: Stupid simple monitoring (2022)
#97Earlier quoted context omitted.
Last time I tried Prometheus was years ago. So I don't know how much might have changed... I gave it a good month or two of effort trying to get the stack to do what I needed and never really succeeded. Just my opinion, but I honestly don't think the scraping model makes much sense. It requires you expose extra ports and paths on your servers that the push model doesn't require. I'm not a fan of the extra effort requ…
The most basic setup, and the one typically used until you need something more advanced, is using Prometheus for scraping and as the TSDB backend. If you ever decide to revisit prometheus, you’ll likely have better luck starting with this approach, rather than implementing your own scraping or involving TimescaleDB at all (at least until you have a working monitoring stack). There used to be a connector called Promsc…
Re: μMon: Stupid simple monitoring (2022)
#98Earlier quoted context omitted.
I wanted something that would run anywhere with no dependencies. This might work on OpenWrt, but would be trickier to setup on Debian.
you can compile with specific plugins and features you need with ./configure and that cuts out most of the dependencies.
Re: μMon: Stupid simple monitoring (2022)
#99I 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)
#100Earlier quoted context omitted.
Microsoft has added basically the same functionality to Power Toys, called Run[0], taking heavy inspiration from Everything. But yeah this should be a built-in utility. [0]: https://learn.microsoft.com/en-us/windows/powertoys/run
Does it read the ntfs journal? Because that's really what makes everything, everything. It makes me wish I used a journaling filesystem on Linux too.
My understanding is that everything uses the file open hooks provided for antivirus to maintain the index, which is why it appears instant.
Adding a millisecond to each open call is imperceptible to the user, and it takes less time than that if you return immediately and process the index update in the background.
[1] happy to be proven wrong.