Share via

Azure Monitor Agent for Linux keeps removing configuration files from /etc/rsyslog.d despite the resource being associated with DCR

Jason Desjardins 20 Reputation points
2026-04-29T18:12:14.0233333+00:00

We have a syslog server sending logs to an Azure Log Analytics workspace. About a week or two ago, there was an update to the Azure Monitor Agent for Linux extenstion and the logs stopped flowing to our logs workbook. I re-installed the extension, and the logs started flowing for about 10 minutes before stopping again.

I then re-installed the extension again, and saw the 10-azuremonitoragent.conf file was created in /etc/rsyslog.d, saw the logs start flowing again, and then about 10 minutes later the configuration file disappeared from /etc/rsyslog.d and the logs stopped once again. I then copied the backup configuration file from /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf back into /etc/rsyslog.d. The logs flowed for 10 minutes, then stopped again, since the configuration file had been removed once more.

This Linux VM is an Azure Arc machine hosted locally and connected to the Azure cloud via a VPN. It is associated with a DCR as a resource. That DCR has Linux Syslog set as a data source. I'm thinking there might be something wrong with the DCR configuration but I've had no luck figuring it out so far.

I appreciate any advice or recommendations to get these logs flowing again. Thank you in advance.

Azure Monitor
Azure Monitor

An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.

Answer accepted by question author

  1. Siva shunmugam Nadessin 9,625 Reputation points Microsoft External Staff Moderator
    2026-04-29T18:29:09.24+00:00

    Hello Jason Desjardins,

    Thank you for reaching out to the Microsoft Q&A forum. 

    When investigated it looks like what you’re seeing is the agent re-syncing your Data Collection Rule (DCR) every ~10 minutes and fully rebuilding the /etc/rsyslog.d folder to match exactly what’s in that rule. If your DCR doesn’t actually include a Linux Syslog data source (or if a second, empty DCR is overriding it), the agent will happily remove the 10-azuremonitoragent.conf file on each sync—and your logs stop flowing.

    Here’s how to fix it:

    Verify the DCR locally

    • On the Arc-enabled Linux VM, run:

    ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/

    grep -Ri ""syslog"" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/*.json

    Make sure you see a "dataSources": { "syslog": … } block defining the facilities and severities you need.

    Check your DCR associations

    • In the Azure portal, go to your Data Collection Rule → Resources → confirm your HybridCompute/machines VM is listed.

    • Ensure no other DCR is targeting the same VM without a Syslog data source.

    Update or recreate the DCR to include Linux Syslog

    • In the DCR’s Data sources tab, add “Linux Syslog” and configure the correct facilities (e.g. auth, authpriv, local0–local7) and severities.

    • Save and let the agent pull the updated rule (or reboot the agent manually:

    sudo systemctl restart azuremonitoragent.

    Confirm the config file sticks

    • After the next agent sync you should see /etc/rsyslog.d/10-azuremonitoragent.conf get recreated—and remain there rather than being deleted.

    1. Check connectivity (in case the rule isn’t downloading) • From your VM run:
    2. curl -v https://global.handler.control.monitor.azure.com

    • If that fails, the agent can’t pull the DCR and might default to an empty config.

    (Optional) Turn on debug logs

    • Create or edit an override for the service to add --debug to the agent’s startup, then systemctl daemon-reload && systemctl restart azuremonitoragent.

    • Inspect /var/opt/microsoft/azuremonitoragent/log/mdsd.err for DCR-apply errors.

    Once your DCR properly includes Syslog and the agent can download it, the rsyslog drop-in will stay in place and your logs will flow continuously. 

    Let me know if any further queries - feel free to reach out! 

    Reference list:

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-04-29T18:12:34.2533333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The behavior indicates that Azure Monitor Agent (AMA) is repeatedly deciding that Syslog collection is not required on this machine and is cleaning up its rsyslog configuration. That decision is driven entirely by the effective Data Collection Rule (DCR) configuration that AMA pulls and parses locally.

    Use the following checks and fixes, in order:

    1. Verify AMA and rsyslog are healthy 
         sudo systemctl status azuremonitoragent
   sudo systemctl status rsyslog
      If either is not active (running), fix that first (restart, check service logs).
    2. Confirm the VM is correctly associated with the DCR On the Azure side (already done conceptually, but re‑validate):
      • Open the DCR → Configuration → Resources.
      • Ensure this Arc machine is listed.
      On the VM side, confirm the DCR configuration is actually present and parsed: 
         sudo ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks
      • Ensure files exist and are recent.
      • If empty or very old, AMA may not be receiving/refreshing the DCR.
    3. Validate that Syslog is defined in the parsed DCR AMA only keeps /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf if the DCR contains a Syslog data source that applies to this machine. On the VM, inspect the parsed config: 
         sudo grep -i -r "syslog" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks
      • Confirm there is a Syslog section and that it includes the facilities/severities expected.
      • If no Syslog configuration is present, AMA will remove its rsyslog forwarding file after a refresh cycle (which matches the “works for ~10 minutes then disappears” pattern). In that case, fix the DCR in Azure (add Linux Syslog data source, correct facilities/severities, save) and wait for the agent to refresh.
    4. Check AMA logs for configuration errors AMA logs configuration and DCR parsing issues under: 
         sudo ls /var/opt/microsoft/azuremonitoragent/log
   sudo cat /var/opt/microsoft/azuremonitoragent/log/mdsd.err
   sudo cat /var/opt/microsoft/azuremonitoragent/log/mdsd.warn
   sudo cat /var/opt/microsoft/azuremonitoragent/log/mdsd.info
      Look for:
      • DCR parsing errors.
      • Messages indicating Syslog configuration is disabled or invalid.
      • Authentication or connectivity issues when fetching DCR.
      If there are configuration errors, correct the DCR (for example, invalid facility/severity combination or destination) and let AMA refresh. Once the DCR is valid, AMA will recreate and keep the rsyslog forwarding file.
    5. Confirm the AMA rsyslog forwarding file is managed by AMA For rsyslog, AMA’s forwarding config should be: 
         cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf
      It should start with a comment similar to: 
         # Azure Monitor Agent configuration: forward logs to azuremonitoragent
      If this file is missing or repeatedly removed, do not manually copy it back as a permanent fix; AMA will overwrite/remove it based on the DCR. Instead, ensure the DCR is correct and applied, then restart AMA: 
         sudo systemctl restart azuremonitoragent
   sudo systemctl restart rsyslog
    6. Verify Syslog workflow end‑to‑end once the file stays in place After the DCR is corrected and the file stops disappearing:
      • Check that rsyslog is listening and forwarding to AMA’s TCP port: 
             sudo ss -lnp | grep -E "28330|514"
        Expect rsyslog on 514 and AMA (mdsd) on its syslog port.
      • Confirm AMA is ingesting Syslog by checking QoS stats: 
             sudo cat /var/opt/microsoft/azuremonitoragent/log/mdsd.qos
        Use this to verify that Syslog events are being processed and uploaded in each 15‑minute window.
    7. If events are received but not visible in Log Analytics If mdsd.qos shows Syslog events processed but they do not appear in the workspace, follow the upload‑failure guidance:
      • Validate the DCR destination (workspace/region) is correct.
      • Check connectivity and authentication errors in mdsd.err.
      • Ensure required Azure Monitor endpoints are reachable from this Arc machine.

    The key is that AMA owns /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf. When the effective DCR for this machine does not contain a valid Syslog data source, AMA removes that file on its next configuration refresh, which explains the repeated 10‑minute behavior. Fixing and reapplying the DCR so that Syslog is correctly defined and parsed will stop the file from being deleted and restore continuous log flow.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.