> For the complete documentation index, see [llms.txt](https://energy-web-foundation.gitbook.io/ewc-validator-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://energy-web-foundation.gitbook.io/ewc-validator-documentation/guides/maintaining-a-validator-node/validator-node-architecture.md).

# Validator Node Architecture

The System architecture of a validator node on the Energy Web Chain is made up of two main components. (Note: the original node architecture featured a node control component, but it was never used and formally deprecated in 2020).&#x20;

![High-level Validator Node Architecture](/files/3Rru5hwp4ALYxhAIv30m)

&#x20;**Client**: The OpenEthereum or Nethermind client that connects the validator to the Energy Web Chain, collects transactions and proposes blocks according to the [AuRa consensus algorithm](https://openethereum.github.io/Aura.html). Read the documentation of the OpenEthereum client [here](https://openethereum.github.io/), and the Nethermind client [here](https://docs.nethermind.io/nethermind/ethereum-client/download-sources). <br>

**Telemetry**: There is a monitoring system on the validator node that uses Telegraf to securely send telemetry to an [InfluxDB](https://www.influxdata.com/) that is connected to [Grafana](https://grafana.com/) and the EWC Validator Data Warehouse & Dashboard. The use of telemetry is opt-in. Validators can disable it if they have their own monitoring system in place that allows for real time tracking of all relevant metrics.

Telemetry data includes:

* CPU usage of the host machine
* Memory usage of the host machine
* Disk usage of the host machine
* Number of connected peers
* List of visible P2P peers
* Current block (latest block synced by the node)
* Network latency to 3 different and major locations (e.g. cloudflare, google, amazon)
* Network throughput
* Network error rate
* Number of SSH keys for the host machine
* Service status for SSH, docker and the parity container
* SHA256 hashes of key system components/binaries
* Current chain specification file (or hash)

As this is sensitive data, we rely on well established industry solutions to transfer these metrics off the validator node. Telegraf is a server agent that plugs into many different services to collect data. Telegraf collects relevant metrics from the host machine and the custom-built parity metrics collector which allows Telegraf to receive the metrics from the parity client. For more information on Telegraf visit: <https://docs.influxdata.com/telegraf/v1.10/>

The collected metrics are then stored in an InfluxDB database and can be visualized using the monitoring tool Grafana. For more information on influxDB visit: <https://docs.influxdata.com/influxdb/v1.7/>

For more information on Grafana visit: <https://grafana.com/docs/>

The use of telemetry is opt-in. Validators can disable it if they have their own monitoring system in place that allows for real time tracking of all relevant metrics.<br>

All components are run in separate docker containers managed by docker compose. For additional information on docker visit: <https://docs.docker.com/> and <https://docs.docker.com/compose/>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://energy-web-foundation.gitbook.io/ewc-validator-documentation/guides/maintaining-a-validator-node/validator-node-architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
