Events Search

Legacy interface

The "expand" icon and < > code view described under Base Event Record, and the screenshots under Older captures, belong to the legacy interface. The page as it is today is described under Page Layout below. The event record fields described under Base Event Record apply to it as well.

The events search page addresses the review of raw events data. In the v2 interface it is Datalake Search in the navigation rail (/v2/events), subtitled Faceted search across all collected events in the data lake. (v1: Data Lake → Search, /dataLake/search, headed Events Search with the tagline "Database Search for all collected Events.").

The page itself, control by control, is documented in the interface reference at Datalake Search (v1: Data Lake → Search). This page covers what to do with it.

Page Layout

v2 interface

From top to bottom:

• Search bar: the Data lake index selector, the search box, the time-range buttons, and Search.
• Toolbar: the record count on the left; Save Facet, the sort order, JSON line, Columns, and Export JSON on the right. Active filters appear as chips below it.
• Histogram: the event count over time for the selected index.
• Filters (left column): the search facet in use and its field groups, each listing the values found in the results. The Facet Section covers the panel.
• Result table (right): one row per event, 25 to a page, with ‹ Prev, the page number, and Next › below it.

Until a search runs, the result table reads Choose a time range and filters, then press Search.

Classic v1 interface

From top to bottom:

• Header: the Events Search title on the left and the Export Data and Run Investigation buttons on the right.
• Search bar: an index selector, the query input, the Search button, and a Sort By menu.
• Facet Search Configurations (left column): the facet configuration selector, the facet groups computed from the search results, and a small facet toolbar of four icon buttons (red X, edit, save, magnifier) at the bottom left of the panel.
• Event Count Timeline (main column): a chart of event counts over the searched period, followed by the time-range field and an Events in Selected Range counter.
• Results list: the matching events, with a Showing X to Y of Z results footer and paging arrows.

Choosing an Index

v2 interface

The drop-down at the left of the search bar, Data lake index, chooses the index the search runs against. Each index is named after its data lake and index (managed-MSEntra is the MSEntra index of the managed lake), and the page opens on managed-default.

Choosing another index redraws the histogram for that index straight away; the results follow when you press Search. Only indexes that use the standard event layout are listed; an index with typed columns of its own, such as AzureSigninLogs, is queried on KQL Search instead.

Classic v1 interface

The leftmost control in the search bar shows the index the search runs against. Click it to choose among the managed indexes configured for your organization: in the example below, managed-AzureAudit, managed-behavior, and managed-default.

Picking a different index re-runs the search against it immediately and, where the index has a facet configuration of its own, switches the facet panel to it. Choosing managed-AzureAudit, for example, applies the Default-AzureAD_SignIn configuration and redraws the range strip with the new index's event volume.

Running the Search

v2 interface

Type the search into the search box: a bare value, matched anywhere in the event, or a @field:value term that matches one field (Search events – an IP, a user, @eventType:fortigate…); or leave it empty to list every event in the time range. Pick the time range with the buttons beside it: 15m, 30m, 1h (the default), 6h, 24h, or Custom, which adds a start and an end date-and-time field to the bar. Then click Search. The page's URL then carries the search's time range and index (/v2/events?from=…&to=…&index=…), so the address of a results page opens the same search again.

The record count reports how many events matched and how many are loaded, for example 1,000 of 5,106 records · first 1,000 loaded. A search loads at most the first 1,000 matching events; narrow the time range or add filters to reach the rest.

The sort drop-down orders the results by time: Newest first (the default) or Oldest first, from the next Search. JSON line, on by default, follows each result row with the event's complete JSON on one wrapped line; turn it off for one line per event. Columns chooses the table's columns: Time, Event Type, Source, Sender, and Parser by default, with Behaviors and Tags available.

Click a row to open the event in a panel that slides in from the right: an OVERVIEW of its Time, Event Type, Source, Sender, and Parser; OTHER FIELDS, every other field with nested fields written as a dotted path and a filter button on each row that adds that field and value to the search's filters; and the RAW JSON, folded until you click Show, with Copy JSON.

Classic v1 interface

Type the query into the Search field and click Search (the magnifier icon) to run it. The query, the selected index, and the time range together define what comes back. Running a search navigates to a URL that records the whole search: the query (q), the time window (from, to), the filter terms (must, not), and the index (index), so a search can be bookmarked or shared.

Sort By sets the order of the results list: Newest or Oldest.

Event Count Over Time

v2 interface

The histogram charts the selected index's event count across several days, with the day boundaries labelled along the bottom, and highlights the selected time range as blue bars at its right-hand end. The heading above it gives the event count for the selected range, such as 2.7 K Events in Selected Range.

Classic v1 interface

The main column charts how many events the search matched over time; the heading gives the total, as in Event Count Timeline (0 Events), and the chart area reads No data available! when nothing matched. Below the chart, a time-range field displays the current search window as start and end timestamps (click its x to clear the range), and the Events in Selected Range line counts the events inside the currently selected portion of the timeline.

Exporting Results

v2 interface

Export JSON, at the right end of the toolbar, downloads the loaded results as newline-delimited JSON: an .ndjson file with one event per line. It is disabled until a search returns records.

Classic v1 interface

Export Data in the page header downloads the events in the current result set. If the search returned nothing, nothing is exported and a red Export error toast appears reading No events data to download; dismiss it with its x.

Investigations

An investigation runs a search as a tracked job, with its scope and cost previewed before it starts.

v2 interface

When the search's time window holds more data than a direct search reads, Search opens the Investigation Search dialog instead of listing results. It shows the Start time and End time of the window (editable), the Query and filters the investigation will run with the index, and a preview of the Events, Search size, Estimated time, Archive files, and Estimated cost. Run Investigation starts it; the dialog then shows its progress, and View Results loads the results into the page once it has completed. Close dismisses the dialog.

Runs are listed on Admin console → Management → Investigation History (/v2/admin/investigations), with each run's ID, Data Type, Index, Search Range, Status, Created On, Cost, and Duration, and an ⓘ button that opens its details.

Classic v1 interface

Run Investigation opens the Investigation Search dialog, which previews the scope and cost of running the current search as an investigation before you start it.

The Search Preview section shows the time range to be searched (with an x to clear it), the Search Query the investigation will run, the projected Total Event Count, Size of Search, and Estimated Search Time, the index the investigation searches (the one selected in the search bar), the Archive Files Count the search covers, and the estimated Search Cost in dollars. Click Search to start the investigation or Close to dismiss the dialog without running it.

Runs are tracked on the Data Lake → Investigations page (/dataLake/search/history), titled Investigation History.

Each row is one investigation run, with the columns ID, Datatype, Index, Search Time Range, State, Created On, Cost, Time Taken, and Actions.

Older captures

The two screenshots below show the legacy Event Search page: its SEARCH BAR / QUERY BUILDER / CUSTOM TABLE tabs, and its results table with the Expand column. The current page is the one shown above.

Base Event Record

When data enters the Fluency system, it is assigned metadata to note where and when the message came into the system. This recording of metadata provides a further layer of timing data to ensure addressing PCI DSS (10.4 and 10.3.3) and NIST 800-53 (AU-8).

Messages are sorted by the incoming timestamp. This means that polling message logs, like cloud logs, are often clustered together.

Click the "expand" icon (under the text "expand") on the left of the table to get the content of message more information.

In the expanded window, click < > on the right to see the syslog:

Field	Description
@message	This is a complete record of the incoming message before parsing.
@facility	A defined group/facility area.
@level	This is the messages priority level.
@tags	An array of any tags what had a matching attribute.
@source	The module that produced this message.
@sender	The capture system that is the source of the message.
@fields	This is the resulting parsed data.
@timestamp	This is the millisecond epoch time. This provides a central timestamp verification of all incoming message.

Parsing Process

Messages that come into the system are stored in the "@message" field. Comparing the "@message" field to the "@fields" object allows for parsing verification.

NOTE: After adding or updating a system, the log should be reviewed to ensure that the incoming message is being properly parsed. This is done by filtering to the Event Table to the changed source and then comparing the "@message" to "@fields" attributes.

JSON Sources

Some sources do not contain "@fields" attributes. These are sources that already produce formatted JavaScript Object Notation (JSON) messages. In this special case, the system can leverage the parsed data and add to the associated flow.

Special Views

Certain events receive a different, more readable format, most notably the Office365 formatting. This is done to allow the events database to be used for analysis that does not involve a known flow or asset.

Using the Facet

Facet is a technical term used for groups of attributes; you can think of them as filters. The Facet Section covers this topic in more detail. Facet is an easy way to focus on data and see the most common responses by field.