* chore: run propagator dialyzer on CI
* Format using Elixir 1.15.6
* Support only Elixir ~> 1.12
It is necessary because :dialyxir requires Elixir ">= 1.12.0"
---------
Co-authored-by: Tristan Sloughter <t@crashfast.com>
* Use test matrix from file
* Only check formatting on specific Elixir version
* Use latest patch version of each Elixir/OTP release in test matrix
* Test on Elixir 1.15 and OTP 26
* Run formatter on opentelemetry_httpoison
* Run formatter on opentelemetry_phoenix
* Run formatter on opentelemetry_tesla
* Fix building opentelemetry_ecto on Elixir 1.15
Upgraded deps to fix ssl_verify_fun not compiling
* Fix building opentelemetry_dataloader on Elixir 1.15
Upgraded deps to fix ssl_verify_fun and ecto_sql not compiling
* Upgrade opentelemetry_finch to build on Elixir 1.15
* Upgrade opentelemetry_httpoison deps to build on 1.15
* Upgrade opentelemetry_nebulex to build on Elixir 1.15
* Upgrade opentelemetry_oban to build on Elixir 1.15
* Upgrade opentelemetry_phoenix deps to build on 1.15
* Upgrade opentelemetry_redix deps to build on 1.15
* Fix warning about <> being ambiguous
* Fix assertion on attributes keys
These are always atoms, not strings.
* Upgrade ssl_verify_fun in opentelemetry_telemetry
* Deterministically sort keys before asserting in tests
* Upgrade opentelemetry_process_propogator to build on Elixir 1.15
* Run mix format on opentelemetry_process_propogator
* Assert keys are atoms, not strings
* Use matrix.os to define runs-on parameter
* Pin test matrix to specific OTP + Elixir versions
* Run formatter on telemetry and process_propagator
* Run formatter over opentelemetry_phoenix
---------
Co-authored-by: Tristan Sloughter <t@crashfast.com>
Add instrumentation for Nebulex, a distributed cache library. This
library provides solid telemetry support for this initial
implementation.
Caching implementation is mostly based on in-memory storage (like ETS)
and RPC calls for distribution (via OTP libraries, like :erpc). AFAICT,
there is not much specifics for how to translate into Semantic
Attributes: those caches are not quite a DB, except maybe for the one
which implements the storage; the RPC can't be reliably captured
either.
Given the above constraints, this initial implementation instruments the
library via custom attributes (namespaced as `nebulex.*`). It's not 100%
clear the behaviour of OTel for actual distributed caches - from my
tests, that may create some orphan spans. I think that's fine as first
release.
Nebulex follow the patterns of Ecto, so this instrumentation follows a
similar pattern of OpentelemetryEcto. It does include a `setup_all/1`
function for convenience, that leverages the :init events Nebulex emit
on process start.
Co-authored-by: Tristan Sloughter <t@crashfast.com>
* Fix CI errors, update GHA deps, update versions
* output syntax
* remove OTP 22 tests
* set concurrency to cancel in progress
* whitespace
* incompatible vsns and failed test
* Try pulling excludes out
* Escaping
* Just drop < 1.13 until this can move to workflows
* quote
* Process propagator library
* Fix Elixir API
* CI files
* Update propagators/opentelemetry_process_propagator/lib/opentelemetry_process_propagator.ex
Co-authored-by: Andrew Rosa <dev@andrewhr.io>
* Update propagators/opentelemetry_process_propagator/lib/opentelemetry_process_propagator.ex
Co-authored-by: Andrew Rosa <dev@andrewhr.io>
* format
Co-authored-by: Andrew Rosa <dev@andrewhr.io>
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
By default a new trace is automatically started when a job is processed
by monitoring these events:
* `[:oban, :job, :start]` — at the point a job is fetched from the database and will execute
* `[:oban, :job, :stop]` — after a job succeeds and the success is recorded in the database
* `[:oban, :job, :exception]` — after a job fails and the failure is recorded in the database
To also record a span when a job is created and to link traces together
`Oban.insert/2` has to be replaced by `OpentelemetryOban.insert/2`.
Before:
```elixir
%{id: 1, in_the: "business", of_doing: "business"}
|> MyApp.Business.new()
|> Oban.insert()
```
After:
```elixir
%{id: 1, in_the: "business", of_doing: "business"}
|> MyApp.Business.new()
|> OpentelemetryOban.insert()
```
Co-authored-by: Tristan Sloughter <t@crashfast.com>
renovate[bot]
Artem Solomatin
Bryan Naegele
João Thallis
Tom Taylor
Cristiano Piemontese
Maarten van Vliet
Andrew Rosa
John Mauricio Carmona E
Ricardo Paiva
Indrek Juhkam