TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

OpenTelemetry protocol with Apache Arrow

107 pointsby tanelpoder4 days ago

7 comments

akdor11543 days ago
Damn that&#x27;s some scope creep if I ever saw it: &#x27;try sending Arrow frames end to end&#x27; =&gt; &#x27;rewrite the otel pipeline in rust&#x27;. Seems like the goals of the contributors don&#x27;t exactly align with the goals of the project.<p>Kind of a bummer - one thing i was hoping to come out of this was better Arrow ecosystem support for golang.
andygrove4 days ago
I&#x27;ve just started exploring adding OpenTelemetry support to the Comet subproject of DataFusion. I&#x27;m excited to see the integration with Apache Arrow (Rust) and potentially DataFusion in the future.
评论 #43986530 未加载
mike_heffner3 days ago
Thanks for sharing this — it’s a really promising direction. The advantages of Arrow for OTLP, especially when used end-to-end, are compelling given the protocol overhead of OTLP.<p>We’ve been thinking along similar lines with the use of Rust, particularly for OpenTelemetry collection in environments where high performance and low resource overhead are critical, such as edge and serverless. With that in mind, we’ve open-sourced a lightweight OpenTelemetry collector written in Rust to address these use cases. We’ve also developed a native Lambda extension around it, and have seen encouraging interest from folks aiming to improve cold start times.<p>The project is still fairly early, but we’re optimistic that Rust can open up new opportunities for efficient observability pipelines. Vendors like Datadog are also moving in this direction with their Lambda extension and appear to be adopting Rust more broadly for data-plane components.<p>If this resonates, feel free to take a look here: <a href="https:&#x2F;&#x2F;github.com&#x2F;streamfold&#x2F;rotel">https:&#x2F;&#x2F;github.com&#x2F;streamfold&#x2F;rotel</a>. We’d love to hear your thoughts on how this could be useful.
julian-datable3 days ago
Integrations with OTLP are critical to driving adoption and probably one of the biggest pain points we&#x27;ve encountered when adopting it ourselves (and encouraging others to the same).<p>Adopting OTLP without third-party support is pretty time consuming, especially is your tech stack is large and&#x2F;or varied.<p>Re runtimes: curious about this too. Feels like the right direction if you’re optimizing a telemetry pipeline.
SomaticPirate4 days ago
Wow, anyone able to provide a ELI5? OTel sounds amazing but this is flying over my head
评论 #43978440 未加载
评论 #43977090 未加载
评论 #43981703 未加载
KAdot4 days ago
&gt; We are interested in making OTAP pipelines safely embeddable, through strict controls on memory and through support for thread-per-core runtimes.<p>I&#x27;m curious about the thread-per-core runtimes, are there even any mature thread-per-core runtimes in Rust around?
评论 #43977834 未加载
gitroom3 days ago
Man Ive dipped my toes into this too, and yeah, the way everyone wants different things always shakes things up fast. Kinda love seeing where it all ends up tbh.