Metrics data and monitoring
You can monitor the metrics data from your node for a variety of reasons, and in different ways. Some suggested scenarios for monitoring are:
- Risk of out of memory error - Monitor the used memory in your node’s
- High CPU usage - Monitor the
SystemCpuLoadproperty of your node, to check for high CPU measurements.
- High flow error rate - Check for repeated errors in the flows being used on your node. Flows are the way CorDapps perform their functions, if there is a high level of errors, there may be either an issue with your node, or a bug in the CorDapp or flow itself.
- Network parameter update proposal not accepted - Check to see whether network parameters that you or another party has proposed to the Network Map have yet been accepted. The updates could still be awaiting approval.
- Processing messages takes too long - Measure the time taken for Peer to Peer (P2P) messaging to be processed. If there is a high latency, you can choose to flag this as an error.
- Committing transactions time - Measure how long it takes to commit an executed action on the network.
- Signing transactions time - Where a signature is required for a transaction, you can measure the time being taken for this to be completed.
You can see a complete list, and guidance on monitoring specific scenarios in the Monitoring scenarios docs.
A Corda node exports a number of metrics for the purpose of monitoring the health of the node via JMX.
You can get metrics for your node from these key sources:
- Caches - A Corda node maintains a number of caches. For each of the metrics below, the name of the cache must be supplied in the component field to show metrics for that cache.
- Flows - Flow metrics can be used to measure key data about the activity on your node. Metrics include the total number of flows in flight at a given time, the total number of completed flows, and the total number of flows that failed with an error.
- Actions - Actions are reified IO actions to execute as part of state machine transitions. These metrics are only exposed when the relevant action gets executed for the first time.
- Metering - Metering metrics can be used to get an overview of the performance of commands that are persisted, the number of persisted signing events, the length of a queue of events waiting to be persisted, and more.
- P2P - Messaging between parties can be measured in a number of ways, including metrics for latency between messages being sent and received between nodes, the size of sent messages, the interval between received P2P messages.
- Other metrics - Measure the tine taken to sign a transaction or check whether proposed network parameter updates have been accepted yet.
Take a look at the Node metrics documentation for a complete range of the metrics data available from your node.
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.