LightfieldAI-native CRM that builds itself and does work for you
Promoted
Fast, scalable and cost-effective open-source observability platform. Monitor logs, metrics & traces with 140x lower storage costs than ElasticSearch. Start in 2 minutes.
This is the 2nd launch from OpenObserve. View more
AI Observability by OpenObserve
Launched this week
Your agent cost $40 and took 34 seconds. But why? OpenObserve traces every agent session across models, tools, services, datastores, and user sessions so you can see exactly where time, money, and quality went. Detect loops, run online evals, and follow failures from the LLM call through your backend and database, alongside the logs, traces, and metrics from the rest of your production stack.
Free Options
Launch Team / Built With
Hey PH - Eli from the GTM team at OpenObserve here! We've worked tons of different use cases and migrations, so if there are any questions feel free to drop them below!
OpenObserve
@elinickerson Thanks for replying Eli, glad you're here! I think it could be helpful to share one or two anecdotes you hear from folks as they're establishing more mature AI observability practices.
@jacob_swiss Good call! Two things we hear a lot:
Teams usually start by just watching if requests succeed or fail. Then a few weeks in, they realize that doesn't tell them if the answers were actually good, so they shift toward actually measuring quality, not just uptime.
On the evaluation side, most teams start out reviewing conversations by hand. That works for a while, but it doesn't scale. The real shift happens when they start using their actual production data to test and improve things automatically, instead of relying on someone eyeballing transcripts all day.
Happy to go deeper on either if useful!
Macaly
otel native is the right call, nobody wants another agent sdk to install 🙌 congrats on #2
OpenObserve
Hi Product Hunt community, I'm Jake and one of the team members at OpenObserve. We're so excited to hear your feedback and questions today. Please drop your message here and let us know what you think.
congrats team! quick question - since traces capture full prompts and outputs, whats the story for sensitive data? users paste all kinds of stuff into prompts and that ends up in the trace. can we redact/mask fields before ingest or does everything get stored as-is?
OpenObserve
@abhay_padamani1 sensitive or PII data can be handled both at ingest (which is before storage) or directly in the query layer.
Also, do you use a collector or agent? I guess we can handle some of it at source as well
@manas_sharma9 Great!! yeah, we run the otel collector, so makes sense to redact there before it even leaves our infra. curious about the query layer option though - if data is already stored raw, does masking at query time mean admins can still see the original? or is there rbac around who sees unmasked payloads?
OpenObserve
@abhay_padamani1 it can be handled in one of the three ways: Drop, Mask or Redact - no one can actually sees the unmasked payloads, but they can search for it with a hash.
are you familiar with regex patterns?
@manas_sharma9 hash search is clever, didnt expect that. yeah regex is fine, will set up the patterns and try it out
OpenObserve
@abhay_padamani1 Sensitive data Redaction handles it well for both incoming data or already ingested queryable data.
The Sensitive Data Redaction helps prevent accidental exposure of sensitive data by applying regex-based detection to values ingested into streams and to values already stored in streams.
@ashish_kolhe2 ah nice, works on already stored data too. good stuff 👍
Congrats on your launch!
One thing I'm curious about, since you're capturing full prompts and LLM responses, how do you handle PII that inevitably flows through agent traces? Is there a built-in redaction or masking layer before data hits storage, or is that left to the user's OTel pipeline to handle?
OpenObserve
OpenObserve
@marketer_kim There's a built-in layer, and it runs at ingest, before anything is written — it's not left to your collector.
It's field-level: you bind a regex pattern to a stream and a field, pick a policy — drop the field, redact the match, or hash it (hashing keeps the value joinable without keeping the value) — and choose where it applies: at ingestion, at search, or both. At ingestion the value never reaches storage; at search it's stored but masked on the way out.
Prompts and responses are ordinary span fields after normalization, so the same engine that redacts your logs covers them. There's no separate LLM path to configure.
Two honest caveats: this lives in the enterprise build — on OSS today it's the collector's redaction processors. And it's regex, so it's strong on structured PII (emails, cards, keys, national IDs) and weak on names buried in free text. Anyone claiming reliable PII detection in free-form prose is overselling it.
Which do you actually need — never-stored, or stored-but-masked for most viewers? Those two pull in different directions.
We run OpenObserve self-hosted at Feature1, so congrats from a user. What I like about AI Observability: agent sessions land next to the logs, metrics and traces we already keep there, on OpenTelemetry, instead of in a separate LLM tracing tool with its own bill. Following a failure from the model call into the backend and the database is the part standalone tools cannot do. Looking forward to putting our own agent runs through it.
congrats! @prabhat_sharma5
OpenObserve
Amazing @abdul_rahmank , and great to hear from a self-hosted user. You are exactly right regarding the reason we built it this way. An agent failure almost never stops at the model call. It's a slow tool call, a bad query, a timeout two services down. If your agent traces live in one tool and your backend traces live in another, you're stitching that story together by hand.
When you run your first agent sessions through it, I'd love to hear what you find. What does your agent stack look like at Feature1?
OpenObserve
@prabhat_sharma5 @abdul_rahmank Thanks — hearing this from someone already running it self-hosted means more than anything on the launch page.
That path you describe, model call → backend → database, is exactly the one we refused to break in half. Good to know it reads that way from outside.
When you do put your own agent runs through it, I'd like to hear the first thing that surprises you. In our own runs it was how much of the spend was cached input, and how many tool calls were just repeats.