Recently on Microsoft Q&A there was question on how you can control Azure SQL Firewall rule in a way that only certain IP addresses are allowed to be configured. Naturally I gave general answer that you can do that via Azure Policy. Initially I didn’t give the person an actual policy as I haven’t done such before. Of course creating Azure Policy definition can be challenging so the person asked him if I can provide him with example.
AzureDiagnstics table is used by many Azure Services when you send diagnostic logs thus the 500 column limit that Microsoft is trying to fix for that table. When you hit that limit there is currently the described workaround but let’s say you have used one service that was sending logs and you no longer use that service. The logs associated with that service are yet to purged but you also want to clean up any custom columns that the service was using. That way you can free some slots for new custom columns for new services that will send logs to AzureDiagnostics table. Of course you can delete the custom column from Log Analytics blade but you do not want to delete a custom column that is also used by another service. This will be a short blog post that I will show you how to find if custom column is used by more than one service by using Kusto query language.
Azure Policy has a unique feature compared to other competitors when it comes to evaluating Azure Resources. As Azure Policy is built along Azure Resource Manager (ARM) policies are in effect right away. This means if you have policy that blocks location and you try to deploy to that location a resource you will not be able to. The effect is enforced no matter if you use ARM Template Deployments, Portal, PowerShell, CLI, SDK or just plain old REST API. Of course on existing resources the policies are evaluated once 24 hours but you can of course trigger on-demand evaluation scan. The time that the scan will run depends on how many resources the policy will need to evaluate. Obviously policies that evaluate many resources (such as policies for tags or locations) will take longer (also dependable on the number of resources for the applied scope).
I have been away from blogging for a while as I needed to dedicate some more time to my family but now I am back with new blog post. Today’s topic we will focus on two Azure Monitor features – Resource Health and Log Analytics. Resource Health is may be not so known feature of Azure Monitor. The service will basically track the health of your resources for specific known issues. Think of it like something between Service Health which monitors health for specific services rather resources on higher level and Log Analytics/Application Insights which allows you to monitor on lower level. Using all of them you can achieve end-to-end monitoring. There are a number of resources that are supported by resource health with a number of issues that are monitored. My advise is if you do not have any monitoring on an Azure resource you should at least create resource health alerts for it. Even if you have monitoring I would still advise to use resource health as it will alert you on things that you probably cannot or your are not checking with your monitoring.
One of my blog readers has asked me about policy for sending Azure Activity logs to Log Analytics. As I have written before this is now possible via diagnostic settings at subscription level and thus is easier to make this into policy.