Managing The Validator

This page describes the regular tasks that you may need to do, as a node runner.

Handling Upgrades

Within the Cosmos ecosystem, upgrades are divided into two types: one that increments the chain-id version, and one that does not. The former set is more manual; the latter is fairly automated.

Note: The option you choose is dependent on the type of upgrade required by the network.

Option 1: Upgrade with chain-id edit

  1. Initialize a new node with the increased chain-id at a new location (for example exocoretestnet_233-3 becomes exocoretestnet_233-4) and configure it. Make sure to re-use the same validator private key ($HOMEDIR/config/priv_validator_key.json) or provide the mnemonic via --recover during the new initialization.

  2. Modify the systemd service to use the provided --halt-height or --halt-time so that all v3 nodes stop at the same time.

  3. Once the network is halted, obtain the new genesis file from the team and add it to the v4 folder. Additionally, upgrade the binary.

  4. Edit the systemd service to point to the v4 folder and remove the --halt parameters

  5. Restart the service

Option 2: Upgrade without chain-id edit

  1. Edit the systemd service with the specified --halt-height or --halt-time.

  2. Once the network is halted, remove the --halt parameters from the systemd file and upgrade the binary.

  3. Restart the service.

This process can be automated with Cosmovisor.

Monitoring Uptime

Enable Prometheus metrics in the configuration by editing $HOMEDIR/config/app.toml

[telemetry]
enabled = true
prometheus-retention-time = 0

Set up a Prometheus instance to scrape the metrics exposed by your node.

scrape_configs:
  - job_name: 'exocored'
    static_configs:
      - targets: ['localhost:26660']

Visualize these with Grafana by using its dashboards. Metrics include:

  • cometbft_consensus_latest_block_height: The latest block height

  • cometbft_consensus_block_syncing: Whether the node is synced or still catching up.

  • cometbft_consensus_block_interval_seconds: Time between blocks, useful for monitoring block production delays.

In addition, system level information can be loaded with prometheus-node-exporter into Grafana to complement the metrics exposed by exocored.

Lastly, third-party monitoring services such as ping.pub may be used when they add support for Exocore.

Useful Commands

PreviousBecoming a ValidatorNextSecurity Best Practices

Last updated