Mainnet Setup and Tooling
It's 🚀 time!
All of the hard work of the community has paid off, and now it's time to take the network live. Preparing your validator for mainnet involves a few extra considerations. They are detailed below, but a sensible checklist is:
- How will you handle chain upgrades?
- consider: Cosmovisor
- How will you know your node is up?
- consider: Monitoring and alerts
- How will you mitigate DDOS attacks?
- consider: Sentry Nodes
- How much storage will you need?
Answering these questions can be daunting, so there is some advice below.
Alerting and monitoring is desirable as well - you are encouraged to explore solutions and find one that works for your setup. Prometheus is available out-of-the box, and there are a variety of open-source tools. Recommended reading:
Using only the raw metrics endpoint provided by
junodyou can get a working dashboard and alerting setup using Grafana Cloud. This means you don't have to run Grafana on the instance.
- 1.First, in
config.tomlenable Prometheus. The default metrics port will be
- 2.Download Prometheus - this is needed to ship logs to Grafana Cloud.
- job_name: cosmops
- targets: ['localhost:26660']
- url: https://your-grafana-cloud-endpoint/api/prom/push
password: "API KEY HERE"
3. Set up a service file, with
sudo nano /etc/systemd/system/prometheus.service, replacing
<prometheus-folder>with the location of Prometheus. This sets the Prometheus port to
ExecStart=/home/<your-user>/<prometheus-folder>/prometheus --config.file=/home/<your-user>/<prometheus-folder>/prometheus.yml --web.listen-address=:6666 --storage.tsdb.path=/home/<your-user>/<prometheus-folder>/data
4. Enable and start the service.
sudo -S systemctl daemon-reload
sudo -S systemctl enable prometheus
sudo systemctl start prometheus
5. Import a dashboard to your Grafana. Search for 'Cosmos Validator' to find several options. You should see logs arriving in the dashboard after a couple of minutes.
A simple node dashboard example
For more info:
The current best practice for running mainnet nodes is a Sentry Node Architecture. There are various approaches, as detailed here. Some validators advocate co-locating all three nodes in virtual partitions on a single box, using Docker or other virtualisation tools. However, if in doubt, just run each node on a different server.
Disk space is likely to fill up, so having a plan for managing storage is key.
If you are running sentry nodes:
- 1TB storage for the full node will give you a lot of runway
- 200GB each for the sentries with pruning should be sufficient
Managing backups is outside the scope of this documentation, but several validators keep public snapshots and backups.
It is anticipated that state-sync will soon work for wasm chains, although it does not currettly.
To give you an idea of cost, on AWS EBS (other cloud providers are available, or you can run your own hardware), with two backups a day, this runs to roughly:
- $150 for 1TB
- $35 for 200GB
- Total cost: $220
What approach you take for this will depend on whether you are running on physical hardware co-located with you, running in a data centre, or running on virtualised hardware.