Monitoring your node

[refaktr]

I'm interested to learn what tools or processes other node operators use to monitor the general health of your node. What do you use to check how well it's running?

Obviously there's the standard infra metrics (CPU, memory, disk, network) that can become overloaded and cause issues or failures. What about node-specific metrics are of most interest to you? Clock drift, block number, services statuses?

I put together a simple web app to help check the status of a public node: https://refaktr.io/nodewatch

[LoyceV]

What do you use to check how well it's running?

The whole point of running a daemon is that I don't have to monitor all of them all the time My Bitcoin Core is doing just fine for many years now.

Obviously there's the standard infra metrics (CPU, memory, disk, network) that can become overloaded

For network, you can set an upload target (read: maximum). There's not really a reason for the rest to suddenly be overloaded, it's not as if Bitcoin is suddenly going to produce much more blocks to verify.

[ABCbits]

I'm interested to learn what tools or processes other node operators use to monitor the general health of your node. What do you use to check how well it's running?

I only use basic monitor tool for the whole system. But if i ever want to monitor both my system and node in detail, i probably would use https://github.com/jlopp/statoshi.

[satscraper]

In fact, the most critical element of any node is the storage medium. My node stores the blockchain on external SSD, so my main concerns are such SSD's parameters such as Wear Leveling Count and Reallocated Sectors Count, which I check periodically on  monthly basis. To be safe, I maintain two external SSDs with full copies of the blockchain, rotating my node’s connection between them each month.

[LoyceV]

my main concerns are such SSD's parameters such as Wear Leveling Count and Reallocated Sectors Count

May I ask why you're concerned about this? A full IBD on a system with low (8 GB) RAM writes several TB of data, which should be at most around 1% of what a modern SSD can handle. It's much less if you have more RAM, and the monthly addition should be only a fraction of a TB in writes. Wear Leveling is handled by the disk itself, so it doesn't need user attention either.

I maintain two external SSDs with full copies of the blockchain, rotating my node’s connection between them each month.

I prefer my lazy approach: in the rare event that the disks with my blocks fails, I'll just install a new disk and let it sync for a day

[satscraper]

my main concerns are such SSD's parameters such as Wear Leveling Count and Reallocated Sectors Count

May I ask why you're concerned about this? A full IBD on a system with low (8 GB) RAM writes several TB of data, which should be at most around 1% of what a modern SSD can handle. It's much less if you have more RAM, and the monthly addition should be only a fraction of a TB in writes. Wear Leveling is handled by the disk itself, so it doesn't need user attention either.

I just want to be at ease about my Samsung SSD. They may promise high endurance for the cells, but in reality it can be lower than advertised due to various technological and manufacturing factors. Even tiny uncontrolled contamination can affect semiconductor behavior. The striking case in point is some batches of Intel’s 13^th generation CPU, which may suddenly crash for no apparent reason.