Prometheus Operator is the perfect cloud-native monitoring solution for Kubernetes. By deploying the Helm chart you get a preconfigured Prometheus and Grafana setup plus an array of CRDs to add monitoring your own services.

Not everything necessarily lives in a Kubernetes cluster, though. So how would you add external targets to a Prometheus Operator setup? One could define an Endpoint, Service and ServiceMonitor for the external resource to have it picked up by Prometheus’ Kubernetes service discovery, which works, but there is a better solution that is more in line with how Prometheus is used outside of the Operator deployment.

TL;DR I wrote a super fast Excel file reader called Xsv, check it out! It’s fast and low on memory because it uses a SAX-based XML parser instead of a DOM-based one. Here’s some benchmarks to prove it.

Simple API for XML, or SAX for short is an event-based API, of which development started in December 1997 1. It is an alternative to the well-known Document Object Model, which was developed around the same time 2.

The topic of this post is neither new nor original, so I’m going to keep things short. People have been using jemalloc with MRI Ruby for years and praising it’s benefits all the while. The TL;DR here is: for Rails apps, using jemalloc will reduce memory consumption and might increase performance a little.

Why?

To illustrate my own experience, here’s a Grafana graph showing the effect of switching to jemalloc on a production server running a few instances of a Rails application:

Ruby on Rails 6 allows us to leverage the excellent Webpack bundler to manage JavaScript and CSS components in a way that’s more native to those technologies than the old asset pipeline: no more gems to wrap JavaScript libraries and no more libv8 gem issues.

Another advantage Webpack brings is the excellent source maps. I was surprised to see the source code of my Svelte components, complete with comments available from the Firefox development tools: