NyheterUtviklereEnterpriseBlockchain ExplainedBegivenheter og konferanserPresseNyhetsbrev

Abonner på vårt nyhetsbrev.

Epostadresse

Vi respekterer personvernet ditt

HomeBlogDevelopers

Hvordan overvåke Eth2 Validator og analysere P&L

av Coogan Brennan 15. januar 2021 Publisert 15. januar 2021

Hvis du er ny i denne serien om hvordan du kjører din egen Eth2-validator, må du sjekke ut del 1 og del 2. Du bør alle sjekke Ben Edgingtons Eth2.Nyhetsbrev feller viktige oppdateringer, feilrettinger og nyheter om den kommende veikartet. Eth2 Knowledge Base er nyttig hvis du trenger mer bakgrunn om viktige begreper, faser og ConsenSys Eth2-produkter.

Introduksjon 

Det har gått halvannen måned siden Ethereum 2.0 Beacon-kjedegenese startet. Allerede har 2.515.170 ETH blitt satt på (ca. 2,9 milliarder dollar til dagens markedspriser) med 61 561 unike validatorer, og ytterligere 16 687 ventet i kø. Til tross for den enorme interessen for staking, har det faktisk vært en ganske begivenhetsrik måned og en halv: Det har ikke vært store forstyrrelser, bare noen skår og validator deltakelse i 98. persentilen mesteparten av tiden. Nå er det en god tid å ta et pust for å gjøre status over det vi har gjort så langt. 

I dette blogginnlegget vil jeg dekke overvåking og økonomisk analyse av Eth2-validatoren din. Jeg gir en oversikt over hvordan du får tilgang til Teku-beregninger, konfigurerer Beaconcha.in-varslinger og hvordan du spør etter noden. Jeg deler også min nåværende P&L sammenbrudd. I den siste delen av denne serien vil jeg diskutere hvordan du trygt og (forhåpentligvis) lykkes med å migrere en Teku-node fra en server til en annen.

Overvåkning

I denne delen skal jeg gå gjennom hvordan du kan lese beregningene for validatornoden din. Å kjøre en Ethereum 2.0-validator kjører infrastruktur for et distribuert system. En viktig del av vedlikehold av infrastruktur er å kunne se hva som skjer. Heldigvis kommer Teku med en flott pakke med overvåkingsverktøy aktivert med “–metrics-enabled” -flagget på oppstartskommandoen, uthevet nedenfor:

ExecStart = / home / ubuntu / teku-20.11.1 / bin / teku –network = mainnet<sterk> sterk> <sterk>–eth1-endpoint = INFURA_ETH1_HTTP_ENDPOINT_GOES_HERE sterk> <sterk>–validator-keys = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json: /home/ubuntu/validator_key_info/validator_keys/KEYSTORE-M_123456_789_ABCD.txt sterk> –rest-api-enabled = true –rest-api-docs-enabled = true – metrics-enabled –validators-keystore-locking-enabled = false <sterk>–data-base-sti = / var / lib / tekustrong>Kodespråk: HTML, XML (xml)

Vi må følge noen få trinn før vi kan lese dataene.

For de som ikke kjører en Teku-klient: Først, hvorfor? For det andre kan du se minimumsberegningene som tilbys av alle klienter i Ethereum 2.0 spesifikasjoner her.

Installere Prometheus

Først må vi installere Prometheus, et overvåkningsprogram med åpen kildekode, og Grafana, en åpen app-analyse og interaktiv visualisering nettapp. Prometheus trekker dataene og Grafana viser dem.

Last ned den siste stabile Prometheus på Ubuntu-kommandolinjen:

krølle -JLO <a href ="https://github.com/prometheus/prometheus/releases/download/v2.23.0/prometheus-2.23.0.linux-amd64.tar.gz">https://github.com/prometheus/prometheus/releases/download/v2.23.0/prometheus-2.23.0.linux-amd64.tar.gza>Kodespråk: HTML, XML (xml)

Komprimere filen slik:

tjære -zxvf <a href ="https://github.com/prometheus/prometheus/releases/download/v2.23.0/prometheus-2.23.0.linux-amd64.tar.gz">prometheus-2.23.0.linux-amd64.tar.gza>Kodespråk: HTML, XML (xml)

Flytt binærfilen slik at den er tilgjengelig fra kommandolinjen:

Cd prometheus-2.23.0 Kodespråk: CSS (css) sudo mv prometheus promtool / usr / local / bin /

Kontroller at den er riktig installert:

prometheus –versjon promtool –versjon

Opprett en prometheus YML-konfigurasjonsfil:

sudo nano prometheus.yml Kodespråk: CSS (css)

Lim inn disse parameterne i konfigurasjonsfilen:

global: scrape_interval: 15s scrape_configs: – job_name: "prometheus" static_configs: – mål: ["lokal vert: 9090"] – jobb navn: "teku-dev" scrape_timeout: 10s metrics_path: / metrics scheme: http static_configs: – targets: ["lokal vert: 8008"] Kodespråk: PHP (php)

Dette instruerer Prometheus til å avstemme Teku-noden din hvert 10. sekund på 8008-porten. Trykk kommando-X og trykk Y for å lagre buffer

La oss nå lage en katalog for å sette vår Prometheus-konfigurasjonsfil:

sudo mkdir / etc / prometheus sudo mv prometheus.yml /etc/prometheus/prometheus.yml

Vi skal lage en annen katalog for andre Prometheus-filer og flytte modulene konsoll og konsoll_bibliotek til / etc / prometheus

sudo mkdir / var / lib / prometheus sudo mv-konsoller / console_libraries / / etc / prometheus / Kodespråk: JavaScript (javascript)

Vi oppretter en prometheus-bruker for å kjøre en systemtjeneste, slik vi gjorde for Teku (les mer her om hvordan rollebasert brukertilgang er best praksis for serversikkerhet) og gi den tilgang til passende filer:

sudo useradd –no-create-home – shell / bin / false prometheus sudo chown -R prometheus: prometheus / var / lib / prometheus sudo chown -R prometheus: prometheus / etc / prometheus sudo chown -R prometheus: prometheus / usr / local / bin / Kodespråk: JavaScript (javascript)

Sist, opprett en systemd-tjeneste som kan kjøre i bakgrunnen og starte på nytt hvis den mislykkes:

sudo nano /etc/systemd/system/prometheus.service

I denne filen (som skal være tom) skal vi legge inn en serie kommandoer som systemd skal utføre når vi starter tjenesten. Kopier følgende til teksteditoren:

[Enhet] Beskrivelse = Prometheus ønsker = nettverk-online.target Etter = nettverk-online.target [Service] Type = enkel bruker = prometheus Group = prometheus Restart = alltid RestartSec = 5 ExecStart = / usr / local / bin / prometheus \ – -config.file = / etc / prometheus / prometheus.yml \ –storage.tsdb.path = / var / lib / prometheus \ –web.console.templates = / etc / prometheus / consoles \ –web.console. biblioteker = / etc / prometheus / console_libraries \ –web.listen-address = 0.0.0.0: 9090 \ [Install] WantedBy = multi-user.target Kodespråk: JavaScript (javascript)

Skriv command-X, og skriv deretter “Y” for å lagre endringene

Vi må starte systemctl på nytt for å oppdatere det:

sudo systemctl daemon-reload

Start tjenesten:

sudo systemctl starte prometheus

Kontroller at den kjører i orden:

sudo systemctl status prometheus

Hvis du ser noen feil, kan du få mer informasjon ved å kjøre:

sudo journalctl -f -u prometheus.serviceKodespråk: CSS (css)

Du kan stoppe Prometheus-tjenesten ved å kjøre:

sudo systemctl stopp prometheus

Installer Grafana

Vi skal bruke APT-pakkebehandleren for Linux til å installere Grafana. Dette vil spare oss for mye arbeid og gi oss det vi trenger. Vi følger trinnene fra Grafana-installasjonssiden:

sudo apt-get install -y apt-transport-https sudo apt-get install -y software-properties-common wget wget -q -O – https://packages.grafana.com/gpg.key | sudo apt-key add -Code språk: JavaScript (javascript)

Vi legger til det stabile Grafana-depotet for oppdateringer:

ekko "deb https://packages.grafana.com/oss/deb stabil hoved" | sudo tee -a /etc/apt/sources.list.d/grafana.list Kodespråk: PHP (php)

Så kjører vi APT:

sudo apt-get oppdater sudo apt-get install grafana Kodespråk: JavaScript (javascript)

Pakken setter opp en systemtjeneste for oss (inkludert en bruker grafana), så vi trenger bare å kjøre:

sudo service grafana-server start sudo service grafana-server status sudo update-rc.d grafana-server standard Kodespråk: CSS (css)

SSH Tunneling

Grafana lager et veldig glatt dashbord der vi kan se beregningene våre. Dette dashbordet er vanligvis tilgjengelig i nettleseren, men siden vi kjører serverversjonen av Ubuntu 20.04, er det hele kommandolinjen. Så hvordan får vi tilgang til Grafana?

Gå inn i SSH-tunneling. Det er den samme protokollen som vi bruker for å få tilgang til AWS fra kommandolinjen vår, men vi skal sette den opp slik at vi oppretter en speilport på vår lokale datamaskin som kobles til en bestemt port på AWS-forekomsten. På den måten, når vi ringer opp porten lokalt, si ved å åpne nettleseren til http: // localhost: 3000, vi ser faktisk på 3000-porten på AWS-forekomsten.

For å gjøre dette riktig, trenger du SSH-nøkkelen for AWS og AWS IP-informasjon. Du må også vite hvilken port du vil koble til. I dette tilfellet vet vi at Grafana-forekomsten kjører på port 3000, så kommandolinjeinstruksjonene vil ha denne generiske strukturen:

ssh -N -L 3000: lokal vert: 3000 -i "PATH_TO_AWS_KEYPAIR.pem"ubuntu@INSTANCE_IDENTIFIER.compute-ZONE.amazonaws.com Kodespråk: CSS (css)

Dette gjør at vi kan gå til http: // localhost: 3000 på vår lokale maskin og se Grafana-dashbordet vårt. Men vi har ikke en ennå, så vi må gjøre følgende:

Legg til Prometheus som datakilde:

Gå til “legg til ny datakilde”

Klikk på “Prometheus” fra rullegardinmenyen

Klikk “Lagre og test”

Klikk + på menyen til venstre og velg “import dashboard”

Legg til Teku Grafana ID: 13457

Og, bada-bing! Vi har dashbordet vårt, synlig fra komforten i vår egen nettleser:

Beaconcha.in App

Grafana dashbordet er utmerket, og Prometheus lagrer informasjon for oss. Det er imidlertid andre alternativer for å sjekke validatorstatus.

Jeg har brukt Beaconcha.in Dashboard mobilapp for Android. Det er et enkelt grensesnitt, som er greit fordi det ikke er min primære overvåkingstjeneste. Det lar meg raskt se på telefonen min for å sjekke validatorstatus og gir varsler om noe er galt med validatoren.

Du angir valideringsadressen du vil se, og det er stort sett det! Igjen, ikke tung overvåking (det er det Grafana Teku-feedet gir). Men det er greit som en sekundær tjeneste, og binær “fungerer validatoren eller ikke”:

Spørring av noden

En annen måte å “overvåke” vår Ethereum validator-klient på er å spørre den! Som en Ethereum 1.0-klient lagrer og opprettholder en Ethereum validator-klient en verdensstat. Det er mye mindre sammenlignet med Ethereum 1.0, men det er fremdeles on-chain data lagret og vedlikeholdt av validator-klienten. 

Dette er de samme dataene som forbrukes av Prometheus / Grafana-arbeidsflyten. Vi kommer ganske enkelt nærmere metallet (praktisk talt) ved å spørre noden selv. Her er et utvalg av tilgjengelige data (full liste her):

• Informasjon om kjedekjede (genese-blokk, blokkoverskrifter og rot, etc.)
• Valideringsinformasjon (liste over validatorer, valideringsbalanse, valideringsansvar osv.)
• Nodeinformasjon (generell helse, liste over jevnaldrende osv.)

krøll

Den første måten å gjøre dette på er fra kommandolinjen. Da vi startet Teku, la vi til flagget –rest-api-enabled = true. Dette åpner et API-endepunkt ved standardporten 5051 (du kan spesifisere en annen port ved å bruke flagget –rest-api-port =). Du kan dobbeltsjekke at porten din er åpen ved å kjøre sudo lsof -i -P -n | grep LYTT.

Når du har bekreftet at port 5051 er åpen av Teku, vil vi bruke den krøll å sende HVILE ringer til Teku API-sluttpunktet kl http: // localhost: 5051. Her er for eksempel måten vi sjekker saldoen til den som gir best validator (ifølge Beaconcha.in):

krølle -X FÅ "http: // localhost: 5051 / eth / v1 / beacon / states / head / validator_balances id = 0x8538bbc2bdd5310bcc71b1461d48704e36dacd106fa19bb15c918e69adbcc360e5bf98ebc3f558eb4daefe6d6c26dda5"Kodespråk: PHP (php)

Her er svaret jeg fikk tilbake i midten av januar 2021 (i Gwei): 

{"data": [{"indeks":"4966","balansere":"32607646851"}]} Kodespråk: JSON / JSON med kommentarer (json)

Prøv noen av metodene på Teku API-dokumentsiden ved hjelp av formatet nederst på denne siden:

curl -X [REST_METHOD] “API_CALL_IN_QUOTES” Kodespråk: CSS (css)

Swagger UI

Det er et grunnleggende grafisk brukergrensesnitt for API-anrop som Teku tilbyr når flagget –rest-api-docs-enabled = true legges til i oppstartskommandoene. Den er bygget på swagger-ui og den er som standard på port 5051, og vi kan bruke SSH-tunneling for å få tilgang til den. Følg de samme SSH-tunnelingstrinnene ovenfra, men med 5051 som port:

ssh -N -L 5051: localhost: 5051 -i "PATH_TO_AWS_KEYPAIR.pem" ubuntu@INSTANCE_IDENTIFIER.compute-ZONE.amazonaws.com Kodespråk: CSS (css)

Fra nettleseren på datamaskinen vår kan vi deretter navigere til http: // localhost: 5051 / swagger-ui, som ser slik ut på maskinen min:

Verdensstat og konsensus er noe som dukker opp i alle offentlige blokkjeder. Dette betyr at Ethereum 2.0 når konsensus av alle validatorer som lagrer og oppdaterer informasjon. Det er litt nerdete, men å se på din lokale stat er å kikke inn i en enkelt rute med en mye større struktur. En delmengde av fraktalen som kontinuerlig oppdateres og vokser ut til noe nytt. Prøv det!

Finansiell analyse

I mitt første innlegg tegnet jeg grunnleggende materielle krav som trengs:

• En tre års forpliktelse til å sette 32 ETH og opprettholde en valideringsnode
• 32 ETH (pluss <1 ETH for gasskostnader)
• $ 717,12 (tre års reservert forekomstprissetting for en m5.xlarge forekomst) + 120 (ett års kostnad på 100 GB lagring, forutsatt konservativt med nesten full lagringskapasitet) = $ 837,12 betalt i løpet av året til AWS
• MetaMask-utvidelse (gratis installasjon) 
• Infura-konto (gratis nivå)

AWS-kostnadene var for en tre års lock-in, men jeg nevnte senere at jeg ikke var helt klar til å gjøre det. Og jeg er glad jeg ikke gjorde det! Du får se hvorfor i et øyeblikk, men her er min grunnleggende oversikt over kostnadene for 31. desember 2020:

AWS månedlige kostnader

• Dataoverføring: $ 8,52
• Server: $ 142,85
• Oppbevaring: $ 72,50
• Totalt: $ 223,87

Eth2 Validator-belønninger 

• Blokker: 5
• Attester: ~ 6,803
• ETH-belønninger: 0.420097728 ($ 485.83 USD)

Som du sikkert kan se, er et overskudd på $ 261,96 ikke en god spredning for en validator. Det er et par alternativer: Dette er en relativt stabil kostnad, så jeg kan satse 32 ETH til. Det bedre alternativet kan være å endre VPS jeg bruker, som jeg nevnte i mitt første innlegg, faktisk:

Opprinnelig var jeg sikker på at AWS var den beste virtuelle plattformen, og det er tjenesten jeg vil bruke for dette innlegget og det neste. Etter å ha gått gjennom hele prosessen skjønte jeg imidlertid at AWS kan være for mye for den enkelte utvikleren. AWS ‘virkelige styrke ser ut til å være kapasiteten til å dynamisk oppskalere for å imøtekomme etterspørsel som koster ekstra. Dette er økonomisk fornuftig for et stort prosjekt på bedriftsnivå, men individuelle Ethereum 2.0-gjeldende kundekrav krever ikke slik strenghet.

Jeg kommer til å fortsette med AWS, men underholder også muligheten til å kjøre en forekomst på Digital Ocean, noe som kan være mer passende for en enkelt utvikler. 

Jeg tror jeg kan få mye bedre fortjeneste ved å kjøre på Digital Ocean og fremdeles ikke slå et slag på validatorytelsen min. En venn kjører en validatorinstans på en mye mindre VPS som koster en størrelsesorden mindre, og vi har samme validatorytelse. 

Det er flott å eksperimentere med AWS, og jeg angrer ikke på at jeg har kapasitet i tilfelle noe går sideveis i fyrkjeden. Imidlertid tror jeg det er egentlig flott at Eth 2-utviklere leverer løftet om å gjøre validering tilgjengelig fra hjemmenettverk og oppsett! 

De nåværende prismoduleringene gjør også økonomisk analyse vanskelig, ettersom serverkostnadene er faste i USD, men belønningene svinger. På lang sikt er jeg veldig trygg på at validatorbelønningene mine vil øke i verdi. Det gjør kost-nytte vanskelig!

For den siste delen av denne serien vil jeg diskutere hvordan man trygt og (forhåpentligvis) lykkes med å migrere en Teku-node fra en server til en annen. Hovedproblemet blir selvfølgelig kuttet. Det ser ut til at det store flertallet av skjæringer som har funnet sted er på grunn av akkurat dette problemet. Vi får se hvordan det går …

Utviklere Ethereum 2.0 Ethereum Client Nyhetsbrev Abonner på vårt nyhetsbrev for de siste Ethereum-nyhetene, bedriftsløsninger, utviklerressurser og mer.