Skip to main content

Indicadores básicos de monitorización en la red ISBE

Este documento resume los indicadores principales que los casos de uso pueden necesitar para verificar el funcionamiento de la red ISBE y de sus nodos regulares. Se trata de una guía minimalista para reconocer el estado general sin entrar en detalles internos de infraestructura.

1. Block time​

El block time indica el intervalo promedio entre bloques generados.

  • Valor esperado: ~2 segundos
  • Qué significa:
    • Si aumenta significativamente → congestión o problemas en validadores.
    • Si disminuye poco → variaciones normales en IBFT.
  • Cómo comprobarlo:
    • A través de Blockscout.
    • Con RPC:
curl -H "Content-Type: application/json"   --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest", false],"id":1}'   http://localhost:8545

2. Peer count​

El número de peers indica cuántos nodos P2P están conectados a tu nodo regular.

  • Valor esperado: > 0
    (Normalmente entre 3 y 7 peers, según entorno)
  • Qué significa:
    • 0 peers → el nodo no está permisionado, el firewall bloquea el puerto o la red no es accesible.
  • Comprobar:
curl -H "Content-Type: application/json"   --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}'   http://localhost:8545

3. Altura de bloque​

Indica el número del último bloque generado en la red.

  • Valor esperado: crecimiento continuo cada ~2s.
  • Qué significa:
    • Si el valor no cambia → el nodo no está sincronizando.
    • Si cambia, pero muy por detrás del explorador → el nodo está atrasado.
  • Comprobar:
curl -H "Content-Type: application/json"   --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'   http://localhost:8545

4. Latencia en RPC​

La latencia indica la capacidad de respuesta del nodo al recibir consultas.

  • Valores orientativos:
    • 20–150 ms: normal.

    • 500 ms: problema de red o sobrecarga del nodo.

  • Cómo medir:
    • Usando scripts de eth_blockNumber repetidos.
    • Revisando tiempos de respuesta en logs de aplicación.
    • Herramientas externas como curl -w "%{time_total}".

5. Uso del nodo regular (opcional)​

Si el caso de uso opera su propio nodo, se recomiendan revisiones periódicas:

CPU​

  • Debe mantenerse por debajo del 70% en uso sostenido.

RAM​

  • Besu suele consumir entre 1–3 GB; si supera 4 GB puede haber fuga de memoria o carga excesiva.

Disco​

  • La carpeta de datos crece con el tiempo.
  • Mantener > 20% libre para evitar corrupción de datos.

Logs​

  • Errores recurrentes como DroppedPeer, SyncError o Permissioning rejected deben investigarse.

6. Interpretación general para casos de uso​

IndicadorEstado buenoEstado dudosoEstado malo
Block time~2 s>3 s>5 s
Peer count>00 intermitente0 constante
Altura de bloqueAvanzaRetraso leveNo avanza
Latencia RPC>150ms150–500ms>500ms

Los equipos solo deben escalar a ISBE en los Estados "malo". Los “dudosos” suelen deberse a condiciones temporales o sobrecarga local del nodo regular.

7. Acciones recomendadas si se detecta un problema​

  • Peer count = 0:

    • Verificar firewall y apertura de puerto 30303/tcp.
    • Confirmar que <IP_NODO> coincide con la enviada en el permisionado.

  • Block time elevado:

    • Revisar Blockscout para ver si es general o local.
    • Contactar con ISBE si se prolonga más de 5 minutos.

  • Altura de bloque no avanza:

    • Reiniciar el nodo.
    • Ver logs de Besu.
    • Contactar si persiste.

  • Latencia alta:

    • Revisar ancho de banda y carga del servidor.
    • Evitar despliegues masivos simultáneos.

8. Resumen​

Este documento resume los indicadores esenciales para validar:

  • Conectividad del nodo (peer count)
  • Salud de la red (block time)
  • Sincronización (altura)
  • Capacidad de respuesta (latencia)

Con estos datos, cualquier caso de uso puede detectar problemas básicos sin requerir acceso a herramientas internas de ISBE.