3 ms·
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 complicat
by growse 3y ago
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.
- jakewins 3y agoYeah 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..
- valyala 3y agoVictoriaMetrics 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]. [1] https://github.com/open-telemetry/opentelemetry-proto-go https://github.com/open-telemetry/opentelemetry-proto-go [2] https://github.com/VictoriaMetrics/VictoriaMetrics/pull/2570#issuecomment-1221981838 https://github.com/VictoriaMetrics/VictoriaMetrics/pull/2570... [3] https://docs.victoriametrics.com/guides/getting-started-with-opentelemetry/ https://docs.victoriametrics.com/guides/getting-started-with... [4] https://github.com/VictoriaMetrics/VictoriaMetrics/issues/6037 https://github.com/VictoriaMetrics/VictoriaMetrics/issues/60...