Skip to main content

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) of max_latency
  • CRITICAL — latency at/past max_latency, or no message within max_latency plus 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)

Source distribution for arrakis-monitor 0.2.2
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)

Table of built distributions (wheels) for arrakis-monitor 0.2.2
File Interpreter ABI Platform Actions
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.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page