Guía Completa de Arquitectura de métricas para blockchain

Cuando se opera un único nodo blockchain, un Prometheus local con Grafana puede ser suficiente. Pero cuando la flota crece a decenas o cientos de nodos, distribuidos en multiples regiones y ejecutando diferentes clientes, se necesita una arquitectura de métricas diseñada para escalar. En esta guía abordamos el diseño del pipeline completo de métricas para infraestructura blockchain: desde la recolección en los nodos hasta el almacenamiento a largo plazo, la visualización y los KPIs específicos que un equipo DevOps debe rastrear.

Diseño del pipeline de métricas

Una arquitectura de métricas para blockchain sigue las mismas capas que cualquier sistema de observabilidad, pero con requisitos específicos:

Capa de recolección

Los nodos blockchain exponen métricas en endpoints HTTP. La recolección se realiza mediante:

Prometheus (modelo pull): Ideal para flotas de nodos donde el servidor de métricas puede alcanzar cada nodo directamente.

# prometheus.yml para una flota multi-nodo
scrape_configs:
  - job_name: 'execution-clients'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/execution/*.yml'
        refresh_interval: 30s

  - job_name: 'consensus-clients'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/consensus/*.yml'
        refresh_interval: 30s

# /etc/prometheus/targets/execution/nodes.yml
- targets: ['node-01:6060', 'node-02:9091', 'node-03:9091']
  labels:
    region: 'us-east-1'
    environment: 'production'

- targets: ['node-04:6060', 'node-05:9091']
  labels:
    region: 'eu-west-1'
    environment: 'production'

Telegraf (modelo push): Util cuando los nodos estan detras de NAT o firewalls que impiden el scrape directo. Telegraf puede recolectar métricas localmente y enviarlas a un endpoint central:

# telegraf.conf - agente en cada nodo
[[inputs.prometheus]]
  urls = ["http://localhost:6060/debug/metrics/prometheus"]
  metric_version = 2
  [inputs.prometheus.tags]
    node_id = "node-01"
    client = "geth"

[[inputs.prometheus]]
  urls = ["http://localhost:5054/metrics"]
  metric_version = 2
  [inputs.prometheus.tags]
    node_id = "node-01"
    client = "lighthouse"

[[outputs.influxdb_v2]]
  urls = ["https://metrics-central.example.com:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "blockchain-ops"
  bucket = "node-metrics"

Capa de almacenamiento

El almacenamiento local de Prometheus tiene limitaciones para flotas grandes y retención a largo plazo. Las soluciones mas utilizadas son:

Thanos: Extiende Prometheus con almacenamiento en object storage (S3, GCS) y permite consultar multiples instancias de Prometheus de forma unificada.

# Thanos Sidecar junto a cada Prometheus
# docker-compose.yml
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.min-block-duration=2h'
      - '--storage.tsdb.max-block-duration=2h'

  thanos-sidecar:
    image: thanosio/thanos:latest
    command:
      - 'sidecar'
      - '--tsdb.path=/prometheus'
      - '--prometheus.url=http://prometheus:9090'
      - '--objstore.config-file=/etc/thanos/bucket.yml'
    volumes:
      - prometheus-data:/prometheus

VictoriaMetrics: Alternativa a Prometheus con mejor rendimiento en ingestion y compresion de datos. Compatible con PromQL y el protocolo de remote write de Prometheus:

# Prometheus con remote write a VictoriaMetrics
remote_write:
  - url: "http://victoriametrics:8428/api/v1/write"
    queue_config:
      max_samples_per_send: 10000
      batch_send_deadline: 5s
      max_shards: 30

Comparación de opciones de almacenamiento

Aspecto	Prometheus local	Thanos	VictoriaMetrics
Retención	Limitada (semanas)	Ilimitada (object storage)	Configurable
Multi-región	No	Si (query federado)	Si (cluster)
Compresion	Buena	Excelente (object storage)	Superior
Complejidad	Baja	Alta	Media
PromQL	Nativo	Compatible	Compatible

Capa de visualización

Grafana sigue siendo la herramienta dominante para visualización de métricas blockchain. La clave esta en organizar los dashboards por nivel de abstracción:

• Vista de flota: Estado general de todos los nodos, porcentaje sincronizado, alertas activas.
• Vista por nodo: Detalle de un nodo específico con todas sus métricas.
• Vista por cliente: Comparación de rendimiento entre diferentes implementaciones de clientes.
• Vista de negocio: KPIs de alto nivel relevantes para staking (rendimiento, penalties, balance).

KPIs específicos para blockchain

Mas alla de las métricas técnicas de cada nodo, una arquitectura de métricas madura debe rastrear KPIs de negocio y operacionales:

Transacciones por segundo (TPS)

# TPS calculado a partir de las transacciones incluidas en bloques
sum(rate(chain_transactions_total[5m]))

El TPS real de la red vs el TPS que tu infraestructura puede procesar es un indicador crítico de capacidad.

Finality time

El tiempo de finalización mide cuanto tarda una transacción en ser considerada irreversible:

# Epochs desde la ultima finalizacion
beacon_head_slot / 32 - beacon_finalized_epoch

En Ethereum, la finalización ocurre cada 2 epochs (~12.8 minutos) en condiciones normales. Un aumento en este tiempo indica problemas en la red.

Attestation effectiveness

Para operadores de validadores, la efectividad de atestación impacta directamente en los ingresos:

# Porcentaje de atestaciones incluidas exitosamente
validator_attestation_hit_percentage

# Distancia promedio de inclusion
avg(validator_attestation_inclusion_distance)

Una atestación incluida en el slot inmediato siguiente es optima (distancia 1). Distancias mayores reducen las recompensas.

Participation rate

# Tasa de participacion de la red
beacon_current_justified_epoch_participation_rate

Una participación por debajo del 66% impide la finalización y es un evento crítico para toda la red.

Disponibilidad del nodo

# Uptime calculado con probe_success (blackbox exporter)
avg_over_time(probe_success{job="blockchain-nodes"}[30d]) * 100

Monitoreo multi-nodo

Cuando se operan multiples nodos, la arquitectura debe soportar comparaciones y correlaciones:

Service discovery dinámico

Para flotas que escalan automáticamente (por ejemplo, en Kubernetes), el service discovery automático es esencial:

# Prometheus con Kubernetes service discovery
scrape_configs:
  - job_name: 'ethereum-nodes'
    kubernetes_sd_configs:
      - role: pod
        namespaces:
          names: ['blockchain']
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: 'ethereum-.*'
        action: keep
      - source_labels: [__meta_kubernetes_pod_label_client]
        target_label: client
      - source_labels: [__meta_kubernetes_pod_label_layer]
        target_label: layer

Recording rules para rendimiento

Las recording rules pre-calculan métricas agregadas frecuentemente consultadas, reduciendo la carga en Prometheus:

# recording_rules.yml
groups:
  - name: blockchain-aggregations
    interval: 30s
    rules:
      - record: blockchain:sync_percentage:avg
        expr: avg by (region, client) (
          chain_head_block / ignoring(region, client) group_left
          max(chain_head_block)
        ) * 100

      - record: blockchain:peer_count:avg_by_region
        expr: avg by (region) (p2p_peers)

      - record: blockchain:attestation_effectiveness:avg
        expr: avg by (node_id) (validator_attestation_hit_percentage)

      - record: blockchain:disk_usage_percent:by_node
        expr: 1 - (node_filesystem_avail_bytes{mountpoint="/data"} /
          node_filesystem_size_bytes{mountpoint="/data"})

Capacity planning

Las métricas historicas son fundamentales para planificar la capacidad de la infraestructura:

Proyección de uso de disco

# Tasa de crecimiento de disco por dia
deriv(node_filesystem_size_bytes{mountpoint="/data"}[7d]) * 86400

# Dias restantes antes de quedarse sin espacio
(node_filesystem_avail_bytes{mountpoint="/data"})
  / (deriv(node_filesystem_size_bytes{mountpoint="/data"} -
     node_filesystem_avail_bytes{mountpoint="/data"}[7d]) * 86400)

Planificación de recursos

Datos tipicos de crecimiento para nodos Ethereum (orientativo):

Recurso	Geth (snap)	Nethermind (snap)	Erigon (archive)
Disco (crecimiento/mes)	~40-60 GB	~40-60 GB	~20-30 GB
RAM recomendada	16 GB	16 GB	16 GB
IOPS requeridos	10k+	10k+	15k+
Ancho de banda	~25 Mbps	~25 Mbps	~25 Mbps

Estos valores cambian con los upgrades de protocolo y el nivel de actividad de la red.

Integración con alertas y respuesta

La arquitectura de métricas se completa con un sistema de respuesta que conecte las alertas con acciones:

# Ejemplo: alerta que activa un runbook automatizado
groups:
  - name: blockchain-response
    rules:
      - alert: NodeDiskCritical
        expr: blockchain:disk_usage_percent:by_node > 0.90
        for: 5m
        labels:
          severity: critical
          runbook: "https://wiki.internal/runbooks/blockchain-disk-full"
        annotations:
          summary: "Disco critico en {{ $labels.node_id }}"
          action: "Ejecutar pruning o expandir volumen"

Conclusion

Una arquitectura de métricas bien diseñada es la base de operaciones blockchain confiables a escala. El pipeline desde la recolección (Prometheus, Telegraf), pasando por el almacenamiento (Thanos, VictoriaMetrics), hasta la visualización (Grafana) y las alertas (Alertmanager) debe disenarse considerando el crecimiento de la flota, la retención de datos historicos para capacity planning, y los KPIs específicos de blockchain como TPS, finality y attestation effectiveness. Invertir en esta arquitectura temprano evita problemas operativos costosos cuando la infraestructura escala.

Recursos

• Thanos Documentation
• VictoriaMetrics Documentation
• Prometheus Best Practices
• Grafana Dashboard Best Practices
• Telegraf Documentation
• Ethereum Beacon Chain Metrics