Adding to the registry
New entries and updates to the ecosystem lists, including the registry, are no longer being accepted while maintainers work out each list’s future. For details and to share input, see issue #11377.
Registry Types
When adding your project to the registry, you need to specify a registryType.
This field categorizes your project based on its relationship to OpenTelemetry.
Below are the possible values and their definitions:
application integration
Use for: Applications or services that have OpenTelemetry natively integrated (built-in support) without requiring external plugins or instrumentation libraries.
Examples: See the list of native application integrations on the Integrations page.
This is the only registry type that allows commercial/proprietary licenses.
api
Use for: Packages that implement the OpenTelemetry API for a language: the interfaces and no-op implementations that instrumented code and libraries depend on, independent of any SDK.
Examples: The Ruby opentelemetry-api, opentelemetry-metrics-api, and
opentelemetry-logs-api gems.
connector
Use for: OpenTelemetry Collector connector components, which join two pipelines by acting as the exporter of one and the receiver of the other, possibly translating between signal types.
Examples: Count connectors, span-to-metrics connectors, or failover connectors.
core
Use for: Core OpenTelemetry project components only. This is never applicable to third-party components or non-OpenTelemetry project components.
exporter
Use for: Exporter components of the OpenTelemetry Collector or exporter libraries within language-specific SDKs.
Examples: OTLP exporters, Prometheus exporters, or any component that sends telemetry data to external systems.
Note: Not applicable for third-party components that are exporting telemetry data.
extension
Use for: Collector or SDK extensions that extend OpenTelemetry functionality.
Examples: Authenticators, config sources/providers, service discovery, health checks/pprof/zpages, or other components that augment Collector/SDK behavior.
id-generator
Use for: SDK components that customize how trace and span IDs are generated.
Examples: AWS X-Ray-compatible ID generators.
instrumentation
Use for: Instrumentation libraries or native instrumentations for specific libraries/frameworks.
Examples: HTTP instrumentation, database instrumentation, framework-specific instrumentation, or auto-instrumentation agents where applicable.
log-bridge
Use for: Language-specific adapters that connect existing logging frameworks/APIs to OpenTelemetry logging, allowing apps to emit OTel logs via familiar logging APIs.
Examples: Bridges/handlers/appenders for frameworks such as Java SLF4J/Log4j/Logback, Python logging, JavaScript Winston/Pino, and Go log/slog/zap.
metric-producer
Use for: SDK components that bridge metrics from third-party sources into an SDK metric reader.
processor
Use for: OpenTelemetry Collector processor components.
Examples: Batch processors, attribute processors, sampling processors, or any component that processes telemetry data within the collector pipeline.
propagator
Use for: Context propagators, which carry trace context and baggage across process boundaries in a specific wire format.
Examples: B3, Jaeger, or AWS X-Ray propagators.
provider
Use for: OpenTelemetry Collector provider components.
Examples: Configuration providers, credential providers, or any component that provides resources or configuration to the collector.
receiver
Use for: OpenTelemetry Collector receiver components.
Examples: OTLP receivers, Prometheus receivers, or any component that receives telemetry data from external sources.
Not applicable for third-party components that are receiving OpenTelemetry telemetry.
resource-detector
Use for: Resource Detectors for language-specific SDKs.
Examples: AWS resource detectors, GCP resource detectors, or any component that automatically detects and adds resource information to telemetry.
sampler
Use for: SDK samplers, which decide which spans are recorded and exported.
Examples: AWS X-Ray remote samplers or rule-based samplers.
sdk
Use for: Packages that implement the OpenTelemetry SDK for a language.
Examples: The Ruby opentelemetry-sdk, opentelemetry-metrics-sdk, and
opentelemetry-logs-sdk gems.
semantic-convention
Use for: Packages that provide semantic-convention constants for a language.
Examples: The Ruby opentelemetry-semantic_conventions gem.
utilities
Use for: Any other tool that people can use to work with OpenTelemetry.
Examples: Testing utilities, debugging tools, migration tools, or any helper library that facilitates working with OpenTelemetry.
Feedback
Was this page helpful?
Thank you. Your feedback is appreciated!
Please let us know how we can improve this page. Your feedback is appreciated!