Skip to main content

No Data Arriving

"We're not seeing logs from X" is the most common support case in any SIEM, and it is almost never one problem: it is any of eight or nine independent failures that all present identically. This page works down the layers between the source system and a queryable event, giving the check that confirms or eliminates each one. Do them in order; the value of the method is that each confirmed layer removes everything below it from consideration.

Work Down the Layers​

Start at the source and work inward, confirming each layer before blaming the next:

  1. Is the source still generating and sending events? Check on the source system itself.
  2. Can the traffic reach the platform or collector (network path, port, and TLS)?
  3. Is the collector healthy, registered and authenticated?
  4. Is the receiving port or endpoint configured to accept what is being sent?
  5. Is the application or integration running rather than aborted?
  6. Is the lake write succeeding, and is the queue draining?
  7. Is the search looking in the right index and time range?

Layers 1 and 2 are diagnosed on the source system and the network between it and the platform, and are outside what the interface can show you. The sections below cover the layers the platform itself reports on.

Collector Health​

Is the Collector Online?​

Check the collector's state from both ends: the platform's view on Configuration → Collectors (/v2/configuration/collectors), and the collector console. The platform page is a table of the registered collectors with Name, Description, Status (a green Active badge while the appliance checks in; Inactive, with the time since its last check-in, once it has gone quiet; Disconnected after a day without contact; a grey No Connection for one that has never connected; see Status), Token, and Actions columns; Refresh, in the header, reloads it. Page reference: Collectors.

Collectors page listing four collectors, one Active and three with No Connection, each with a redacted token, a copy button, and Delete; the Active collector also has Configure

Console access and the mgmt commands are covered in Collector Login.

Receiving Configuration​

A listener has to exist for the port and the protocol the source is sending on. The failure worth naming explicitly is a protocol mismatch: UDP sent to a TCP listener, or the reverse, produces exactly the "nothing arrives" symptom with no error logged at either end. See Syslog Ports for the listener configuration and HEC for HTTP-delivered data.

Application and Integration State​

The Status Badge​

On Applications (/v2/applications) each installed application is a row naming the application, with its instance's display name beneath it, and carrying a status badge: green Running for a healthy instance, red Error for one that stopped on an error or has raised recent alerts, and amber Inactive or Waiting for consent for one that is disabled or waiting. The Error and Attention filters above the table narrow it to the applications that need action:

Applications page with five status counters across the top, the All, Running, Attention, Error, and Disabled filters, a search field, Table and Board view buttons, and a table of eight installed applications, two of them with a red Error badge

Click the row to open the application's details page. On an application that stopped on an error, the summary card carries the error message explaining why it stopped (a data-lake index name conflict, for example), and Error bytes by component shows which pipeline component reported errors. A source that cannot start, such as one whose credential the vendor rejects, is listed under Data source errors at the foot of the summary card, with the error the source reported.

The page also shows the Parameters the application was installed with (secrets masked) and the Actions the install performed, so you can confirm the values in play without reinstalling. Parameter values are read-only; to change one, uninstall the application and install it again. To uninstall, click Uninstall at the top right of the application's details page.

AWS Sources: Is the Role Still There?​

An AWS application reads through the role named in its Pre-defined AWS Role parameter. If that role is deleted from Configuration → AWS Roles (v1: Settings → Advanced → AWS Roles), or is deleted or changed on the AWS side, the application stops collecting. It may do so silently, without aborting, because nothing checks for a removed role. Take the role name from the Parameters of the application's details, then find it on AWS Roles (v1: Settings → AWS Roles):

  • Missing from the list: the role was deleted from the platform. Reinstall the application with a role that is registered and green.
  • Red Status dot (v2: an Invalid status badge): the platform can no longer assume the role. The usual causes are a deleted IAM role or stack, a changed trust policy, or a mismatched External ID. See Connecting to AWS.

Lake Write​

Queue Length​

Configuration → Data Lakes (/v2/configuration/data-lakes) shows one panel per lake with a card for each index in it. Every card gives the index name and its schema, the events it has Stored (24H) and its Est. Rate, a sparkline of recent ingest, and a footer with Queue (the items waiting to be imported), Merged, and Imported. Non-zero and stable is normal under load; non-zero and rising means the write side is not keeping up or is failing.

Data Lakes page showing the managed lake panel with its 24-hour totals and a grid of index cards, each with stored count, estimated rate, a sparkline, and queue, merged and imported details, followed by a Create New Index tile

Merged and Imported are separate: an index that has never been merged shows a placeholder date in the year 1 under Merged, and a real Imported time beside it means data is arriving and has simply not been merged yet, not that nothing arrived.

Lake Tasks​

Check Admin console → Lake Tasks for storage-side work that has failed or stalled. Lake Tasks sits in the Admin console's side navigation under the Management group, alongside Audit Logs and Report Tasks. Each task is listed with its State and a one-line Summary; type a state in the Search id, name, account, or state field to find the tasks that did not complete, and click a task to read its full summary. Page reference: Lake Tasks.

Lake Tasks page listing input, eventwatchJob, platformJob, and pluginJob tasks, newest first, with a 1–25 of 200 pager at the bottom

You Are Looking in the Wrong Place​

The layer everyone forgets, and a surprisingly large share of "missing data" cases.

Wrong Index​

Searching the default index when the data landed in a per-source one.

The index the search runs against is set by the Data lake index drop-down at the left of the search bar on Datalake Search; click it to see the indexes configured for your organization and switch between them: managed-default, which the page opens on, plus per-source indexes such as managed-MSEntra. Each index is named after its data lake and index.

Data lake index drop-down open, listing the managed-MSEntra, managed-behavior and managed-default indexes with managed-default selected

Choosing a different index redraws the histogram for that index straight away; press Search to run the search against it.

Wrong Time Range​

Data present but outside the selected window, including the case where source timestamps are wrong, so events land far from "now". The Time Adjustment parser recipe is the fix for that.

Last updated on