Analyze Go metrics

Dynatrace OneAgent tracks numerous Go-related metrics.

The Go metrics and Go HTTP metrics tabs on the process overview page contain the most important Go-specific and HTTP metics. The Go managed memory, Heap details, and Scheduling tabs—all accessible via the Further details tab—bring even more valuable insights into your Go-based application performance.

Key metrics

The Go metrics tab provides an overview of the following important Golang metrics:

  • Suspension: The Go garbage collector percentage share compared to the overall application CPU time.
  • Runtime heap: The amount of memory used or committed to the Go heap as well as Go garbage collection times.
  • Goroutines: The number of Goroutines instantiated by the application and Go runtime infrastructure.

Go metrics tab

HTTP metrics

On the Go HTTP metrics tab, you can explore the following HTTP metrics:

  • Total requests: The number of all requests representing the overall traffic flow.
  • Number of HTTP 5xx responses: The number of responses that indicate repeatedly crashing apps or response issues from applications.
  • Number of HTTP bad gateways: The number of responses that indicate invalid service responses produced by an application.
  • Response latency: The average response time from the application to clients.

Go HTTP metrics tab

Go managed memory

The Go managed memory tab breaks down memory metrics into various categories:

  • Heap: The amount of the memory used or committed to Go runtime heap.
  • OffHeap: The amount of the memory used or committed to Go runtime internal structures that are not allocated from heap memory. Data structures used in the Go heap implementation are an example of OffHeap memory.
  • Overall: The sum of Heap, OffHeap, and Stack memory.
  • Stack: The amount of the memory used or committed to dynamic Go stacks. Go stacks are used to execute Goroutines and grow dynamically.

Go managed memory tab

Heap details

The Heap details tab digs deeper into the anatomy of the Go heap.

  • Heap allocated Go objects count: The number of Go objects allocated on the Go heap.
  • Heap idle size: The amount of memory not assigned to the heap or stack. Idle memory can be returned to the operating system or retained by the Go runtime for later reassignment to the heap or stack.
  • Heap live size: The amount of memory considered live by the Go garbage collector. This metric accumulates memory retained by the most recent garbage collector run and allocated since then.
  • Garbage collector invocation count: The number of Go garbage collector runs.

Heap details tab


The Scheduling tab provides unique insights into Goroutine scheduling.

  • Go runtime system call count: The number of system calls executed by the Go runtime. This number doesn't include system calls performed by user code.
  • Go to C language (cgo) call count: The number of cgo calls.
  • Parked worker thread count: The number of worker threads parked by Go runtime. A parked worker thread doesn't consume CPU cycles until the Go runtime unparks the thread.
  • Out-of-work worker thread count: The number of worker threads whose associated scheduling context has no more Goroutines to execute. When this happens, the worker thread attempts to steal Goroutines from another scheduling context or the global run queue. If the stealing fails, the worker thread parks itself after some time. This same mechanism applies to a high workload scenario. When an idle scheduling context exists, the Go runtime unparks a parked worker thread and associates it with the idle scheduling context. The unparked worker thread is now in the "out of work" state and starts Goroutine stealing.
  • Worker thread count: The number of operating system threads instantiated to execute Goroutines. Go doesn't terminate worker threads; it keeps them in a parked state for future reuse.
  • Global Goroutine run queue size: The number of Goroutines in the global run queue. Goroutines are placed in the global run queue if the worker thread used to execute a blocking system call can't acquire a scheduling context. Scheduling contexts periodically acquire Goroutines from the global run queue.
  • Idle scheduling context count: The number of scheduling contexts that have no more Goroutines to execute and for which Goroutine acquisition from the global run queue or other scheduling contexts has failed.

Scheduling tab