Metrics data and monitoring scenarios

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 HeapMemoryUsage attribute.
  • High memory usage - Monitor the SystemCpuLoad property 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.

Metrics data

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.