Expose request and dependency id for use in operation parent id

[frigus02]

I would like to link items to a request or dependency. I read in the Application Insights telemetry correlation documentation, that this should work by setting the operation_parentId to the id of the parent request or dependency.

As far as I can see the id is currently randomly generated for both RequestTelemetry and RemoteDependencyTelemetry and this id is not exposed in the public API. Would you mind a pull request that adds an id() getter for those structs? Or am I going in the competely wrong direction?

Thanks for this library, btw. Everything else works really well with it.

[dmolokanov]

Hi @frigus02! Thanks for reaching out!
It looks like you are right. In order to make a dependency graph what we should use are telemetry event id and some setters set_id and set_parent_id from OperationTagsMut. I believe the trick is here that parent telemetry event is submitted after all its dependencies. So exposing only telemetry event getters will not be sufficient.

The way it should probably work is

let operation_id = ...;

...

let mut dependency = RemoteDependencyTelemetry::new(...);
dependency.tags_mut().operation_mut().set_id(operation_id);
dependency.tags_mut().operation_mut().set_parent_id(operation_id);

client.track(dependency);

...

let mut request = RequestTelemetry::new(...);
request.set_id(operation_id);
request.tags_mut().operation_mut().set_id(operation_id);

client.track(request);

I'll try to get back to the issue as soon as I can. Stay tuned!

PS. Please feel free to open a PR with changes. Any help is greatly appreciated!

[frigus02]

I played more with Application Insights in the mean time and looked for an ergonomic API to keep track of all the IDs. This ended up in an exporter for OpenTelemetry Rust, which seems like the right way for me to go in: opentelemetry-application-insights.

Unfortunately it meant a few more requirements like being able to set every field of requests and dependencies, and also being able to send captured telemetry synchronously. I re-implemented the bits I needed for this. But I would love to throw those away and use this library instead 🙂. Being able to set the IDs would be a good first step.

I'm going to prepare a PR to add a set_id function to request and dependency.

[dmolokanov]

Thanks for the heads up! Yeah, I think is allowing to modify each field will be beneficial for the majority of programmers who use the crate. I hope I find some time to do so.

Feel free to ping me if you have more ideas to improve code ergonomics!

[frigus02]

I'm trying to remember the changes I made. I think the biggest one was having control over when telemetry items are sent to App Insights. This is because the OpenTelemetry library has it's own way of scheduling, batching and retrying. I'm not sure if that usecase would fit this crate.

Another one was reducing the data sent to App Insights by adding #[serde(skip_serializing_if = "Option::is_none")] to all optional fields in the contracts.