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?

you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 20 hours ago* (4 children)

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?

  • source
  • hideshow 4 child comments
  • [–] 0 points 19 hours ago (3 children)

    Smokeping? In 2026? Jesus....

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 12 hours ago (2 children)

    What's not to like?

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

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 4 hours ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 2 hours 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.

  • source
  • parent