Core Scoping Fields: service, account, daxtraResource & source
Graylog
Chapter 2 · Core Scoping Fields: service, account, daxtraResource & source
Almost every query you'll build in this course starts by narrowing down where to look before worrying about what went wrong. These four fields are that narrowing toolkit — each answering a genuinely different real question: which application, whose data, which piece of infrastructure, and which exact machine.
service — The Logical App Name
service is the field you'll reach for first in nearly every investigation — it names the
logical application that produced a given log message, independent of which specific host or container
it happened to run on. The known clean values in real use:
Chapters 5 and 6 come back to several of these by name — the Node/Koa-shaped services (scout, search, integrations-api, ws-lite), the Flux pipeline (flux-worker, flux-controller, flux-rest), the Java monolith (hwsdb), and the legacy Perl stack (integrations-perl) each carry their own additional real field families on top of the ones this chapter covers.
account — The Customer/Account Identifier
account identifies a specific customer or account, and is mainly populated on the
integration/RMS job platform. Real shapes seen in practice vary by which part of the system wrote the
value:
account is an exact-match field. Guessing the wrong separator — a hyphen where the real
value uses an underscore, or vice versa — doesn't produce a partial match or a warning; it silently
returns zero results. If an account query comes back empty, confirm the real, exact value first before
concluding the account has no matching log activity at all.
daxtraResource — The Infrastructure Unit
daxtraResource names the specific piece of infrastructure a message came from — a cluster
or a host, one level more concrete than the logical service name. Real examples:
This is the field to reach for when a problem is suspected to be regional or cluster-specific — the
same logical service running in two different clusters can behave differently, and
daxtraResource is what lets you isolate one from the other.
source — The Always-Present Fallback
source is the lowest-level identity field — a hostname or container ID — and unlike the
three fields above, it's always present on every message, regardless of which service produced it or
whether that service bothered to populate the more specific fields. When nothing else is available to
scope a search, source still is.
| Field | Answers | Always present? |
|---|---|---|
| service | Which application? | No — populated per service, but consistently used |
| account | Whose data? (mainly integration/RMS platform) | No — mainly integration/RMS platform |
| daxtraResource | Which cluster or host? | No — infrastructure-dependent |
| source | Which exact machine/container? | Yes — the real fallback field |
Hands-On Exercises
A ticket mentions account "bullhorn_31200" but a query for
account:bullhorn-31200 returns zero results. Using this chapter's own material, explain
the most likely cause and how you'd confirm it.
A query scoped by service and account returns nothing at
all, and you suspect the service in question never populates the account field for this particular
log line. Using this chapter's own material, name the one field that should still be usable to
identify where the message came from.
Write a query that scopes to the scout service running specifically on the
eu-west-2 cluster, using this chapter's own real daxtraResource example value.
Chapter 2 Quick Reference
- service — the logical app name (scout, hwsdb, ws-lite, nginx, and more); the field almost every query starts from
- account — customer/account identifier, mainly on the integration/RMS platform; exact-match — a wrong separator (hyphen vs. underscore) silently returns zero results
- daxtraResource — the specific cluster or host; use it to isolate a regional or cluster-specific problem
- source — hostname or container ID; the one field that's always present, regardless of service
- Combining
service+accountis a real, common scoping pattern - Next chapter: Severity & the level Field