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

subscriber: use Span::record for attribute updates #264

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

zaharidichev
Copy link
Collaborator

This PR switches to using Span::record for recording state updates on
async ops and resources as suggested in #246. The changes a bit the scheme
for naming attributes. Basically now fields that are recorded as state attributes
need to be defined on span creation and have the form of state.field_name.unit
where the unit is optional. We then use Span::record to emit an update on this field.
In order to express an update that is a delta we can use state.field_name.delta. This
only works for numeric fields.

The fact that we now need to know the attributes for a resource or an async op upfront
allows us to avoid resizing the map of attributes and using the mutex on it. However, it also
brings a complication around attribute inheritance. Basically, we use attribute inheritance for
resources and async ops to propagate the attributes of some private type like
batch_semaphore::Semaphore to some other public type like the Semaphore. This also
stands true for async ops of these resources. This allows us to instrument parent async
ops very easily by just doing this. Because now we need to know the set of fields upfront, it will
make this kind of instrumentation harder.

You can patch the tokio version with this branch to test.

Signed-off-by: Zahari Dichev zaharidichev@gmail.com

Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
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.

1 participant