Blocker
Pattern #5 Layer 1 (kernel AER) needs the journald-kernel OTTL recipe
to extract kernelevents.pcie_aer.severity + kernelevents.pcie_aer.type
gpu.id (PCI BDF) from PCIe Bus Error: ... lines. The recipe today
extracts kernelevents.xid + gpu.id from NVRM: Xid lines (sibling
NVRM stanza), but has no PCIe AER stanza.
Source-of-truth: docs/integrations/journald-kernel.md.
The wiring projection
(projectPCIeAERRecord in patterndetectorprocessor) gates on
kernelevents.pcie_aer.severity AND gpu.id. Without this recipe
stanza, the projection stays a NO-OP on real journald-kernel output and
the detector cannot fire end-to-end.
What's missing
Add an OTTL transform statement parallel to the existing NVRM Xid
stanza that:
-
Matches dmesg-style PCIe AER kernel-line bodies. A representative
line shape:
[12345.678] pcieport 0000:3b:00.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
-
Extracts these attributes (regex named-capture against the line
body):
| Attribute |
Capture |
Notes |
kernelevents.pcie_aer.severity |
severity=([A-Z][a-z]+) |
Corrected / Fatal / Uncorrected |
kernelevents.pcie_aer.type |
type=([A-Z][\w ]+?Layer) |
Data Link Layer / Physical Layer / Transaction Layer |
gpu.id |
the pcieport <BDF> substring |
per RFC-0013 §3 — customer-stable PCI BDF |
-
Falls through silently on non-AER kernel lines (the existing
Xid stanza pattern is the canonical no-match precedent).
Why now
Pattern #5 detector + processor wiring ship in this PR as the v0.3
moat per ADR-0001's intentional split. Real-cluster end-to-end firing
on Layer 1 is gated on this recipe extension.
Sibling: the NVRM Xid stanza already in the recipe is the proximate
analog — same file, same extraction shape, different kernel-line family.
Blocker
Pattern #5 Layer 1 (kernel AER) needs the journald-kernel OTTL recipe
to extract
kernelevents.pcie_aer.severity+kernelevents.pcie_aer.typegpu.id(PCI BDF) fromPCIe Bus Error: ...lines. The recipe todayextracts
kernelevents.xid+gpu.idfromNVRM: Xidlines (siblingNVRM stanza), but has no PCIe AER stanza.
Source-of-truth:
docs/integrations/journald-kernel.md.The wiring projection
(
projectPCIeAERRecordin patterndetectorprocessor) gates onkernelevents.pcie_aer.severityANDgpu.id. Without this recipestanza, the projection stays a NO-OP on real journald-kernel output and
the detector cannot fire end-to-end.
What's missing
Add an OTTL transform statement parallel to the existing NVRM Xid
stanza that:
Matches dmesg-style PCIe AER kernel-line bodies. A representative
line shape:
Extracts these attributes (regex named-capture against the line
body):
kernelevents.pcie_aer.severityseverity=([A-Z][a-z]+)Corrected/Fatal/Uncorrectedkernelevents.pcie_aer.typetype=([A-Z][\w ]+?Layer)Data Link Layer/Physical Layer/Transaction Layergpu.idpcieport <BDF>substringFalls through silently on non-AER kernel lines (the existing
Xid stanza pattern is the canonical no-match precedent).
Why now
Pattern #5 detector + processor wiring ship in this PR as the v0.3
moat per ADR-0001's intentional split. Real-cluster end-to-end firing
on Layer 1 is gated on this recipe extension.
Sibling: the NVRM Xid stanza already in the recipe is the proximate
analog — same file, same extraction shape, different kernel-line family.