This documentation serves to document the "look and feel" of a basic layout for OpenTelemetry projects. This package layout is intentionally generic and it doesn't try to impose a language specific package structure.
Here is a proposed generic package structure for OpenTelemetry API package.
A typical top-level directory layout:
api
├── context
│ └── propagation
├── metrics
├── trace
│ └── propagation
├── baggage
│ └── propagation
├── internal
└── logs
Use of lowercase, CamelCase or Snake Case (stylized as snake_case) names depends on the language.
This directory describes the API that provides in-process context propagation.
This directory describes the Metrics API that can be used to record application metrics.
This directory describes the Baggage API that can be used to manage context propagation and metrics-related labeling.
This API consist of a few main classes:
Traceris used for all operations. See Tracer section.Spanis a mutable object storing information about the current operation execution. See Span section.
Private application and library code.
TODO: logs operations
Here is a proposed generic package structure for OpenTelemetry SDK package.
A typical top-level directory layout:
sdk
├── context
├── metrics
├── resource
├── trace
├── baggage
├── internal
└── logs
Use of lowercase, CamelCase or Snake Case (stylized as snake_case) names depends on the language.
This directory describes the SDK implementation for api/context.
This directory describes the SDK implementation for api/metrics.
The resource directory primarily defines a type Resource that captures information about the entity for which stats or traces are recorded. For example, metrics exposed by a Kubernetes container can be linked to a resource that specifies the cluster, namespace, pod, and container name.
This directory describes the SDK implementation for api/trace.
Private application and library code.
TODO: logs operations