Service-Specific Field Families: Flux, hwsdb & Legacy Perl/CGI

Graylog

Chapter 6 · Service-Specific Field Families: Flux, hwsdb & Legacy Perl/CGI

Chapter 5 covered a field shape shared across five services. This chapter covers the opposite — vocabularies that belong to just one part of the stack, and one field, candidateId, that genuinely isn't a structured field at all despite looking like one.

integrations-api's Own Fields

action and integration are structured fields specific to integrations-api only.

integrations-api ≠ integrations-perl

These two service names look like variants of the same thing, but they genuinely aren't — they're different real codebases with different real field vocabularies. action and integration apply to integrations-api and are not structured fields on integrations-perl, which has its own separate real field family, covered later in this chapter. Double-check which of the two you're actually querying before assuming a field applies.

candidateId — The Free-Text-Only Gotcha

candidateId is usually NOT a structured field

In most real services, candidateId appears only as free text embedded in a log message, not as its own structured field. Searching candidateId:<id> as a field will usually miss real matches entirely — search the ID as plain, unquoted-field free text instead:

This is a genuinely easy mistake, since candidateId looks exactly like the other ID-shaped fields covered in Chapter 4 — the difference is that those really are structured, and this one usually isn't.

Flux Pipeline Fields

Field	Holds
rmsId	An RMS-side identifier
datumType	Candidate or Vacancy
datum	The Mongo ID of the underlying record
requestTime	Time, in milliseconds

These sit alongside Chapter 4's own Flux-relevant correlation fields (correlationId, inputId) — together they cover both what a Flux pipeline step touched (datumType/datum) and which run it belonged to.

hwsdb (Java Monolith) Fields

Field	Holds
class	The fully qualified class name
pid	Process ID
thread	Thread name

A direct echo of Chapter 1

class is exactly the field Chapter 1 used to introduce the leading-wildcard limitation — class:*Foo fails, only a trailing wildcard like class:Foo* works. Anytime you're narrowing an hwsdb investigation by class name and only know part of it, that constraint applies directly.

Legacy Perl/CGI Fields

Field	Holds
file	Source filename
line	Line number
package	Perl package name
subroutine	Subroutine name
categoryName	A dot-joined category, e.g. `CC.Bullhorn.DB`

categoryName is worth a second look — its dot-joined structure (CC.Bullhorn.DB) means a broader category search can use a trailing wildcard the same way class does: categoryName:CC.Bullhorn.* would match every subcategory under CC.Bullhorn at once.

Hands-On Exercises

Exercise 1

A colleague queries action:sync AND service:integrations-perl and gets zero results, even though they're confident sync actions are happening on that service right now. Using this chapter's own material, explain the most likely cause.

📄 View solution

Exercise 2

You need to find every log line mentioning candidate ID cand-88213. Using this chapter's own material, explain why candidateId:cand-88213 is the wrong query to start with, and write the query you'd actually use instead.

📄 View solution

Exercise 3

Write a query, using this chapter's own real field and its trailing-wildcard behavior, that matches every legacy Perl/CGI log line categorized anywhere under CC.Bullhorn.

📄 View solution

Chapter 6 Quick Reference

action / integration — integrations-api only, genuinely NOT shared with integrations-perl despite the similar name
candidateId — usually free text only, not a structured field; search the ID as plain text instead
Flux — rmsId, datumType (Candidate/Vacancy), datum (Mongo ID), requestTime
hwsdb — class (subject to Chapter 1's leading-wildcard limit), pid, thread
Legacy Perl/CGI — file, line, package, subroutine, categoryName (dot-joined, wildcard-friendly from the right end)
Next chapter: Building Effective Lucene Queries