<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: RGJorge</title><link>https://news.ycombinator.com/user?id=RGJorge</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 18 May 2026 09:11:18 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=RGJorge" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by RGJorge in "Traceway: MIT-licensed observability stack you can self-host in ~90s"]]></title><description><![CDATA[
<p>The "easy to set up" framing usually skips the hardest part: whether the metric you're alerting on is meaningful. Most stacks pull container memory from cAdvisor's `container_memory_usage_bytes`, which is the 
same broken `memory_stats.usage` that `docker stats` reports — includes the kernel's reclaimable page cache. For DB containers with hot working sets, that metric stays at 95%+ constantly. Beautiful Grafana 
dashboards alerting on a structurally wrong number. The fix is   computing real anonymous memory (subtract active_file + inactive_file) — most stacks leave that as a custom exporter exercise. Curious how Traceway handles this out of the box.</p>
]]></description><pubDate>Wed, 13 May 2026 14:12:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=48122170</link><dc:creator>RGJorge</dc:creator><comments>https://news.ycombinator.com/item?id=48122170</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48122170</guid></item></channel></rss>