6.6 Connector Troubleshooting

Connector Troubleshooting

By the end of this subsection, you will be able to diagnose and fix the five most common connector failures using systematic troubleshooting and KQL diagnostic queries.

Connectors fail silently. The workspace does not alert you when data stops flowing — you discover the failure when an investigation returns empty results or an analytics rule stops firing. This subsection teaches you to find and fix failures before they create blind spots.

The universal diagnostic approach

Every connector failure falls into one of three zones. Determine which zone first, then drill down.

Zone 1: Source device — Is the device generating and sending logs? Zone 2: Transport layer — Is the data reaching the forwarder/ingestion endpoint? Zone 3: Workspace — Is the data being accepted, transformed, and stored?

Start at Zone 1, work forward. This prevents the common mistake of debugging the workspace when the firewall stopped sending logs.

Problem 1: Connector shows “Connected” but no data

Symptom: Green status in the connector page. Target table returns zero events.

Zone 1 check — is the device sending?

For Syslog/CEF sources, SSH to the forwarder:

1
2
3
4

-- Shell command on the forwarder VM:
-- sudo tcpdump -i any port 514 -c 10
-- If packets appear: data is reaching the forwarder. Problem is Zone 2 or 3.
-- If no packets: the source device is not sending. Check device config.

Zone 2 check — is rsyslog processing?

1
2
3
4
5

-- Shell commands:
-- systemctl status rsyslog
-- tail -f /var/log/syslog | grep CEF
-- If rsyslog is running and CEF messages appear: problem is the AMA (Zone 3).
-- If rsyslog is stopped: sudo systemctl restart rsyslog

Zone 3 check — is the AMA connected?

Check Azure Portal → Monitor → Data Collection Rules → verify the forwarder VM is listed. Check AMA agent health: sudo /opt/microsoft/azuremonitoragent/bin/mdsd --version on the forwarder. If AMA is not running, restart: sudo systemctl restart azuremonitoragent.

For Microsoft first-party connectors (no forwarder), check:

• Entra ID: Are diagnostic settings still configured? (Settings can be deleted during admin changes)
• M365 Defender: Is the connector still enabled in the Sentinel portal? (Portal updates can reset connector state)
• Azure Activity: Is the subscription still selected?

Problem 2: Data flowing but with high latency

Symptom: Data arrives 10-30 minutes after the event occurred.

1
2
3
4
5
6
7

CommonSecurityLog
| where TimeGenerated > ago(1h)
| extend IngestionDelay = ingestion_time() - TimeGenerated
| summarize
    AvgDelay = round(avg(IngestionDelay) / 1m, 0),
    P95Delay = round(percentile(IngestionDelay, 95) / 1m, 0),
    MaxDelay = round(max(IngestionDelay) / 1m, 0)

Problem 3: Duplicate events

Symptom: The same event appears multiple times.

1
2
3
4
5
6
7

CommonSecurityLog
| where TimeGenerated > ago(1h)
| summarize Count = count()
    by DeviceEventClassID, SourceIP, DestinationIP,
    bin(TimeGenerated, 1s)
| where Count > 1
| summarize DuplicateEvents = sum(Count - 1), AffectedBuckets = count()

Problem 4: Missing fields (null columns)

Symptom: Data arrives but SourceIP, DeviceAction, or other critical fields are null.

1
2
3
4
5
6

CommonSecurityLog
| where TimeGenerated > ago(1h)
| where isempty(SourceIP) or isempty(DeviceAction)
| take 5
| project TimeGenerated, DeviceVendor, DeviceProduct,
    SourceIP, DeviceAction, Message

Problem 5: Connector was working, then stopped

Systematic check (in order):

1. Source device: Configuration change? Reboot that lost Syslog config? Firmware update that changed log format?
2. Network: Firewall rule change blocking port 514 (to forwarder) or 443 (forwarder to Azure)?
3. Forwarder: VM running? Disk full? rsyslog running? AMA running?
4. DCR: Was the DCR modified? A syntax error in the transformation silently drops all data. Check the DCR’s “last modified” timestamp.
5. Workspace: Accepting data? Check the ingestion health query from Module 5.9.