Job queues (track B2)
The agent reads each job framework's own store (no change to the application, no exporter) and reports one shared metric family, so every framework feeds the same Queues page and alert pack shape. One agent module per framework; the module name is also the integration manifest (integrations/<name>/).
Metric contract (shared with the Queues page, track E)
Metric | Type | Labels | Meaning |
|---|---|---|---|
| gauge |
| Jobs per state. Standard states: |
| gauge |
| Seconds since the oldest waiting job became ready; 0 when nothing waits. Only where the store records the time. |
| gauge |
| Jobs held by a worker past the framework's lease (Laravel |
| gauge |
| Live worker processes; |
| counter |
| Only where the framework keeps counters. |
| gauge |
| 1 per healthy collection round, 0 when the store cannot be read. |
queue="*" marks a value the store keeps for all queues together (for example Sidekiq's retry and dead sets). Every series a queue ever had is written each round, as 0 when the store no longer reports it, so a drained queue reads 0 instead of going stale. At most 200 queues per module. The BullMQ module (bullmq_*) predates this family and keeps its own names.
Common settings: interval (default 30s), queues (filter, or the list itself where the store has none), stall_after. Credentials (dsn, addr/password, token) live only in the agent's own config file. Postgres sessions are read-only.
Each pack: backlog (waiting > 1000 for 10 min), oldest waiting job > 5 min (where the age exists), dead jobs rising (> 10 in 10 min), stalled jobs (where reported), no workers (where reported) and unreachable.
Frameworks
Module | Store | Reads | Settings |
|---|---|---|---|
| Postgres |
|
|
| Postgres |
|
|
| Postgres |
|
|
| Postgres |
|
|
| Postgres |
|
|
| Postgres |
|
|
| Postgres |
|
|
| Redis |
|
|
| Redis |
|
|
| Redis | per configured queue the list and its priority lists; |
|
| Redis |
|
|
| Redis | per configured queue |
|
| Redis | per configured queue |
|
| Redis |
|
|
| SQL Server |
|
|
| Faktory server |
|
|
| Temporal HTTP API |
|
|
Not covered
Throughput for SQL-backed frameworks (they keep no counters and counting finished rows scans history); use the SDK spans for rates there.
Celery and Dramatiq on RabbitMQ: their queues are RabbitMQ queues, read by the
rabbitmqmodule.Hangfire on Redis (Hangfire.Pro.Redis), Solid Queue on MySQL or SQLite, Que before 1.0, resque-scheduler's delayed jobs (stored per timestamp, not countable without a scan).
Per-queue active counts where the store keeps them only per process (Sidekiq
<process>:work, Resque workers); those reportqueue="*".