Good monitoring and alerting are essential for running services in production. As a Java developer, I’m a bit spoiled by my platform of choice, Spring Boot 2. Thanks to Micrometer it provides out of the box instrumentation for HTTP requests, data sources, caches, memory, threads, logging, and many more. When playing with Go, I found the experience less than ideal, to say the least.
I use Gnome on Ubuntu 18.04 with static workspaces and switch between them using keyboard shortcuts – for example, ALT+1 takes me to workspace one. Unfortunately, using the graphical settings editor, I was only able to assign keyboard shortcuts to the first four workspaces. After a bit of research and playing with gconf-editor, I found the command line to achieve what I need.
In a large-scale distributed system, it’s inevitable that some requests will fail. Even if your collaborating systems work perfectly, sooner or later you will experience temporary network issues and other intermittent errors. That’s why a lot of people try to paint over this issue by implementing retries in their applications. Unfortunately, if it’s not done properly, this can cause serious stability problems.
When trying to set up alerting for Spring Boot services with Prometheus, I discovered the synthetic “up” time series which is great for checking whether the monitoring system can reach my service instances. While this is a great thing, I also wanted to alert on the health status of my instances, as reported by /actuator/health. Unfortunately, there is nothing in Spring Boot’s /actuator/prometheus endpoint that I could use.
With much of the web switching to HTTPS and at least some people becoming more concerned about privacy, DNS has recently come into the spotlight because it provides an ISP with the ability to monitor which websites a user visits. Multiple mitigations have been proposed – Android for example is going to support DNS Over TLS, which tunnels good old DNS payload over TLS. And now there is a working group at the IETF developing DNS Over HTTPS (DoH), which layers DNS on top of HTTP/2.
The sed(1) stream editor is one of the most powerful tools from the classic Unix tool box. It is a close cousin to the ed(1) command line editor and a descendant of the ex(1) editor, the command line mode of vi(1). In this article I’ll show a few idioms that I frequently use in practice.
In many applications it’s important to react to failed logins and other security-critical events, for example to log the failed login attempt to a file or to display a captcha after repeated failures. Spring-based applications come with a simple mechanism to access this kind of information using Application Events.
