As an ISV, would be great to have app/extension-level telemetry extended to include more events.

The following events could be included so that ISVs can benefit from it:

• Database deadlocks
• Deadlocks occurring on the ISV extension objects should be included. I understand that a deadlock relates to two different processes running and these processes might not even be related to the extension where the table being locked belongs to, but would be really helpful for the ISVs to understand what objects are most commonly being part of deadlocks. If we have access to the stack trace, that could make us understand what events custom apps might be subscribing and causing the deadlocks and we can take actions to improve our code or advise the partner/customer to fix their custom code, for instance.
• Database lock timed out
• Same as deadlocks. Database locks timed out are related to a specific object and if this object is related to an ISV extension, would be great to get that information via our app-level telemetry. Having access to the alStackTrace might help us understanding why the lock timeout is occurring, if it might be caused by some third party app extending our app and to understand if there's anything that can improved in our code to fix it.
• Error Message Quality
• For the same reasons stated before, if the error messages are being triggered by an ISV app, then would be great to get this kind of information to understand if the error message is clear or not to the user and if there's any error message that's being triggered too many times, which might be happening because the information provided to the user on a certain process is not clear as it could possibly be.
• Feature Telemetry
• It is not clear if after registering the feature telemetry module in the ISV app, the feature telemetry is send to the ISV app telemetry. According to the documentation, Feature Telemetry is not included in the app/extension-level telemetry.

Thanks!