Skip to content

Add tracing to keyvault-keys library#4654

Merged
ramya-rao-a merged 17 commits intoAzure:masterfrom
ramya-rao-a:keys-tracing
Aug 5, 2019
Merged

Add tracing to keyvault-keys library#4654
ramya-rao-a merged 17 commits intoAzure:masterfrom
ramya-rao-a:keys-tracing

Conversation

@ramya-rao-a
Copy link
Contributor

@ramya-rao-a ramya-rao-a commented Aug 3, 2019

This PR adds tracing to keyvault-keys library and is based on the work done by @sarangan12 in #4506

  • Each api in the convenience layer (index.ts) is updated to
    • create a span based on the spanOptions in the request options passed by the user
    • start & end the span before & after the call to the service
    • set this new span as "parent" in the spanOptions in the request options so that
      • Any new span created in the pipeline (in the future) for this request gets the right parent
      • The right "parent" gets serialized in the header, so that any new span created on the service side gets the right parent.
  • The operation spec for each api is updated to serialize the contents of options.spanOptions in the header

path: "keys/{key-name}/create",
urlParameters: [Parameters.vaultBaseUrl, Parameters.keyName0],
queryParameters: [Parameters.apiVersion],
headerParameters: [Parameters.acceptLanguage],
Copy link
Contributor

Choose a reason for hiding this comment

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

This file needs few more additions in getDeletedKeysOperationSpec, importKeyOperationSpec, etc. Else, the span will not be serialized to the service.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done with e2c529f

Copy link
Contributor

Choose a reason for hiding this comment

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

We need to speak with @daviwil and @schaabs to make sure that we can apply these changes to a future version of our core files, since they're auto-generated.

@sarangan12
Copy link
Contributor

I have tested with my sample with and without tracers and code looks fine. But some of the header parameters are missing and I added the comment on it. We must add them before release

Copy link
Contributor

@sadasant sadasant left a comment

Choose a reason for hiding this comment

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

It looks good! Let's make sure we have a plan to have this updated in the auto-generated code. We also need this in secrets and in credentials, since they all share the same core.

@sadasant
Copy link
Contributor

sadasant commented Aug 5, 2019

@ramya-rao-a & @sarangan12

Here's @schaabs 's reply to this PR:

[...] in general I would avoid manually editing the generated code as much as possible.

That being said I would imagine that inserting tracing around network calls would be ultimately inserted into autorest. So if the plan is to update autorest you would need to ensure autorest was updated in the same way.

I would suggest making the changes in autorest and regenerating though b/c that way you don't have to worry about differences ultimately.

I would talk to David, I believe he's done some work updating autorest to use core-http.

I'll come back with feedback from @daviwil (or he might too).

@ramya-rao-a
Copy link
Contributor Author

@sadasant For Preview 3, we will definitely look into having this auto-generated.
For the Preview 2, the idea was to provide a proof of concept of how tracing would look like and what kind of plumbing would be needed. Therefore, we chose just keys and kept secrets, certificates untouched.

@daviwil
Copy link
Contributor

daviwil commented Aug 5, 2019

@ramya-rao-a is correct, there isn't time to add this to the code generator for Preview 2 and all we really want is to validate the overall design anyway. I think hand-editing the code is fine in this case since we are in total control of when it gets regenerated in the future. We'll add some logic to autorest.typescript to generate this code in Preview 3, I don't think it will be that difficult to do so.

*/
private createSpan(methodName: string, requestOptions: RequestOptionsBase): Span {
const span = TracerProxy.getTracer().startSpan(methodName, requestOptions.spanOptions);
requestOptions.spanOptions = { ...requestOptions.spanOptions, parent: span };
Copy link
Contributor

Choose a reason for hiding this comment

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

It'd be nice if we could do this without directly manipulating the original requestOptions object, but it's fine for now.

@daviwil
Copy link
Contributor

daviwil commented Aug 5, 2019

/azp run js - client - ci

@azure-pipelines
Copy link

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

@daviwil
Copy link
Contributor

daviwil commented Aug 5, 2019

/azp run js - keyvault - ci

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@daviwil
Copy link
Contributor

daviwil commented Aug 5, 2019

/azp run js - core - ci

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

delete unflattenedOptions.expires;
delete unflattenedOptions.requestOptions;

const span = this.createSpan("createEcKeyMethod", unflattenedOptions);
Copy link
Contributor

Choose a reason for hiding this comment

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

This might be a bit of a nit, but why do these all end with "*Method"? It's a hunch, but I'd think we'd want the exact same name so that they can do a search for the symbol and find it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed with 64ea0ae

Copy link
Member

Choose a reason for hiding this comment

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

+1, method suffix is unnecessary, should match the symbol.

unflattenedOptions
);

span.end();
Copy link
Contributor

@chradek chradek Aug 5, 2019

Choose a reason for hiding this comment

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

We also need to end the span if createKey throws an error, otherwise the span will never be closed.

Edit: This applies to all the places where we call start and stop around an awaited function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed with 53a6c66

@ramya-rao-a
Copy link
Contributor Author

Serializing the entire spanOptions in the header is not desirable. We instead want to pass only the TraceContext in the header.

Therefore, updated this PR to revert changes related to headers in this PR with 139f4a3

We will look into creating a policy just for key vaults keys (since it already uses other custom policies) to do the needful in a separate PR

@ramya-rao-a ramya-rao-a merged commit c926735 into Azure:master Aug 5, 2019
@ramya-rao-a ramya-rao-a deleted the keys-tracing branch August 5, 2019 20:28
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.

7 participants