OpenTelemetry Tracing Overhead in a Single Go Service on Kubernetes

Abstract

This thesis measures the computational resource cost of OpenTelemetry distributed tracing when running a single instrumented Go service on Kubernetes. The focus is on CPU, memory, latency and network overhead and on how different sampling strategies change those costs. The diagnostic value obtained from each strategy and the privacy and security trade-offs of different configurations are also examined. A Go service with five different workload endpoints was built and experiments were run on a managed Kubernetes cluster at three load levels. Prometheus was used to collect resource and performance metrics during the test runs. Trace data was ex- ported to Grafana Tempo for span count validation and sampling rate confirmation. The results show that tracing overhead is predictable and scales with the sampling rate. Even at 100% sampling the system stayed stable. In this single-service setup, head-based and parent-based sampling performed the same across all workloads. In multi-service deployments the difference moves more to architectural questions since parent-based sampling keeps traces consistent across services without notice- able resource overhead. A custom adaptive sampler was also implemented in the Go service that adjusts its rate based on observed error counts and latency. It did not add measurable overhead to the service and captured a larger batch of relevant re- quests and traces. Overhead from this strategy was stable across all configurations. The privacy and security analysis shows that at low overhead levels, sampling rate becomes more of a data governance decision: what accumulates in the tracing back- end and who can access it depends on configuration choices rather than technical constraints.