Go

Go is a programming language created by Robert Griesemer, Rob Pike, and Ken Thompson. Go is the cloud-native programming language of choice for many organizations.

Capabilities

  • Automatic injection and instrumentation of Go executables
  • Always-on 24x7 production grade CPU profiling
  • Go-specific metrics:
    • Suspension time
    • Committed, Used, Idle, and Live heap memory sizes
    • Goroutine count (application / system)
    • Go managed memory heaps: Off-heap, Stack, and overall Committed / Used memory
    • Allocated Go object count
    • Garbage collector invocation count
    • Go runtime system call count, cgo call count
    • Global Goroutine run queue size
    • Parked, Out of work, and Overall worker-thread counts, Idle scheduling context count
  • Incoming / Outgoing web request monitoring
  • Custom service monitoring

Support and desupport

The Go release policy supports the last two major Go versions.

Whenever a new Golang major version (even or uneven) is released, we add support for that version. Dynatrace will add support for each minor version; you can see the Version matrix for more details.

Dynatrace will follow this support model, but will support each Go version at least half a year longer to give our customers time for upgrades.

Go Version released EOL Supported by Dynatrace until Last supported OneAgent Version
1.7 2016/08/15 August 2017 December 2018 1.157
1.8 2017/02/16 February 2018 December 2018 1.157
1.9 2017/08/24 August 2018 June 2019
1.10 2018/02/16 February 2019 August 2019
1.11 2018/08/24 August 2019 February 2020
1.12 2019/02/25 February 2020 August 2020

Version Matrix

OneAgent versions Go 1.7 Go 1.8 Go 1.9 Go 1.10 Go 1.11 Go 1.12
v1.129, v1.131, v1.133 1.7.0 - 1.7.5 1.8.0 - 1.8.5 1.9.0 - 1.9.2 - - -
v1.135, v1.137 1.7.0 - 1.7.6 1.8.0 - 1.8.6 1.9.0 - 1.9.2 - - -
v1.139 1.7.0 - 1.7.6 1.8.0 - 1.8.6 1.9.0 - 1.9.3 - - -
v1.141 1.7.0 - 1.7.6 1.8.0 - 1.8.7 1.9.0 - 1.9.4 - - -
v1.143 1.7.0 - 1.7.6 1.8.0 - 1.8.7 1.9.0 - 1.9.4 1.10.0 - -
v1.145 1.7.0 - 1.7.6 1.8.0 - 1.8.7 1.9.0 - 1.9.5 1.10.0 - 1.10.1 - -
v1.147 1.7.0 - 1.7.6 1.8.0 - 1.8.7 1.9.0 - 1.9.6 1.10.0 - 1.10.2 - -
v1.151 1.7.0 - 1.7.6 1.8.0 - 1.8.7 1.9.0 - 1.9.7 1.10.0 - 1.10.3 - -
v1.155 1.7.0 - 1.7.6 1.8.0 - 1.8.7 1.9.0 - 1.9.7 1.10.0 - 1.10.4 1.11.0 -
v1.157 1.7.0 - 1.7.6 1.8.0 - 1.8.7 1.9.0 - 1.9.7 1.10.0 - 1.10.4 1.11.0 - 1.11.1 -
v1.159 - - 1.9.0 - 1.9.7 1.10.0 - 1.10.5 1.11.0 - 1.11.2 -
v1.161, v1.163 - - 1.9.0 - 1.9.7 1.10.0 - 1.10.7 1.11.0 - 1.11.4 -
v1.165 - - 1.9.0 - 1.9.7 1.10.0 - 1.10.8 1.11.0 - 1.11.5 1.12.0
v1.167 - - 1.9.0 - 1.9.7 1.10.0 - 1.10.8 1.11.0 - 1.11.6 1.12.0 - 1.12.1
v1.169 - - 1.9.0 - 1.9.7 1.10.0 - 1.10.8 1.11.0 - 1.11.8 1.12.0 - 1.12.3

Known Limitations

Support limited to official, stable Go releases

OneAgent doesn't support binaries compiled using the gccgo tool chain.

Application binary must be dynamically linked

This restriction applies only to Linux systems.

OneAgent fully automatic injection requires dynamically linked application binaries. Dynamic linking is automatically applied if the application uses certain standard runtime library packages (net/http).

In all other cases, dynamic linking can be enforced with the command line option -ldflags '-linkmode=external'.

Example

Consider the following minimalistic Go application (GoMinimal.go):

package main
import "fmt"

func main() {
    fmt.Print("Enter text: ")
    var input string
    fmt.Scanln(&input)
    fmt.Print(input)
}

Building the application will result in a statically linked application binary:

$ go build GoMinimal.go
$ file GoMinimal
GoMinimal: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

Enforce dynamic linking with -ldflags '-linkmode=external':

$ go build -ldflags '-linkmode=external' GoMinimal.go
$ file GoMinimal
GoMinimal: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32

The application can't be built with the -linkshared option

Go supports dynamic linking of the Go standard library. This build mode is rarely used and OneAgent won't inject into applications built this way.

Sample application of -linkshared

$ go install -buildmode=shared -linkshared std
$ go build -linkshared GoMinimal.go

The resulting application binary will be rejected by OneAgent.


Applications that load Go plugins aren't supported

A Go plugin is a package compiled using the build flag -buildmode=plugin to produce a shared object file. This build mode is rarely used and OneAgent will disable deep monitoring when an application actually loads a Go plugin.


Application must contain a symbol table

OneAgent relies on information stored in the application binary files symbol table. Go will generate by default a symbol table into the application binary, but this can be suppressed by command line parameters or external tools like strip.

go run

go run <application> is a rarely used command form which will build and run the application on the fly. As the output application file is temporary which is deleted automatically after application termination, the application binary is generated without a symbol table. Thus, OneAgent will not be able to monitor the generated application.


musl libc support

Go code module supports musl libc based Go applicatiobs (e.g. Alpine Linux) starting with version 1.167.

musl libc is a drop in replacement for glibc and mimics in very detail glibc functionality. Nevertheless, subtle behavioral differences to glibc exist. Moreover, the musl based Go tool chain is not officially supported by Go (meaning, Go tool chain binaries cannot be downloaded from golang.org web site).

A serious issue limits the extent Go code module can support musl based applications. Go toolchain includes an internal linker, which generates musl based application binaries which will not correctly initialize musl libc at application startup. This issue prevents Go code module from monitoring these applications. Dynatrace will display "Activation of deep monitoring was unsuccessful, Monitoring of Go musl binaries built with Go internal linker is not supported" message in according applications process screen.

Using the system linker to generate the application binary, will add startup code that correctly initializes shared objects. Adding -ldflags '-linkmode external' to the build command line enforces usage of the system linker. The resulting binary can be monitored by Go code module and will execute with a correctly initialized libc. limitation.