Live data from Hacker News

Show HN: Open-source APM with support for tracing, metrics, and logs

app.uptrace.dev

41–49 of 49 posts

Re: Show HN: Open-source APM with support for tracing, metrics, and logs

#41
post #40

Anyways to export dashboard for public viewing, maybe even static image? It looks like all drawing is done client side at present.

Echarts which we use supports exporting charts as images so it probably can be added relatively easy. Embedding is another possible option.

Re: Show HN: Open-source APM with support for tracing, metrics, and logs

#44
post #26

Before you try, please make sure you are comfortable with their license - https://github.com/uptrace/uptrace/blob/master/LICENSE (Business Source License 1.1), which as License says "The Business Source License (this document, or the “License”) is not an Open Source license"

It’s a shame that whenever something cool is posted on HN some long ass thread about licensing floats to the top. Nothing wrong with the parent comment but do we really need a ‘yes it is’ / ‘no it isn’t’ back and forth that goes on seemingly forever almost EVERY TIME? I’m gonna need a ‘license nitpick remover’ to complement my adblocker!

It says Open Source right in the HN headline. That the license contradicts that seems like important information to discuss.

Re: Show HN: Open-source APM with support for tracing, metrics, and logs

#47

I see lots of new tracing options these days, and that seems to have taken over the "APM" term. I still have yet to see new profiling options. When I think of APM, I think of CPU profiling and automatic instrumentation of black box systems, not request tracing. I should be able to see which function calls are slow/problematic, without having to add code to the application.

I think there is some interesting work being done with eBPF in the profiling space

Re: Show HN: Open-source APM with support for tracing, metrics, and logs

#48
post #5

Nice to see so many new projects in the area of APM in the last few months. We recently tried Signoz and Grafana Tempo and while I can't say something about uptrace yet (will definitely try it out) I want to list some pros and cons about them. Grafana Tempo Pros: - Easy and smooth integration into our existing Grafana instance, no additional frontend needed - No new storage engine needed (No additional Clickhouse, Po…

thanks for the mention. I am one of the maintainers at SigNoz [1].

Thanks for laying out the points in Pro section. We also recently launched logs witg v0.11.0 so you may want to give it a try again - we now have have metrics, logs and traces in a single app.

Would love to understand a few points in more details you have mentioned in Cons for SigNoz

> - Uses new storage engines (or extends the software stack) with adding ClickHouse Can you explain a bit more on the concern here?

> - Doesn't provide SSO yet, so you need to manage users differently

This is in our roadmap and we will be shipping it soon.

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

Re: Show HN: Open-source APM with support for tracing, metrics, and logs

#49
post #19

I wonder if anyone can answer some question on distributed tracing for me. The difference between old days of APM vs. tracing as I understand is two things. 1. Originally APM was single process and it was language aware, usually do sampling stacktrace to find where times are being taken and some very well know place to instrument for exact timing say response time or query time. Tracers are more working by instrument…

My understanding is that APM became or always was a marketing term which is used rather freely. For that reason I try to avoid it, but search engines love it and I don't know a better alternative. >Whether I can find out why that component is slow might not be as easy (not sure what granularity tracing happens inside a component). It is true that you can't always guess what operation going to be slow and instrument i…

By traditional APM I primarily meant stacktrace sampling based monitoring of applications.

As for overhead of tracing I wanted roughly compare (obviously it depends on the application a lot) stacktrace sampling vs. tracing based one. Are they usually of similar overhead or say tracing is lighter?

I was thinking tail based sampling could be a lot more expensive because say a head based sampling is doing trace for 10% request whereas regardless of how many sample are kept a tail based one is dong 100% trace. So tracing overhead would be much higher right?

I'm not sure why head based sampling is being called accurate in your doc? Isn't it the least accurate in a sense that it's purely statistical and rare outlier like latency spike or error could be missed?

And yes obviously a tail based sampling has to be something like (trace 5% random request or 1 every five + any outlier that gets calculated based on the captured trace)/

Post reply on HN