An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.
Hi @S Bak
Those mdsd errors all point to one thing: the agent can't reach the Azure Monitor control endpoints in Azure Government. "Response Code: 0" means it never got any reply, so it keeps retrying, and every retry gets logged. That's what is flooding syslog. Once the agent can connect, the noise stops by itself.
- From the VM, test the connection directly with
curl -v https://global.handler.control.monitor.azure.usandcurl -v https://usgovvirginia.handler.control.monitor.azure.us. A timeout or TLS error confirms a network block. - Allow outbound TCP 443 from the VM to
global.handler.control.monitor.azure.us,usgovvirginia.handler.control.monitor.azure.usand<workspace-id>.ods.opinsights.azure.us. If you use an NSG or Azure Firewall, the AzureMonitor and AzureResourceManager service tags cover these. - If traffic goes through a firewall or proxy that does HTTPS inspection, exclude these endpoints. AMA doesn't work with inspected TLS.
- If the VM can only get out through a proxy, configure it on the AMA extension (the
proxysetting). Proxy environment variables only work from AMA for Linux 1.24.2 onwards. - If you use Azure Monitor Private Link, the agent should use your private data collection endpoint instead. Check that the DCR has a DCE associated and that private DNS resolves it.
Also, I'd avoid posting subscription IDs and resource paths here, even partly masked. Share those privately if someone asks.
What does the curl test return from the VM: a timeout, or a certificate error?
If this resolved your issue, please consider accepting it as the answer. If the endpoints are reachable and the errors continue, let me know and I'll be happy to keep helping.
Reference: