gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-07-03 12:54:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Markdown linter (#5494)

Browse Source 
* linter

* Add markdown linter

* add env

* only check markdown

* Add token

* Update .github/workflows/test-suite.yml

* Markdown linter

* Exit code

* Update script

* rename

* mdlint

* Add an empty line after end of file

* Testing disable

* add text

* update mdlint.sh

* ori validator inclusion

* Add config yml file

* Remove MD041 and fix advanced-datadir file

* FIx validator inclusion file conflict

* Merge branch 'unstable' into markdown-linter

* change files

* Merge branch 'markdown-linter' of https://github.com/chong-he/lighthouse into markdown-linter

* mdlint

* Remove MD025

* Remove MD036

* Remove MD045

* Removr MD001

* Set MD028 to false

* Remove MD024

* Remove MD055

* Remove MD029

* Remove MD040

* Set MD040 to false

* Set MD033 to false

* Set MD013 to false

* Rearrange yml file

* Update mdlint.sh and test

* Test remove fix

* Test with fix

* Test with space

* Fix summary indentation

* Test mdlint.sh

* Update mdlint.sh

* Test

* Update

* Test fix

* Test again

* Fix

* merge into check-code

* Update scripts/mdlint.sh

Co-authored-by: Mac L <mjladson@pm.me>

* Update scripts/mdlint.sh

Co-authored-by: Mac L <mjladson@pm.me>

* Remove set -e

* Add comment

* Merge pull request #7 from chong-he/unstable

Merge unstable to markdown branch

* mdlint

* Merge branch 'unstable' into markdown-linter

* mdlint
This commit is contained in:
chonghe
2024-05-24 10:45:19 +08:00
committed by GitHub
parent 7073242ccc
commit 3070cb7c39
68 changed files with 720 additions and 637 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
book/src/validator-monitoring.md
View File

@@ -20,7 +20,6 @@ Lighthouse performs validator monitoring in the Beacon Node (BN) instead of the
- Users can use a local BN to observe some validators running in a remote location.
- Users can monitor validators that are not their own.
## How to Enable Monitoring
The validator monitor is always enabled in Lighthouse, but it might not have any enrolled
@@ -57,7 +56,8 @@ Monitor the mainnet validators at indices `0` and `1`:
```
lighthouse bn --validator-monitor-pubkeys 0x933ad9491b62059dd065b560d256d8957a8c402cc6e8d8ee7290ae11e8f7329267a8811c397529dac52ae1342ba58c95,0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c
```
> Note: The validator monitoring will stop collecting per-validator Prometheus metrics and issuing per-validator logs when the number of validators reaches 64. To continue collecting metrics and logging, use the flag `--validator-monitor-individual-tracking-threshold N` where `N` is a number greater than the number of validators to monitor.
> Note: The validator monitoring will stop collecting per-validator Prometheus metrics and issuing per-validator logs when the number of validators reaches 64. To continue collecting metrics and logging, use the flag `--validator-monitor-individual-tracking-threshold N` where `N` is a number greater than the number of validators to monitor.
## Observing Monitoring
@@ -102,7 +102,7 @@ dashboard contains most of the metrics exposed via the validator monitor.
Lighthouse v4.6.0 introduces a new feature to track the performance of a beacon node. This feature internally simulates an attestation for each slot, and outputs a hit or miss for the head, target and source votes. The attestation simulator is turned on automatically (even when there are no validators) and prints logs in the debug level.
> Note: The simulated attestations are never published to the network, so the simulator does not reflect the attestation performance of a validator.
> Note: The simulated attestations are never published to the network, so the simulator does not reflect the attestation performance of a validator.
The attestation simulation prints the following logs when simulating an attestation:
@@ -118,11 +118,11 @@ DEBG Simulated attestation evaluated, head_hit: true, target_hit: true, source_h
```
An example of a log when the head is missed:
```
DEBG Simulated attestation evaluated, head_hit: false, target_hit: true, source_hit: true, attestation_slot: Slot(1132623), attestation_head: 0x1c0e53c6ace8d0ff57f4a963e4460fe1c030b37bf1c76f19e40928dc2e214c59, attestation_target: 0xaab25a6d01748cf4528e952666558317b35874074632550c37d935ca2ec63c23, attestation_source: 0x13ccbf8978896c43027013972427ee7ce02b2bb9b898dbb264b870df9288c1e7, service: val_mon, service: beacon, module: beacon_chain::validator_monitor:2051
```
With `--metrics` enabled on the beacon node, the following metrics will be recorded:
```
@@ -134,11 +134,12 @@ validator_monitor_attestation_simulator_source_attester_hit_total
validator_monitor_attestation_simulator_source_attester_miss_total
```
A grafana dashboard to view the metrics for attestation simulator is available [here](https://github.com/sigp/lighthouse-metrics/blob/master/dashboards/AttestationSimulator.json).
A grafana dashboard to view the metrics for attestation simulator is available [here](https://github.com/sigp/lighthouse-metrics/blob/master/dashboards/AttestationSimulator.json).
The attestation simulator provides an insight into the attestation performance of a beacon node. It can be used as an indication of how expediently the beacon node has completed importing blocks within the 4s time frame for an attestation to be made.
The attestation simulator provides an insight into the attestation performance of a beacon node. It can be used as an indication of how expediently the beacon node has completed importing blocks within the 4s time frame for an attestation to be made.
The attestation simulator _does not_ consider:
The attestation simulator *does not* consider:
- the latency between the beacon node and the validator client
- the potential delays when publishing the attestation to the network
@@ -146,10 +147,6 @@ which are critical factors to consider when evaluating the attestation performan
Assuming the above factors are ignored (no delays between beacon node and validator client, and in publishing the attestation to the network):
1. If the attestation simulator says that all votes are hit, it means that if the beacon node were to publish the attestation for this slot, the validator should receive the rewards for the head, target and source votes.
1. If the attestation simulator says that all votes are hit, it means that if the beacon node were to publish the attestation for this slot, the validator should receive the rewards for the head, target and source votes.
1. If the attestation simulator says that the one or more votes are missed, it means that there is a delay in importing the block. The delay could be due to slowness in processing the block (e.g., due to a slow CPU) or that the block is arriving late (e.g., the proposer publishes the block late). If the beacon node were to publish the attestation for this slot, the validator will miss one or more votes (e.g., the head vote).