-
Notifications
You must be signed in to change notification settings - Fork 287
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
Allow customers to provide Telemetry properties at individual item level, and at global level. #820
Comments
I think I see what you're trying to do. I support having two property bags on telemetry items. However, I think that the low-cardinality one (GlobalProperties) should be set via the TelemetryClient. It should otherwise be internal (non-public). |
An initial version is in. Will submit a followup PR to address Pauls comments. |
This is added for 2.8.0-beta1 to allow longer beta period. (originally it was supposed to be in 2.7-beta3, which allowed too little time to gather feedback) |
I have a telemetryinitializer that for each Api Controller request logs the device ID and the tenant ID (from claims): would those be considered global or not? And I I want to add them to ISupportProperties - where do I find that in this context?
|
Is this how I would rewrite it? Should I use SupportProperties or GlobalProperties for this kind of per request info?
|
Its not entirely obvious what is meant by the term "Global". Does "Global" mean global to the Application. Or does "Global" mean global to the request? This should be made clear in the documentation. Global is too vague of a term. |
Global here means global for the application - something which wont change for every request. Agree there are no official docs, but some discussion spread in github issues... |
So telemetaryClient.Context.Properties now contains the following obsolete message:
Which when you google brings you here. The official docs also contain a similar blanket message. A similar issue raised here has just been blanket closed pointing at this issue.
But it is really not very clear in any of the documentation (that I can find) how I should use these new properties. For example I want to add a property at request level. How do I do that? |
After much digging and experimenting eventually this seem provided me the solution #1428 (comment) so the answer to adding request telemetry is: Activity.Current?.AddTag("key", "value"); |
|
This'd be incorrect, as applicationinsights SDK by default does not copy Activity tags into any telemetry. |
Please use the example here: https://docs.microsoft.com/en-us/azure/azure-monitor/app/api-filtering-sampling#addmodify-properties-itelemetryinitializer which shows how an initializer is used to add additional properties to the Request |
I don't have the data at the TelemetryInitializer stage. My data is calculated and i want to tag the request with this data. I'm interested as to why you think the Activity. Is incorrect. I've tested it and it works? |
Because this SDK does't copy Activity Tags into custom properties. TelemetryInitializer is run sync in the same context as the request. So you should have access to all the context when initializers are run. |
Its done by Functions host. |
Present State
Currently
ITelemetry
has aTelemetryContext
which can define the context of theITelemetry
item. This context holds information that are global than the individual item properties. Apart from well known fields like Cloud ("ai.cloud.roleinstnace"), Device("ai.user.devicetype") etc.,TelemetryContext
also contains a property bag collection to store any key,value (string,string) pair of information.All concrete
ITelemetry
implementations defined in the base sdk (eg: RequestTelemetry, DependencyTelemetry) also implementsISupportProperties
interface.This gives them a 'Properties' bag which can store any key,value (string,string) pair of information applicable to the individual telemetry item.
TelemetryClient
also contains aTelemetryContext
and properties from it are automatically applied to all the telemetry items tracked using that instance ofTelemetryClient
.In effect, there are 3 places to set properties about an item.
Properties
ofISupportProperties
Properties
ofTelemetryContext
ofITelemetry
Properties
ofTelemetryContext
ofTelemetryClient
(more like a helper method, as this property bag is simply copied to (2) inTrack()
method.For the current json wire format, all the above properties are serialized into "properties" section inside the telemetry.
The present implementation internally uses same Dictionary to hold the properties of individual item, and that from
TelemetryContext
.i.e
var req = RequestTelemetry()
req.Properties
andreq.Context.Properties
are internally the same collection, each being affected by modification to the other.Issues
Since all properties are serialized into same "properties" bag in json, AI back-end cannot distinguish whether any given property belongs to just individual item or it belongs to a more global context.
Withtout this information back-end or UI cannot make special provisions for the global properties.
For eg: UI could chose to index global properties for fast filtering.
As the current implementation internally uses the same object to hold both properties, users has no way of informing AI that some properties are meant to
be global and some are only applicable to telemetry item.
Proposal
We want to provide users with a way to specify properties for telemetry items in 2 levels - one is local to the individual item, and can be high cardinality.
Other is more of a 'global' property, which AI back-end could chose to treat special. (For eg: by providing UI filters for global propps)
By splitting the
Properties
ofISupportProperties
andProperties
ofTelemetryContext
into separate collection, user can achieve this.But this might be breaking change for customers who counted on these two property bags being the same.
So we'd like to provide a new field in
TelemetryContext
, calledGlobalProperties
(making it obvious to users that these are global level properties, and to avoid confusion withProperties
onISupportProperties
). Users wishing to supply global properties could useGlobalProperties
onTelemetryContext
to do so.For properties limited to individual item,
Properties
onISupportProperties
could be used. TheProperties
onTelemetryContext
would be marked obsolete.Note: For initial implementation, the
GlobalProperties
will be serialized into same "properties" bag in wire format (only in wire format). This is temporary until back-ends are changed. Also there are few internal users who would be using this SDK with custom channel+serialization, to send data to different back-ends (which support global vs local). They can take advantage of this right away.Eg:
Since no breaking change, we will ship this in 2.7 itself. And use 3.0 to remove the obsolete fields.
The text was updated successfully, but these errors were encountered: