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

Enable ServiceBus dependency and request collection #1797

Merged
merged 1 commit into from
Aug 15, 2018

Conversation

lmolkova
Copy link
Member

@lmolkova lmolkova commented Jul 6, 2018

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

@lmolkova
Copy link
Member Author

lmolkova commented Jul 6, 2018

@brettsam @fabiocav please review when you have time

@lmolkova lmolkova changed the title Enable ServiceBus dependency and request collection [DO NOT MERGE] Enable ServiceBus dependency and request collection Jul 6, 2018
Copy link
Member

@brettsam brettsam left a 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.
Copy link
Member

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>();
Copy link
Member

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?

Copy link
Member Author

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)
Copy link
Member

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;
Copy link
Member

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())
Copy link
Member

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?

Copy link
Member Author

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);
Copy link
Member

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.

@brettsam
Copy link
Member

brettsam commented Jul 6, 2018

FYI -- I'll do another pass through when it's all ready to merge for a final review

@lmolkova
Copy link
Member Author

lmolkova commented Jul 7, 2018

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...

@lmolkova lmolkova force-pushed the lmolkova/ServieBusTracking branch from ed4687a to 22a9ec6 Compare July 7, 2018 04:10
@lmolkova
Copy link
Member Author

lmolkova commented Jul 7, 2018

@brettsam
I've done with my changes, but I found the issue in ApplicaitonInsights SDK that seems to affect tests only: microsoft/ApplicationInsights-dotnet-server#948.

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.

@lmolkova lmolkova changed the title [DO NOT MERGE] Enable ServiceBus dependency and request collection Enable ServiceBus dependency and request collection Jul 7, 2018
@lmolkova
Copy link
Member Author

lmolkova commented Aug 8, 2018

@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

@lmolkova
Copy link
Member Author

lmolkova commented Aug 8, 2018

Still blocked because of microsoft/ApplicationInsights-dotnet-server#970

@lmolkova
Copy link
Member Author

Finally ready. All issues fixed and tests passed

@lmolkova lmolkova force-pushed the lmolkova/ServieBusTracking branch 2 times, most recently from 6fbd04d to b662a3d Compare August 13, 2018 20:10
@lmolkova
Copy link
Member Author

quick pulse tests still seem to be unstable. But this change is ready for merge.
@brettsam

@lmolkova
Copy link
Member Author

@brettsam could you please merge it if you don't have other concerns

@brettsam
Copy link
Member

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.

Copy link
Member

@brettsam brettsam left a 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.
Copy link
Member

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());
}
Copy link
Member

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).

Copy link
Member Author

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

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?

Copy link
Member

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" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathewc / @fabiocav -- this change is bumping our ServiceBus dependency. Do we have any concerns with that? I know we wanted to do it anyway, but wanted to make sure it was clear that it was happening here.

Copy link
Member

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).

@brettsam
Copy link
Member

It looks like we're seeing an additional trace with those QuickPulse tests. Do you see that locally?

@lmolkova lmolkova force-pushed the lmolkova/ServieBusTracking branch 5 times, most recently from b7d0a6e to f31da7a Compare August 15, 2018 04:07
@lmolkova
Copy link
Member Author

It looks like we're seeing an additional trace with those QuickPulse tests. Do you see that locally?

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...

@brettsam
Copy link
Member

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.

@brettsam
Copy link
Member

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).

@brettsam brettsam merged commit 3403636 into Azure:dev Aug 15, 2018
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.

2 participants