Exporters
Send telemetry to the OpenTelemetry Collector to make sure it’s exported correctly. Using the Collector in production environments is a best practice. To visualize your telemetry, export it to a backend such as Jaeger, Zipkin, Prometheus, or a vendor-specific backend.
Available exporters
The registry contains a list of exporters for Erlang/Elixir.
Among exporters, OpenTelemetry Protocol (OTLP) exporters are designed with the OpenTelemetry data model in mind, emitting OTel data without any loss of information. Furthermore, many tools that operate on telemetry data support OTLP (such as Prometheus, Jaeger, and most vendors), providing you with a high degree of flexibility when you need it. To learn more about OTLP, see OTLP Specification.
This page covers the main OpenTelemetry Erlang/Elixir exporters and how to set them up.
Exporting to the OpenTelemetry Collector
The Collector provides a vendor agnostic way to receive, process and export telemetry data. The package opentelemetry_exporter provides support for both exporting over both HTTP (the default) and gRPC to the collector, which can then export Spans to a self-hosted service like Zipkin or Jaeger, as well as commercial services. For a full list of available exporters, see the registry.
For testing purposes the opentelemetry-erlang repository has a Collector
configuration,
config/otel-collector-config.yaml
that can be used as a starting point. This configuration is used in
docker-compose.yml
to start the Collector with receivers for both HTTP and gRPC that then export to
Zipkin also run by docker-compose.
To export to the running Collector the opentelemetry_exporter package must be
added to the project’s dependencies:
{deps, [{opentelemetry_api, "~> 1.2"},
{opentelemetry, "~> 1.3"},
{opentelemetry_exporter, "~> 1.6"}]}.
def deps do
[
{:opentelemetry_api, "~> 1.2"},
{:opentelemetry, "~> 1.3"},
{:opentelemetry_exporter, "~> 1.6"}
]
end
It should then be added to the configuration of the Release before the SDK Application to ensure the exporter’s dependencies are started before the SDK attempts to initialize and use the exporter.
Example of Release configuration in rebar.config and for
mix’s Release task:
%% rebar.config
{relx, [{release, {my_instrumented_release, "0.1.0"},
[opentelemetry_exporter,
{opentelemetry, temporary},
my_instrumented_app]},
...]}.
# mix.exs
def project do
[
releases: [
my_instrumented_release: [
applications: [opentelemetry_exporter: :permanent, opentelemetry: :temporary]
],
...
]
]
end
Finally, the runtime configuration of the opentelemetry and
opentelemetry_exporter Applications are set to export to the Collector. The
configurations below show the defaults that are used if none are set, which are
the HTTP protocol with endpoint of localhost on port 4318. If using grpc
for the otlp_protocol the endpoint should be changed to
http://localhost:4317.
%% config/sys.config.src
[
{opentelemetry,
[{span_processor, batch},
{traces_exporter, otlp}]},
{opentelemetry_exporter,
[{otlp_protocol, http_protobuf},
{otlp_endpoint, "http://localhost:4318"}]}]}
].
# config/runtime.exs
config :opentelemetry,
span_processor: :batch,
traces_exporter: :otlp
config :opentelemetry_exporter,
otlp_protocol: :http_protobuf,
otlp_endpoint: "http://localhost:4318"