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

tracing: observe modes and other tracing improvements. #5611

Conversation

GabrielBuica
Copy link
Contributor

As a follow-up to commenting out the warning when no tracer providers were enabled here #5583. This is meant to solve the issue of spamming the logs by properly setting the observe mode inside the library.

This is based on top of #5601 that addresses missing lock in the library.

Some other improvements:

  • removes some code duplication;
  • adds unit tests for the library;
  • moves functions under a more appropriate module level;
  • adds documentation on TracerProvider module.

edwintorok and others added 6 commits May 2, 2024 15:08
It is not safe to access a global hashtable from multiple threads, even if the operations are read-only
(it may be concurrently changed by another thread, which then may result in errors in the racing thread).

This means we must always take the mutex, and because OCaml doesn't have a reader-writer mutex, we need to take the exclusive mutex.

Eventually we should use a better datastructure here (immutable maps, or lock-free datastructures), but for now
fix the datastructure that we currently use to be thread-safe.

Signed-off-by: Edwin Török <edwin.torok@cloud.com>
In preparation for OCaml 5, on OCaml 4 they'd be equivalent.

Note that adding Atomic doesn't make operations on these values always atomic: that is
the responsibility of surrounding code.
E.g. Atomic.get + Atomic.set is not atomic, because another domain might've raced and changed the value inbetween
(so in that case Atomic.compare_and_set should be used).

However for global flags that are read multiple times, but set from a central place this isn't a problem.

Signed-off-by: Edwin Török <edwin.torok@cloud.com>
Sets `observe` to `false` until at least one tracer provider is enbaled.
If all tracer proveder are become disabled we set it back to `false`.

Prior to this `observe` seemed to be always `true` (apart from unit
tests). This would cause `with_tracing` to spam the logs with warnings
`No provider found...` until at least one tracer provider is enabled.

By setting `observe` to `false` as default and updating it depending on
the state of the trecing providers, `with_tracing` should now execute no
extra operations. Therefore, we avoid spamming the logs unnecesarrly.

Signed-off-by: Gabriel Buica <danutgabriel.buica@cloud.com>
Create a new unit test file `test_tracing.ml` for the `tracing` library.
Add tests for `create`/`set`/`destroy` tracer providers.

Now that we change the library to have `observe` modes based on weather
or not we have `tracer providers` enabled, we want to make sure that
functions on applied on tracer providers set the correct mode for the
library.

Signed-off-by: Gabriel Buica <danutgabriel.buica@cloud.com>
Removes code duplication in `storage_mux.ml` by using already the
already existing `with_dbg` implementation from `debuginfo` module.

This should lower the chances of unintetionally introducing bugs by
having to maintain two version of the same functions. e.g. Not using the
no op when tracing is disabled and generating unwanted warning messages.

Signed-off-by: Gabriel Buica <danutgabriel.buica@cloud.com>
Moves the following:

- `create` under `TracerProvider`;
- `set` under `TracerProvider`;
- `destroy` under `TracerProvider;
- `get_tracer_providers` unde `TracerProvider`;
- `get_tracer` under `Tracer`.

Adds documentation for `TracerProvider` module.

It kept being confusing of what `Tracing.set` does unless I was going through
the implementation again and again. Therefore, I moved some of the
functions so that their functionality becomes (hopefully) more intuitive.

Signed-off-by: Gabriel Buica <danutgabriel.buica@cloud.com>
@GabrielBuica GabrielBuica force-pushed the private/dbuica/CP-48195-tracing-observe-modes branch from 9f16429 to 1f29d7c Compare May 2, 2024 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants