1,289 karma · joined September 12, 2014
Maintainer - https://github.com/SigNoz/signoz
Twitter - https://twitter.com/pranay01
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
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 :)
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/...
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-...
Lot of this you can do with traces today which trace AI specific calls
can you share more on what you mean by this?
> 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
PS: I am one of the maintainers
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 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...
> 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...).
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 :)
Do share any feedback you have on github or on our slack community - https://signoz.io/slack
Has metrics, logs and traces in a single app and built natively on OpenTelemetry
Disclaimer : I am a maintainer
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
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
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
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.
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
do you mean one can write query on StarTree using PromQL?