-
Schemaprocessor in collector-contrib. It's a stub and does not do anything. It's not included into collector-contib image.
-
Search for https://opentelemetry.io/schemas/ does not show if anyone uses transformation logic.
-
There is no schema transformation logic in exporters in
opentelemetry-collector-contribrepo. -
There is a schema parser https://pkg.go.dev/go.opentelemetry.io/otel/schema/v1.1
Based on:
- AMQP
- General
- Azure ServiceBus AMQP extensions
- Azure EventHubs AMQP extensions
- JMS
- Kafka
- RabbitMQ
Context: https://gist.github.com/lmolkova/b9004307a09be788af04f05ebe22ad3c
Follows general OTel Metrics conventions and depends on OTel Messaging conventions changes
| Name | Description | Units | Instrument Type (*) | Value Type | Attribute Key(s) | Attribute Values |
|---|
- Host:
net.peer.name:net.peer.port(actual host contacted)- always present
- Topic name:
messaging.destination.name- maybe present per message, not per publish call - https://stackoverflow.com/questions/39093488/can-single-kafka-producer-produce-messages-to-multiple-topics-and-how
no url notion
The immediate goal is to report metrics from Azure messaging SDKs (EventHubs and ServiceBus) to help customers detect and investigate configuration issues, performance bottlenecks, application and SDK bugs.
It can be broken down into smaller goals:
- define metrics essential for messaging scenarios
- define Metrics API in azure-core
- metrics plugin implementations
Quarkus configuration is very similar to Spring:
- supports
application.propertiesandapplication.yaml - conventions on property names are the same: '.' as separator, kebab-case.
- supports property sources, iterating over them and getting value by name programmatically or with annotation
What's different:
- Quarkus uses smallrye-config which is implementation of microprofile-config. Annotation and feature-wise, it's similar to spring, but more explicit (reflection is discouraged)
- Property metadata can be extended with microprofile language-server extension (example)