News for hackers. Stuff that matters.

GalKlm

Show HN: MCP Server for OpenTelemetry

https://github.com/traceloop/opentelemetry-mcp-server

Hey HN, Gal, Nir and Doron here.Over the past 2 years, we've helped teams debug everything from prompt issues to production outages.We kept running into the same problem: Jumping between our IDEs and our observability dashboards. So, we built an open-source MCP server that connects any OpenTelemetry backend (Grafana, Jaeger, Datadog, Dynatrace, Traceloop) to our dev environment using an...

( Read More... | 2 comments | 13 points | on HN )

Launch HN: Traceloop (YC W23) – Detecting LLM Hallucinations with OpenTelemetry

Hey everyone, we are Nir and Gal from Traceloop (https://www.traceloop.com). We help teams understand when their LLM apps are failing or hallucinating at scale. See a demo: https://www.traceloop.com/video or try it yourself at https://www.traceloop.com/docs/demo.When moving your LLM app to production, significant scale makes it harder for engineers and data scientists alike to understand when...

( Read More... | 74 comments | 28 points | on HN )
Re: on Thursday October 12, 2023 @02:46AM (#37854180)
Hey it's Gal from Traceloop,

That's a good tbh. I wonder whether we should implement instrumentations for LLMs "hosting solutions" or for specific LLMs (E.g. LLaMa/Falcon) and ignore the hosting solution (not sure if that's even possible though as it sort of dictates the inference api).

wdyt?

Re: on Wednesday October 11, 2023 @01:35PM (#37847614)
Hey Gal from Traceloop here,

We definitely have pgvector on our roadmap (which tbh I think we better publish in the repo). For Graphana tempo, it's just a matter of making sure that it works as a destination - we'll do it today/tomorrow.

Show HN: Test distributed systems with 10 lines of code

https://github.com/traceloop/jest-opentelemetry

Hey HN, Nir, Gal and Tomer here. Last week, we open-sourced a new testing framework in Typescript on top of Jest and OpenTelemetry (https://github.com/traceloop/jest-opentelemetry). It makes it easy for developers to write end to end tests for a microservice-based system with many side effects.Writing good end-to-end tests is hard. They take a lot of time to write, developers are afraid to...

( Read More... | no comments | 2 points | on HN )
I appreciate the willingness to try it! Thanks!

This one may help you: https://docs.enrolla.io/contributing/overview

If it doesn't, feel free to reach out at the community slack: https://join.slack.com/t/enrollacommunity/shared_invite/zt-1...

We can even jump on a call to assist you.

Thanks again; glad to shed some light :)

I totally get you; we're struggling to find the correct wording. As an engineer, I also bump into the "gradual (temporal) rollout" as the first association of "Feature Flags".

What wording would make sense to you now that you understand the vision?

It goes beyond a feature toggle. Pricing Tiers/Packages tend to consist of more "sophisticated" pricing mechanisms, usually split into Licensed Features (simple toggles like SAML enabled and limits like Seat Count) and Metered Features (either quotes/limits or pay as you go). We're currently working on the metering functionality together with billing systems integration. That's the difference, IMO, from the common Feature Flags solution.

Thanks for the comments; they are much appreciated and help us shape our messaging and understand what's not going through.