Talks

Zero-touch observability for Go is finally becoming real. In this talk, we walk through the different strategies you can use to instrument Go applications without changing a single line of code, and what they cost you in terms of overhead, stability, and security. We compare several concrete approaches and projects: eBPF-based auto-instrumentation using OpenTelemetry’s Go auto-instrumentation agent and OBI (OpenTelemetry eBPF Instrumentation), compile-time manipulation using tools like Orchestrion and the OpenTelemetry Compile-Time Instrumentation SIG, runtime injection via Frida/ptrace, and USDT (User Statically-Defined Tracing) probes — both via libstapsdt and a custom Go runtime fork. ...

Measuring software performance reliably is remarkably difficult. It’s a specialized version of a more general problem: trying to find a signal in a world full of noise. A benchmark that reports a 5% improvement might just be measuring thermal throttling, noisy neighbors, or the phase of the moon. In this talk, we walk through the full stack of reliable performance measurement — from controlling your benchmarking environment (bare metal instances, CPU affinity, disabling SMT and dynamic frequency scaling) to designing benchmarks that are both representative and repeatable. We cover the statistical methods needed to interpret results correctly (hypothesis testing, change point detection) and show how to integrate continuous benchmarking into development workflows so regressions are caught before they reach production. ...

The -toolexec flag hides a super-power in the Go toolchain: it lets you turn every go build into a programmable pipeline. In this session we’ll reveal how a simple wrapper command can inject custom analysis, code generation, and instrumentation—without changing a line of application code. You’ll see how platform and tooling teams use -toolexec to weave organisation-wide practices directly into the build, from enforcing error-handling standards to automatically adding observability hooks. We’ll map the journey from a “hello-world” wrapper to full Aspect-Oriented compile-time transformations, and discuss the trade-offs that come with this new power. ...

Most Python profilers ask you to decide in advance. You import something, or you wrap the process, or you restart it with a flag. That works on your laptop and helps little at 3 a.m., when the profile you want is of a process that has already been running for six hours. eBPF changes the bargain. An agent samples from the kernel on a timer, and the application never knows it is there. For compiled code that is close to free: read the registers, walk the frames, resolve the addresses against DWARF. Python is where it stops being easy. ...

Prometheus is the second-oldest project in the CNCF and the default answer for metrics in Kubernetes. Which means most people meet it already running, configured by someone who has since left, and never get a chance to ask how the thing works. This is the maintainer track session for people in that position. We start from the beginning for anyone who has only ever touched Prometheus through a Grafana panel: what it scrapes, what it keeps, and what the query engine is actually doing while your dashboard spins. Then we go under the covers into the storage layer, the write path, and the places the memory tends to go. ...