Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OpenTelemetry API package layout #86

Merged
merged 4 commits into from
Jun 10, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions specification/package-layout.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# OpenTelemetry Project Package Layout
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mayurkale22 great document!

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.

## API Package
Here is a proposed generic package structure for Public API package.
SergeyKanzhelev marked this conversation as resolved.
Show resolved Hide resolved

### `/metrics`

This directory describes the Metrics API that can be used to record application Metrics.
SergeyKanzhelev marked this conversation as resolved.
Show resolved Hide resolved

### `/resources`

This API for resource information population.

The resource directory primarily defines a type [Resource](../terminology.md#resources) 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.

### `/distributedcontext`

This directory describes the DistributedContext API that can be used to manage metrics-related labeling.
SergeyKanzhelev marked this conversation as resolved.
Show resolved Hide resolved
SergeyKanzhelev marked this conversation as resolved.
Show resolved Hide resolved

This API consists of a few main classes:

- `Entry` is used to label anything that is associated with a specific operation, such as an HTTP request.
- An `Entry` consists of `EntryMetadata`, `EntryKey`, and `EntryValue`.

### `/trace`

This API consist of a few main classes:

- `Tracer` is used for all operations. See [Tracer](./tracing-api.md#tracer) section.
- `Span` is a mutable object storing information about the current operation
execution. See [Span](./tracing-api.md#span) section.
- `SpanData` is an immutable object that is used to report out-of-band completed
spans. See [SpanData](./tracing-api.md#spandata) section.

### `/internal` (_Optional_)
Private application and library code.

### `/log` (_In the future_)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### `/log` (_In the future_)
### `/logs` (_In the future_)

I think it will be plural. Like metrics and resources

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think log (singular) is a convention as package name? /cc @reyang

> TODO: log operations


A typical top-level directory layout:
```
api
├── metrics
├── resources
├── trace
│ ├── propagation # headers that are the public API for trace propagation, using different encodings.
SergeyKanzhelev marked this conversation as resolved.
Show resolved Hide resolved
│ └── samplers # is used to make decisions on `Span` sampling.
├── distributedcontext
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does distributedcontext intend to cover local context (in-process propagation) as well?
If yes, suggest to consider context.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like a hot topic for the Tuesday specification group call =)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the current Java reference implementation context (in-process) is a separate package, probably we should keep it that way as we discussed (currently we document the way java reference implementation did then later change if we agree otherwise).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missed this. @mayurkale22 can you please fix?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

│ └── propagation
├── internal
└── log
```
> Use lowercase or CamelCase or Snake Case (stylized as snake_case) depends on the language.