I also think that printf debugging is fine, but there are better tools [1] - however they might be more involved to setup, or not be available in your codebase.
Go: go templates and fiber for http serving. I have a mini framework for adding some structure to the templates (folder per feature: contains controller, templates, etc, and some naming conventions)
If I understood correctly, you can achive this with `hx-target` and `hx-select` - I'm doing this in an app to replace an editor content based on which link is clicked.
Yep, I actually don't even do server side checks in my app I am building, I just hx-boost on my html element and then server side I redirect back to the page that should have the updated content, just like you would a traditional server rendered app, and htmx then swaps out the body, but if I use target and that I can tell it to only return say the `<main>` tag and maybe another part of the page, the rest doesn't change.
Yes, and itel has instrumentation libraries which do this.
However, no automatic instrumentation can do everything for you; it can't know what are all the interesting properties or things to add as attributes. But adding tracing automatically to SQL clients, web frameworks etc is very valuable
As other posters have mentioned, the incument companies rebranding to Observability definitely are expensive, because they are charging in the same way as they do for logs and/or metrics: per entry and per unique dimension (metrics especially).
Honeycomb at least charges per event, which in this case means per span - however they don't charge per span attribute, and each span can be pretty large (100kb / 2000 attributes).
I run all my personal services in their free tier, which has plenty of capacity, and that's before I do any sampling.
Yes, but going to this effort, why not move to tracing instead?
A migration path I could see might be:
- replace current logging lib with otel logging (sending to same output)
- setup tracing
- replace logging with tracing over time (I prefer moving the most painful areas of code first)
One benefit is that you only need to send one string value (traceId) through the whole call stack, instead of passing around a trace object that gets built up. It seems lighter and simpler to add to an existing codebase.
I think my major pain point with them being everywhere is unlike a log they push a new stack frame and closure. They make tracebacks so much more annoying, yes I know the error happened in a start span, thank you.
I wish observability actually observed more than it contributed. Once https://peps.python.org/pep-0669/ is available I'm gonna try my damndest to get otel working through it. Just give me a config file that says what functions you're interested in and I'll do the rest.
Agreed the amount of stuff showing in stack traces can be annoying - but it does depend on language.
I agree 100% in javascript/typescript its annoying, and I would love to get rid of them, In go however, there isn't an extra stack frame. Nor in C# thinking about it.
The config file of functions to trace is a really interesting idea. How would you handle wanting to add data to the spans from inside those functions though? e.g. I want to add all kinds of props to the spans that can't be known except inside the function executing.
I started my APM journey when using Spring w/ Java and fell in love with how i can trace the entire flow through the entire application and then just config on how many spans i want to send over and what sample rate i want collected.
I'd love to accomplish that.
What you mentioned is all nice and well (optimal route), but right now, i'm working with some applications that needs it, but has i don't even know how many methods / classes that i'd need to go through and implement it on.
[1]: https://andydote.co.uk/2024/11/24/print-debugging-tracing/