Re:OpenTelemetry Is Too Complicated
by pranabgohain on Wednesday April 03, 2024 @02:53AM
(#39914369)
Maybe if you're setting everything up yourself, yes. But with Observability backends (like https://www.kloudmate.com for example) that support OTel natively, all you have to do is auto-instrument or collect logs, while the tool correlates everything else and presents the data.
Re:OpenTelemetry Is Too Complicated
by switch007 on Wednesday April 03, 2024 @05:10AM
(#39915047)
Lots of your recent comments appear to be self promotion. Guidelines state "Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.”
Re:OpenTelemetry Is Too Complicated
by growse on Wednesday April 03, 2024 @05:28AM
(#39915156)
Given that the actual complaint is that the specific OTel metrics library (it's not specified which) they chose to bundle into their client lib is too complicated, this feels a little click-bait-y.
Re:OpenTelemetry Is Too Complicated
by valyala on Wednesday April 03, 2024 @07:11AM
(#39915913)
VictoriaMetrics CTO here.
The referred library is the official OpenTelemetry package for reading metrics in Go language [1] - more details are available at [2].
Note that we at VictoriaMetrics like the idea of unified observability standard like OpenTelemetry. The issue is in the current otel implementation. It is too bloated and very inefficient. This contradicts our experience with observability cases, which need optimized yet easy to debug format for metrics' transfer in order to reduce costs on CPU and network traffic needed to transfer and process these metrics.
VictoriaMetrics continues investing in OpenTelemetry by providing integration docs [3] and improving the existing functionality for otel metrics' ingestion [4].
Re:OpenTelemetry Is Too Complicated
by jakewins on Wednesday April 03, 2024 @05:55AM
(#39915365)
Yeah this just seemed like people making rude (“designed by monkeys”, really HN?) unspecific statements about a standard while the examples were about a library they didn’t specify..
The referred library is the official OpenTelemetry package for reading metrics in Go language [1] - more details are available at [2].
Note that we at VictoriaMetrics like the idea of unified observability standard like OpenTelemetry. The issue is in the current otel implementation. It is too bloated and very inefficient. This contradicts our experience with observability cases, which need optimized yet easy to debug format for metrics' transfer in order to reduce costs on CPU and network traffic needed to transfer and process these metrics.
VictoriaMetrics continues investing in OpenTelemetry by providing integration docs [3] and improving the existing functionality for otel metrics' ingestion [4].
[1] https://github.com/open-telemetry/opentelemetry-proto-go
[2] https://github.com/VictoriaMetrics/VictoriaMetrics/pull/2570...
[3] https://docs.victoriametrics.com/guides/getting-started-with...
[4] https://github.com/VictoriaMetrics/VictoriaMetrics/issues/60...