Table of Contents

• Introduction
• The Problem
• The Architecture
• How It Works
• CLI Mode — One-Shot Reports
• Prometheus Mode — Continuous Monitoring
• Deploying on Kubernetes with Helm
• Grafana Dashboards
• Security Considerations
• Conclusion
• Reflections

Here we are. If you’ve ever managed a Contentful space at scale — I mean real scale, with thousands of entries, a dozen environments, and a team that publishes hourly — you’ve hit the wall. The Contentful web app shows you… not much. A few dashboard widgets, some high-level numbers, but nothing you can export, alert on, or trend over time.

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:

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.

It’s time to talk about the API gateway.

In a modern infrastructure — especially in a microservices environment — you probably know what I’m referring to. But it’s worth being explicit about it:

“An API gateway takes all API calls from clients, then routes them to the appropriate microservice with request routing, composition, and protocol translation. Typically it handles a request by invoking multiple microservices and aggregating the results, to determine the best path.”

]]>https://www.k8s.it/posts/docker-latency/Tue, 11 Aug 2020 00:00:00 +0000Lorenzo Girardihttps://www.k8s.it/posts/docker-latency/

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.

]]>https://www.k8s.it/posts/kubernetes-for-mere-mortals/Tue, 10 Apr 2018 00:00:00 +0000Lorenzo Girardihttps://www.k8s.it/posts/kubernetes-for-mere-mortals/

Hardware Setup

Here we are — a homemade Kubernetes cluster built on ARM hardware. No cloud credits. No expensive servers. Just OrangePis and a USB hub.

Bill of materials:

• 1x Anker 60W PowerPort 6 USB hub (power for all nodes)
• 4x Orange Pi Plus 2E single-board computers

Total cost: well under what a single month of cloud compute would run.

]]>