Observability Stack?

21 days ago by dandiandy to c/selfhosted

I'm curious as to which tools and technologies you all are using to keep track of all those services you are deploying, whether it be resource tracking, network traffic, logs, traces, or uptime.

As a bonus question, how have you organized your network or your services to reduce the overhead of implementing observability?

faltryka 22 points 21 days ago

If you’re wanting to go hard in the paint here, Grafana has a great OSS stack with Grafana, Loki, Mimir, Tempo, and Alloy.

path: 0 26031635, hotness: undefined, score: 22, children: 7
NotSteve_ 2 points 20 days ago

Can confirm it's a great stack! We run it at my work and its quite nice to work with. I've been thinking of replacing Prometheus in my homelab with Alloy

path: 0 26031635 26033136, hotness: undefined, score: 2, children: 0
dandiandy 1 point 20 days ago

It looks really compelling. Really flexible with deep options. Seems like I could spend 10 years building the dashboard alone!

path: 0 26031635 26034174, hotness: undefined, score: 1, children: 1
foggy 1 point 20 days ago

I stood up grafana at work, and I make dashboards to keep my role secure.

Everyone uses my shitty little dashboards :)

path: 0 26031635 26034174 26034430, hotness: undefined, score: 1, children: 0
bigmclargehuge 1 point 20 days ago

It’s curios if you used Prometheus as well

path: 0 26031635 26035086, hotness: undefined, score: 1, children: 3
HK65 1 point 20 days ago

Mimir and Alloy are two specialised forks of Prometheus

path: 0 26031635 26035086 26041037, hotness: undefined, score: 1, children: 2
False 2 points 20 days ago

How are they specialized?

path: 0 26031635 26035086 26041037 26042148, hotness: undefined, score: 2, children: 1
HK65 2 points 19 days ago

Mimir is just the DB, no metric scrapers, but it's distributed and capable of high volume ingestion, retention and querying. Can't scrape metrics though.

Alloy has no storage persistence, so it's just the scraper part, but is massively scalable, its basically a Prometheus Agent on steroids. Can do logs, traces, Pyroscope profiles too.

So instead of deploying one server to scrape and store metrics, you deploy one to store and one to scrape.

path: 0 26031635 26035086 26041037 26042148 26060791, hotness: undefined, score: 2, children: 0
hazard_iguana 17 points 20 days ago

Bezsel, simple and easy, constantly having new features added.

path: 0 26032783, hotness: undefined, score: 17, children: 2
dimjim 1 point 18 days ago

I second Beszel, fantastic monitoring platform!

path: 0 26032783 26079519, hotness: undefined, score: 1, children: 0
dandiandy 1 point 20 days ago

Beszel looks really convenient.

path: 0 26032783 26034251, hotness: undefined, score: 1, children: 0
NewOldGuard 12 points 20 days ago

Prometheus, grafana, loki

path: 0 26032922, hotness: undefined, score: 12, children: 1
foggy 3 points 20 days ago

Everything else is just those tools but you're abstracted away from some level of control.

Or ELK.

path: 0 26032922 26034401, hotness: undefined, score: 3, children: 0
Shimitar 10 points 21 days ago

Observawhat? My services just exist, if they fail and nobody complains.... Well, they get removed. If the fail and somebody complains... The get restarted....

Pretty efficient but simple approach.

path: 0 26031426, hotness: undefined, score: 10, children: 2
Toribor 3 points 19 days ago

I got tired of only noticing something was broken when I needed to use it instead of when I was working on things. Now if I make a change I notice issues right away and can fix them.

path: 0 26031426 26048788, hotness: undefined, score: 3, children: 1
Shimitar -1 points 19 days ago

Things usually break on updates unless your disk fills up or worse some hardware fails...

So it's pretty easy to fix: never upgrade automatically.

I always upgrade manually and check immediately what I have upgraded. Works fine so far.

And I was only partially joking... Yeah if a service stays broken for a long time, just uninstall it, it was useless.

path: 0 26031426 26048788 26051700, hotness: undefined, score: -1, children: 0
BlackEco 7 points 21 days ago

I used to run dockprom but it was pretty ressource intensive and I have since moved to Beszel + Uptime Kuma.

I have yet to find a way to keep logs between container re-creation (I unsuccessfully tried to set up Loki back when I ran dockprom), both Beszel and Komodo only display logs from the container currently running in the stack.

path: 0 26031641, hotness: undefined, score: 7, children: 1
nykula 1 point 20 days ago

To have logs from every container launch in journalctl, I have systemd run podman-compose without daemonizing it. To debug container logs, a shell is usually needed anyway, so I see little point in exposing logs through a web dashboard.

path: 0 26031641 26038560, hotness: undefined, score: 1, children: 0
Eggymatrix 7 points 21 days ago

Systemd

path: 0 26031480, hotness: undefined, score: 7, children: 1
nykula 3 points 20 days ago

To add, journal-brief can e-mail you systemd logs. If your apps aren't very noisy, this can be helpful without a need to set up a complex observability stack.

path: 0 26031480 26032681, hotness: undefined, score: 3, children: 0
Cyber 5 points 20 days ago

Uptime Kuma if I want something to alert me (still trying to decide between ntfy & gotify)

Home Assistant is also checking some stuff

Watchdog to reboot my Raspberry Pi Zeros when they fall off the wifi

Smokeping for a general, long term feel of the network, which might answer your bonus question?

path: 0 26032316, hotness: undefined, score: 5, children: 9
krisbalintona 1 point 10 days ago

Did you ever decide on Ntfy vs Gotify?

path: 0 26032316 26210181, hotness: undefined, score: 1, children: 2
Cyber 2 points 10 days ago

Not yet πŸ™‚

Both services work well, but the (Android) app is also a consideration... Gotify appears to keep losing the connection, but as I have different alerts going via different routes I need to sit down and spend some quality time with these, which I don't have at the moment.

path: 0 26032316 26210181 26210439, hotness: undefined, score: 2, children: 1
krisbalintona 1 point 10 days ago

I asked since I recently started using Ntfy and was just curious if you found something in Gotify that's relevant to me

I have different alerts going via different routes I need to sit down and spend some quality time with these, which I don’t have at the moment.

If you mean you send notifications to different services/platforms, you should look into Apprise, which is meant to do exactly this for you but easier supposedly

path: 0 26032316 26210181 26210439 26216127, hotness: undefined, score: 1, children: 0
non_burglar 1 point 20 days ago

Smokeping? In 2026? Jesus....

path: 0 26032316 26032985, hotness: undefined, score: 1, children: 5
Cyber 4 points 20 days ago

What's not to like?

Still alive & still maintained, and less resources than Grafana & Prometheus...

path: 0 26032316 26032985 26036680, hotness: undefined, score: 4, children: 4
non_burglar 4 points 20 days ago

Sorry, no disrespect intended, but I'm shocked. It's like hearing someone say they drive a 1988 Toyota Cressida because it's great... It was great at the time, but we've moved on and the smokeping website should tell you how ancient it is; sponsors from 2007 by companies that don't exist anymore.

Still alive & still maintained

Alive, maybe. I think any maintenance is down to bodges to keep it running in modern environments. Neither Toby nor Niko have worked on sp in over a decade.

Smokeping is fine if all you do is look at its own graphs and you have enough traffic to see patterns in latency.

But:

  • more or less unmaintained for a long time
  • cgi scripts and scraping
  • jitter is estimated from rping, not calculated with real values from more than one point on a route (that means a lot when you have a DMZ)
  • Perl
  • rrd tool is... Not great. Not very configurable, also unmaintained, lua support is not good, etc
  • difficult to customize unless you use their submenu system
  • no reporting, you get what you get with smokeping

I had to retire 2 smokeping monitors because their CGI implementations were security risks. That was 2015. Not a good reason for homelab, but CGI is a pretty ancient and insecure way to interact with the web server.

Smokeping is good in a big organization with lots of traffic and a few broadcast domains. It isn't really great at monitoring remote sites because ICMP doesn't tell you what segment in route is causing the issue, even with rping.

I used smokeping a lot in my career from about 2005 to 2015, when security audits made me retire it. Just even using rrdtool with an exporter and graphana would be preferable to smokeping itself.

path: 0 26032316 26032985 26036680 26040772, hotness: undefined, score: 4, children: 3
nykula 1 point 20 days ago

What's insecure about CGI? I thought the main reason it isn't popular now is because runtimes are slow to start. Though IIRC when I used busybox httpd CGI with a small runtime, quickjs, speed wasn't an issue.

path: 0 26032316 26032985 26036680 26040772 26042343, hotness: undefined, score: 1, children: 1
Cyber 1 point 19 days ago

Sorry, no disrespect intended, but I'm shocked. It's like hearing someone say they drive a 1988 Toyota Cressida because it's great...

How did you know I had an 88 Cressida? (jk)

You have good points there, but for a homelab, it does show some interesting insights (ie, I did an upgrade of my Raspberry Pi Zeros and saw how all their latency changed after the reboot... weird)

I've been using this for years as it just worked, but a recent update has broken it (a simple "v1.10 is earlier than v1.9" issue) and I had to rollback and have been waiting for someone to fix the bug for a few weeks, so, yep, the slowness of response is a fair point.

Ah, dunno, maybe I'll look at some alternatives... one day...

path: 0 26032316 26032985 26036680 26040772 26059713, hotness: undefined, score: 1, children: 0
GMac 4 points 21 days ago

Portainer, beszel, and Whats up docker

path: 0 26031626, hotness: undefined, score: 4, children: 5
Kirk 4 points 20 days ago

I recently switched to Dockhand from Portainer and I like it a lot more, it's much cleaner and straightforward. It also auto-updates so you might be able to ditch whats up docker too.

path: 0 26031626 26031859, hotness: undefined, score: 4, children: 3
GMac 1 point 20 days ago

No auto updates thanks. πŸ˜… I've just reset all my compose files to pin versions today after an unintended mariadb update cost me hours to repair. I'll look into dockhand though. Was unimpressed at portainer's announcement that new version wont have a community edition. Portainer is really just an 'at a glance' view for me since i try to do all the compose and troubleshooting stuff in terminal. Wud will probably become a thing i just review every few weeks to make sure i dont get too adrift from latest.

I ought to look into a unified dashboard as i dont have easy visibility or things like disk usage, sheduled backup success etc that id like to see alongside the container status and beszel activity graphs.

Im still quite new to it all though.

path: 0 26031626 26031859 26031987, hotness: undefined, score: 1, children: 2
Kirk 2 points 20 days ago

Me too lol I thought What's Up Docker was for auto updates. What does it do?

path: 0 26031626 26031859 26031987 26032172, hotness: undefined, score: 2, children: 1
GMac 1 point 20 days ago

For me, its just a board that knows which imagea i am running and tells me if there is a newer one so that i know how out of date i am πŸ˜‚

path: 0 26031626 26031859 26031987 26032172 26032208, hotness: undefined, score: 1, children: 0
N0x0n 1 point 20 days ago

Yeah WUD is a bit underrated, haven't seen it recommended a lot here, but it's actually very good !

path: 0 26031626 26038422, hotness: undefined, score: 1, children: 0
NotSteve_ 4 points 20 days ago

I use Prometheus with various exporters pushed to Grafana which I have displayed on a small screen running on a ROCK Pi in my office

path: 0 26031809, hotness: undefined, score: 4, children: 0
placebo_button 3 points 20 days ago

I asked this of the #homelab fediverse a few weeks back, as I was starting to deploy a family of apps to my "homelab" which is really a raspi3b with a repurposed spinny-platty laptop drive connected to some cloudflare tunnels. I settled on VictoriaLogs and VictoriaMetrics for the actual observing bits, fluentd for a log driver (I'm using docker-compose), and postgres-exporter, node-exporter, and handrolled metrics endpoints for prometheus metrics exposure (victoriametrics can do the metrics scraping itself).

If I were to change anything at the moment, I'd replace fluentd first, as some of the filters I use require the ruby interpreter and that seems a little heavy for my setup. Second I'd probably move to Grafana for dashboards. Alerting is gaping hole in the setup right now; I've used alertmanager in the past and not been particularly happy with it, but I don't have a specific alternative I would suggest at the moment. If I had a much larger deployment, especially spread across multiple nodes, I'd consider ProxMox, but I'm just not there yet.

There were other suggestions that I didn't go too deep into, especially after I got something working sufficiently, including dockhand, gatus and beszel, but so far (and to my surprise) having what I described above all running in containers on this little pi is doing the trick.

path: 0 26039938, hotness: undefined, score: 3, children: 3
nebula 3 points 18 days ago

I'd second this. Victoria metrics and Victoria logs is orders of magnitude better than Prometheus and Loki. However, I'd switch fluent for Vector for logs collection.

path: 0 26039938 26077569, hotness: undefined, score: 3, children: 1
placebo_button 2 points 17 days ago

Ah good to know re:vector. When I have some time I’ll give that a look.

path: 0 26039938 26077569 26081815, hotness: undefined, score: 2, children: 0
dandiandy 2 points 20 days ago

Thanks for sharing. Some good info here.

path: 0 26039938 26043394, hotness: undefined, score: 2, children: 0
NormDeplume 3 points 20 days ago

I've got grafana and Prometheus, but I'm currently working on a generic log pulling script that will then feed to a local ollama instance to summarize the logs and let me know if there are any potential issues I should be aware of. Grafana is great for current state, but I'm a big believer in watching the logs to see trends, but I'm too lazy to do it by hand.

Once that's up and running and steady, I'll probably tie it into ntfy to actually alert me in real time

path: 0 26033558, hotness: undefined, score: 3, children: 4
dandiandy 2 points 20 days ago

Cool, sounds like a fun project.

Not sure if you have been looking into Jev or other System 1 models, but it might be a good fit since it can output a structured type-safe output. Most of the automation I've tried in the past with LLMs failed due to the output structure being hallucinated (ignoring my requested structure). But it sounds like System 1 models might fix that.

I've been looking at an open source model called Laya a little and it might work well for your project. Sounds like you'd want structured output.

What kind of rig do you have ollama running on?

path: 0 26033558 26033999, hotness: undefined, score: 2, children: 1
NormDeplume 2 points 20 days ago

Jev and ollaya are on my list to eventually add. I'm running ollama through an RTX 3080 with 10 gigs of RAM. Just because it's what I had lying around. I was mostly using it for gaming but it works for local model use. I'm also planning on installing Hermes in a bit once the log manager project is done, but that's going to take some careful tinkering because I'm technically underpowered for it. I'm probably just going to have some gate checks up to make sure nothing loads during a gaming session.

My main goal is to completely get off the frontier models if possible because I have concerns about the environmental impacts, especially. As a shameless pirate I mind intellectual theft less, but I really do disagree with the environmental impact, especially when a optimized local model plus a bit of scripting and filtering. Does the job 90% of the time

But we'll see, I'm still tweaking everything, but I think I'm about 90% done with the log normalizer to do most of the heavy lifting act on the logs programmatically, to keep the context window for my local models as optimized as possible.

It's definitely been a good fun learning project

Oh, one of the first things that I implemented was a hallucination checker. If it cites any data that's not actively in one of the corpus I've supplied, it automatically gets flagged and filtered out. But most of what I do can be handled with internal documentation and material I explicitly provide.

path: 0 26033558 26033999 26034077, hotness: undefined, score: 2, children: 0
Lyricism6055 2 points 20 days ago

Loki?

path: 0 26033558 26035019, hotness: undefined, score: 2, children: 1
NormDeplume 2 points 20 days ago

I may eventually add that, but right now my goal isn't the actual logging itself, it's creating a digest and summarizing the logs down to the key points, and eventually getting a notification every morning if something weird showed up. I'm definitely going to add this to my backlog though, thanks for the suggestion

path: 0 26033558 26035019 26039363, hotness: undefined, score: 2, children: 0
blueduck 2 points 20 days ago

I set up homedex alongside portainer and dozzle

path: 0 26032073, hotness: undefined, score: 2, children: 0
rhaidiz 1 point 20 days ago

I use the Grafana stack but I do not self host it. It’s the only thing I use in the cloud with their free offering which is pretty generous and good enough for homelabbing. I have also recently transition away from Alloy to Vector, mainly to give that a try and because the configuration of Vector seems easier and somewhat more intuitive.

path: 0 26038592, hotness: undefined, score: 1, children: 0
selfhosted
selfhosted

@lemmy.world

login for more options
63001
6813
5980

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

go to feed...