-
Notifications
You must be signed in to change notification settings - Fork 358
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
Enable ServiceBus dependency and request collection #1797
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a couple of initial comments.
@@ -143,5 +143,10 @@ public static class LogConstants | |||
/// Gets the name of the key used to store a metric sum. | |||
/// </summary> | |||
public const string MetricValueKey = "Value"; | |||
|
|||
/// <summary> | |||
/// Gets the name of they key used to store function execution time in the ApplicationInsights RequestTelemetry properties. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: "they" -> "the"
return dependencyCollector; | ||
}); | ||
services.AddSingleton<ITelemetryModule, AppServicesHeartbeatTelemetryModule>(); | ||
|
||
ServerTelemetryChannel serverChannel = new ServerTelemetryChannel(); | ||
services.AddSingleton<ITelemetryChannel>(serverChannel); | ||
services.AddSingleton<ITelemetryChannel, ServerTelemetryChannel>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this the other Disposal issue that you'd mentioned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exactly
} | ||
|
||
private static void ApplyFunctionResultProperties(RequestTelemetry requestTelemetry, IEnumerable<KeyValuePair<string, object>> stateValues) | ||
private static void ApplyFunctionResultActivityTags(IEnumerable<KeyValuePair<string, object>> state, IDictionary<string, object> scope) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment as to what's happening here? We're adding these to the Activity Tags... and then they'll be used elsewhere by App Insights?
// Set ip address to zeroes. If we find HttpRequest details below, we will update this | ||
requestTelemetry.Context.Location.Ip = LoggingConstants.ZeroIpAddress; | ||
// Set ip address to zeroes. If we find HttpRequest details below, we will update this | ||
//requestTelemetry.Context.Location.Ip = LoggingConstants.ZeroIpAddress; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this commented out line? Looks like you do this elsewhere now.
if (telemetry is ISupportProperties telemetryProps) | ||
// this could be telemetry tracked in scope of function call - then we should apply the logger scope | ||
// or RequestTelemetry tracked by the WebJobs SDK or AppInsight SDK - then we should apply Activity.Tags | ||
if (request == null && scopeProps.Any()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How are you determining whether the RequestTelemetry
is part of a function call here? Shouldn't RequestTelemetry
not be null in that case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RequestTelemetry is never null (initializer runs on tracked telemetry item). The question is: who reported RequestTelemetry: functions in LogFunctionResult or AppInsights SDK automagically
_functionWaitHandle.WaitOne(); | ||
|
||
//TODO : clean me | ||
await Task.Delay(5000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note -- one thing I've been doing lately to remove these delays is to instead use TestHelpers.Await()
and wait for the telemetries to appear. It'll auto-timeout if it takes too long, and that way the test is more deterministic.
FYI -- I'll do another pass through when it's all ready to merge for a final review |
thanks, I'm debugging the new test that always passes locally, I'll fix it and go through your comments. I'll let you know when I'm done, please ignore all debugging commits for now... |
ed4687a
to
22a9ec6
Compare
@brettsam The test fails because other service bus tests might run before it and it affects magical auto-collection :( We are fixing the issue in the next ApplicaitonInsights release (stable in a 1-2 weeks) and I'll update the version and enable the test. Please advise whether it's ok to merge like that. |
1e66458
to
4132a51
Compare
@brettsam could you please have a look? There was an issue with ServiceBus dependency collection that we've fixed in AppInsights 2.7, so if you're ok with this, it is ready to merge |
Still blocked because of microsoft/ApplicationInsights-dotnet-server#970 |
Finally ready. All issues fixed and tests passed |
6fbd04d
to
b662a3d
Compare
quick pulse tests still seem to be unstable. But this change is ready for merge. |
@brettsam could you please merge it if you don't have other concerns |
Taking another look now... I've kicked off another test run to make sure that it's just flakiness with that QuickPulse test. I made some improvements to it in v2.x but I need to port those over to dev. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just one really minor comment (on a comment). If you can get that spelling fixed (and squash down to a single commit), I'll double-check that moving the SB nuget forward is okay. Then I'll go ahead and merge.
// are added to the Properties bag. | ||
foreach (KeyValuePair<string, object> prop in stateValues) | ||
// Activity carries tracing context. It is managed by instrumented library (e.g. ServiceBus or Asp.Net Core) | ||
// and consumed by ApplicaitonInsigts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: spelling
|
||
if (scope.TryGetValue(LogConstants.LogLevelKey, out object logLevel)) | ||
{ | ||
currentActivity.AddTag(LogConstants.LogLevelKey, logLevel.ToString()); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I'll need to set the FunctionInvocationId here as well, right? (as part of my PR that's out for review).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems I've found a simpler way to set invocation id on all telemetry in WebJobsTelemetryInitializer
Line 77 in 4ee8b1c
string invocationId = scopeProps.GetValueOrDefault<string>(ScopeKeys.FunctionInvocationId); |
It will be stamped on all telemetry even dependencies that do not come through the ApplicationInsightsLogger.
But your PR still does some nice refactoring and better tests. Could you merge it and I'll rebase this one after that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, thanks! Merging now.
@@ -9,8 +9,8 @@ | |||
</PropertyGroup> | |||
|
|||
<ItemGroup> | |||
<PackageReference Include="Microsoft.Azure.ServiceBus" Version="2.0.0" /> | |||
<PackageReference Include="StyleCop.Analyzers" Version="1.1.0-beta004"> | |||
<PackageReference Include="Microsoft.Azure.ServiceBus" Version="3.0.2" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chatted with Mathew and Fabio -- this should be fine (and we needed to do it anyway).
It looks like we're seeing an additional trace with those QuickPulse tests. Do you see that locally? |
b7d0a6e
to
f31da7a
Compare
I'm not able to repo it locally. On the build server, if the new test introduced in this PR is enabled, it causes some strange side effects on quick pulse test. I'm investigating this and it seems to take a while... |
Okay -- don't worry too much about that if it doesn't happen locally. I'll port over my improvements from the other branch and maybe that'll make things better. If everything else is ready and passing but that test is still failing sometimes, we can still get this in. I'll take care of improving it. |
4e99d23
to
10027f9
Compare
Can you do one more rebase on dev? I just checked in those QuickPulse improvements, which add some additional logging so maybe we can capture what's failing (assuming it still fails). |
10027f9
to
ca8f61c
Compare
This change enables ServicBus calls tracking
ApplicaitonInsights listens to ServiceBus SDK events and tracks requests automatically, enriching them with ServiceBus specific properties such as endpoint, queue name, function called (Send/Process)
Such events are translated to telemetry so that 'Send' is tracked as dependency and 'Process' is a request.
ServiceBus SDK also ensures that is there is a trace context in the message, it will be used.
There is a small caveat with request tracking: AppInsights SDK tracks request from SB automatically and therefore Request tracked by webjobs SDK, in this case, is not needed.
Based on the presence of Activity.Current, we can say whether someone tracks request already and avoid double-tracking.
We've had an offline conversation with @brettsam about HTTP requests, and we've decided that 'outer', 'automagical' request should be tracked: it contains specific info (such as SB message Id or queue name, or in case of HTTP request URL and response code).
'Outer' request will have a bit bigger duration than a pure function call; for now, actual function duration is added into the telemetry properties.
Request operation name still is set to function name as portal UI depends on it.
ServiceBus package was updated to the latest stable version 3.0.2 because of NullReferenceException bug in diagnostics code Azure/azure-service-bus-dotnet#459