Reading Splunk Live in a Data Grid

It is 8am and the alert queue already has forty items in it. The old way to work through them is a saved search, a results page and a lot of scrolling back to the search bar to narrow things down. The grid changes that shape: open a live Splunk search in an ordinary table, and every filter, sort or page you click becomes a piece of Splunk’s own search language, sent to Splunk, answered by Splunk.

Type into the action column, tick “blocked” and “failed_login”, narrow the time range to the last six hours, and the grid writes one search string and sends it. Splunk does the filtering, the sorting and the counting; the grid holds only the page of rows you are looking at. Ten thousand events or a hundred thousand behave the same way from the table’s point of view, because the table never asked Splunk for more than a screenful at a time.

The search string, next to the rows

Every query the grid runs is visible in plain text alongside the results, so “why does this row show up” has an answer you can read rather than a black box to trust. Widen a filter, narrow it, add a second condition, and the search string updates immediately. An analyst working a real incident this way can triage fifty thousand events without leaving the table: the grid never blocks on Splunk’s own paging, and stepping to the next page of results reuses the same running search instead of starting a new one.

What actually pushes into Splunk

Not every kind of question is worth sending over the network, and not every kind needs to be. What does travel as part of the search:

• equality and negation on any column
• greater than, less than and the inclusive forms of both
• contains, starts with and ends with
• matching against a list of values
• blank and not-blank
• any combination of the above joined with AND, OR and NOT
• a time range, mapped onto the search’s own window rather than left as a filter Splunk has to scan past
• a sort on any column
• paging through the result set

Two ways to run the query itself: read a window of results as you page through them, or stream the whole matching set to the table in one pass for a search you already know will be large. Both read from the same search; which one to reach for is a question of how you want the first rows to arrive.

In production, the token never reaches the browser

Point the grid at your own application, not at Splunk directly. Your application signs the visitor in whatever way it already does, and a small proxy sitting behind it holds the one Splunk service token: it forwards only the four routes a search needs, dispatching a job, reading its results, exporting them, cancelling the job, narrows index= to whatever that visitor is allowed to see, rate-limits the calls, and adds the cross-origin headers the browser needs. The grid points at the proxy and never sees a token at all.

The page itself gets simpler for it, not more complex: one URL, no headers.

const adapter = splunkAdapter({
  url: 'https://app.example.com/splunk',
  search, earliest,
});

A token grants everything its own role can do, across every index it can see, to anyone who can read the page it sits in. Keeping it behind a proxy means a leaked page costs nothing, because the page never held anything to leak.

Behind your own login instead of a public one, a lighter shape does the same job: each user signs into Splunk with their own account, and the page holds that one person’s own short-lived session key in memory rather than a shared token. What leaks if that page is compromised is one person’s own access, not everyone’s, and it expires on its own.

The bearer token sitting in headers earlier on this page is there so you can try the search against a development instance, nothing more than that.

See where the credential lives in the adapter guide for the reference proxy in full.

See it running against a mock of the search API, since there is no public Splunk instance this page could point at, or read the full adapter guide for wiring it to a real one.