TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

112 点作者 vmihailenco超过 2 年前
Uptrace is an all-in-one tool that supports distributed tracing, metrics, and logs. It uses OpenTelelemetry observability framework to collect data and ClickHouse database to store it.<p>You can ingest data using OpenTelemetry Protocol (OTLP), Vector Logs, and Zipkin API. You can also use OpenTelemetry Collector to collect Prometheus metrics or receive data from Jaeger, X Ray, Apache, PostgreSQL, MySQL and many more.<p>The latest Uptrace release introduces support for OpenTelemetry Metrics which includes:<p>- User interface to build table-based and grid-based dashboards.<p>- Pre-built dashboard templates for Golang, Redis, PostgreSQL, MySQL, and host metrics.<p>- Metrics monitoring aka alerting rules inspired by Prometheus.<p>- Notifications via email&#x2F;Slack&#x2F;PagerDuty using AlertManager integration.<p>There are 2 quick ways to try Uptrace:<p>- Using the Docker container - <a href="https:&#x2F;&#x2F;github.com&#x2F;uptrace&#x2F;uptrace&#x2F;tree&#x2F;master&#x2F;example&#x2F;docker" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uptrace&#x2F;uptrace&#x2F;tree&#x2F;master&#x2F;example&#x2F;docke...</a><p>- Using the public demo - <a href="https:&#x2F;&#x2F;app.uptrace.dev&#x2F;play" rel="nofollow">https:&#x2F;&#x2F;app.uptrace.dev&#x2F;play</a><p>I will be happy to answer your questions in the comments.

14 条评论

derN3rd超过 2 年前
Nice to see so many new projects in the area of APM in the last few months.<p>We recently tried Signoz and Grafana Tempo and while I can&#x27;t say something about uptrace yet (will definitely try it out) I want to list some pros and cons about them.<p>Grafana Tempo<p>Pros:<p>- Easy and smooth integration into our existing Grafana instance, no additional frontend needed<p>- No new storage engine needed (No additional Clickhouse, Postgres, etc) as it saves its data to S3<p>- Supports OTLP<p>Cons:<p>- Search is limited by param size and unique params (as its baked to be indexed)<p>- Ingestion is not in real time, but configurable (time to finish span)<p>Signoz:<p>Pros:<p>- Supports OTLP<p>- Integrates Logs and Metrics within the same service (for Grafana you need Loki then)<p>- Supports real time querying<p>Cons:<p>- Uses new storage engines (or extends the software stack) with adding ClickHouse<p>- Adds an additional frontend (might not be relevant for everyone)<p>- Doesn&#x27;t provide SSO yet, so you need to manage users differently<p>Interesting to see, that UpTrace also chose ClickHouse (btw I love ClickHouse!)<p>Some questions:<p>- Can I easily disable certain features? (e.g. alerting)<p>- Is there support for SSO for self-hosted installation?<p>- Are there any recommendations for scaling (e.g. benchmarks) on how many spans&#x2F;s are supported on what hardware?<p>Thanks in advance!
评论 #32734211 未加载
评论 #32748809 未加载
评论 #32736346 未加载
vmihailenco超过 2 年前
You can ingest data using OpenTelemetry Protocol (OTLP), Vector Logs, and Zipkin API. You can also use OpenTelemetry Collector to collect Prometheus metrics or receive data from Jaeger, X Ray, Apache, PostgreSQL, MySQL and many more.<p>The latest Uptrace release introduces support for OpenTelemetry Metrics which includes:<p>- User interface to build table-based and grid-based dashboards.<p>- Pre-built dashboard templates for Golang, Redis, PostgreSQL, MySQL, and host metrics.<p>- Metrics monitoring aka alerting rules inspired by Prometheus.<p>- Notifications via email&#x2F;Slack&#x2F;PagerDuty using AlertManager integration.<p>There are 2 quick ways to try Uptrace:<p>- Using the Docker container - <a href="https:&#x2F;&#x2F;github.com&#x2F;uptrace&#x2F;uptrace&#x2F;tree&#x2F;master&#x2F;example&#x2F;docker" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uptrace&#x2F;uptrace&#x2F;tree&#x2F;master&#x2F;example&#x2F;docke...</a><p>- Using the public demo - <a href="https:&#x2F;&#x2F;app.uptrace.dev&#x2F;play" rel="nofollow">https:&#x2F;&#x2F;app.uptrace.dev&#x2F;play</a><p>I will be happy to answer your questions in the comments.
评论 #32733945 未加载
bovermyer超过 2 年前
I see lots of new tracing options these days, and that seems to have taken over the &quot;APM&quot; term.<p>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&#x2F;problematic, without having to add code to the application.
评论 #32736454 未加载
评论 #32744648 未加载
jonasdevops超过 2 年前
Before you try, please make sure you are comfortable with their license - <a href="https:&#x2F;&#x2F;github.com&#x2F;uptrace&#x2F;uptrace&#x2F;blob&#x2F;master&#x2F;LICENSE" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uptrace&#x2F;uptrace&#x2F;blob&#x2F;master&#x2F;LICENSE</a> (Business Source License 1.1), which as License says &quot;The Business Source License (this document, or the “License”) is not an Open Source license&quot;
评论 #32735372 未加载
评论 #32734590 未加载
KronisLV超过 2 年前
This seems like a pretty cool project!<p>Currently using Apache Skywalking myself, because it&#x27;s reasonably simple to get up and running, as well as integrate with some of the more popular stacks: <a href="https:&#x2F;&#x2F;skywalking.apache.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;skywalking.apache.org&#x2F;</a><p>I do wonder how ClickHouse (which Uptrace uses) would compare with something like ElasticSearch (which is used by Skywalking and some others) and how badly&#x2F;well an attempt to use something like MariaDB&#x2F;MySQL&#x2F;PostgreSQL for a similar workload would actually go.<p>I mean, something like Matomo Analytics already uses a traditional RDBMS for storing its data, albeit it might be an order of magnitude or two off from the typical APM solution.
评论 #32735766 未加载
tylergetsay超过 2 年前
I think the log interface should be optimized for keyboard navigation and larger screens. On my 4k monitor it only takes up 1&#x2F;2 the width and only shows 10 lines at a time, id expect closer to ~100
评论 #32736300 未加载
tmd83超过 2 年前
I wonder if anyone can answer some question on distributed tracing for me.<p>The difference between old days of APM vs. tracing as I understand is two things.<p>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.<p>Tracers are more working by instrumenting methods of framework&#x2F;servers&#x2F;runtime at well known point and getting the timing. In man ways it&#x27;s a lot more coarse as it might know of a hot loop that I have in my code. But it can trace very well with exact timing at framework boundary like web, cache, db etc.<p>2. The APM were primarily single process and couldn&#x27;t really show a different service&#x2F;process which doesn&#x27;t work in a micro-service&#x2F;distributed world.<p>The way I understand it is that Tracers would allow me to narrow down to the service&#x2F;component very easily. Whether I can find out why that component is slow might not be as easy (not sure what granularity tracing happens inside a component).<p>I wonder if this understanding of mine is correct.<p>The second thing I am really unsure about is sampling and overhead. What&#x27;s the usual overhead of a single tracing (I know it&#x27;s variable) but generally are they more expensive at a single request level. Also do they usually sample and is there a good&#x2F;recommend way to sample this. I forgot exactly who but (probably NewRelic) was saying they collect all traces (like every request?) and discard if they are not anomalous (to save on storage). But does that mean taking a trace is very cheap? And is that end of the request sampling decision something that&#x27;s common or that&#x27;s a totally unique capability some have.
评论 #32735683 未加载
PeterZaitsev超过 2 年前
False Advertising!<p>BSL Licensed is not Open Source. To Be fair Utrace restrictions are relatively light but it is still Source Available project not Open Source
nik736超过 2 年前
Nice! Exactly what I&#x27;ve been looking for, will give it a try for sure. Sentry eats a lot of resources so I was looking for an alternative.
评论 #32734335 未加载
edf13超过 2 年前
Looks nice... I&#x27;m a bit out of touch in this space but my last solution for similar would be Datadog. How does this compare?
评论 #32734333 未加载
xyzzy_plugh超过 2 年前
I&#x27;ve been out of the loop for a while but...<p>&gt; OpenTelemetry Protocol (OTLP)<p>&gt; OTLP<p>&gt; OLTP<p>I&#x27;m going back to bed.
xfer超过 2 年前
Anyways to export dashboard for public viewing, maybe even static image? It looks like all drawing is done client side at present.
评论 #32737889 未加载
ram_rar超过 2 年前
can you elaborate more on why clickhouse for backend? And what challenges if any are you facing with clickhouse?
wdb超过 2 年前
How does it compare to Opstrace? (www.opstrace.com)