¿Cómo comprobar el tiempo de actividad de Optimism y qué significa para tu dApp?

Respuesta rápida: dónde comprobar el tiempo de actividad de Optimism

Si necesitas una respuesta rápida, la página de estado oficial de Optimism es la fuente autorizada para la disponibilidad a nivel de red. Realiza un seguimiento de componentes como la API pública, depósitos, retiros, secuenciación de transacciones, envío de lotes y sincronización de nodos. Para una vista más granular de la salud del endpoint RPC, puedes usar agregadores de terceros o tus propias sondas de monitoreo.

Pero aquí está el detalle: el tiempo de actividad de la red y el tiempo de actividad del RPC no son lo mismo. Incluso si la red de Optimism está completamente operativa, el proveedor de RPC que uses podría experimentar tiempo de inactividad, límites de velocidad o rendimiento degradado. Este artículo te ayuda a entender la diferencia y decidir qué monitorear para tu dApp.

Guía de decisión: qué monitorear para tu dApp

Antes de comenzar a revisar los números de tiempo de actividad, pregúntate qué necesitas monitorear realmente. La respuesta depende de la arquitectura de tu aplicación y las expectativas de los usuarios.

• Si estás construyendo un frontend simple que lee datos: Necesitas endpoints RPC públicos confiables, pero puedes tolerar interrupciones breves ocasionales si tienes un respaldo.
• Si estás ejecutando un protocolo DeFi o un bot de trading: Necesitas RPC de baja latencia y alta disponibilidad con conmutación por error automática. Unos segundos de inactividad pueden significar transacciones perdidas o pérdidas financieras.
• Si estás indexando datos o ejecutando análisis: Necesitas acceso consistente a datos de archivo y flujos WebSocket. El tiempo de actividad es crítico, pero también lo es la integridad de los datos.

Para la mayoría de las aplicaciones de producción, recomendamos una estrategia de múltiples proveedores. Usa un proveedor de RPC principal y configura un respaldo a otro proveedor o a un endpoint público. De esta manera, si un proveedor tiene un incidente, tu aplicación puede seguir operando.

Qué rastrea la página de estado oficial de Optimism

La página de estado oficial te da una vista de alto nivel de la salud de la red. Normalmente muestra los siguientes componentes:

Puedes consultar esta página para ver si hay incidentes en curso. Sin embargo, no te informa sobre el rendimiento de los proveedores de RPC de terceros, que es lo que tu aplicación realmente usa.

Por qué el tiempo de actividad del RPC importa más que el tiempo de actividad de la red

Tu dApp interactúa con Optimism a través de un endpoint RPC. Si ese endpoint está caído, tu aplicación no puede leer ni escribir datos, independientemente de la salud general de la red. Por lo tanto, al evaluar el tiempo de actividad de Optimism, debes centrarte en el tiempo de actividad del proveedor de RPC, no solo en el de la red.

El tiempo de actividad del RPC generalmente se mide como un porcentaje durante un período (por ejemplo, alto en los últimos 30 días). Pero los números brutos de tiempo de actividad pueden ser engañosos. Un proveedor puede tener un alto tiempo de actividad pero aún experimentar cortes cortos frecuentes que causan fallos en las solicitudes. También debes considerar:

• Latencia: ¿Qué tan rápido responde el proveedor? La alta latencia puede hacer que tu aplicación se sienta lenta.
• Límites de velocidad: ¿El proveedor limita las solicitudes? Si excedes los límites, puedes obtener errores.
• Consistencia de datos: ¿El proveedor devuelve datos obsoletos? Esto puede suceder si el nodo está atrasado.
• Fiabilidad de WebSocket: Para actualizaciones en tiempo real, las conexiones WebSocket deben ser estables.

Cómo monitorear el tiempo de actividad del RPC de Optimism tú mismo

Puedes configurar tu propio monitoreo para rastrear el tiempo de actividad y el rendimiento de tus endpoints RPC. Aquí hay un enfoque simple usando un script que envía una solicitud JSON-RPC y mide el tiempo de respuesta.

#!/bin/bash
# Verificación simple de tiempo de actividad para RPC de Optimism

RPC_URL="https://mainnet.optimism.io"

response=$(curl -s -o /dev/null -w "%{http_code} %{time_total}" -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  $RPC_URL)

http_code=$(echo $response | cut -d' ' -f1)
time_total=$(echo $response | cut -d' ' -f2)

if [ "$http_code" -eq 200 ]; then
  echo "RPC está activo. Tiempo de respuesta: ${time_total}s"
else
  echo "RPC está caído. Código HTTP: $http_code"
fi

Puedes ejecutar este script periódicamente (por ejemplo, cada minuto) y registrar los resultados. Para un monitoreo más avanzado, usa un servicio como UptimeRobot o Grafana con Prometheus para rastrear el tiempo de actividad a lo largo del tiempo y configurar alertas.

Qué buscar en el tiempo de actividad de un proveedor de RPC

Al comparar proveedores de RPC, no te limites a mirar el porcentaje de tiempo de actividad principal. Pregunta o verifica lo siguiente:

• Tiempo de actividad en diferentes períodos: 24 horas, 7 días, 30 días, 90 días. Un proveedor puede tener un gran tiempo de actividad de 90 días pero problemas recientes.
• Historial de incidentes: ¿Con qué frecuencia ocurren los incidentes? ¿Cuánto duran? Un proveedor con una interrupción larga puede ser peor que uno con varios parpadeos cortos.
• Página de estado: ¿El proveedor tiene una página de estado pública? ¿Qué tan rápido la actualizan?
• SLA (Acuerdo de Nivel de Servicio): ¿El proveedor ofrece un SLA? ¿Qué sucede si lo incumplen?
• Redundancia: ¿El proveedor tiene múltiples nodos y centros de datos? Esto reduce el riesgo de un punto único de falla.

En OnFinality, operamos nodos dedicados y endpoints RPC en múltiples regiones. Puedes consultar nuestras redes compatibles para ver si Optimism está disponible y revisar nuestros precios de RPC para obtener detalles sobre los niveles de servicio.

Errores comunes al depender de endpoints RPC públicos

Los endpoints RPC públicos, como el proporcionado por Optimism, son convenientes para el desarrollo y uso ligero, pero tienen limitaciones:

• Límites de velocidad: Los endpoints públicos a menudo tienen límites de velocidad estrictos. Si tu aplicación hace demasiadas solicitudes, recibirás errores como 429 Too Many Requests.
• Sin SLA: Los endpoints públicos se proporcionan tal cual, sin garantía de tiempo de actividad o rendimiento.
• Infraestructura compartida: Los endpoints públicos son utilizados por muchos desarrolladores, por lo que pueden congestionarse en momentos de alta demanda.
• Métodos limitados: Algunos endpoints públicos pueden no admitir ciertos métodos, como eth_getLogs con rangos grandes o métodos trace_*.

Si tu aplicación está en producción, deberías considerar usar un proveedor de RPC dedicado que ofrezca mayor fiabilidad y más funciones.

Cómo construir resiliencia en tu dApp

Incluso con un proveedor de RPC confiable, debes diseñar tu dApp para manejar fallos de RPC con elegancia. Aquí hay algunas mejores prácticas:

• Usa múltiples endpoints RPC: Configura tu aplicación para probar un endpoint de respaldo si el principal falla.
• Implementa lógica de reintento: Para solicitudes críticas, reintenta con retroceso exponencial.
• Almacena en caché los datos: Almacena en caché los datos de acceso frecuente para reducir el número de llamadas RPC.
• Monitorea tu aplicación: Usa herramientas como Sentry o Datadog para rastrear errores y rendimiento.

Aquí hay un ejemplo de cómo configurar un RPC de respaldo en ethers.js:

const { ethers } = require("ethers");

const primaryProvider = new ethers.JsonRpcProvider("https://mainnet.optimism.io");
const fallbackProvider = new ethers.JsonRpcProvider("https://optimism-mainnet.public.blastapi.io");

const provider = new ethers.FallbackProvider([primaryProvider, fallbackProvider], 1);

async function getBlockNumber() {
  try {
    const blockNumber = await provider.getBlockNumber();
    console.log("Número de bloque:", blockNumber);
  } catch (error) {
    console.error("Error al obtener el número de bloque:", error);
  }
}

getBlockNumber();

De esta manera, si el endpoint principal falla, el respaldo se usará automáticamente.

Conclusiones clave

• El tiempo de actividad de Optimism se refiere a la disponibilidad de la red y sus servicios principales, pero el tiempo de actividad del RPC es lo que afecta directamente a tu dApp.
• Consulta la página de estado oficial de Optimism para incidentes a nivel de red, pero también monitorea el rendimiento de tu proveedor de RPC.
• Al elegir un proveedor de RPC, mira más allá de los porcentajes de tiempo de actividad y considera la latencia, los límites de velocidad, la consistencia de datos y la fiabilidad de WebSocket.
• Los endpoints RPC públicos no son adecuados para producción; usa un proveedor dedicado como OnFinality para una mayor fiabilidad.
• Construye resiliencia en tu dApp usando múltiples endpoints, lógica de reintento y almacenamiento en caché.

Preguntas frecuentes

P: ¿Cuál es el tiempo de actividad actual de Optimism?

R: La página de estado oficial muestra el estado actual de los componentes de Optimism. Para el tiempo de actividad histórico, puedes consultar agregadores de terceros o tus propios datos de monitoreo.

P: ¿Cómo se calcula el tiempo de actividad de Optimism?

R: El tiempo de actividad generalmente se calcula como el porcentaje de tiempo que un servicio está operativo durante un período determinado. Por ejemplo, un tiempo de actividad alto significa que el servicio estuvo inactivo menos de 43 minutos en un mes de 30 días.

P: ¿Optimism tiene un SLA?

R: La red de Optimism en sí no ofrece un SLA para su API pública. Sin embargo, los proveedores de RPC como OnFinality pueden ofrecer SLA para servicios dedicados.

P: ¿Qué debo hacer si la API pública de Optimism está caída?

R: Si la API pública está caída, puedes cambiar a un proveedor de RPC de terceros. OnFinality ofrece endpoints RPC confiables de Optimism; consulta nuestras redes compatibles para más detalles.

P: ¿Cómo puedo obtener alertas para el tiempo de inactividad de Optimism?

R: Puedes configurar tu propio monitoreo usando herramientas como UptimeRobot o Grafana, o suscribirte a las notificaciones de la página de estado de Optimism o de tu proveedor de RPC.