Here we go… another weird sidecar container.

Motivations

I’ve always been interested in the observability area. There are many aspects that improve performances and fix bugs. One of the most interesting is network usage.

This is not about network issues:

It’s about understanding where bandwidth is actually going.

You’re probably used to seeing something like this for your VMs:

When I first got into IT, devices ran continuously. My first lab was an impressive tower from 1999 with substantial disk and memory banks, a quality CPU cooled by a massive copper heatsink and a 12cm fan. During the night, those components produced noise comparable to a helicopter. Neighbors complained. I didn’t sleep well.

The lab evolved over the years. Not just for noise reasons, but prioritizing cost-effective hardware that could replicate a simplified production environment. The goals today are very different from 1999:

In the home automation era, I wanted to understand how simple thermal sensors actually work — not just buy a commercial solution and plug it in, but build the whole thing from scratch. Here’s what I put together.

What We Need

• ESP8266
• DHT22
• USB power supply
• InfluxDB
• Grafana

Hardware

I initially considered Arduino but followed a colleague’s suggestion to use NodeMCU instead. NodeMCU is an open source platform developed for IoT where you can compile firmware with the sensors you need. Its primary advantage is Lua support, which is significantly simpler than Arduino’s C implementation for this kind of work.

Contrary to popular belief, monitoring an infrastructure is the opposite of just having some metrics about applications and network.

There are many excellent resources on this topic. One of the most interesting is just a few pages from Google — the art of SLOs. I took the book version from a Google on-site deep dive.

To structure this properly, I want to use four simple statements:

• WHAT
• WHY
• WHO
• HOW

WHAT

This is probably the main argument we’ll discuss here.

First, a thought about what this is and what it isn’t: this is about website metrics management. Not the only way, but one way for a high-level overview.

I’m focused on sharing concepts about website monitoring and one possible way to manage this in Kubernetes. You can reach the same goal with just Docker and crontab — but I’m using some other tools in Kubernetes because I’m evaluating them for other purposes.

aka the network blaming tool

Every network admin hears it. “The VPN is slow.” “I can’t connect to $something.” “It worked yesterday.”

The problem: these complaints are vague. Is it the provider? A T2/T3 routing issue? The user’s local network? Without data, you’re guessing.

This tool collects data.

How to Understand if Your Network is Really Slow

Deploy a pre-configured Grafana stack that monitors internet connection statistics. Select the endpoints that matter — VPN gateways, datacenter public IPs, main DNS servers — and get a continuous picture of latency and packet loss.