@kellytk from the looks of the tokio-rs/tracing library, it looks like the intention is a big different than what opentelemetry / opentracing are designed for. Rather than the emitting of various events, opentelemetry is specifically designed for the emitting of specific types of telemetry. Namely, distributed traces, metrics, and logs.
That all said, the idea of logging specific event points is really interesting. In OTelemetry we have a concept of metric measures that I could see working closely with emitting events, since the latter could be a raw format that feeds into an aggregated former.
telemetryapplication for emitting structures events. users then instrument with that library to emit trace events and OTel subscribes and creates/updates spans based on those events
kind of misc, but I wanted to direct some attention towards open-telemetry/community#163
TL;DR, I would like OpenTelemetry to have some “soft” guidelines on how we treat each other (as well as newcomers to the project). This is not about harrassment and other “bannable” / code-of-conduct infractions, but more about our aspirations for communication and how we treat each other. Happy to take any and all feedback, including “this is a bad idea for <reason>”.
examples/k8s.yamlthere. An operator is really helpful for a production deployment though, especially if it's able to handle day 2 operations
we need to setup a opentelemetry org in dockerhub
opentelemetryon quay.io and added @pavolloffay and @objectiser as admins as well. I'm happy to add others
:wave: Hello everyone!
to what extent will the spec be recommending or mandating common attribute names?
If you think of the
name as the instance of a span, does anyone have a recommendation they use as the name for the
class of a span? eg.
name: DB select-todo-items vs
type: postgresql-query, or
name: GET /user/:userId vs