From 3a659fd213fbe69c85ba0a7a635fcfb9f7e251a0 Mon Sep 17 00:00:00 2001 From: Rich Morin Date: Mon, 12 Aug 2024 11:52:21 -0700 Subject: [PATCH] Update README.md tidy up the grammar, etc. --- README.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/README.md b/README.md index b768cedb..f2e34667 100644 --- a/README.md +++ b/README.md @@ -70,8 +70,8 @@ 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. @@ -79,17 +79,17 @@ popular Erlang and Elixir libraries and frameworks. 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. @@ -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. @@ -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"}}, @@ -165,15 +165,15 @@ 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 @@ -181,8 +181,8 @@ $ 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