AI Ingestion
System Health
The Parallel Ledger is designed to be a "good citizen" within your existing infrastructure. We defer complex alerting and visualization to the Partner Gateway or your organization's standard observability stack to ensure the Ledger remains a decoupled, high-integrity state machine.
Monitoring Philosophy
We prioritize raw signal over proprietary dashboards. For this release, we expect operators to monitor the Ledger host using standard systems-level telemetry.
I/O & Storage
Monitor Disk Wait and IOPS on the PostgreSQL volume. Sustained high latency in the WAL (Write-Ahead Log) is the primary indicator of throughput bottlenecks.
Process Health
The Ledger runs on the Erlang BEAM VM. Standard process monitoring should ensure the service remains active; the VM's internal scheduler will manage CPU distribution across available cores.
Database Connectivity
Track the Connection Pool saturation. If TPL_POOL_SIZE is consistently exhausted, check for long-running locks or unoptimized maintenance tasks.
Future Telemetry Roadmap
We are currently evaluating the most efficient method for exposing internal protocol metrics. Our goal is to provide high-resolution data without impacting the performance of the witness relay.
Planned: State Machine Statistics
Future builds will include a dedicated telemetry endpoint (likely via Prometheus Exporter) to track:
- updates_per_second
- blocks_witnessed_count
- last_block_hash_latency
- dictionary_cache_hit_ratio
Operator Feedback
As an implementer, your observations are vital to our calibration. If your environment requires specific OpenTelemetry spans or custom GenServer-based polling intervals to satisfy local audit requirements, please coordinate with your technical representative.
System Health
The Parallel Ledger is designed to be a "good citizen" within your existing infrastructure. We defer complex alerting and visualization to the Partner Gateway or your organization's standard observability stack to ensure the Ledger remains a decoupled, high-integrity state machine.
Monitoring Philosophy
We prioritize raw signal over proprietary dashboards. For this release, we expect operators to monitor the Ledger host using standard systems-level telemetry.
I/O & Storage
Monitor Disk Wait and IOPS on the PostgreSQL volume. Sustained high latency in the WAL (Write-Ahead Log) is the primary indicator of throughput bottlenecks.
Process Health
The Ledger runs on the Erlang BEAM VM. Standard process monitoring should ensure the service remains active; the VM's internal scheduler will manage CPU distribution across available cores.
Database Connectivity
Track the Connection Pool saturation. If TPL_POOL_SIZE is consistently exhausted, check for long-running locks or unoptimized maintenance tasks.
Future Telemetry Roadmap
We are currently evaluating the most efficient method for exposing internal protocol metrics. Our goal is to provide high-resolution data without impacting the performance of the witness relay.
Planned: State Machine Statistics
Future builds will include a dedicated telemetry endpoint (likely via Prometheus Exporter) to track:
- updates_per_second
- blocks_witnessed_count
- last_block_hash_latency
- dictionary_cache_hit_ratio
Operator Feedback
As an implementer, your observations are vital to our calibration. If your environment requires specific OpenTelemetry spans or custom GenServer-based polling intervals to satisfy local audit requirements, please coordinate with your technical representative.