search

coolhome / Hangfire.Extensions.ApplicationInsights

Application Insights integration with Hangfire
MIT License
21 stars 11 forks source link

Enqueued job telemetry is not sent to AI #6

Open vladik-vitre opened 10 months ago

vladik-vitre commented 10 months ago

As I understand it, the https://github.com/coolhome/Hangfire.Extensions.ApplicationInsights/blob/main/Hangfire.Extensions.ApplicationInsights/ApplicationInsightsBackgroundJobFilter.cs needs to be registered as a filter that will report telemetry that starts with "Enqueue " (see https://github.com/coolhome/Hangfire.Extensions.ApplicationInsights/blob/main/Hangfire.Extensions.ApplicationInsights/ApplicationInsightsBackgroundJobFilter.cs#L26C23-L26C31) The issue is I don't see it, I only see telemetry that starts if "JOB " from https://github.com/coolhome/Hangfire.Extensions.ApplicationInsights/blob/main/Hangfire.Extensions.ApplicationInsights/ApplicationInsightsBackgroundJobPerformer.cs#L26C23-L26C31. It looks like the ApplicationInsightsBackgroundJobFilter is not registered in the service collection properly for some reason. The other three services before it are added to the services from https://github.com/coolhome/Hangfire.Extensions.ApplicationInsights/blob/main/Hangfire.Extensions.ApplicationInsights/ServiceCollectionExtensions.cs and the last one isn't, maybe this is the issue?

vladik-vitre commented 10 months ago

I have service X enqueuing a job and service Y performing the job. I see the JOB telemetry from service Y but don't see the Enqueue telemetry from service X. I want to see the full chain of events in AI where service X gets an HTTP request, enqueues a job and service Y performs it with the dependencies and all (the dependencies work fine also). I assume that this package has the ability to track the telemetry in a way that it will be easy for me to see what's happening. Both services report to different AI resources and even if I make them report to the same AI resource the operations do not stick together because they have different operation ids. PR https://github.com/coolhome/Hangfire.Extensions.ApplicationInsights/pull/3 kind of helps when with allowing to pass the operation id to the job as a parameter and this way allow two services to stick the AI data together there the operation id is the same.

coolhome commented 10 months ago

@vladik-hbinov what version are you using? This feature is only introduced in 1.1.0-alpha1. Fair warning it does not work with Hangfire.Pro yet.

https://github.com/coolhome/Hangfire.Extensions.ApplicationInsights/compare/1.0.0...1.1.0-alpha1

In addition, this filter needs to be added via AddHangfire().UseApplicationInsights()

vladik-vitre commented 10 months ago

Ok now I understand why it happened to me, the main branch of the repo doesn't have the same code as the Nuget package I use. I figured it out a few minutes before you answered but I didn't have a chance to update the issue... Don't know if this is the practice regularly used, I'd suggest to leave the main branch as the official release of 1.0.0 and other prereleases as branches in development because it is really confusing.

Thank you very much for the quick reply!

vladik-vitre commented 10 months ago

If I'll update the version to the 1.1.0 version will it support my use case of two services with different AI resources and the same operation id for chaining? I think not, right?

vladik-vitre commented 10 months ago

@coolhome I tried 1.1.0-alpha1 and it looks much better on AI with the new Enqueue dependency telemetry! The thing is I don't see this telemetry when I trigger a recurring job from the UI or when I requeue a job in the UI as well on Hangfire 1.7.31 if it matters.

Also, if I use two different application insights resources for service X and service Y where X enqueues the job and Y executes it, the telemetry doesn't stick together although it has the same parent id, when I send the telemetry to the same application insights resource it does manage to stick it together, although the operation id is different, using the parent id I assume...

Am I expecting too much?

vladik-vitre commented 10 months ago

I read here that the root id is used for correlation and I see in the 1.0.0...1.1.0-alpha1 that you do use the RootId with Activity.RootId so why doesn't it stick together?