Why Graylog? Architecture & the Lucene-Style Search Box

This course is deliberately practical, not a general Graylog administration guide — it's built around real usage at Daxtra's own Graylog instance, logger.daxtra.io, and the actual fields, services, and query patterns a solutions engineer runs into day to day. This opening chapter covers just enough of the underlying architecture and search syntax to make everything that follows make sense.

What Graylog Actually Is

Graylog is a log management platform — something that collects log messages from many different services, stores them centrally, and lets you search across all of them from one place instead of SSHing into a dozen different machines and grepping local files by hand. Under the hood, Graylog is built directly on real, well-established storage technology: it indexes and searches messages using Elasticsearch or OpenSearch (Graylog's own open-source codebase ships storage modules for both), while Graylog's own configuration — dashboards, alert definitions, user accounts — is kept separately in MongoDB. Log messages themselves arrive through inputs, real configured listeners that accept messages from applications, containers, or other log-shipping tools.

None of that plumbing needs to be memorized to use Graylog well day to day — but it explains a real, practical fact worth knowing up front: the search box you'll spend most of this course in isn't running a Graylog-invented query language of its own. It's speaking Lucene.

The Search Box Speaks Lucene

Graylog's own search box uses Lucene-style query syntax — the same query language family used by Elasticsearch itself and a wide range of other search tools built on it. The core shape of a query is field:value:

Combine multiple conditions with real boolean operators — AND, OR, and NOT — and group alternatives inside parentheses:

Wrap free text in double quotes to search for an exact phrase rather than individual words, and use a trailing asterisk for a wildcard match:

What's Ahead in This Course

Chapters 2 through 6 build up the real field vocabulary used across Daxtra's own services — the core scoping fields every query starts from, severity levels, the correlation IDs that let you follow one request or job across multiple log lines, the HTTP-shaped fields common to the Node-based services, and the field families specific to Flux, the legacy Java monolith, and the older Perl/CGI stack. Chapter 7 turns that vocabulary into genuinely effective queries, Chapter 8 works through real troubleshooting scenarios query by query, and Chapter 9 covers the gotchas that cause a technically-correct query to still mislead you. The capstone ties all of it into one realistic incident investigation, start to finish.

Hands-On Exercises