<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Loki on heezy.blog</title><link>https://heezy.blog/tags/loki/</link><description>Recent content in Loki on heezy.blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 22 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://heezy.blog/tags/loki/index.xml" rel="self" type="application/rss+xml"/><item><title>The LGTM Stack: Monitoring a Homelab Like It's Production</title><link>https://heezy.blog/posts/lgtm-monitoring-stack/</link><pubDate>Sun, 22 Mar 2026 00:00:00 +0000</pubDate><guid>https://heezy.blog/posts/lgtm-monitoring-stack/</guid><description>&lt;p&gt;The monitoring stack runs on a dedicated VM at 10.x.x.x (shared-lgtm), deliberately separate from the Kubernetes cluster it watches. If the cluster goes down, the thing watching it needs to still be running. Seven containers in a single Docker Compose stack handle metrics collection, log aggregation, long-term storage, tracing, and dashboards with alerting. The whole thing is deployed and configured by a single Ansible role (&lt;code&gt;roles/lgtm/&lt;/code&gt;) with Jinja2 templates for every config file. Push a change, GitHub Actions runs the playbook, Ansible templates the configs and restarts the stack. This post covers what each component does, what gets scraped, and how alerting works.&lt;/p&gt;</description></item></channel></rss>