Take one HTTP request, GET /orders/42, headed for a Go service nobody is going to rebuild this quarter. We want a span for it, another for its database call, and the trace context handed on to the next service, all without touching the service. “Zero code changes” travels far in conference talks and vendor docs. Today we watch that one request from the kernel and find out where the phrase holds. ...
We’re going to chase down one benchmark result that looks suspiciously good. The function under test calls make([]byte, 64) every time it runs, and the benchmark reports 0.34 ns/op, 0 B/op, 0 allocs/op. That is almost three billion heap allocations per second on a laptop, and the allocator counted none of them. (It comes from a real run, more on that below.) Keep it in your pocket; we’ll follow it the whole way. ...
Start a Java service with one extra flag and it gets traced, with no source change and no rebuild: 1 java -javaagent:agent.jar -jar app.jar The JVM offers each class’s bytes to the agent’s ClassFileTransformer before it defines the class, so the agent can rewrite a method on its way in. Python lets you swap a method at runtime, which is the monkey-patching of the title. That flag is Java’s agent slot, and Python doesn’t even need one. Go has no such slot, and that follows from how Go was designed. ...
We’re going to write one small benchmark, run it, and read every word of what comes back. By the end you’ll know where ns/op comes from, what -count and -benchtime change, what the -16 is, and how to ask the compiler and the profiler what the benchmark really did. Here is the line we’ll be decoding: 1 BenchmarkMakeBuffer-16 99632604 18.53 ns/op 64 B/op 1 allocs/op This is a primer before part 1 of Why Your Go Benchmarks Are Lying, the written companion to my GopherCon UK talk, Why Your Go Benchmarks Are Lying. The series argues about numbers like the one above, so it helps to know how they are made first. If you have run go test -bench before, skim. ...
The first post in this thread was about why I keep saying yes to mentorship. The second was the playbook for mentees. This one is for the people on the other side of the table: the maintainers, the SIG leads, the engineers in companies that depend on a project and are starting to wonder whether dependency is enough. The frame I’m borrowing comes from a piece my colleagues at Bloomberg published with the CNCF in March: Sustaining OpenTelemetry: Moving from Dependency Management to Stewardship (also on Bloomberg’s company stories). The phrase has stuck with me. It names something I’ve been trying to articulate for years, and gives me a concrete vocabulary for talking about what mentorship is for inside a project the size of OpenTelemetry. ...