> For the complete documentation index, see [llms.txt](https://svpchain.gitbook.io/svpchain-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://svpchain.gitbook.io/svpchain-docs/chain/monitoring.md).
# Monitoring
Metrics, logs, and alerts for SVPChain nodes and validators.
A node that you don't watch will fail silently. The cheapest insurance is a Prometheus scrape and three alerts: **am I syncing**, **do I have peers**, **am I out of disk**. For validators, add a fourth: **am I signing blocks**.
### Metrics endpoints
| Endpoint | Source | Default | Notes |
| --------------------------- | ----------- | -------- | ------------------------------------------------------------------------ |
| Prometheus (CometBFT + app) | `svpchaind` | `:26660` | Enable in `config.toml` under `[instrumentation]` (`prometheus = true`). |
| EVM JSON-RPC metrics | `svpchaind` | `:6065` | Enable in `app.toml` under `[json-rpc] metrics-address`. |
| Slinky oracle (validators) | sidecar | `:8001` | Set via `prometheus_server_address` in `app.toml [oracle]`. |
| Node exporter | host | `:9100` | Standard Prometheus host metrics — install separately. |
### Enable in `config.toml`
```toml
[instrumentation]
prometheus = true
prometheus_listen_addr = ":26660"
```
Then reload: `sudo systemctl restart svpchaind`.
### Key signals
**Liveness**
* `cometbft_consensus_height` — block height the node has committed. Should match the network tip.
* `cometbft_p2p_peers` — connected peer count. Below 3–5 is a problem.
* `cometbft_consensus_validator_missed_blocks` (validators only) — increases mean you're missing pre-commits.
**Resource**
* Disk free on the data directory (`~/.svpchain/data/`).
* CPU utilization — sustained > 80% on the node process means you can't keep up with block execution.
* `process_open_fds` vs `LimitNOFILE` — if it climbs toward the limit, raise `LimitNOFILE` in the systemd unit.
**Latency**
* `eth_blockNumber` HTTP latency, sampled by your RPC clients (Blackbox exporter, or a tiny external probe).
* WebSocket reconnect rate.
### Minimum viable alerts
| Alert | Condition | Why |
| -------------------------------- | ----------------------------------------- | --------------------------------------------------- |
| Node not syncing | `latest_block_height` unchanged for > 30s | Stuck consensus, peer issue, or a panicked process. |
| Low peer count | `peers < 3` for 5m | About to lose head visibility. |
| Disk filling | `disk_free < 10%` | The chain doesn't pause politely when you run out. |
| Validator missing blocks | missed > 0 in last 100 | Approaching downtime jail thresholds. |
| Slinky sidecar down (validators) | container not running for > 60s | Invalid vote extensions → jail. |
{% hint style="info" %}
Alert on **symptoms**, not every metric. A one-page dashboard with the five graphs above plus a clear "node OK / node NOT OK" status beats a 40-panel dashboard nobody reads.
{% endhint %}
### Logs
```bash
sudo journalctl -u svpchaind -f # node
docker logs -f slinky # oracle sidecar (validators)
```
For long-term retention, ship `journalctl` output to your log store (Loki, Elasticsearch, etc.). The signal-to-noise ratio in `svpchaind` logs is decent — `ERR` and `WRN` lines are usually actionable.
### Validator-specific watchpoints
* **Double-sign protection.** Never run two nodes with the same `priv_validator_key.json`. If you migrate hardware, stop the old node, copy the key, *then* start the new node — and verify the old service can't restart.
* **Signing health.** Track your validator's address in `cometbft_consensus_validator_missed_blocks`. A persistent uptick means missed pre-commits — investigate before you hit jail thresholds.
* **Slinky liveness.** A bonded validator without Slinky produces invalid vote extensions and gets jailed quickly. Alert on the sidecar container's `Status`.
### Next steps
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://svpchain.gitbook.io/svpchain-docs/chain/monitoring.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.