50ed370444
Initial approach follows Ecto instrumentation, recording spans for all
Redix `[:redix, :pipeline, :stop]` events.
The command sanitization is inspired-by and adapted from [Java
instrumentation][1], from where I've also copied the actual commands and
what configuration should they follow.
Network attributes are tracked via a "sidecar" process, which keeps
track of connection attributes also via `telemetry`. This extra bit of
bookkeeping is needed as command events doesn't include that piece of
information, unfortunately.
[1]: b2bc41453b/instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/db/RedisCommandSanitizer.java
35 lines
1.1 KiB
Elixir
35 lines
1.1 KiB
Elixir
# This file is responsible for configuring your application
|
|
# and its dependencies with the aid of the Mix.Config module.
|
|
import Config
|
|
|
|
# This configuration is loaded before any dependency and is restricted
|
|
# to this project. If another project depends on this project, this
|
|
# file won't be loaded nor affect the parent project. For this reason,
|
|
# if you want to provide default values for your application for
|
|
# third-party users, it should be done in your "mix.exs" file.
|
|
|
|
# You can configure your application as:
|
|
#
|
|
# config :opentelemetry_redix, key: :value
|
|
#
|
|
# and access this configuration in your application as:
|
|
#
|
|
# Application.get_env(:opentelemetry_redix, :key)
|
|
#
|
|
# You can also configure a third-party app:
|
|
#
|
|
# config :logger, level: :info
|
|
#
|
|
|
|
# It is also possible to import configuration files, relative to this
|
|
# directory. For example, you can emulate configuration per environment
|
|
# by uncommenting the line below and defining dev.exs, test.exs and such.
|
|
# Configuration from the imported file will override the ones defined
|
|
# here (which is why it is important to import them last).
|
|
#
|
|
try do
|
|
import_config "#{Mix.env()}.exs"
|
|
rescue
|
|
_ -> :ok
|
|
end
|