mirror of
https://github.com/pezkuwichain/pezkuwi-telemetry.git
synced 2026-10-21 19:16:20 +00:00
Satoshi Qazi Muhammed
a4fbd9c061
Backend (Cargo.lock): openssl 0.10.55 -> 0.10.81, bytes 1.12.1, h2 0.3.27, tokio 1.26 -> 1.47.1 (mio 1.x), url 2.3.1 -> 2.5.7 (idna 1.1), rand 0.8.8, spin 0.9.9, time 0.3.55, ring 0.17.14. Three alerts needed manifest changes: - tokio-rustls 0.23 -> 0.26 (rustls 0.20 -> 0.23), which is what moves ring off 0.16. The ring provider is selected explicitly instead of the default aws-lc-rs, so the image build needs no cmake/C toolchain; roots still come from webpki-roots (now 1.0). Checked against live hosts: a valid certificate connects, an expired one and a name mismatch are refused. - maxminddb 0.23 -> 0.27: lookup() now returns a result that is decoded, and the City model's fields are no longer Options. The existing locate_random_ip test (12.5.56.25 -> "Gardena") passes. - structopt (clap 2, which pulled atty) -> clap 4 derive in telemetry_core, telemetry_shard and the soak tests; criterion 0.4 -> 0.5 for the same reason. Both binaries' arguments were parsed before and after for the docker-compose invocations and a set of other cases: identical results, except that `--feed-timeout` given without a value is now an error where structopt silently used the default. --denylist keeps taking every value up to the next flag (num_args = 1..), as its help text describes. Frontend: npm audit fix within ranges, and webpack-dev-server 4 -> 5.2.6 (no devServer options are configured, so nothing to migrate). Left: sockjs -> uuid 8 inside webpack-dev-server 5; the fix is 6.0, which needs Node 22 while CI runs 20, and it is the local dev server only. Checked: backend cargo test (58 passed), clippy, fmt; frontend lint, prettier, test and build.
Backend Crates
This folder contains the rust crates and documentation specific to the telemetry backend. A description of the folders:
- telemetry_core: The Telemetry Core. This aggregates data received from shards and allows UI feeds to connect and receive this information.
- telemetry_shard: A Shard. It's expected that multiple of these will run. Nodes will connect to Shard instances and send JSON telemetry to them, and Shard instances will each connect to the Telemetry Core and relay on relevant data to it.
- common: common code shared between the telemetry shard and core
- test_utils: Test utilities, primarily focused around making it easy to run end-to-end tests.
- docs: Material supporting the documentation lives here
Architecture
As we move to a sharded version of this telemetry server, this set of architecture diagrams may be useful in helping to understand the current setup (middle diagram), previous setup (first diagram) and possible future setup if we need to scale further (last diagram):
Deployment
A Dockerfile exists which builds the Shard and Telemetry Core binaries into an image. A docker-compose.yaml in the root of the repository can serve as an example of these services, along with the UI, running together.