pranay01

open source observability platform - https://github.com/signoz/signoz

SigNoz | US Remote | Forward Deployed Engineer, DevRel and Growth Marketing | Full-Time | $120K-$200K

SigNoz is an open source observability platform based natively on OpenTelemetry. We developers monitor their applications & infrastructure, and troubleshoot problems quickly. https://github.com/SigNoz/signoz

We have crossed 23000+ Github stars, 6000+ members in the slack community and 150+ contributors.

We are expanding our US team & hiring for the following roles:

Forward Deployed Engineer - https://jobs.ashbyhq.com/SigNoz/8f0a2404-ae99-4e27-9127-3bd6...

DevRel Engineer - https://jobs.ashbyhq.com/SigNoz/8447522c-1163-48d0-8f55-fac2...

Growth Marketing - https://jobs.ashbyhq.com/SigNoz/a3644d27-3dfc-44cb-962d-5f27...

if interested, reach out directly to us at hiring@signoz.io. Mention that you saw this post in HN

like that it is based on OTel. can you share the project if it is public?

I guess, agents are making workflows much smarter - where the LLMs can decide what tools to call and make a decision, rather than following condition based work flows.

Agents are not that different than what lot of us are already doing. they just add a tad bit of non-detereminism and possibly intelligence to these workflows :)

Yes, it is happening because OpenInference assumes these span kind values https://github.com/Arize-ai/openinference/blob/b827f3dd659fc...

Anything which doesn't fall in other span kinds is classified as `unknown`

For reference, these are span kinds which opentelemetry emits - https://github.com/open-telemetry/opentelemetry-python/blob/...

one of the cases we have observed is that Phoenix doesn't completely stick to OTel conventions.

More specifically, one issue I observed is how it handles span kinds. If you send via OTel, the span Kinds are classified as unknown

e.g. The Phoneix screenshot here - https://signoz.io/blog/llm-observability-opentelemetry/#the-...

interesting. So, you mean say if an agent is working on automatically doing a PR review, how many such calls to agents are failing, how much time they are taking, etc?

Lot of this you can do with traces today which trace AI specific calls

leveraged for agent platforms & orchestration

can you share more on what you mean by this?

thanks for the detailed note

My first "sniff test" for observability platforms is a tool to quickly jump to a given trace/span by ID.

You should be able to do this in SigNoz https://www.loom.com/share/71a2a95b76584b3983d9eeebb60ac420?...

"show this event within the surrounding context"

we have this in the context logs. does this solve your use case or you mean something else? https://www.loom.com/share/9039afd5c4bf45e7b357a22c9943bb32?...

But you make up for that by having bad search in traces

Did you mean for this to search across all attributes in spans or when you know which attribute you want to search in? If later, than you can do this through our query builder even today.

Your feedback on "Trace View" is fair. We are planning some improvements on that

I don't think the primary goal here is "surveillance" but better understanding where in the team are tools like claude code getting adopted, what models are being used, are there best practices to learn in token usage which could make it more efficient

great to hear. yes, it can help understand how developers are using Claude Code and also optimise token usage etc.

SigNoz maintainer here. Curious, when did you try SigNoz (which version/which timeframe) and any specific feedback on what you don't like about it's tracing UI? Would be helpful for us to understand areas to improve on

you might want to take a look at SigNoz - https://github.com/SigNoz/signoz logs, metrics & traces in a single pane and you can create advanced alerts and dashboards as well

PS: I am one of the maintainers

hey, SigNoz maintainer here.

Can you share which version of SigNoz did you try or what time frame? We recently made a lot of improvement in how you can host SigNoz including support for Postgres and better docs fro self hosting corretcly - https://signoz.io/docs/collection-agents/get-started/

SigNoz | https://signoz.io | Remote (US) | Platform Engineer | Full Time

SigNoz is an open source observability platform based natively on OpenTelemetry

Looking for a Platform engineer to join our team at SigNoz. You will be part of the first few hires in our US team and will have the opportunity to own a significant part of the product.

Why us?

- Opportunity to work in a global dev infra product

- Handle Petabyte scale

- Work on an open source product (22K+ github stars). Engage with the community. Build your GitHub profile

- Fully Remote

Detailed JD and application form here - https://jobs.ashbyhq.com/SigNoz/01ebd081-db0c-4eec-8a8b-e346...

Interesting game!

hey, SigNoz maintainer here.

an official first-party product on top

So, seems like the direction you are going is trying to enable ingestion to different ClickHouse instances (Cloud/BYOC/Self hosted) and then use HyperDX as the query & visualization layer on top.

I think, fundamental difference we have at SigNoz on how we approach this is that we want to solve for observability and the fact that we use ClickHouse today is just a point in time fact. In future, we are open to use any other datastore which may be more performant for observability. We can also use different databases to augment different use cases in observability.

Ultimately from a product philosophy standpoint, we aren't big believers in the "3 pillars" concept, which tends to manifest as 3 silos/tabs for "logs", "metrics", "traces" (this isn't just SigNoz - but across the industry).

I am not too sure on how this works in practice, do you expect people to write metrics and logs query in the same explorer. From our experience, the query writing experience is very different for logs and metrics and you need different defaults to make the query writing UX easier for users.

Though I agree, the ability to query across signals is an important point and we are already doing work on this at SigNoz (https://signoz.io/blog/observability-requires-querying-acros...).

Thanks for the shoutout for SigNoz and the feedback.

We are actively working on shipping innovative features in this space. btw, we also have our launch week going on currently if you want to have a look :)

https://signoz.io/launch-week/

Thanks! great to see that you liked it

Do share any feedback you have on github or on our slack community - https://signoz.io/slack

Check out SigNoz, https://github.com/signoz/signoz

Has metrics, logs and traces in a single app and built natively on OpenTelemetry

Disclaimer : I am a maintainer

Thanks for the shout out to SigNoz. Do reach out to us in our slack community if you need any help setting things up - https://signoz.io/slack

For others checking out this thread, here's our github repo - https://github.com/signoz/signoz

PS: I am one of the maintainers at SigNoz

there will be a valid open source competitor to Grafana ecosystems

You may want to check out SigNoz [1] - takes a all in one app approach compared to different modules for each signal approach which Grafana takes

Disclaimer : I am one of the maintainers

[1] https://github.com/SigNoz/signoz

If you want to check out OpenTelemetry, Otel-collector does the same job - though it's tightly coupled to opentelemetry

As mentioned by philip below, 500 spans is a very small amount. I have seen customers send 1000s of spans in a trace very easily

part of the reason for that experience is also because DataDog is not open telemetry native and all their docs and instructions encourage use of their own agents. Using DataDog with Otel is like trying to hold your nose round over your head

You should try Otel native observability platforms like SigNoz, Honeycomb, etc. your life will be much simpler

Disclaimer : i am one of the maintainers at SigNoz

I literally gave a lightning talk on this in Kubecon NA last year. Here's the youtube video, might help you get some perspective

tl;dr

while there are certainly many areas to improve for the project, some reasons why it could seem complicated

Extensibility by Design: Flexibility in defining meters and signals ensures diverse use cases are supported.

It's still a relatively new technology (~3 years old), growing pains are expected. OpenTelemetry is still the most advanced open standard handling all three signals together.

[1]https://www.youtube.com/watch?v=xEu8_Aeo_-o

Agree. Here's the repo for SigNoz if you want to check it out - https://github.com/signoz/signoz

Congrats on the launch!

TIL that BigPanda and Moogsoft solve the same problems which you are trying to solve :)

Would have loved to see SigNoz also in the list of supported integrations

StarTree is compliant with PromQL

do you mean one can write query on StarTree using PromQL?

Yeah, totally agree this is very helpful