OpenTelemetry-Go Contrib

repository·main·Indexed 23 days ago

https://github.com/open-telemetry/opentelemetry-go-contrib

A repository of community-contributed extensions for the OpenTelemetry-Go SDK. It provides instrumentation for third-party libraries, custom propagators, exporters, and resource detectors for various cloud environments including AWS (Lambda, EC2, ECS, EKS), Azure (App Service, Container Apps, Functions, VM), GCP, Hetzner Cloud, IBM Cloud VPC, Vultr, and Kubernetes API.

Tokens: 71.8K
Snippets: 106
Records: 544
Agent score: 82%

What's inside opentelemetry-go-contrib

Overview of OpenTelemetry-Go Contrib
main
OpenTelemetry-Go Contrib is a collection of 3rd-party packages designed to extend the core OpenTelemetry-Go ecosystem. It provides additional functionality for instrumentation, propagation, resource detection, and data export.
The repository is organized into several functional categories:
- Instrumentation: Packages that provide OpenTelemetry instrumentation for 3rd-party libraries.
- Propagators: Packages providing context propagators for 3rd-party propagation formats.
- Detectors: Resource detectors for identifying 3rd-party cloud computing environments.
- Exporters: Exporters for 3rd-party export formats.
- Samplers: Additional implementations of OpenTelemetry samplers.
- Bridges: Adapters for 3rd-party instrumentation frameworks.
- Processors: Additional implementations of OpenTelemetry processors.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/README.md
Overview of OpenTelemetry Zap Log Bridge
main
The OpenTelemetry Zap Log Bridge allows you to bridge logs from the uber-go/zap logging library into the OpenTelemetry Logs API. This enables your Zap logs to be processed by OpenTelemetry log exporters, allowing for unified observability where logs can be correlated with traces and metrics within the OpenTelemetry ecosystem.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/bridges/otelzap/README.md
Use the Azure Functions Resource Detector
main
The azurefunctions detector is used to automatically identify and populate resource attributes for applications running within Azure Functions. It extracts metadata about the Azure Functions environment to enrich OpenTelemetry telemetry with relevant cloud provider context.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/azure/azurefunctions/README.md
Use the Azure App Service Resource Detector
main
The Azure App Service Resource Detector is a component of the OpenTelemetry Go Contrib library designed to automatically detect and populate resource attributes when your application is running on Azure App Service. It identifies the specific Azure App Service environment and adds relevant metadata to your OpenTelemetry resources, which helps in correlating telemetry with your Azure infrastructure.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/azure/azureappservice/README.md
Use the Vultr Cloud Compute Resource Detector
main
The Vultr detector is a resource detector for OpenTelemetry-Go that automatically identifies Vultr cloud compute resources. It populates resource attributes with metadata specific to the Vultr environment, allowing for better observability and filtering of telemetry data originating from Vultr instances.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/vultr/README.md
Use the Azure Container Apps Resource Detector
main
The azurecontainerapps detector is used to automatically identify and populate resource attributes for applications running within Azure Container Apps. It extracts metadata about the container app environment to enrich OpenTelemetry telemetry with relevant cloud provider context.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/azure/azurecontainerapps/README.md
Discover and use instrumentation packages
main
The instrumentation/ directory contains instrumentation for 3rd-party Go packages and parts of the standard library. You can use these to automatically collect Traces and Metrics for your application's dependencies.
To find the most up-to-date list of available instrumentation, consult the OpenTelemetry registry.
Commonly supported packages include:
- Web Frameworks: gin (otelgin), echo (otelecho), gorilla/mux (otelmux), go-restful (otelrestful).
- Database/Drivers: mongo-driver (otelmongo), grpc (otelgrpc).
- Standard Library: net/http (otelhttp), net/http/httptrace (otelhttptrace).
- Cloud SDKs: aws-sdk-go-v2 (otelaws).
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/README.md
Use the Azure VM Resource detector
main
The azurevm detector is used to automatically detect Azure Virtual Machine resource information for OpenTelemetry resource attributes. This allows your application to enrich its telemetry with metadata specific to the Azure VM environment it is running in.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/azure/azurevm/README.md
Hetzner Cloud Resource Detector for Go
main
The Hetzner Cloud Resource Detector is a component for OpenTelemetry-Go that automatically detects and populates resource attributes for applications running on Hetzner Cloud infrastructure. It allows you to enrich your telemetry data with metadata specific to your Hetzner environment.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/hetzner/README.md
IBM Cloud VPC Resource Detector for Go
main
The ibmcloud/vpc package provides a resource detector for IBM Cloud VPC environments. It is used to automatically identify and populate resource attributes for OpenTelemetry resources when running on IBM Cloud VPC infrastructure.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/ibmcloud/vpc/README.md
Use AWS X-Ray Propagator and IDGenerator
main
This package provides an AWS X-Ray compatible TextMapPropagator and IDGenerator. Use these components when you need to propagate trace context within AWS environments that rely on X-Ray's specific trace ID format and header propagation logic.
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/propagators/aws/xray/README.MD
How Passthrough setup affects trace visualization
main
In a distributed system, if a component in the middle of a call chain (e.g., Outer -> Passthrough -> Inner) only has propagators configured and lacks an SDK TracerProvider, it will not create its own spans.
In a standard setup where all components have an SDK, the trace would look like:
```
|-------outer---------|
 |-Passthrough recv-| 
  |Passthrough send| 
    |---inner---| 
```
In a Passthrough setup where the middle component only has propagators, the trace will skip the middle component's spans and appear as if the outer component called the inner component directly:
```
|-------outer---------|
    |---inner---| 
```
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/examples/passthrough/README.md