|
|
|
De: *Robert Martin-Legene*
|
|
|
|
Enviado el: lunes, *06 de agosto de 2018* 01:51 p.m.
|
|
|
|
Para: Rodrigo Jimenez; blockchain
|
|
|
|
Asunto: Re: Sobre Monitoreo de la red
|
|
|
|
|
|
|
|
On 08/03/2018 10:15 AM, Rodrigo Jimenez wrote:
|
|
|
|
> En relación al estado de salud de la red , creo que resulta importante poder recolectar información histórica y de tiempo real de distintos parámetros de la red.
|
|
|
|
>
|
|
|
|
> Parámetros a medir en los clientes geth (nodos de la red):
|
|
|
|
>
|
|
|
|
> 1. Número de bloque actual (con timestamp)/Número de bloque anterior(con timestamp)
|
|
|
|
> 2. Tiempo desde último bloque
|
|
|
|
> 3. Numero de peers conectados
|
|
|
|
> 4. Estado de nodos sealers y de propuestas en curso.
|
|
|
|
|
|
|
|
4.1 Especificamente, hace cuantos bloques firmó cada de los selladores.
|
|
|
|
|
|
|
|
> 5. Numero de TX en ultimo bloque, ultimo 1 minuto, 5 minutos, 1 hora, 1 dia, 1 semana y premedios (?). Yo piense en RRD (pero no soy religioso) porque es facil usar.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> Al recolectar estos valores desde múltiples clientes geth podríamos tener una idea del estado de la red y diagnosticar condiciones irregulares (caídas de nodos clientes, sealers, cambio los parámetros de quorum, etc).
|
|
|
|
|
|
|
|
Si, es importante que estan todos mas o menos de acuerdo por lo menos hablando de #1 y #2. Si lo ponemos en "el paquete de selladores" (los bash scripts ;-) que tienen que correr todos) no creo que estamos pidiendo mucho.
|
|
|
|
|
|
|
|
|
|
|
|
> Entiendo que va a ser recomendable que al menos dos equipos de monitoreo en sitios distintos se encarguen de recolectar estas métricas del mayor número posible de nodos (para tener una foto lo más completa posible del estado de la red)
|
|
|
|
> Una opciones es usar Zabbix Server, que nos permitiría el almacenamiento de métricas históricas y envío de alertas; y el zabbix-agent para métricas de OS y ejecución de scripts para métricas especiales.
|
|
|
|
|
|
|
|
En esto especialmente monitorear espacio libre es importante. También el volumen de trafico que pasa por la tarjeta de red.
|
|
|
|
|
|
|
|
> También puede resultar útil configurar la API de net-stats de Ethereum y el Dashboard que muestra (pero no alerta) todos los indicadores mencionados anteriormente.
|
|
|
|
> La “eth-net-intelligence-api“ es una mini app en nodeJS que se conecta a puerto de HTTP RPC de geth y envía estadísticas a un dashboard central.
|
|
|
|
> El eth-netstats es justamente ese dashboard central, también hecho en nodeJS, levanta un puerto de escucha HTTP donde recibe métricas de las eth-net-intelligence-api y presenta un dashboard bastante completo del estado de la red.
|
|
|
|
> (Dashboard: https://github.com/cubedro/eth-netstats y API: https://github.com/cubedro/eth-net-intelligence-api)
|
|
|
|
|
|
|
|
Me gustan los colores! ;-)
|
|
|
|
Por lo que veo, el api no suporta 2 destinos. Supongo que "el NOC" va a recibir esto y el servidor web esta accesible para "todos" (falta la definicion de "todos").
|
|
|
|
|
|
|
|
--
|
|
|
|
robert
|
|
|
|
|
|
|
|
|
