iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In a 2026 DEV Community post, author yureki_lab reports adding OpenTelemetry tracing to 47 services in nine days with Claude Code. The approach was not to let an agent loose on the whole fleet: the author first instrumented one service, then used that working implementation as a pattern, enforced repeatable rules with a validator, and tested exported traces before merging. The account is a useful engineering case study, not an independently audited benchmark.
Why the author instrumented the services
The author describes a backend fleet that already had structured JSON logs but no distributed traces. When an incident occurred, it could take more than 40 minutes, by the author’s estimate, to determine “which service is actually slow.” That figure is the author’s reported median, with no incident dataset or calculation supplied in the post.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
The fleet comprised mostly Node.js 22.x services using Express or Fastify, plus a handful of Python 3.13 services using FastAPI. That mix shaped the rollout: services were grouped by framework so that related implementation work could be repeated together.
Recommended Free Tools
How the rollout worked
1. Instrument one service as the reference
The author found that a prose conventions document led to inconsistent agent output. Instead, they manually instrumented one service and treated its code as the concrete example for the rest. The Node.js bootstrap described in the post configures a NodeSDK, an OTLP HTTP trace exporter, Node auto-instrumentations, service name and version, environment attributes, and shutdown handling. It disables filesystem instrumentation.
This makes the intended pattern inspectable: a reviewer can compare later services against working code rather than infer implementation details from a prompt. It is still a pattern to adapt, not proof that every service has identical startup, shutdown, or instrumentation needs.
2. Make conventions executable
The author wrote a Python validator to check for a tracing bootstrap, interpolated span names, selected high-cardinality or potentially sensitive attributes, and span namespaces that did not match the service. According to the post, this caught 31 cardinality violations that might otherwise have been merged. The article links no code or audit record for that count, and the validator is not established as a complete privacy or correctness check.
Rank #2
Its practical value was narrower: repeatable mechanical checks could be handled automatically, leaving human reviewers more attention for decisions that depend on service-specific context.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →3. Test exported traces, not just source code
A static validator can confirm that expected code exists; it cannot establish that spans are actually exported or connected into a trace. The author’s smoke test sent a request, flushed spans from a local collector, and checked for both an HTTP span and a database span with a parent-child relationship. It also checked that a concrete invoice ID did not appear in the route span name.
That runtime check exposed context-propagation failures that could otherwise produce separate spans instead of one connected trace. The distinction matters: syntactically correct instrumentation can still fail to provide the end-to-end context an operator needs.
4. Repeat by framework, with human review
The author repeated an agent–validator–test–review loop, grouping services by framework. A human reviewed remaining service-specific decisions before pull requests were merged. The post specifically cautions against delegating choices that require undocumented operational knowledge, such as whether old logs should be deleted.
What the reported timeline does—and does not—show
Yureki_lab reports that the first six services took four days and the remaining 41 took five, while the author spent about 90 minutes per day on the work. They estimate that manual instrumentation would have taken roughly half a day per service, or about six weeks for 47 services. These are the author’s estimates, not a measured comparison against a manual control group. The post does not establish that another team, fleet, or project would achieve the same schedule or savings.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The account’s strongest transferable point is about work design: establish a sound example, convert repeatable requirements into checks, verify behavior at runtime, and keep judgment calls with people. It does not compare Claude Code with other agents or compare tracing vendors.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to take from the case study
- Prefer a working reference over prompt-only conventions. An implementation gives an agent and reviewers a concrete pattern to inspect.
- Use automation for repeatable checks. A validator can surface known classes of mistakes, but its coverage must be understood and maintained.
- Test trace behavior end to end. Confirm spans reach a collector and parent-child context is preserved; source-level checks alone cannot prove this.
- Review naming, cardinality, and data exposure deliberately. Avoid identifiers in span names and examine attributes for sensitive or high-cardinality values. The post’s checks are examples of the author’s conventions, not a complete security standard.
- Batch similar services together. Framework-based grouping lets implementation knowledge carry from one nearby task to the next; the author’s advice is to order work by similarity rather than convenience.
What the author planned next
The post says the author’s next work was sampling policy, with 100% head-based sampling in staging and an intention to explore tail-based sampling, followed by trace-driven performance work and generated service dependency graphs. These are plans stated in the post, not confirmation that they were later completed.
Source: DEV Community: “How I Added OpenTelemetry Tracing to 47 Services With Claude Code in 9 Days” by yureki_lab, displayed September 24 and identified in search as a 2026 post.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
