If we disable the AKS monitoring add-on completely for AKS monitoring as mentioned below documents will it affect the AKS deployments or services?
https://docs.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-optout#azure-cli
where the Kubernetes logs are saved for AKS if we disable the monitoring add-on?
I am trying to get performance from network interfaces from network device (mikrotik, cisco routers etc.) about interface traffic via SNMP poll and send those data to Azure Monitor Log Analytics.
I have installed and working Azure Log Analytics agent on Debian Linux, https://docs.microsoft.com/en-us/azure/azure-monitor/agents/agent-linux and working Syslog monitoring https://docs.microsoft.com/en-us/azure/azure-monitor/agents/data-sources-syslog
However, I am unable to find a good example of CollectD configuration file using SNMP plugin and how to send those performance data to Azure Monitor service https://docs.microsoft.com/en-us/azure/azure-monitor/agents/data-sources-collectd
https://collectd.org/wiki/index.php/Plugin:SNMP
If somebody can share CollectD configuration files using SNMP CollectD plugin and sending this performance data to Azure Monitor? Or how to troubleshoot CollectD service with SNMP plugin? Or any other free software (on Linux or Windows) which can do SNMP pull (and SNMP trap) and supports sending data to Azure Monitor I would be thankful.
I would like to know the difference between timeTaken_d and clientResponseTime_d
please find the query below
AzureDiagnostics | where Category == 'ApplicationGatewayAccessLog' | project timeStamp_t, timeTaken_d, clientResponseTime_d, serverResponseLatency_s, httpStatus_d, requestUri_s, instanceId_s
Note that I am not asking about multihoming the Log Analytics agent, such that it writes to two Workspaces. Rather, I would like to know whether, in the case where I already have two Workspaces, if one of them can send its content to the other on an ongoing basis.
We are using Azure Sentinel to monitor logs for both our Azure-based and on-premises resources. We are using a single Sentinel instance, with a single Log Analytics Workspace. All of the resources we need to monitor store their logs in this one Workspace, per the recommendation of the Microsoft doc.
For our on-prem Windows servers, we are using the Azure Log Analytics agent to send various logs to the Sentinel Workspace. One such log is the Windows Event Log, of which we are sending certain events from the Security, Application, and System logs to Azure. This is working fine.
(Note: Don't let the mention of SQL Server scare you off; it is only incidental to the question at-hand.)
Some of our on-prem Windows hosts are running SQL Server. We have a compliance requirement to audit certain database events. We are using SQL Server Audit to write these events to the Windows Security Event Log.
The problem is that the Log Analytics agent is not sending the events that we care about from the Security Event Log to Sentinel's Log Analytics Workspace. This is expected, based on our configuration; see next.
We can configure which information from the Windows Event Log to store in Azure. This configuration is defined by the target Log Analytics Workspace.
Presently, however, Azure only allows relatively coarse configuration options. For the Security Event Log, we can store nothing, everything, or one of two groups of events: "Minimal" and "Common". Microsoft documents the list of Event IDs in each of these categories.
Unfortunately, the SQL Server related events that we care about are not included in either the Minimal or Common Event ID groups.
I see several options for storing the specific Event IDs that we want, but each has a nontrivial drawback:
Store all events. We can change the configuration of Sentinel's Workspace to store all events from the Security Event Log. The problem is that changing this setting will affect all of our Windows hosts (we only need to increase logging for the subset of hosts running SQL Server). If we did this, our data ingress and storage costs would increase dramatically, especially given our long retention requirements.
Use the new Azure Monitor agent. The Azure Monitor agent will eventually replace the Log Analytics agent, and includes the ability to define granular event storage filters. Presently, however, this agent is in Preview status. Additionally, our schedule does not include enough time to replace our Log Analytics agents with the Azure Monitor agent, learn/write the filters, or update ancillary infrastructure like the Azure Policies that automatically deploy agents to new hosts.
Create a second Sentinel instance. Using a second Sentinel, with its own Log Analytics Workspace, would allow us send logs from just the database servers there. In turn, we could configure the Workspace to store all events from the Security Event Log. This would allow us to store the events we need from those few database servers, without storing an overwhelming amount of noise from the other Windows servers. The problem is that we'll now have two, independent Sentinel instances which, if I understand correctly, would require additional configuration (e.g. cross-workspace queries for Analytics Rules, Workbooks, etc.) to correlate security events between the different tiers of our environment (e.g. databases, web apps, operating systems).
I envision a possible solution where we use a second, "staging" Log Analytics Workspace for just the database servers. This Workspace would be configured to store all events from their Security Event Logs - and then forward those events to the Sentinel Workspace.
In this scenario, the two Workspaces would allow us to configure Event Log storage more granularly than with a single Workspace. But, we would still have a single Sentinel instance that could correlate events using a one, consolidated Workspace.
Admittedly, the second Workspace would be storing duplicate records, but we could configure a short retention period because they would be forwarded for long-term storage to the "real" Workspace that Sentinel is using. The extra cost would be tolerable.
I don't know if this is possible, though. I've read about Continuous Export from Log Analytics Workspaces, but it looks like the targets can only be Storage Accounts and Event Hubs, not other Workspaces.
So, I'm hoping that someone knows of an easy way to forward records from one Log Analytics Workspace to another (i.e. the original question).
Of course, if you have other suggestions to accomplish our business goal of sending the specific Windows Security Event Log Event IDs to our Sentinel instance, please feel free to recommend them. Note that we currently have limited access to Sentinel expertise, so anything that requires more than the most modest Sentinel reconfiguration is probably impractical for the moment.
Thank you in advance for your time and consideration.
Using an ARM Template I want to enable diagnostics settings for my Azure SQL Database and have that data stored in a Log Analytics workspace I created. I want to enable the errors, timeouts, blocks and wait statistics logs and the basic metric option. I was able to get this working with a web app so I took a similar approach but my template fails and throws errors saying the metrics or diagnostic categories I reference don't exist or not supported. Here's some of the resources section my template:
I'm not sure if additional settings need to be enabled or referenced in the template for this to work but I would appreciate any help, thanks!
"resources": [
{
"type": "databases",
"apiVersion": "2019-06-01-preview",
"name": "[parameters('sqlDatabase')]",
"location": "[parameters('location')]",
"tags": {},
"dependsOn": [
"[parameters('sqlServer')]"
],
"sku": {
"name": "GP_Gen5_4",
"tier": "GeneralPurpose"
},
"properties": {
"startIpAddress": "0.0.0.0",
"endIpAddress": "0.0.0.0"
}
},
{
"type": "providers/diagnosticSettings",
"name": "[concat('Microsoft.Insights/', parameters('diagnostics-name'))]",
"dependsOn": [
"[resourceId('Microsoft.Sql/servers', parameters('sqlServer'))]",
"[resourceId('Microsoft.Sql/servers/databases', parameters('sqlServer'), parameters('sqlDatabase'))]"
],
"apiVersion": "2017-05-01-preview",
"properties": {
"name": "[parameters('diagnostics-name')]",
"workspaceId": "[concat('subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('loganalytics-rg'), '/providers/Microsoft.OperationalInsights/workspaces/', parameters('workspacename'))]",
"logs": [
{
"category": "Errors",
"enabled": "true",
"retentionPolicy": {
"enabled": "true",
"days": 7
}
},
{
"category": "DatabaseWaitStatistics",
"enabled": "true",
"retentionPolicy": {
"enabled": "true",
"days": 7
}
},
{
"category": "Timeouts",
"enabled": "true",
"retentionPolicy": {
"enabled": "true",
"days": 7
}
},
{
"category": "Blocks",
"enabled": "true",
"retentionPolicy": {
"enabled": "true",
"days": 7
}
}
]
}
}
]
}
]
}