blog: The Lazy Developer’s Guide to Observing Your Own Code

[didiViking]

Blog Post Title

The Lazy Developer’s Guide to Observing Your Own Code

Blog Post Outline

Blog Post Title
The Lazy Developer’s Guide to Observing Your Own Code

Authors: @didiViking @avillela

Cross-post from the original: Dynatrace community blog and Geeking Out Podcast Substack

Blog Post Outline
An educational post on how developers can start observing and troubleshooting their own code with the help of OpenTelemetry.

Outline:

Developers will learn:

• Why do it?
• Basic overview of OTel instrumentation concepts
• Overview of desktop tooling for developers to visualize OTel data
• How to add meaningful traces, metrics, and logs to your code with minimal changes
• A practical, repeatable workflow for using OTel to troubleshoot code
• Common pitfalls (like accidental high cardinality) and how to avoid them

Sponsoring SIG: SIG-end-user

Sponsor Name: @reese-lee

Additional info: we already have this article prepared, it's ready for a PR

Technologies Used

-OpenTelemetry Java SDK
-instrumentation

Related Special Interest Groups (SIGs)

• SIG end-user
• SIG comms

Sponsoring SIG

SIG end-user

Sponsor Name

@reese-lee

Additional Information

No response

[reese-lee]

I sponsor!

[svrnm]

I read the proposal and scanned the blog post, I like the content very much, however I think this is not a blog post, this is a major rework for parts of our instrumentation (https://opentelemetry.io/docs/concepts/instrumentation/) guidelines. It is probably also very much in line with @kaspernissen's proposal on the maturity model proposal where we talked about the need to have more guidelines on instrumentation practices.

Please consider if you can take the content of this blog post and put it into documentation.

Thanks.

[avillela]

I read the proposal and scanned the blog post, I like the content very much, however I think this is not a blog post, this is a major rework for parts of our instrumentation (https://opentelemetry.io/docs/concepts/instrumentation/) guidelines. It is probably also very much in line with @kaspernissen's proposal on the maturity model proposal where we talked about the need to have more guidelines on instrumentation practices.

Please consider if you can take the content of this blog post and put it into documentation.

Thanks.

Hey @svrnm any chance we can do both the blog post and documentation updates as you suggested? @didiViking and I wanted to specifically call out the importance of OpenTelemetry for developers and open source tooling currently available to help them observe their own code, so this blog post covers more than just instrumentation tips for devs.

[svrnm]

Hey @svrnm any chance we can do both the blog post and documentation updates as you suggested? @didiViking and I wanted to specifically call out the importance of OpenTelemetry for developers and open source tooling currently available to help them observe their own code, so this blog post covers more than just instrumentation tips for devs.

I think that's actually a good idea, when we have updated the documentation with better guidelines for instrumentations, a blog post that highlights those changes and adds reading material that we kept out of the docs, would draw some attention to it 👍