Skip to main content

Troubleshooting

Most problems in a SIEM deployment are the same problem seen from different angles: something that used to arrive has stopped arriving, or something that arrives is not usable. This section gives a method for narrowing that down (work from the outside of the pipeline inward, confirm each layer before blaming the next) and a map of the diagnostic surfaces the product provides. Each page that follows takes one class of problem and works down its layers.

Diagnostic Surfaces​

Where the product will tell you something is wrong, if you know to look. Each subsection says what the surface shows, what a healthy reading looks like, and what an unhealthy one implies.

Applications​

Applications, in the navigation rail (/v2/applications), carries a status badge on every installed application: 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 counter across the top of the page counts the applications in error, and the Error and Attention filters narrow the list 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 a row to open the application's details page. Its summary card shows the application's state beside the traffic in and out, Error Bytes, Drop Rate, and Last Event; for an application that stopped on an error it also carries the error message explaining why: for example a data-lake index name conflict. Error bytes by component breaks the error bytes down by pipeline component, and the Pipeline card draws the components the application installed:

Application details page for an Azure Directory Audit (Event Hub) instance, showing the Uninstall and Refresh buttons in the header, the summary card with In / Out, Error Bytes, Drop Rate, and Last Event, the Pipeline card from source through router to its destinations, and the Parameters and Actions cards

This is the first place to look when one source stops and the others keep going. Page reference: Applications and Application Details.

Home Dashboard Application Health​

The Home page's Health & status panel counts the installed applications in each state, Healthy (green), Inactive (amber), and Error, and lists applications by name beneath the counters, each with its state on the right. The Overall status banner across the top of the page sums it up in one line, such as 2 applications erroring and 3 applications inactive. A non-zero Error count, or an application you expect to be sending data listed as Inactive, localizes the problem to one application at a glance. Click the application to open its details page, or Applications in the panel's upper-right corner to open the Applications page. Panel reference: Home → Health & Status.

Home dashboard with the Attention needed banner across the top, the Open cases, Usage and Datalake storage panels on the left, and on the right the Health & status panel counting three healthy, three inactive and two error applications above the Cases handled and Median MTTR panels

Usage​

Two of the dashboard reports on Reports, in the navigation rail, cover ingest and search volume. The Event Ingress Report charts ingress over a range from 1H to 30D, or a Custom one: its Ingress activity chart plots volume or events, its index drop-down (or a click on an entry under Top indexes) limits the chart to one index, and Ingress by index lists every index's volume and events. Use it to see which index stopped and exactly when.

Event Ingress Report over seven days, with time-range buttons, four headline figures, the Ingress activity chart, the Top indexes list, and the Ingress by index table

The Usage Report gives the totals for Eventwatch, Datalake, Search, and Realtime search over 7D, 30D, or 90D, with a Daily volume chart and a Daily usage table, one row per day. Use its Search and Realtime search figures to see whether a cost problem is coming from queries rather than ingest. Report reference: Event Ingress Report and Usage Report.

Data Lakes​

Configuration → Data Lakes (/v2/configuration/data-lakes) shows one panel per data lake, with a card for every index in it. Each index card gives the index name and the schema it uses, 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: when the index was last merged and when data was last imported into it. An index that has never been merged or imported shows a placeholder date in the year 1 there. A Queue that is non-zero and rising means data is arriving but not landing, a very different problem from data not arriving at all. Page reference: Data Lakes.

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

Audit Log​

Audit Logs (/v2/admin/audit) sits under the Management group in the Admin console's side navigation, alongside Lake Tasks, Report Tasks, Archived Reports, and Investigation History. The audit record is what was changed in the platform and by whom; this is how "what changed?" gets an actual answer. Background: What Is an Audit Log.

The page is a Search audit logs field over a table of User, Action, Category, Error, and Date, with a Filters panel on the left grouping User, Role, API, API Type, Category, and Error. Click a value in the API group (login, Add User, Delete User, and so on) to answer "who changed this and when" in one click, and combine Category: authentication with the Error group to isolate failed sign-ins. Download Audit Logs, in the upper-right corner, exports the log for a case or an access review.

Audit Logs page with the Download Audit Logs button, a search bar, a record count, the Filters panel with User, Role, API, API Type, Category, and Error groups, and the table of audit records

Lake Tasks​

The Lake Tasks entry in the same Management group shows the platform's own storage-side work. Use it when data has been accepted but is not yet queryable. Page reference: Lake Tasks (v1: Settings → Lake Tasks).

Report Scheduler Run History​

Aborted scheduled runs, climbing run durations, and rising cost all show up in a scheduled report's prior runs: the Prior Runs dialog on Configuration → Report Scheduler (v1: the Scheduler's prior-runs table). Admin console → Report Tasks (v1: Settings → Management → Reports) is the run history of every report; in v2, searching aborted there finds the runs that did not finish. See Scheduling and Delivery.

Investigation History​

Long-running or expensive searches are tracked on Admin console → Investigation History (/v2/admin/investigations): one row per run, with ID, Data Type, Index, Search Range, Status, Created On, Cost, and Duration columns, and an ⓘ button at the end of each row that opens the run's details, including the Query it ran. This is where a "the search never came back" report gets resolved: Status gives the run's current state, Cost the cost of the search, and Duration how long the run took.

Investigation History page with a refresh button, a search field, and a table of completed Lake Search investigations, each row ending in an ⓘ details button

Collector Console​

For collector-side problems the diagnostic surface is the collector itself, over its console. See Fluency Collector.

Last updated on