hiveiq-src/hiveops-guide
4
0
Fork 0
Code Issues 10 Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

content(guide): reconcile platform.kafka catalog — 15 code-verified topics (Refs #3)

Browse Source 
The per-service pass surfaced 10 topics beyond the original 5 (agent.online/
offline, fleet.task.events, incidents.created/updated/resolved, journal.
transactions.recorded, analytics.snapshot-ready, adoons.rule-suggestion.
requested/ready). All grep-confirmed as literals in producing-service source.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Johannes
2026-07-01 09:04:11 -04:00
parent 6542c4f348
commit a41f7d522c
1 changed files with 23 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend/src/main/resources/content/platform/kafka/overview.md
+23 -10
View File
@@ -17,20 +17,33 @@ an event; the **record-keeping / mirror** service consumes and stores it. Kafka
history, cross-service mirrors, and eventual propagation** — not for live state or synchronous
commands (those go over direct API). See **platform.data-architecture**.
## Topic catalog (names verified in code)
## Topic catalog (all names verified in code)
| Topic | Producer | Consumers (non-exhaustive) | Payload |
|-------|----------|----------------------------|---------|
| `hiveops.device.events` | devices | incident, fleet, reports, recon, vault | device create/update → `device_summary` mirrors |
| `hiveops.messages` | messaging (`MessageEvent`) | messaging (`MessageConsumer`) | user/broadcast/action messages |
Every topic below was grep-confirmed as a literal in the producing service's source (2026-07-01).
Consumer edges marked "(see service guide)" are not yet pinned to a listener class — check the
relevant `technical.<service>` guide.
| Topic | Producer | Consumers | Payload |
|-------|----------|-----------|---------|
| `hiveops.device.events` | devices | incident, fleet, reports, recon, vault (`DeviceEventConsumer`) | device create/update/delete → `device_summary` mirrors |
| `hiveops.fleet.task.events` | fleet | devices | fleet task lifecycle → device-scoped `DeviceFleetTask` history |
| `hiveops.incidents.created` | incident | (see service guide) | incident opened |
| `hiveops.incidents.updated` | incident | (see service guide) | incident changed |
| `hiveops.incidents.resolved` | incident | (see service guide) | incident resolved |
| `hiveops.journal.transactions.recorded` | journal | (see service guide) | parsed transaction recorded |
| `hiveops.messages` | messaging | messaging (`MessageConsumer`) | user/broadcast/action messages |
| `hiveops.reports.completed` | reports | messaging (`ReportCompletedConsumer`) | report finished → notify |
| `analytics.snapshot-ready` | analytics | (see service guide) | `SnapshotReadyEvent` — fleet metrics snapshot |
| `adoons.rule-suggestion.requested` | incident | ai (Adoons) | request AI rule suggestion (async pipeline) |
| `adoons.rule-suggestion.ready` | ai (Adoons) | incident (`RuleSuggestionResultConsumer`, group `hiveops-incident-adoons`) | AI rule suggestion result |
| `hiveops.agent.online` | remote | (see service guide) | agent registered/online (`AgentConnectionEvent`, keyed by `machineId`) |
| `hiveops.agent.offline` | remote | (see service guide) | agent marked stale/offline (timer-driven sweep) |
| `hiveops.aria.threats` | aria | aria | threat/IOC events |
| `hiveops.aria.sequences` | aria | aria | attack sequence events |
| `hiveops.aria.sequences` | aria | aria | attack-sequence events |
Confirmed consumers found in code: `hiveops-vault` (DeviceEventConsumer),
`hiveops-messaging` (MessageConsumer, ReportCompletedConsumer),
`hiveops-aria` (AriaKafkaConfig). The device_summary mirror set (incident/fleet/reports/recon) is
operationally established — the per-service guides will pin each consumer class.
> Note the two naming conventions in play: most topics are `hiveops.*`; the AI pipeline uses
> `adoons.*`; analytics uses a bare `analytics.snapshot-ready`. All are real — do not "normalise"
> them. Per-service producer/consumer classes are pinned in each `technical.<service>` guide.
## Key flows