Monitoring of a Go application

Monitoring of a Go application
Today we are chatting with Aurélien Rainone, a programmer at Develer, who recently held one of our techLabs at the Student Hotel in Florence.

In this interview, briefly retracing his workshop, he will illustrate the main concepts related to monitoring an application written in Go (also known as Golang) and will explain how to best use the tools that are available to us.

Hello Aurélien, in your experience what are the typical problems encountered when we have to monitor an app?

The problems are very common: is the program too slow? For what reasons? Could it go faster? How does the app behave in production? How does it behave under load?

What are the tools we can use to solve these problems?

In the first part of the workshop, we looked in detail at the tools included in the language distribution: just install Go and you already have several tools at your disposal, including the execution tracer, the profiler and also the ability to easily write and run benchmarks . In Go, benchmarks are simple functions that have “Benchmark” as a prefix (for example “BenchmarkMyFunction”); the “testing” package already provides a lot of features, which allow you to test your code extensively without having to use additional tools .

What are the differences between these tools?

The execution tracer is a graphical tool that allows you to understand when certain events related to the Go runtime occur, such as the scheduling of goroutines and the identification of competition problems.

The profiler allows you to analyse in detail a function or a part of code at the performance level, both for the CPU and for the memory, to know exactly what are the critical points in the code and then to optimise them.

In the second part, we then introduced real-time monitoring concepts, using Prometheus, a time-series database (TSDB), and illustrated what types of metrics we can monitor.

Prometheus is a third-party tool not included in the Go distribution, therefore it must be installed separately. During the workshop, the participants learned to monitor an HTTP server in real-time, using a Prometheus/Grafana stack installed via docker-compose

In conclusion, is there a better tool than others to use?

I would say that no, there is no better tool to use than the others; a tool should be used according to the use case.

For example, if I know that a function takes a little too long and I have to improve it, so I write a benchmark to evaluate the execution time and measure the improvement that I can achieve with each change. If instead I don’t know exactly where it is that my program spends most of the time, I use the profiler in order to identify the critical points.

Another example: I have an HTTP server that is running 24/7 and I have to be able to continuously monitor how it is going. With Prometheus, I can monitor CPU and memory based on how many connections are open on the server, and see how it behaves under load.

In conclusion, it is experience that guides us in the choice: once you have acquired a good knowledge of the different tools, you know which one to use in different circumstances

Curious to know more? 

To stay updated on our events, follow us on social media or subscribe to the NewsLetter. We look forward to seeing you at the next techLab!