You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Added ability to test distributed tracing functionality. (#2896)
Fixes#2769 - Adds ability to easily test distributed tracing.
Also adds a test example for KeyVault Secrets APIs.
This PR introduces a new `azure_core_test` API named
`assert_instrumentation_information` whose purpose is to ensure that the
distributed tracing information is correctly generated for a given
service client implementation.
The API takes three pieces of information: A capture which creates a
service client with a provided distributed tracing `TracerProvider`, a
capture which actually performs the test and an
`InstrumentationInformation` structure which describes the service
calling the API and the particular service client APIs which are
expected to have been called during the test.
It then analyzes the actual traces generated during the test and
verifies that the expected service client calls were made and that the
expected distributed tracing attributes have been generated.
---------
Co-authored-by: Heath Stewart <[email protected]>
This means that the following are valid parameters for `tracing::function`:
354
351
355
352
*`#[tracing::function("MyServiceClient.MyApi")]` - specifies a public API name.
356
-
*`#[tracing::function("Name", (az.namespace="namespace"))]` - specifies a public API name and creates a span with an attribute named "az.namespace" and a value of "namespace".
357
-
*`#[tracing::function("Name", (api_count=23, "my_attribute" = "Abc"))]` - specifies a public API name and creates a span with two attributes, one named "api_count" with a value of "23" and the other with the name "my_attribute" and a value of "Abc"
358
-
*`#[tracing::function("Name", ("API path"=path))]` - specifies a public API name and creates a span with an attribute named "API path" and the value of the parameter named "path".
353
+
*`#[tracing::function("Name", attributes = (az.namespace="namespace"))]` - specifies a public API name and creates a span with an attribute named "az.namespace" and a value of "namespace".
354
+
*`#[tracing::function("Name", attributes = (api_count=23, "my_attribute" = "Abc"))]` - specifies a public API name and creates a span with two attributes, one named "api_count" with a value of "23" and the other with the name "my_attribute" and a value of "Abc"
355
+
*`#[tracing::function("Name", attributes = ("API path"=path))]` - specifies a public API name and creates a span with an attribute named "API path" and the value of the parameter named "path".
359
356
360
357
This allows a generator to pass in simple attribute annotations to the public API spans created by the pipeline.
361
358
@@ -379,14 +376,14 @@ The client can then add whatever attributes to the span it needs, and after the
379
376
380
377
Note that in this model, the client is responsible for ending the span.
381
378
379
+
<!-- cspell:ignore subclients -->
382
380
### Service implementations with "subclients"
383
381
384
382
Service clients can sometimes contain "subclients" - clients which have their own pipelines and endpoint which contain subclient specific functionality.
385
383
386
384
Such subclients often have an accessor function to create a new subclient instance which looks like this:
This adds a clone of the parent client's `tracer` to the subclient - it functions similarly to `#[tracing::new]` but for subclient instantiation.
412
+
413
+
## Verifying distributed tracing support
414
+
415
+
The `azure_core_test::tracing` package provides functionality to allow developers to verify that their distributed tracing functionality is generating the expected tracing information.
416
+
417
+
This functionality is driven from the `azure_core_test::tracing::assert_instrumentation_information` API.
418
+
419
+
This function takes two closures and a structure which describes the expected API shape. The first closure is used to create an instance of the public API, the second actually executes the public API.
420
+
421
+
As an example, here is a test for the `keyvault_secrets` package:
422
+
423
+
```rust
424
+
assert_instrumentation_information(
425
+
// Create an instance of a SecretClient adding the instrumentation options to ensure distributed tracing is enabled.
The first closure creates an instance of a KeyVault client. The second one executes a keyvault secrets round trip test setting a secret and retrieving the secret. In this case, the instrumentation information describes the name of the package and the namespace for the service client. It says that there will be two instrumented APIs being called - the first named `KeyVault.setSecret` and the second named `KeyVault.getSecret`.
0 commit comments