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

Support for providing ExceptionTelemetry without actual/original exception object? #498

Closed
sopelt opened this issue Mar 31, 2017 · 11 comments

Comments

@sopelt
Copy link

sopelt commented Mar 31, 2017

Hello, I was wondering if AI could provide support for tracking exceptions (creating an exception telemetry/exception details) without having the actual exception object instance. When using AI in different layers of an app (asp.net (core), JS ...) and adding a small IoT component it would be nice to unify the logs in a central system (AI).
This could work by serializing traces and exceptions, sending them to a blob/webapp/function/... and moving them to AI from there.
As ExceptionTelemetry requires an exception one could implement an exception type that just provides the serialized message and stacktrace but that loses the exception type.

Having a proper API for this use case (without exposing ExceptionDetails?) could be interesting if other people face this use-case as well.

@SergeyKanzhelev
Copy link
Contributor

Thanks for your proposal. We will likely implement it in the version after the next

@sopelt
Copy link
Author

sopelt commented Apr 4, 2017

That is good to hear. Right now we can put StackTrace, Message, ClassName .. in custom dimensions/Properties within the ExceptionTelemetry but it would preferable to track them the same way as service-side exceptions.
My idea with implementing an exception type overriding StackTrace fell short as AI seems to invoke some code for handling stack traces that does not rely on the properties but works with the underlying fields.

@dnelly
Copy link

dnelly commented May 15, 2017

I have a similar issue

The need:
My app emits exceptions and I want to have the exceptions recorded in Application Insights along with all attributes like inner exception objects and stack traces. However, I need to censor some of the values in the exceptions without dropping the attribute altogether (just change the value to something like XX-XX-XX).

The attempt:
I implemented a telemetry processor that applies the following pattern.

  1. Identify that the telemetry item is an ExceptionTelemetry item
  2. Serialize the ExceptionTelemetry to JSON
  3. Mutate the relevant values (without dropping the attributes altogether)
  4. Deserialize JSON back to an instance of an ExceptionTelemetry object and overwrite the original item

Once again, no attribute is dropped from the exception.

Strange result:
The mutated exceptions make it to Application Insights and he can also see them in Application Analytics, but very strangely, the mutated exceptions no longer have a message and stack trace attributes in the exception and inner exception. If I disable the custom telemetry processor then the full exception makes it to AI without losing any attributes. Also, serialization/deserialization of the object works fine. This can also be observed from the output window in Visual Studio when in a F5 scenario.

@dnelly
Copy link

dnelly commented Jun 16, 2017

Any updates on this?

@kunalspathak
Copy link
Member

I am facing similar problem that @dnelly is having. Basically I want to record an app exception into AI, but the exception might have PII information that I don't want to send. The approach I am taking currently is extract out interesting non-PII information from the exception objects (this will not be as simple as it sounds), create a new ExceptionTelemetry() object and populate it with relevant information before calling TraceException() passing the newly created ExceptionTelemetry object.

@SergeyKanzhelev
Copy link
Contributor

@kunalspathak we are open for contributions. Otherwise I cannot give an ETA for the fix. The only workaround for now is to convert ExceptionTelemetry into TraceTelemetry by serializing exception into text manually.

@kunalspathak
Copy link
Member

Thanks @SergeyKanzhelev. I spent some time understanding the code base and it looks like there is already a class ExceptionDetails that can solve the purpose. It gets populated from the exception object and maintains the exception hierarchy. The only problem is this class is not public.

I was wondering if we can have a way to let user create ExceptionTelemetry object with an exception object and let user access the list of exception details (that gets populated from exception object) through the instance of ExceptionTelemetry to update it however he like. This will help users stripping the information that they don’t want to log in telemetry. To begin with, we could just allow users to update message and typeName fields.

try {
   // user code
} catch (Exception ex) {
   var telemetryEx = new ExceptionTelemetry(ex);
   var listOfDetails = telemetryEx.ExceptionDetails;
   stripPIIData(listOfDetails);
}

void stripPIIData(IList<ExceptionDetails> details) {
    foreach(var detail in details) {
          // update message and typeName
    }
}

@SergeyKanzhelev
Copy link
Contributor

Ideally there should be separate API level classes with the fields similar to what we have in ExceptionDetails. ExceptionDetails classes are automatically generated from schema so we cannot make fancy constructors like construct stack trace from System.Diagnostics.StackTrace object. Also it gives level of indirection between programming API and actual schema contracts.

But yes, that the right approach in general

@kunalspathak
Copy link
Member

@tokaplan and me discussed the design for this and here is our proposal.

  • Create two new stub classes corresponding to existing ExceptionDetails and ExceptionData. Let’s call them NewExceptionDetails and NewExceptionData respectively. The instance of these classes will be on that of TelemetryException object. Instance of NewExceptionData will hold the underlying ExceptionData instance and likewise there will be a relation between NewExceptionDetails and ExceptionDetails instances. Any changes done on the public fields of these two classes will directly update the underlying instance of internal ExceptionDetails and ExceptionData objects.
  • Add a public methods to get NewExceptionData and list of NewExceptionDetails.
  • Add 3rd ctor for ExceptionTelemetry that takes NewExceptionData object as input.

Use scenarios it will address –

  • If user has an exception object but wants to remove the PII data, he can do something like:
var te = new TelemetryException(myExceptionObject);
IList<NewExceptionDetails> exceptionDetails = te.NewExceptionDetails;
// Update exceptionDetails to remove PII data
  • If user has some kind of flat list of exceptions text that he wants to log to the telemetry:
var exceptionData = new NewExceptionData();
// populate with interesting data
var te = new TelemetryException(exceptionData);

@SergeyKanzhelev - Feel free to suggest names for NewExceptionDetails and NewExceptionData because they will be public exposed APIs.

TimothyMothra pushed a commit that referenced this issue Oct 25, 2019
@reyang reyang removed this from the Future milestone Mar 9, 2021
@github-actions
Copy link

github-actions bot commented Jan 4, 2022

This issue is stale because it has been open 300 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the stale label Jan 4, 2022
@kunalspathak
Copy link
Member

This is already addressed in #865.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants