opentelemetry-rust VS rillrate

Why are you accusing me of posting an LLM reply?

I just shared that I enjoyed using and contributing to OpenTelemetry. I never used an LLM. Do I really need to prove that I'm human?

- a couple PRs I posted to Rust impl: https://github.com/open-telemetry/opentelemetry-rust/pulls?q...

I believe if you set up an Open Telemetry tracer, you can use the Datadog Lambda Extension to send those traces (as well as logs and some additional lambda metrics) to Datadog.

A lot of APM products these days support OpenTelemetry in addition to their custom APM agents. You could try using https://github.com/open-telemetry/opentelemetry-rust paired with an APM provider that works with OpenTelemetry.

(Source: https://github.com/open-telemetry/opentelemetry-rust/blob/main/examples/http/src/client.rs)

Here’s a recent example: https://github.com/open-telemetry/opentelemetry-rust/pull/881

dd-trace-layer is a middleware for sending Datadog's trace. It's based on Tower and OpenTelemetry Rust.

I plan to use OpenTelemetry for my async project, but I'm a bit unclear about whether to use the `tracing`, native `opentelemetry` or even the `tracing-opentelemetry` crate? Both tracing and opentelemetry support instrumenting async/await code. What is the relationship between tracing and opentelemetry? If Otel is trying to standardize a spec for observability across languages and vendors and supports async/await rust code, what's the motivation to learn the `tracing` crate's API at this time?

The git repository called opentelemetry-rust contains implementations of several crates that expand the opentelemetry ecosystem. There you can find common instrumentations, exporters, and subscribers use them in a Rust program.

Not sure about the Aspecto exporter you are using but the last time I tried to use the Jaeger one it seemed fundamentally broken if you had even a moderate amount of spans in a way that keeps popping up and the developers keep closing with various suggestions for workarounds (on the issues of previous people encountering it) that did not work for me ( https://github.com/open-telemetry/opentelemetry-rust/issues/851 ).

You could give open telemetry a try. I've been meaning to check it out, but haven't had a chance yet. https://github.com/open-telemetry/opentelemetry-rust

You can see sources of the Yew App here: https://github.com/rillrate/rillrate/tree/trunk/pkg-dashboard

Cool! I also found an opportunity to have multiple layers of controls and monitoring. If a subcrate also uses rillrate, then a developer will have both dashboards: for the app and the subcrate. It's a great opportunity for monitoring and tweaking almost every used component. I just added a demo: https://github.com/rillrate/rillrate/tree/trunk/demo

I've released RillRate for Python 🎉

The repository: https://github.com/rillrate/rillrate

It uses RillRate - the dynamic UI for bots, microservices, and IoT.