Prometheus golang_client helps to expose go runtime/metrics so you can collect it, and the block below shows a short example.
collectors.WithGoCollectorRuntimeMetrics accepts various rules and prometheus collector package also offers several options.
This page offers a table to show prometheus exposed go runtime metrics naming, and the rules to enable them for reference. It solves 2 painpoints listed below.
This page helps you to quickly query when a metric of runtime/metrics was supported. For example, you can query the table to know metrics /gc/gogc:percent was added in go1.21.0
This blog explains how the Go runtime metrics /cpu/classes/total:cpu-seconds is calculated. Go1.22.7 is used as source code reference.
Go standard library provides os pacakge to trackle with os related concepts, for example, the working dir. Working dir is a os level concept rather than a concept maintained by os package. Indeed, os package doesn't reinvent the wheel but rely on the operation system to tackle it.
Working dir is a concept for a process rather than an executable. So statement "the working dir of binary ./bin/server is ~/workspace/server" is totally wrong.
This is a reading note to summarise the build list and dependency requirements of minimal version selection of go. If you want to learn more about minimal version select(MVS), please read the documentation and design docs below.
In short, MVS produces the build list as output, the list of module versions used for a build. The "minimal" in MVS means it selects the minimal version of each module that satisfies all requirements, instead of automatically choosing the highest available version. For example, if the requirements are "v1.1, v1.2, v1.3", the version v1.3 is the minimal version that satisfies all requirements. According to the MVS, v1.3 is selected.