What to track
- Application Session start/stop. Include a log statement as early and as late as possible in your application session.
- User Session start/stop. For many applications such as services and web apps, there may be many user sessions within a single application session. Also, you should track distinctive messages at the start and end of any logical sessions.
- Handled Exceptions. When you log an exception also add the Informational severity.
- Significant User Actions. We also recommend that you log every significant action taken by the user and that you use a specific category for these log messages. This makes it easy to reconstruct reproduction steps for defect reports.
- Feature usage. Don't forget to track important or significant feature usage so you understand how your product is being used in the field.
What not to track
-
Avoid excessive logging. We do not recommend logging high-frequency user interactions and you should only include logging only where it provides useful information to help you understand application flow.
-
Avoid logging in tight loops that will be executed many times a second. You can get a very good sense of what an application is doing with relatively few well-placed log messages.
-
Think carefully about sensitive information. Be sensitive to privacy and intellectual property considerations when adding log messages to your application. For example, passwords and sensitive information such as social-security numbers should never be logged.
Tips & Tricks
- Use the same default logging in Debug and Release builds. If logging is used judiciously (following the guidelines above) there is no need to disable logging for release builds which reduces the risk of different behaviors in release builds. If some logging is selectively disabled, have it disabled by default in both Debug and Release builds.
- Consider using a custom Event Metric for usability events such as Help Requests and Cancelled Actions.
- Consider using a custom Event Metric for tracking request durations. Long requests such as database transactions or cross-process network calls can be performance hot spots. By recording the duration of these calls in a custom metric, you make it easy to identify and troubleshoot issues when they arise.