<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Monitoring on Sohil Ladhani Blog</title><link>https://sohilladhani.com/blog/tags/monitoring/</link><description>Recent content in Monitoring on Sohil Ladhani Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 19 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://sohilladhani.com/blog/tags/monitoring/index.xml" rel="self" type="application/rss+xml"/><item><title>Push vs Pull Metrics Collection: Two Ways to Get the Numbers</title><link>https://sohilladhani.com/blog/post/2026-03-19-push-vs-pull-metrics-collection/</link><pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate><guid>https://sohilladhani.com/blog/post/2026-03-19-push-vs-pull-metrics-collection/</guid><description>You have 200 microservices. Each produces metrics. How do those metrics reach your monitoring system? Two fundamentally different approaches, and the choice affects service discovery, failure modes, and scalability.
Pull Model (Prometheus-Style) Each service exposes a /metrics endpoint. The monitoring system knows about all services (via service discovery) and scrapes each one on a schedule: every 15 seconds, hit /metrics, parse the response, store the data.
// Spring Boot Actuator exposes metrics automatically // GET /actuator/prometheus returns: // http_server_requests_seconds_count{method=&amp;#34;GET&amp;#34;,uri=&amp;#34;/api/users&amp;#34;} 1523 // http_server_requests_seconds_sum{method=&amp;#34;GET&amp;#34;,uri=&amp;#34;/api/users&amp;#34;} 45.</description></item><item><title>Downsampling: Keeping Trends, Not Every Data Point</title><link>https://sohilladhani.com/blog/post/2026-03-18-downsampling-and-data-retention/</link><pubDate>Wed, 18 Mar 2026 00:00:00 +0000</pubDate><guid>https://sohilladhani.com/blog/post/2026-03-18-downsampling-and-data-retention/</guid><description>Your monitoring system stores CPU usage every second. That&amp;rsquo;s 86,400 data points per day per metric. For 1,000 metrics across 200 services, you&amp;rsquo;re generating 17 billion data points per day. Storage isn&amp;rsquo;t free, and nobody will ever look at per-second data from three months ago.
But you can&amp;rsquo;t just delete it. &amp;ldquo;What was our error rate trend last quarter?&amp;rdquo; is a legitimate question. You need the trend without the granularity.</description></item><item><title>Time-Series Databases: Storage Built for Timestamps</title><link>https://sohilladhani.com/blog/post/2026-03-17-time-series-databases/</link><pubDate>Tue, 17 Mar 2026 00:00:00 +0000</pubDate><guid>https://sohilladhani.com/blog/post/2026-03-17-time-series-databases/</guid><description>Every second, your system emits: CPU usage, memory, request count, error rate, latency percentiles, queue depth. Multiply by 200 services. That&amp;rsquo;s hundreds of thousands of data points per second, all append-only, all timestamped, and you mostly query them by time range.
Regular databases can handle this, technically. But they weren&amp;rsquo;t built for it.
What Makes Time-Series Different The access pattern is extreme. Writes are almost entirely appends: new data comes in, old data never changes.</description></item></channel></rss>