arrakis-monitor
HTTP health sidecar for Arrakis Flight servers.
Overview
arrakis-monitor runs alongside each Arrakis server and exposes its health
status over HTTP, allowing standard monitoring tools (Nagios/Icinga via NRPE +
check_http) to check gRPC Flight servers without needing a gRPC-native plugin.
Installation
pip install arrakis-monitor
Usage
# basic health sidecar
arrakis-monitor --server grpc://localhost:31206
# with scope map domain validation
arrakis-monitor --server grpc://localhost:31206 --expect-domains H1,L1,V1
# with publisher liveliness/latency checks (online servers)
arrakis-monitor --server grpc://localhost:31206 --check-publishers
# custom bind address
arrakis-monitor --server grpc://localhost:31206 --host 127.0.0.1 --port 9090
Endpoints
| Endpoint | Description |
|---|---|
GET / |
Show server configuration |
GET /health |
Run a health check (calls server_info()) |
GET /scope-map |
Run a scope map check (calls scope_map()) |
GET /publishers |
Probe every publisher in the scope map (--check-publishers) |
GET /publishers/{publisher} |
Probe a single publisher (--check-publishers) |
Health and scope-map endpoints return JSON with an HTTP status code:
- 200 — OK or WARNING
- 503 — CRITICAL (server unreachable or scope map empty)
- 500 — UNKNOWN (unexpected error)
Response format
Both check endpoints include a latency_s field measuring the gRPC call
round-trip time in seconds:
{
"status": "ok",
"message": "Server 0.12.0 (kafka)",
"version": "0.12.0",
"backend": "kafka",
"domains": ["H1", "L1"],
"capabilities": ["find", "count", "describe", "stream"],
"latency_s": 0.042
}
Publisher checks
On online (Kafka-backed) servers, --check-publishers enables
per-publisher liveliness and latency monitoring. For each publisher
tagged in the server's scope map, the sidecar consumes the publisher's
metadata topic from the local broker to select a surrogate channel,
then probes the data topic for that channel's partition, waiting for a
fresh message. The block-time latency of the freshest record batch is
compared against the max_latency advertised in the channel metadata:
- OK — fresh data arrived within the latency budget
- WARNING — latency within
--publisher-warn-margin(default 1 s) ofmax_latency - CRITICAL — latency at/past
max_latency, or no message withinmax_latencyplus one block stride (reported with the age of the last retained message)
/publishers probes every publisher concurrently and reports the
worst status; /publishers/{publisher} probes one, for fine-grained
per-publisher alerting. Publishers registered in the scope map ahead
of going live would keep the aggregate check CRITICAL, so list them
with --ignore-publisher — /publishers skips them (reporting them
under ignored) while /publishers/{publisher} still probes them on
request. A server's scope map may describe every endpoint at its site;
pass --scope-endpoint with the URL the scope map uses for this
server so /publishers covers only its own publishers. Surrogate resolution is cached per publisher
(--metadata-ttl, default 600 s), and check results are cached
briefly (--probe-cache-ttl, default 60 s) so aggregate and
per-publisher checks polling around the same time share one probe —
a shared result carries its age in a cached_age_s field.
Options:
| Flag | Default | Description |
|---|---|---|
--check-publishers |
off | Enable publisher checks |
--bootstrap-servers |
localhost:9092 |
Kafka bootstrap server(s) |
--publisher-warn-margin |
1 |
Warn within this many seconds of max_latency |
--publisher-max-latency |
30 |
Fallback budget when metadata has no max_latency |
--probe-timeout |
30 |
Cap on waiting for a data message per probe |
--metadata-ttl |
600 |
Seconds to cache surrogate resolution |
--probe-cache-ttl |
60 |
Seconds to serve cached probe results (0 disables) |
--surrogate PUB=CHANNEL |
auto | Explicit surrogate channel (repeatable) |
--ignore-publisher PUB |
none | Skip a publisher in /publishers, e.g. one registered ahead of going live (repeatable) |
--scope-endpoint URL |
all | Scope map endpoint whose publishers /publishers checks |
{
"status": "ok",
"message": "Publisher 'H1_lldd' live (latency 3.2s)",
"publisher": "H1_lldd",
"channel": "H1:AOS-ETMX_BAFFLEPD_1_DC_POWER",
"replay_id": null,
"max_latency_s": 12.0,
"warn_latency_s": 11.0,
"latency_s": 3.2,
"transport_latency_s": 0.05,
"block_time_gps": 1400000000.0
}
NRPE Integration
Each Arrakis host runs the sidecar locally, and NRPE executes check_http
against the sidecar's port. The -w and -c flags set warning and
critical thresholds on the HTTP response time (in seconds). When the
Arrakis hosts are not reachable from the monitoring server, the commands
can live on an NRPE gateway host on the same network instead, targeting
each host by name:
# health check (warn at 2s, critical at 5s)
command[check_arrakis]=/usr/lib64/nagios/plugins/check_http -H <host> -p 8080 -u /health -w 2 -c 5
# scope map validation (info servers only)
command[check_arrakis_scope_map]=/usr/lib64/nagios/plugins/check_http -H <host> -p 8080 -u /scope-map -w 2 -c 5
# publisher liveliness/latency, every publisher at once (online servers
# with --check-publishers); probes wait for live data, so allow more
# response time than the other checks
command[check_arrakis_publishers]=/usr/lib64/nagios/plugins/check_http -H <host> -p 8080 -u /publishers -w 10 -c 30 -t 40
# per-publisher liveliness/latency, one command per publisher
command[check_arrakis_publisher_<publisher>]=/usr/lib64/nagios/plugins/check_http -H <host> -p 8080 -u /publishers/<publisher> -w 10 -c 30 -t 40
Publisher probes can wait up to --probe-timeout (30 s) for live data,
so the NRPE client needs a matching timeout in place of its 10 s
default (check_nrpe -t 45, or vars.nrpe_timeout = 45 on the Icinga
service).
Resources
Metadata
Release files for arrakis-monitor 0.2.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| arrakis_monitor-0.2.2.tar.gz | 208.0 kB | Without provenance | Details for arrakis_monitor-0.2.2.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| arrakis_monitor-0.2.2-py3-none-any.whl | Python 3 | none | any | Details for arrakis_monitor-0.2.2-py3-none-any.whl |
Total release size: 249.9 kB
Release files / arrakis_monitor-0.2.2.tar.gz
| Download URL | arrakis_monitor-0.2.2.tar.gz |
|---|---|
| Size | 208.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c3f01a1bb0138813fac79b5c386767edffac33f9c932800df10e5ea7ce289710
|
|
BLAKE2b-256 checksum How to use checksums |
07f3c6326210f417610a13fc35f22ee9cbcc55f6ea3cf251566a9463c17b4676
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
Hatch/1.16.5 cpython/3.13.12 HTTPX/0.28.1
|
Release files / arrakis_monitor-0.2.2-py3-none-any.whl
| Download URL | arrakis_monitor-0.2.2-py3-none-any.whl |
|---|---|
| Size | 41.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
ed5ae3bb5098ffb715a941bed65815a46fd6d2e0c5c1a97e3a7bdb2d22ad5474
|
|
BLAKE2b-256 checksum How to use checksums |
81e5ecbc2131bb3e12859e5d90a27439d3212cc9b3eb0e989478af1c40b6c925
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
Hatch/1.16.5 cpython/3.13.12 HTTPX/0.28.1
|
Security for arrakis-monitor 0.2.2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.