GRIN/nym
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update NM readme, fmt

Browse Source
This commit is contained in:
durch
2025-05-19 16:42:37 +02:00
parent 3be9e06bef
commit 8d8ce29113
2 changed files with 111 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
nym-api/src/support/storage/manager.rs
+24 -6
View File
@@ -12,9 +12,9 @@ use crate::support::storage::DbIdCache;
use nym_mixnet_contract_common::{EpochId, IdentityKey, NodeId};
use nym_types::monitoring::{NodeResult, RouteResult};
use sqlx::FromRow;
use std::collections::HashMap;
use time::{Date, OffsetDateTime};
use tracing::info;
use std::collections::HashMap;
#[derive(Clone)]
pub(crate) struct StorageManager {
@@ -106,7 +106,11 @@ impl StorageManager {
for corrected_node_info in corrected_reliabilities {
// Check if this node_id is a mixnode by attempting to fetch its identity key as a mixnode.
// This relies on get_mixnode_identity_key returning Some for mixnodes and None (or error) for non-mixnodes.
if self.get_mixnode_identity_key(corrected_node_info.node_id).await?.is_some() {
if self
.get_mixnode_identity_key(corrected_node_info.node_id)
.await?
.is_some()
{
avg_mix_reliabilities.push(AvgMixnodeReliability {
mix_id: corrected_node_info.node_id,
value: Some(corrected_node_info.reliability as f32),
@@ -131,8 +135,13 @@ impl StorageManager {
for corrected_node_info in corrected_reliabilities {
// Check if this node_id is a gateway.
if self.get_gateway_identity_key(corrected_node_info.node_id).await?.is_some() {
let total_samples = corrected_node_info.pos_samples_in_interval + corrected_node_info.neg_samples_in_interval;
if self
.get_gateway_identity_key(corrected_node_info.node_id)
.await?
.is_some()
{
let total_samples = corrected_node_info.pos_samples_in_interval
+ corrected_node_info.neg_samples_in_interval;
let reliability_value = if total_samples <= 3 {
100.0 // Default to 100% if 3 or fewer samples
} else {
@@ -1421,7 +1430,15 @@ impl StorageManager {
Ok(db_routes
.into_iter()
.map(|r| (r.layer1 as NodeId, r.layer2 as NodeId, r.layer3 as NodeId, r.gw as NodeId, r.success.unwrap_or_default()))
.map(|r| {
(
r.layer1 as NodeId,
r.layer2 as NodeId,
r.layer3 as NodeId,
r.gw as NodeId,
r.success.unwrap_or_default(),
)
})
.collect())
}
@@ -1491,7 +1508,8 @@ impl StorageManager {
// Attempt to fetch identity, first as mixnode, then as gateway if not found.
// This assumes get_mixnode_identity_key and get_gateway_identity_key return Result<Option<String>, sqlx::Error>
let mut identity: Option<String> = self.get_mixnode_identity_key(node_id).await.unwrap_or(None);
let mut identity: Option<String> =
self.get_mixnode_identity_key(node_id).await.unwrap_or(None);
if identity.is_none() {
identity = self.get_gateway_identity_key(node_id).await.unwrap_or(None);
}
nym-network-monitor/README.md
+87
View File
@@ -4,6 +4,14 @@ Monitors the Nym network by sending itself packages across the mixnet.
Network monitor is running two tokio tasks, one manages mixnet clients and another manages monitoring itself. Monitor is designed to be driven externally, via an HTTP api. This means that it does not do any monitoring unless driven by something like [`locust`](https://locust.io/). This allows us to tailor the load externally, potentially distributing it across multiple monitors.
## Features
- **Continuous Monitoring**: Periodically sends test packets through the network
- **Node Performance**: Tracks individual node reliability metrics
- **Route Performance**: Records route-level success rates through specific node combinations
- **Multi-API Submission**: Capable of submitting metrics to multiple API endpoints (fanout)
- **Force Routing**: Can force packets through all mixnet nodes for comprehensive testing
### Client manager
On start network monitor will spawn `C` clients, with 10 being the default. Random client is dropped every `T`, defaults to 60 seconds, and a new one is created. Clients chose a random gateway to connect to the mixnet. Meaning that on average all gateways will be tested in `NUMBER_OF_GATEWAYS/N*T`, assuming at least one request per client per T.
@@ -40,8 +48,87 @@ Options:
-m, --mixnet-timeout <MIXNET_TIMEOUT> [default: 10]
--generate-key-pair
--private-key <PRIVATE_KEY>
--database-url <DATABASE_URL> SQLite database URL
--nym-apis <NYM_APIS> Comma-separated list of Nym API URLs
-h, --help Print help
-V, --version Print version
```
## Metrics Collection & Reporting
### Node Metrics
The Network Monitor tracks performance metrics for individual nodes:
- **Reliability**: Percentage of successful packet handling
- **Failure Sequences**: Tracking consecutive failures
- **Volume**: Number of packets handled
### Route Metrics
Since version 1.1.0, the Network Monitor also tracks route-level metrics:
- **Route Success Rates**: Tracking which specific combinations of nodes have successful packet delivery
- **Layer Analysis**: Identifying weak points in specific network layers
- **Path Correction**: Improved algorithms for attributing failures to specific nodes
### Metrics Fanout
The Network Monitor can submit metrics to multiple API endpoints simultaneously:
1. Metrics are collected during each monitoring cycle
2. The collected metrics are submitted to each configured API endpoint
3. This provides redundancy and allows for distributed metrics collection
To enable metrics fanout, use the `--nym-apis` parameter with a comma-separated list of API URLs:
```bash
cargo run -p nym-network-monitor -- --nym-apis https://api1.example.com,https://api2.example.com
```
## Route Data Structure
Route metrics use the following data structure:
```rust
// Route performance data
pub struct RouteResult {
pub layer1: u32, // NodeId of layer 1 mixnode
pub layer2: u32, // NodeId of layer 2 mixnode
pub layer3: u32, // NodeId of layer 3 mixnode
pub gw: u32, // NodeId of gateway
pub success: bool, // Whether the packet was successfully delivered
}
```
## Forced Routing
To ensure comprehensive testing of all nodes in the network, the Monitor supports forcing packets through all available nodes:
- Each node is assigned to a specific layer (1, 2, or 3) deterministically
- This ensures all nodes participate in route testing
- The routing algorithm cycles through all possible node combinations
Since version 1.1.0, Network Monitor automatically forces all available nodes to be active and distributes them evenly across the three layers (Layer 1, Layer 2, and Layer 3). This ensures every node in the network participates in testing, providing more comprehensive coverage and better metrics for all nodes, not just the popular ones.
## Node Performance Calculation
The Network Monitor uses a sophisticated algorithm for attributing failures to specific nodes:
1. For successful packet deliveries, all nodes in the path receive a positive sample
2. For failed deliveries:
- Nodes with more than 2 consecutive failures are considered "guilty"
- If no node is clearly guilty, all nodes in the path receive negative samples
3. Final node reliability is calculated as: positive_samples / (positive_samples + negative_samples)
## Changelog
### Version 1.1.0
- Added route-level metrics tracking and submission
- Implemented metrics fanout to multiple API endpoints
- Forced routing through all available nodes for comprehensive testing
- Improved reliability corrections with consecutive failure tracking
- Updated data structures for better metrics organization
### Version 1.0.2
- Initial public release with basic monitoring capabilities