Node monitoring and observability
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. An experimental implementation exposes basic node status and metrics surfaces for internal use, and an experimental finality status query exists but reports nothing as final, because the finality component is not yet connected. Broader monitoring, alerting and service-level objectives are planned with no values published; the existing surfaces are not production monitoring, and nothing is publicly available for live use.
Before you read: Operating a node: intended roles and what exists today.
What could an operator observe about a node’s health and status? This page explains the main observability concepts, states which experimental surfaces exist and what they do not offer, describes what is planned, notes that monitoring data can itself reveal activity, and distinguishes node monitoring from querying network data. It gives no metric names, interface details, thresholds or objective values.
What observability means for an operator
Observability is being able to understand a node’s condition from what it reports. Five concepts recur on this page:
- Health — whether a node is running and responding.
- Status — where a node is in its work, such as what it has recorded so far.
- Metrics — counts and measurements collected over time, used to spot trends and problems.
- Alerts — notifications that something needs attention.
- Service-level objectives — stated targets for how a service should behave, used to judge whether it is healthy.
Each answers a different question. Health tells an operator whether something is wrong now; status shows how far along the node is; metrics reveal trends that a single reading would miss; alerts bring a problem to someone’s attention without anyone having to watch continuously; and objectives give a yardstick for deciding whether the service is behaving well enough. A service-level objective is not the same as a service level, which is the treatment an application would request for its transactions; see Service levels and admission control.
What exists today
Experimental implementation exists — internal only.
- An experimental implementation exposes basic node status and metrics surfaces.
- No particular metric is documented as available, so none is listed here. Do not assume that any specific measurement exists or carries meaningful values.
- An experimental finality status query exists, but it reports nothing as final, because the finality component is not yet connected. See Agreement and finality status.
- These surfaces are internal. They are not production monitoring, and they are not publicly reachable.
What is planned
Planned.
- Broader operational monitoring and alerting are planned.
- Service-level objectives are planned. No objective values are published, and no measurements are published to compare them with.
- What would be monitored, and how objectives would be set, is not described.
Monitoring and what it can reveal
Monitoring data describes activity, so it can itself reveal information about what a node is doing, such as how much work it is handling and when. Limiting what activity reveals is part of the wider concern described on What remains observable: the design acknowledges that some protocol metadata remains observable even with confidential execution, and is exploring ways to bound and reduce it.
- Who could access monitoring surfaces, and how that access would be controlled, is not described.
- Operators would need to protect monitoring data with the same care as their other operational data, because it describes their node’s activity.
Node monitoring compared with querying network data
Three views of the network are easy to confuse. They answer different questions for different readers.
Table: node monitoring, network queries and finality status compared.
| View | Whose view | Question it answers | Status today |
|---|---|---|---|
| Node monitoring | The operator’s view of one node | What condition is this node in? | Basic status and metrics surfaces, internal only |
| Querying network data and browsing activity | The developer’s and user’s view | What has the network recorded? | Experimental interfaces for internal testing only; data is neither final nor confidential |
| Finality status | An application’s view of a result | Can this result still change? | An experimental query reports nothing as final; the finality component is not yet connected |
A healthy node is not the same thing as a final result: monitoring could show that a node is running and recording transactions while nothing it has recorded is final.
What operators would plan for
Planned. Once node software is released:
- Operators would decide which signals to watch and how they want to be alerted. Supported surfaces and guidance would accompany a release.
- No thresholds, dashboards, runbooks or objective values are published, and none should be inferred from this page.
- Monitoring would support other operational work, such as noticing when recovery is needed and recognising an incident early. See Deployment, backup and recovery: what operators would plan for and Emergency controls and protocol safeguards.
Assumptions, trust and limitations
- The experimental surfaces are basic and internal, and they may change.
- They are not evidence of how a released node would perform. No performance figures are published.
- Statements on this page describe the state of development as of the page’s date.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once supported node software exists, this page would describe the supported monitoring surfaces at the level approved for publication and link to versioned reference. If service-level objectives are published, they would accompany a release together with their scope. Status changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- any metric name, interface detail, threshold or objective value;
- that production monitoring or alerting exists;
- that any finality data is available: nothing is reported as final.
Anything not stated here as available should be treated as unavailable.
Related pages
- Operating a node: intended roles and what exists today — where monitoring fits among operator responsibilities.
- Agreement and finality status — the finality status query and why it reports nothing as final.
- Deployment, backup and recovery: what operators would plan for — operational concerns that monitoring would support.
- Querying network data and browsing activity — the developer’s view of recorded network data.
- What remains observable — why monitoring data can itself reveal activity.
- Service levels and admission control — service levels, as distinct from service-level objectives.
Glossary
References
No approved public references yet.
