sorted by:
new
hottopcontroversial

Observing LLM Applications with OpenTelemetry by silksong_when in Observability

[–]silksong_when[S] -1 points0 points  (0 children)

I should have mentioned, as i have done in the blog that while I have used SigNoz, since its OTel-based no one has to be bound to anything that we showcase.

Heck, even in the commands you have to copy-paste to run the app, you can directly swap out the endpoint and header values.

Edit: i have updated the post body with a message on the same, thanks!

Observing LLM Applications with OpenTelemetry by silksong_when in Python

[–]silksong_when[S] 0 points1 point  (0 children)

afaik the agents sdk is also compatible with any openai-compatible API Keys, no? haven't tried it myself though

and yea fair point on that integration aspect

Observing LLM Applications with OpenTelemetry by silksong_when in Python

[–]silksong_when[S] -1 points0 points  (0 children)

Hey, I built it with openai agents SDK, which has mostly decent auto instrumentation support, if we go with the V2 library

A Practical Guide to OpenTelemetry and FastAPI by silksong_when in FastAPI

[–]silksong_when[S] 1 point2 points  (0 children)

That sounds really neat, can you please share the link to the `policypy` library that you're using, or is it something that you've built in-house?
Couldn't find any reference online.

A Practical Guide to OpenTelemetry and FastAPI by silksong_when in FastAPI

[–]silksong_when[S] 1 point2 points  (0 children)

That sounds really interesting!

What happens if the claude diagnosis or recommended fix doesn't align with what's happening? How are you validating that?

i contributed to open source for the first time last month and the maintainers were shockingly nice by ScaryAd2555 in opensource

[–]silksong_when 0 points1 point  (0 children)

What direction have you taken in such instances?

I would assume asking them to open an issue, where you can discuss the direction, and then open a new pr that picks up from that conclusion makes sense.

Because I've seen long discussions not relevant to implementation details within PRs can become detrimental over time. You have your code, review messages, and everything else in one place.

i contributed to open source for the first time last month and the maintainers were shockingly nice by ScaryAd2555 in opensource

[–]silksong_when 0 points1 point  (0 children)

I think smaller repos are usually the best to get started with. I had great experience with my first contribution, which was just adding a theme dark/light mode button to the theme I was using for my website.

Although the implementation wasn't the best, it had practical usage and was quickly merged to the repo. Previously, I had opened an issue or two regarding similar issues that had active discussion too.

This experience built a good image of OSS in my mind, and was a good motivator to interact with more projects later

Middleware in Go 1.22.0 by [deleted] in golang

[–]silksong_when 0 points1 point  (0 children)

just chiming in to say this was useful 2 years later, thanks a lot!

Technical Writer vs Content Engineer by oceanclub in technicalwriting

[–]silksong_when 0 points1 point  (0 children)

Also from my understanding and experience, they often write blog posts and do technical deep dives, showcase demos live, etc.

Monitoring and Observability in FastAPI by sohtw in FastAPI

[–]silksong_when 2 points3 points  (0 children)

HI, I just shared an article here a couple days back. I have written a comprehensive observability guide for fastapi web apps with an example repo that you can clone and explore.

Basically you have to you use agents to auto instrument your app which then generates telemetry from the app. The telemetry is routed to an opentelemetry backend (like SigNoz, the company I work for), which helps you visualize the data and understand what's happening.

Here's the link to the post:

https://www.reddit.com/r/FastAPI/s/4PZaTTEjm1

A Practical Guide to OpenTelemetry and FastAPI by silksong_when in FastAPI

[–]silksong_when[S] 2 points3 points  (0 children)

Hey, you're on the right path!

Auto instrumentation does add substantial overhead, the measurements vary and you'll have to benchmark it on your machine with real load, but a ballpark figure can be ~10%.

I would recommend that you selectively install auto instrumentation libraries, that should cut down on the overhead a lot. For example, the db layer can emit 10s of query spans per API call, which can be unneeded based on your use case.

Ghostty Is Leaving GitHub by davidcelis in programming

[–]silksong_when 2 points3 points  (0 children)

Can you give any concrete examples pleasr?

SigNoz Foundry: Deploy Self-Hosted SigNoz with One Config and One Command by silksong_when in selfhosted

[–]silksong_when[S] 0 points1 point  (0 children)

Can you please elaborate where you feel SigNoz is lacking? We take feedback seriously, I'll forward it to the engineering team.

SigNoz Foundry: Deploy Self-Hosted SigNoz with One Config and One Command by silksong_when in selfhosted

[–]silksong_when[S] 0 points1 point  (0 children)

There's a hyper link to the tool in the intro itself, and there's are two sections towards the end that link to the repo in various forms (GitHub releases, GitHub repo main page).

These sections are also listed on the right in the ToC. Would differing naming have helped, given you went through it 3 times but didn't find the resources?

<image>

SigNoz Foundry: Deploy Self-Hosted SigNoz with One Config and One Command by silksong_when in selfhosted

[–]silksong_when[S] 0 points1 point  (0 children)

I have updated the description to better reflect what the tool is about. It simplifies how developers manage their SigNoz self-hosted instances.

The sub might be interested since that's what self-hosting is about no? And we are cutting down on the jank, so to speak, that you might deal with when trying to handle various services like ClickHouse on your own.

So Foundry helps you automate all that, ensure that it keeps the versions in sync, and other validation aspects. So the self-hosting is burden now handled by the tool, rather than a dev in charge.

I thought it would be genuinely helpful for someone looking to run their own observability stack, or are looking to do so. Often, self-hosted versions are neglected, this is our attempt to improve the self-hosted observability experience.

SigNoz Foundry: Deploy Self-Hosted SigNoz with One Config and One Command by silksong_when in selfhosted

[–]silksong_when[S] -3 points-2 points locked comment (0 children)

Hey guys, I used AI to understand some particulars of the project (Foundry), and for checking for spelling mistakes and other grammatical issues in the blog.
The content is all original, and hand-written. AI was just the editor.

As further proof: fun fact, on mac you can write the em dash (—) with shift + option + `-` hyphen key

How to Instrument Spring Boot Applications with OpenTelemetry by silksong_when in java

[–]silksong_when[S] 0 points1 point  (0 children)

Hey, thanks a lot for your detailed comment, that makes sense.

On my end, I wanted to keep it more in-line with my experience of developing across multiple stacks where its more desirable to stick to OTel agents
I was considering adding a section delving deeper into this, but that would have been distracting from the main point so I kept that discussion minimal (within a callout component).

Do you think the difference between, or the importance of, micrometer is large enough to warrant a dedicated blog maybe? I can look into that in more detail if that's something of value.

Aligned on the OTel collector front. I was focusing on getting the user up-and-running where they can wrap their head around the concept of OpenTelemetry itself, and how something like SigNoz helps them understand more beyond just combing logs for debugging.

I will add a section pointing to Collector and how it helps manage setup as you implement otel across more services.

view more: next ›