Field dictionary
Scan an index: which fields it has, their types, cardinality and sample values. Confirm field names before writing a query or a rule.
The field dictionary reads the index mapping plus a sample of documents and shows the fields and values the cluster actually has, independent of the ECS spec. Smart query and detection rules use the same scan internally. Every edition.
Scanning
Pick an index (wildcards allowed, e.g. logs-nginx.*) and click "Scan index". Results are cached for 5 minutes (RST_FIELD_DICT_CACHE_TTL_S).
Scan overview
| Card | Meaning |
|---|---|
| Documents | How many indices matched, how many documents |
| Fields scanned | How many the mapping declares, how many the sample saw; large indices scanned partially are marked |
| Empty fields | In the mapping but never seen in the sample; avoid them in rules |
| Highest-cardinality field | Most distinct values, usually IDs, timestamps, message bodies |
| Type mix | Share of keyword / text / date / ip / long … |
Field table
One row per field: name, type, estimated distinct values, sample values (most frequent first).
- Filter by name, filter by type.
- Click a sample value to copy it as
field:"value", ready to paste into a query or rule. - Row actions: "Insert into query" takes the field to Smart query; "Aggregate by X, top 10" builds a statistics question in one click.
Typical uses
- Confirm field names before writing a detection intent:
event.actionorevent.type, valuelogin_failureorfailed. - Check sample values when a smart query finds nothing: the log says
ERROR, noterror. - Judge whether an index is worth onboarding: many empty fields or odd cardinalities point at a collector mapping problem.
Detection rules
Describe the behaviour to catch in one sentence and get a Kibana detection rule (KQL / EQL / threshold) mapped to MITRE ATT&CK; export .ndjson and import into Kibana. Paid.
Runbooks
SOPs, runbooks and environment notes as a searchable knowledge base; triage, investigation, rule generation and the check-up read cite it automatically.