Skipper increases network observability for developers and operators alike.
In my previous article, I introduced Skipper, an open source HTTP router and reverse proxy for service composition. This article focuses on how Skipper increases network visibility and describes its advantages for both developers of scalable applications and operators of the infrastructure they run on.
What is network visibility?
As an HTTP routing provider, Skipper wants to provide visibility to application developers. At e-commerce retailer Zalando, our developers in feature teams want to monitor their systems to understand failure rates (%), throughput (request per second, or RPS), and latencies (e.g., p50, p99, p999). Skipper library users who want to instrument their custom proxies can use Skipper’s metrics package to instrument their proxies and create custom metrics.
Operators need observability to understand how the system behaves in general and at certain points in time, so they’re ready when someone asks, “What happened yesterday at 2:30am?” or “How would this request be processed?” Skipper can help answer these questions by increasing backend applications’ visibility.
Skipper exposes response latencies, RPS throughput, and OK and failure rates for routes and aggregated routes. These are the basic signals that application owners need to get alerts on, so they can take action as needed.
Skipper can serve different application metrics depending on your needs. Metrics can be collected by Host header or by route. If you start Skipper with -serve-host-metrics, you can collect and expose metrics grouped by Host header. If you need more details, you can use -serve-route-metrics to split metrics by route, status code, and method.