With Node Exporter installed in each of the Raspberry Pi machines, I can now start scraping these metrics and actually using them to build a dashboard to monitor my machines. And this is also the step in which I create a GitHub repository where all scripts and configuration files used are stored, just in case my laptop decides to perish a second time and I have to go through this all over again (RIP my old SSD).

I have a bunch of physical machines and it is important to keep track of how healthy these machines are. More specifically, I want to keep track of some key metrics such as how much CPU or memory is being used and disk space. Additionally, I also want to keep track of the temperature of these machines because I do not want to accidentally burn down my house (that would really destroy the budget for this project).

I have three machines with Ubuntu installs up and running but there is one thing that I really want to avoid: having to ssh into them to install software, since the effort of installing a given package/software is always multiplied by three. As such, I thought this was an appropriate time to refresh my Salt knowledge, which is an event-driven framework/automation tool whose name probably derives from the high blood pressure it induces whenever it is used to perform changes on production environment machines.

Now that I have some hardware available, I need to install an operating system on these machines so that I can then install some software that will enable me to actually do something with these things. Since I do not want to have to connect a monitor to these machines every time I need to use them, I also have to set up some type of remote access. Other posts in this series Adventures in Overengineering 1: Inventory Adventures in Overengineering 3: Installing Salt to manage Raspberry Pi machines Adventures in Overengineering 4: Installing Node Exporter via Salt Adventures in Overengineering 5: Monitoring Raspberry Pi Machines with Prometheus and Grafana Adventures in Overengineering 6: A quick update on the status of the project Preparing the microSD cards This part is extremely simple.

A few months ago, I started a series of posts about my attempt to completely overengineer a simple Go web server. After a few posts, I had to archive that series. I was not pleased with the result, it wasn’t… enough. Last time, I began this adventure by running a Kubernetes instance on my laptop. This time, I’ve gone deeper into the overengineering madness. Keep in mind that the end goal is still to deploy a very basic Golang web server.

I rencetly watched a GopherCon talk titled “Understanding Allocations: The Stack and the Heap” by Jacob Walker, and found it really interesting, especially the final conclusion on why the io.Reader interface is the way it is. As it turns out, it is related to how memory allocation works in Go. More specifically, where the memory is allocated. The io.Reader interface There isn’t much to say here, everyone that has been programming in Go has surely found this interface out in the wild multiple times, and it looks like this: