RNS Monitoring Agent
Find a file
2025-07-17 21:27:21 +01:00
.github/workflows Add linting actions (#2) 2025-05-29 17:36:57 +01:00
response_examples add support for transport node client interfaces, rnode stats 2025-05-18 12:05:15 +01:00
src/rnmon Add linting actions (#2) 2025-05-29 17:36:57 +01:00
.gitignore update gitignore 2025-05-14 02:24:58 +01:00
.python-version Initial exploratory commit 2025-05-10 13:35:55 +01:00
docker-compose.yaml Add Container image and github actions (#1) 2025-05-29 17:19:01 +01:00
Dockerfile Add linting (#3) 2025-05-29 19:23:11 +01:00
LICENSE Add Container image and github actions (#1) 2025-05-29 17:19:01 +01:00
pyproject.toml bump version for RNS 1.0.0 2025-07-17 21:27:21 +01:00
README.md Add Container image and github actions (#1) 2025-05-29 17:19:01 +01:00
scraping.yaml.example add support for transport node client interfaces, rnode stats 2025-05-18 12:05:15 +01:00
uv.lock add LICENSE 2025-05-26 17:24:30 +01:00

RNMon - Reticulum Application Monitoring Daemon

RNMon is a simple monitoring daemon designed to monitor the status of multiple RNS applications and push the metrics over http using the influx line protocol.

Supported Applications

  • Reticulum Transport Nodes (Also some metrics for non transport nodes)
  • LXMF Propagation Nodes

Installing

Package

The package is available in PyPI, install it with your python package manager of choice.

I recommend using uv since it cleanly manages an environment if you run or install it as a tool:

Execute it simply: uvx rnmon

Install it globally (but in its own environment): uv tool install rnmon and run rnmon

Container

There is a container image available at ghcr.io/lbataha/rnmon. You can use the latest tag, or specify the version matching the git tag you want, there are also image builds available in github actions.

The repo contains a Dockerfile and an example docker-compose.yml, but you can run it simply with:

docker run --name rnmon -v /path/to/config:/config ghcr.io/lbataha/rnmon:latest

Configuration

Configure the daemon via scraping.yaml, the example config has comments explaining the options.

The configuration for reticulum is auto-discovered, but you can specify the location of the configuration directory using the --rns-config argument.

Operational principles

The metric pusher and all targets are executed in their own thread. The main thread starts a new RNS instance, and closes it on exit.

A link is established for each scrape target to reduce network overhead. If a link is broken for any reason, the thread is terminated and restarted - this avoids having to deal with the built-in RNS link retry mechanisms, their associated timeouts and any edge cases caused by using shared RNS intances. This might be changed in the future if RNS fixes the issues particular to this use case.