AJ's Blog

Monitor Your apps and systems with Telegraf + Prometheus

Telegraf makes it easy to collect many types of metrics and you only configure what you need. Prometheus makes metric storage effortless. Together they form a monitoring stack you can run anywhere Docker works.

By the end of this post you’ll have:

• Telegraf exporting metrics at /metrics
• Prometheus scraping those metrics every 10 seconds
• A foundation you can plug into Grafana for dashboards

Prometheus can scrape metrics for you directly but sometimes applications are written to emit metrics when an event occurs and telegraf can aggregate those metrics for you. If your application has tens or hundreds of servers all emitting metrics, telegraf can help you aggregate those metrics before they are stored in prometheus (or another system to store time-series data). Otherwise you would need prometheus to scrape hundreds of different endpoints or only collect a sample of metrics from something like a load balancer endpoint.

Store metrics with Grafana Mimir

Grafana Mimir is a powerful, horizontally scalable, multi-tenant long-term store for Prometheus metrics. In this post, we’ll spin up a lean, monolithic Mimir stack with Docker Compose. We’ll use local filesystem storage for quick experiments, plus Prometheus for scraping and Grafana Alloy for collecting and forwarding telemetry. I have used this project to store metrics from over 6 different Kubernetes Clusters in one central data repository (Mimir in this case).

Monitor Your Linux System with the Elastic Stack

With the Elastic Stack (formerly known as ELK Stack) and Docker Compose, you can set up a powerful monitoring solution that is also equipped to scale as a backend document database for modern software applications. I am giving it another go in 2025 since I use Elastic in my current job. If you have never heard of Elasticsearch (which is fair if you do not work in software development), check out a previous post for a brief overview of how to get started.

Ghostty Terminal Emulator

Why I Finally Switched Terminal Emulators After a Decade

It’s rare that I change the core tools in my daily workflow. For years, my terminal emulator has been as constant as my morning coffee. A terminal emulator is how developers interact with their computers using text-based commands, connect to remote servers via SSH, and navigate the depths of their operating systems. For someone like me who opens SSH sessions multiple times a day (and has for decades), the terminal is second-nature when using a computer.

Monitor Debian Linux with Grafana Alloy

I have most systems using grafana alloy for logs that send to a loki server. It can also collect metrics and eliminate the prometheus node exporter as a separate install. In a previous post I migrated my systems that used Grafana Promtail -> Grafana Alloy. I have used those projects to collect log events from my Linux servers at home. They can also collect logs from Docker containers and forward log events to another server which in an older post I set up Grafana Loki to store log events from all of my servers, containers, and applications that could support this system.

Fedora 43 upgrade

Today is a spooky day and Fedora 43 has been released as of October 29, 2025. This release is a bit spooky with the default desktop environment only supporting Wayland. Typically there are 2 Fedora releases per year. I upgraded to 42 earlier this year in a previous post and this process is going to be the same.

There are a few notable user visible changes in this release. When installing from the ISO installation image there is a new Anaconda WebUI. This was the default installer interface for Fedora Workstation 42, and now it’s the default installer UI for the Spins as well. If you are a GNOME desktop user, you’ll also notice that the GNOME is now Wayland-only in Fedora Linux 43. GNOME upstream has deprecated X11 support, and has disabled it as a compile time default in GNOME 49. Upstream GNOME plans to fully remove X11 support in GNOME 50.