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

Update README.md #759

Merged
merged 2 commits into from
Aug 20, 2024
Merged
Changes from all commits
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
36 changes: 18 additions & 18 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,26 +70,26 @@ Slack](https://elixir-slackin.herokuapp.com/).
You can find a getting started guide on [opentelemetry.io](https://opentelemetry.io/docs/instrumentation/erlang/getting-started/).

To start capturing distributed traces from your application it first needs to be
instrumented. The easiest way to do this is by using an instrumentation library,
there are a number of [officially supported instrumentation
instrumented. The easiest way to do this is by using an instrumentation library.
There are a number of [officially supported instrumentation
libraries](https://github.com/open-telemetry/opentelemetry-erlang-contrib) for
popular Erlang and Elixir libraries and frameworks.

## Design

The [OpenTelemetry
specification](https://github.com/open-telemetry/opentelemetry-specification)
defines a language library as having 2 components, the API and the SDK. The API
defines a language library as having two components, the API and the SDK. The API
must not only define the interfaces of any implementation in that language but
also be able to function as a noop implementation of the tracer. The SDK is the
default implementation of the API that must be optional.

When instrumenting a project your application should only depend on the
When instrumenting a project, your application should only depend on the
[OpenTelemetry API](https://hex.pm/packages/opentelemetry_api) application,
found in directory `apps/opentelemetry_api` of this repo which is published as
the hex package [opentelemetry_api](https://hex.pm/packages/opentelemetry_api).
found in directory `apps/opentelemetry_api` of this repo. The API is published as
the Hex package [opentelemetry_api](https://hex.pm/packages/opentelemetry_api).

The SDK implementation, found under `apps/opentelemetry` and hex package
The SDK implementation, found under `apps/opentelemetry` and Hex package
[opentelemetry](https://hex.pm/packages/opentelemetry), should be included in an
OTP Release along with an exporter.

Expand Down Expand Up @@ -121,16 +121,16 @@ def project do
end
```

Note that you also need to add `opentelemetry_exporter` before your other `opentelemetry` dependencies in `mix.exs`
Note that you also need to add `opentelemetry_exporter` before your other `opentelemetry` dependencies in `mix.exs`,
so that it starts before `opentelemetry` does.

In the above example `opentelemetry_exporter` is first to ensure all of its
In the above example `opentelemetry_exporter` is listed first, ensuring that all of its
dependencies are booted before `opentelemetry` attempts to start the
exporter. `opentelemetry` is set to `temporary` so that if the `opentelemetry`
application crashes, or is shutdown, it does not terminate the other
applications in the project -- `opentelemetry_exporter` does not not need to be
`temporary` because it does not have a startup and supervision tree. This is
optional, the `opentelemetry` application purposely sticks to `permanent` for
optional; the `opentelemetry` application purposely sticks to `permanent` for
the processes started by the root supervisor to leave it up to the end user
whether they want the crash or shutdown or `opentelemetry` to be ignored or
cause the shutdown of the rest of the applications in the release.
Expand All @@ -145,9 +145,9 @@ depending on the git repo is necessary. Because the OpenTelemetry OTP
Applications are kept in a single repository, under the directory `apps`, either
[rebar3's](https://rebar3.org) `git_subdir` (rebar 3.14 or above is required) or
[mix's](https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html)
`sparse` feature must be used when using as Git dependencies in a project. The
blocks below shows how in rebar3 and mix the git repo for the API and/or SDK
Applications can be used.
`sparse` feature must be used when using these as Git dependencies in a project. The
blocks below show how the git repo for the API and/or SDK
Applications can be used in rebar3 and mix.

``` erlang
{opentelemetry_api, {git_subdir, "http://github.com/open-telemetry/opentelemetry-erlang", {branch, "main"}, "apps/opentelemetry_api"}},
Expand All @@ -165,24 +165,24 @@ Applications can be used.
```

The `override: true` is required because the SDK Application, `opentelemetry`, has
the API in its `deps` list of its `rebar.config` as a hex dependency and this will
the API in its `deps` list of its `rebar.config` as a Hex dependency and this will
clash when `mix` tries to resolve the dependencies and fail without the
override. `override: true` is also used on the SDK because the
`opentelemetry_exporter` application depends on it and the API as hex deps so if
`opentelemetry_exporter` application depends on it and the API as Hex deps so if
it is included the override is necessary.

## Benchmarks

Running benchmarks is done with [benchee](https://github.com/bencheeorg/benchee). Benchmark functions are in modules under `samples/`. To run them open a rebar3 shell in the `bench` profile:
Running benchmarks is done with [benchee](https://github.com/bencheeorg/benchee). Benchmark functions are stored in modules, under `samples/`. To run them, open a rebar3 shell in the `bench` profile:

``` shell
$ rebar3 as bench shell

> otel_benchmarks:run().
```

If an Elixir script is wanted for the benchmarks they could be run like (after
running `rebar3 as bench compile`):
If an Elixir script is wanted for the benchmarks they could be run (after
running `rebar3 as bench compile`) as follows:

``` shell
$ ERL_AFLAGS="-pa ./_build/bench/extras/samples/" ERL_LIBS=_build/bench/lib/ mix run --no-mix-exs samples/run.exs
Expand Down
Loading