OpenObserve

AI-native, open-source Datadog alternative

5.0•6 reviews•

1K followers

AI-native, open-source Datadog alternative

5.0•6 reviews•

1K followers

Visit website

Observability tools

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

OpenTelemetry-native observability for agents and LLMs

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.

AI Observability by OpenObserve gallery image

Free Options

Launch tags:Developer Tools•Artificial Intelligence•Tech

Launch Team / Built With

Zendesk for StartupsUp to 2 years free for startups + AI Agents & Copilot

Promoted

OpenObserve

Maker

📌

Hi Product Hunt, Ashish here, Head of Engineering at OpenObserve.

If your AI agent got stuck in a tool-call loop right now, would you know? Would you spot it before your customer did?

We didn't.

During a live demo, our own AI SRE Agent silently stalled. No errors. No timeouts. Nothing useful in the logs.
We had to dump raw spans and debugged through them just to find the loop.

Reading raw spans isn't a debugging strategy—it’s an apology waiting to happen.

So we built AI Observability directly into OpenObserve. We wanted to see inside the black box.

Here is what it actually gives you:

Sessions map out every single turn. You see every LLM request, tool call, token count, cost, and exactly what prompt caching saved you.
Agent Graph plots your agents, tools, and models onto the exact same service map as the rest of your backend infrastructure.
Agent Behavior automatically flags the sessions that loop or fail—long before a user complains.
Online Evals let you score live sessions using any judge model (bring your own provider and key).
Annotation Queues let you turn those ugly, failed sessions into clean datasets so you can regression-test your fixes.

The best part? It's OpenTelemetry-native.

It normalizes OTel GenAI, OpenInference, OpenLLMetry, and Vercel AI SDK and many more out of the box. Nothing you’ve already wired up goes to waste, and you don’t have to ship a second copy of your data to another platform.

Our SRE Agent runs on this daily now, and it's still our harshest critic.

Point it at your own agent traces. I'd love to hear what you find.

Report

15d ago

@ashish_kolhe2 Seems very promising.
Thin on footprint and very rich on features.

Report

6h ago

Mesh

💡 Bright idea

Congrats on the updates! 🎉🎉

Some minor feedback, last I checked (~ month ago) it only allows integration via manual integration or custom harnesses, which is great of course for many cases.

However in case is with an existing harness, such as OpenClaw, Hermes, and LobeHub, I didn't see an easy way to easily integrate this feature.

Ideally would leverage corresponding model's API or webhooks to allow all uses of inference to be hooked up even in cases where the harness isn't cooperative.

Maybe this is all solved now, but Iast I checked was an issue as much work is done via existing or well known harnesses.

Please keep it up, really great improvements over the last year!!

Report

16h ago

OpenObserve

Maker

@asherraph This is very useful feedback! You're right that the cleanest path today is OTel. If the harness emits OpenTelemetry, you point it at us and you're done. Claude Code and Codex work this way. Your own app works with the auto-instrumentation.

Harnesses that don't emit OTel and don't expose hooks are the gap you're describing. The workaround right now is sitting between the harness and the model with a gateway or proxy that emits spans for every inference call, so you get coverage even when the harness isn't cooperative. A first-class version of that, where you point the harness at an OpenObserve endpoint and it just works, is exactly the direction we're pushing.

BTW, which of the three matters most to you? That helps us prioritize where to start.

Report

15h ago

OpenObserve

Maker

@asherraph You're right, and it's the sharpest version of a gap two other people hit today.

Right now it's OTel from the harness, which works when the harness cooperates — and plenty don't. The proxy idea is the general answer: sit in front of the provider endpoint and capture every inference regardless of what's calling it. We don't ship that today.

The trade-off worth naming: a proxy gives you complete coverage but loses structure — it sees the calls, not which agent, which tool, or which session they belonged to, unless the harness passes something through. OTel gives you structure but only where the harness cooperates. You end up wanting both, because they answer different questions.

Someone asked about Hermes specifically this morning and I opened an issue for it: https://github.com/openobserve/openobserve/issues/14410

Which harness is blocking you most right now? If it's OpenClaw or LobeHub I'll file those too.

Report

8h ago

OpenObserve

Maker

Hi guys, Hengfei here, I designed this module, so let me add the part the launch page doesn't cover — what we deliberately chose not to build.

Sessions, not calls. Most LLM tracing anchors on a single request. But agents don't fail at a call — they fail across a path: right answer, wrong tool, fourteen times. So the session is the first-class object, and cost, tokens and scores roll up to it. Spans are the substrate, not the unit of analysis.

One data layer. We could have shipped a separate AI observability product. We didn't — because half of what kills an agent isn't the model. It's a vector DB timing out, a 429 from a downstream service, a retry storm in your own API. If agent spans live in a different system than your infra traces, you get to debug the same incident twice.

Scores are append-only. An evaluation is data, not a label. Change your judge prompt and the old scores don't get overwritten — they get a new version. Otherwise "quality improved" is unfalsifiable.

Bring your own judge. The judge model is yours, self-hosted open weights included. Evaluating production traffic shouldn't require shipping production traffic to someone else.

One thing that genuinely surprised me while building this: the OTel GenAI semconv renamed core attributes twice in two years (gen_ai.system → provider.name, events → input/output.messages). Betting on a fixed schema would have been the real mistake. The mapping layer turned out to be the feature.

What's the worst agent failure you've had to debug straight from raw spans? Collecting these — seriously.

Report

1d ago

Hey @hengfei_yang , I am mostly interested in the steps required to set this up - like how easy it is. Basically, I just want to start monitoring my prompts and understand how I am utilising the agent. How can set this up quickly without the need to understand all the advanced parts of the AI observability? Also, if there is any document/article you can share, that would be great as well! And congrats for the launch!!

Report

1d ago

OpenObserve

Maker

Hey @subhra264 It is pretty easy to start monitor you AI works. we have one command to integrate for most AI tools. Which tool are you using? Claude Code or Codex?

Report

1d ago

@hengfei_yang I mostly use Claude Code only. But I might want to switch to Codex soon. So, if you can share for both that would be great ;)

Report

1d ago

OpenObserve

Maker

@subhra264 Both are covered. Quick start is here — about 2 minutes: https://openobserve.ai/docs/getting-started/

Once it's running, the integration guide lives inside the product: http://localhost:5080/web/ingestion/ai-integrations/popular/claude-code
gives you the one-line command for Claude Code, and Codex, OpenCode and the rest are in the same section. Paste it and your sessions, prompts and token usage start showing up — nothing else to configure. Evals and annotation queues are there when you want them, but you don't need any of that for this.

Ping me if you hit anything odd. And once you're in, tell me what you look at first — cost, or the tool calls?

Report

1d ago

@hengfei_yang hey, how does the mapping layer works here? Also can we use some custom attributes that are attached to traces in this flow? Thanks :)

Report

1d ago

OpenObserve

Maker

@yashodhan_joshi Mapping happens at ingest. Extractors read each span and normalize the different dialects — OTel GenAI, OpenInference, OpenLLMetry, Vercel AI SDK, Langfuse and a few more — into one set of gen_ai.* fields: model, provider, input/output/cache tokens, cost, tool, agent, session and user id. It's additive, not destructive: if you already set a field yourself, yours wins — we only fill in what's missing.

And yes, custom attributes work. Every span attribute is flattened into a top-level field and is queryable and groupable in SQL like any other — nothing is dropped. If a name would collide with a reserved field it gets an attr_ prefix instead of overwriting it. session.id is just an attribute too, so session grouping is yours to control.

What are you attaching — tenant, feature flag, prompt version?

Report

1d ago

@hengfei_yang
I'm planning to send Claude Code or Claude desktop telemetry to OpenObserve. Does the OTel exporter add some lag to responses, or export run entirely in the background?

Report

1d ago

OpenObserve

Maker

@nikhil_sai4 Claude Code uses the OTel SDK's batching exporters, so nothing ships on the request path: metrics flush every 60s by default, logs/events every 5s, and traces every 5s behind the beta flag. Exporter failures surface as errors instead of touching the session, so even if the backend is slow or down, Claude Code just carries on.

Are you doing this for one machine or rolling it out across a team? Happy to share the config we run internally.

Report

1d ago

@hengfei_yang currently I am doing this for one machine , it would be helpful if you can share the config .

Report

1d ago

OpenObserve

Maker

@nikhil_sai4 Here's the whole thing for a single machine — drop it in your shell profile:

CLAUDE_CODE_ENABLE_TELEMETRY=1
CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=otlp
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf OTEL_EXPORTER_OTLP_ENDPOINT=https://host/api/:org OTEL_EXPORTER_OTLP_HEADERS=Authorization=Basic <base64 of email:password>

Two things that bite people: no trailing slash on the endpoint, and CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 is what turns traces on — without it you get metrics and events but no session view.

Full doc: https://openobserve.ai/docs/integration/ai/claude-code-tracing/

Start a session and it should show up within a few seconds. Come back and tell me what surprised you most — for most people it's how much of their token spend turns out to be cached input.

Report

1d ago

@hengfei_yang the agents are loop detection sounds really very useful, especially when there is no obvious errors,

I like that this work on with Open telemetry instead of a need another data pipeline.

How do you decide which fail sessions are worth turning into a eval data?

Report

23h ago

OpenObserve

Maker

@amrita_prajapati2 Honest answer: most of them aren't. Three filters. Can you state what the right answer should have been? If not, it's a bug report, not eval data. Does it represent a class of failure rather than one weird input? And is the failure actually in the model or the prompt — a session that failed because a downstream service timed out is an infra fix, and putting it in your eval set just teaches you noise.

In the product, flagged sessions land in a review queue, a human grades them, and only reviewed items get promoted into a versioned dataset. The human step is the point: the queue collects candidates, it doesn't decide.

How big is your eval set today?

Report

22h ago

OpenObserve

Maker

@hengfei_yang @amrita_prajapati2

Thanks! Loop detection matters because the agent isn't crashing, it's just burning tokens in circles, so nothing shows up in your error logs. And OTel-native was a hard requirement. If you already have traces flowing, you shouldn't need a second pipeline.

On evals: we don't turn every failure into eval data. Scorers flag the sessions that fall below your quality bar or trip a signal like a loop. Those go to a review queue where a human annotates what went wrong, and the ones that repeat or matter get promoted into a dataset. That dataset becomes the regression suite you run every time you change a prompt, model, or tool.

Report

21h ago

OpenObserve

Maker

@amrita_prajapati2 Thanks! And yes, I think the key is not to turn every failed session into eval data. I’d prioritize sessions that reveal a repeatable or meaningful failure pattern agent loops, unexpected tool calls, poor outputs, high cost/latency, or failures that traditional error monitoring doesn’t catch.

Those traces can then be promoted into datasets and used as evaluation cases, so the production failure becomes a regression test for future changes. OpenObserve supports promoting captured traces into datasets and running experiments against versioned datasets.

Report

20h ago

OpenObserve

Maker

@amrita_prajapati2 You can refer to the docs here: https://openobserve.ai/docs/integration/ai/llm-experiments/

Report

20h ago

OpenObserve

Maker

@hengfei_yang You might have answered that but can I compare the quality of one version for another?

Report

19h ago

OpenObserve

Maker

@shohams Yes — three ways, depending on how confident you need to be.

Side by side on a single input, when you're still iterating on wording. Across a dataset, where both versions run over the same set and get scored by the same scorers — so you're comparing score distributions, not impressions. And in production: the prompt version rides along on the span, so you can slice live quality, cost and latency by version and see whether the one that won offline is still winning on real traffic.

That last one is the one people skip, and it's where offline wins usually go to die.

Are you comparing prompt versions, or model versions?

Report

10h ago

I love OpenObserve because of its very friendly to use with great UI. I will like to know if there is test package that can be used as a proof of concept with my team?

Report

16h ago

OpenObserve

Maker

@simon_oluyomi

Thanks, that's great to hear. Yes, a few ways to run a POC depending on how your team wants to work.

Fastest is OpenObserve Cloud. Sign up, get a free tier, and you're ingesting in minutes. No infra to stand up.

If you need it self-hosted, the open-source build is a single binary or a Helm chart, and it's the same core product. If your POC needs enterprise features like SSO or RBAC, we hand out free self-hosted enterprise license keys for evaluation. Just ask.

BTW, Which way does your team lean, cloud or self-hosted? I can point you at the right starting kit.

Report

16h ago

OpenObserve

Maker

@simon_oluyomi Hi Simon,

You could use either of

open-source self-hosted (start in under 2 minutes -
)
enterprise self-hosted product, which is free for 50 GB per day ingestion forever
OpenObserve Cloud, which has a 14-day trial

All of these are great options.

Report

15h ago

OpenObserve

Maker

@simon_oluyomi Yes — and you don't need a special package for it. OpenObserve is open source: self-host it and run the PoC on your own infrastructure, no trial clock and no license key. Install is a single binary or one docker run, a couple of minutes, and you can point real traffic at it the same day.

If your PoC has a shape to it — a volume target, a migration off something else, a specific agent workload — tell me and I'll point you at the right setup so you don't lose the first week to tuning.

Report

8h ago

Does this integrate with products like Hermes? I tend to use this to as the main agent coordinator for my projects but it then also delegat3s to opencode. It would be amazing if this integrated with hermes so that it can monitor usage across all of my projects including the tasks that are delegated. I like the idea of b3ing able to better visualize and analyze usage directly, it is often the hidden layer that is missing and so telling when things are either not working or costing more than expected. Great work.

Report

13h ago

OpenObserve

Maker

@dmoniz22 No first-party Hermes integration today — being straight with you. But two pieces make it workable right now.

OpenCode is already a one-command setup on our side, so the delegated half is covered. And Hermes can emit OTel via the community hermes-otel plugin, which ships traces, metrics and logs to any OTLP endpoint — point it at OpenObserve and the coordinator layer lands in the same place as everything else. We haven't tested that combination ourselves yet.

The seam worth watching is the one you're actually asking about: for a delegated task to show up inside the parent run rather than as its own separate trace, Hermes has to pass a session id down to OpenCode.

This is a good catch and we'll add proper Hermes support — I've opened an issue for it so you can follow along: https://github.com/openobserve/openobserve/issues/14410

Are you delegating to OpenCode from a single Hermes instance, or one per project?

Report

8h ago

@hengfei_yang at the moment I have one hermes instance managing a number of projects. I had been using separate instances but it honestly became more confusing. I find the one instance managing several projects easier for me to manage and coordinate.

Thanks for opening the issue, I will definitely be following it.

Report

7h ago

OpenObserve

Maker

@dmoniz22 Hengfei has the integration path covered, so I'll just add one thing. The "hidden layer" you describe is exactly what we hear most. Costs drift and behavior degrades quietly, and by the time someone notices, nobody can say which project or which delegated task did it. Getting coordinator and delegate usage into one place is the whole point, and your setup is a good test of it.

Watch the issue Hengfei linked. Once Hermes support lands, I'd like to hear whether the per-project view gives you what you need.

Report

8h ago

OpenObserve

If an agent uses many models in one session, can I see how much costs for each model, and total cost for the session?

Report

1d ago

OpenObserve

Maker

@huaijin_hao Good question, In OpenObserve cost lives at three levels: span, trace, session. Each span is priced from its own model, so a request fanning out into 30 calls across 4 models is already one session total, with per-turn and per-tool breakdowns underneath — mixed-model runs need nothing special. Insights then flags which sessions and traces are cost outliers, so you land on the expensive one instead of scanning.

What's your fan-out shape — one agent calling several models, or sub-agents spread across services?

Report

1d ago

OpenObserve

@hengfei_yang i use the sub-agents with different model, the more capable model for plan, and then give the execution to the sub-agent with cheaper moodels.

Report

1d ago

OpenObserve

Maker

@huaijin_hao That's exactly the shape the rollup is built for. Every span carries its own model and its own cost, so cost-by-model is just a group-by — inside a single session, or across all of them. And agent name is a dimension too, so you can put the sub-agents side by side.

The interesting thing to watch usually isn't the planner. It's a cheap sub-agent that retries eight times and quietly costs more than the expensive model it was supposed to save you from.

One thing worth checking on your side: if the sub-agents run as separate services, make sure session.id (or gen_ai.conversation.id) is propagated — otherwise they show up as separate sessions instead of one.

Curious what your planner-vs-execution split actually comes out to😯

Report

1d ago

OpenObserve

Maker

@huaijin_hao That’s actually a great use case for this. With multiple sub-agents, I’d imagine the tricky part is getting the full picture , which model was used where, what each step cost, and how that adds up across the whole session.

Report

1d ago

OpenObserve

Maker

@huaijin_hao We roll all those calls up to the session, so you can see what the overall request cost you and then drill down into each model call. This gets pretty interesting with agents because one user request can end up making a lot more calls than you’d expect.

Report

1d ago

Cool service! Can I break everything down by user and see statistics for each user? We have many agents working within a single user session, and that would be very useful for unit economics.

Report

21h ago

OpenObserve

Maker

@natalia_iankovych Thanks! Yes. Everything comes in as OpenTelemetry traces, so if your agents tag spans with a user ID (user.id or your own attribute), you can group by it. Multiple agents in one session roll up under that session, and sessions roll up under the user.

From there you get per-user token usage, cost, latency, tool calls, and error rates across all their agents. That's the unit economics view: what each user actually costs you to serve, and which agent is driving it.

If you're not tagging user IDs yet, that's a one-line change in your instrumentation.

Curious @natalia_iankovych , are your agents sharing one model or mixing models across a session? That changes how you'd want to break cost down.

Report

20h ago

OpenObserve

Maker

@natalia_iankovych Thanks!

To add. Since the traces are OpenTelemetry-based, you can attach user/session attributes to your telemetry and use those dimensions to analyze the data.

Report

20h ago

OpenObserve

Maker

@natalia_iankovych This should work well for a multi-agent setup where several agents contribute to a single user session.

A few useful docs:

Report

20h ago

OpenObserve

Maker

@natalia_iankovych Yes — user is a first-class dimension. user.id is normalized at ingest, so every span, trace and session carries it. Sessions are listed with their user, there's a top-users-by-cost view, and anything beyond that is a group-by: cost per user, tokens, sessions, steps, error rate.

Your case is actually the easy one — many agents inside a single user session all roll up into that session, so cost per user session is one number with the per-agent split underneath it.

For unit economics you usually want tenant or plan as well. Any custom attribute you attach to the trace works as a group-by the same way, so that's a one-line change on your side.

Are you costing per end user, or per tenant/plan?

Report

20h ago

OpenObserve

Maker

@natalia_iankovych When you combine that with session recording and frontend to backend tracing you get complete visibility and a single pane of glass.

Report

18h ago

1 2 3

Previous OpenObserve Launches

OpenObserveAI-native, open-source Datadog alternative

Launched on March 18th, 2026

Forum Threads

p/openobserve

•

3d ago

We're launching AI Observability this Thursday. Here's what it is and how you can help.

Hey everyone,

Quick heads up: OpenObserve AI Observability goes live on Product Hunt this Thursday, September 10, at 12:01 AM PT.

View all

Hi Product Hunt, Ashish here, Head of Engineering at OpenObserve.

If your AI agent got stuck in a tool-call loop right now, would you know? Would you spot it before your customer did?

We didn't.

During a live demo, our own AI SRE Agent silently stalled. No errors. No timeouts. Nothing useful in the logs.
We had to dump raw spans and debugged through them just to find the loop.

Reading raw spans isn't a debugging strategy—it’s an apology waiting to happen.

So we built AI Observability directly into OpenObserve. We wanted to see inside the black box.

Here is what it actually gives you:

Sessions map out every single turn. You see every LLM request, tool call, token count, cost, and exactly what prompt caching saved you.
Agent Graph plots your agents, tools, and models onto the exact same service map as the rest of your backend infrastructure.
Agent Behavior automatically flags the sessions that loop or fail—long before a user complains.
Online Evals let you score live sessions using any judge model (bring your own provider and key).
Annotation Queues let you turn those ugly, failed sessions into clean datasets so you can regression-test your fixes.

The best part? It's OpenTelemetry-native.

Our SRE Agent runs on this daily now, and it's still our harshest critic.

Point it at your own agent traces. I'd love to hear what you find.

CLAUDE_CODE_ENABLE_TELEMETRY=1 CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 OTEL_METRICS_EXPORTER=otlp OTEL_LOGS_EXPORTER=otlp OTEL_TRACES_EXPORTER=otlp OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf OTEL_EXPORTER_OTLP_ENDPOINT=https://host/api/:org OTEL_EXPORTER_OTLP_HEADERS=Authorization=Basic <base64 of email:password>

OpenObserve

AI-native, open-source Datadog alternative

AI-native, open-source Datadog alternative

AI Observability by OpenObserve

Previous OpenObserve Launches

Forum Threads

We're launching AI Observability this Thursday. Here's what it is and how you can help.

Previous OpenObserve Launches

Forum Threads

We're launching AI Observability this Thursday. Here's what it is and how you can help.

What's great

What needs improvement

vs Alternatives

What's great

What needs improvement

vs Alternatives

What's great

What needs improvement

vs Alternatives

What's great

What needs improvement

vs Alternatives

What's great

What needs improvement

vs Alternatives

What's great

What needs improvement

vs Alternatives