89 votes6 comments · Application Insights » Service monitoring and diagnostics · Flag idea as inappropriate… · Admin →
The approach using instrumentation in the StatusMonitor is on hold, it could be fragile given the StackExchange SDK may change in a way that breaks the auto-collection.
Please use custom instrumentation to collect calls to Redis.
We are still taking requests for onboarding to the preview of Application Insights variable retention. Some features required to enable this via self-service are taking longer than expected, but we are still working it, and in the meantime will be glad to enable your Application Insights resource to have different retention settings.
The first iteration of this feature will allow setting retention up to 2 years in several increments for each Application Insights resource (e.g. not by data type). The pricing for this will follow the same Azure Monitor log data retention pricing as used by Log Analytics.
We will be able to onboard a limited number of customers manually in the coming weeks. If you’re interested, please send me (email@example.com) the instrumentation key(s) of your Application Insights resource(s), and the desired retention duration (30, 60, 120, 180, 270, 365, 550 or 730 days).
Thank you for all the votes and feedback. We have started work on this and the capability will be supported soon. If you would like to get in touch with us to discuss your scenarios, please fill this form: https://aka.ms/ApplicationGatewayCohortBen Clapp commented
It would also be really good to be able to see all responses returned to clients by the Application Gateway.
There are cases where the gateway is overloaded, where 503s will be returned, but not logged in a way that's currently visible to us.
Also, per second metrics around CPU, throughput and any other bottlenecks are absolutely required for us to know when and how to scale App Gateway.