En esta nueva etapa de Admapu me enfonqué en un aspecto que suele quedar postergado en muchas PoC on-chain: observability.

Hasta ahora, una parte importante del seguimiento operativo dependía de queries directas al RPC, por medio de Makefile o directamente comandos en la terminal. Si bien esto puede servir en etapas tempranas, es bastante limitado: escala pésimo, introduce fragilidad operativa, es difícil de reproducir y termina mezclando responsabilidades que es mejor separar desde el principio.

Por eso, tomé la desición de seguir una ruta más robusta y profesional desde el principio, integrando The Graph para indexar y consultar los datos on-chain de forma eficiente, auditable y escalable. Esto no solo mejora la experiencia de desarrollo, sino que también sienta las bases para una operación más fluida y confiable a medida que el proyecto avanza.

Para lograr esto, creé un nuevo repositorio que llamé (de forma muy creativa) observability, que corre en un CloudFlare Worker, y que básicamente se encarga de consultar el subgraph de Admapu usando el endpoint de GraphQL. De ahí, expone dos endpoints:

• /health, porque sí.
• /metrics, que devuelve metrics en Prometheus.

La configuración del worker es trivial, no es realmente interesante. Lo que sí lo es, es que ahora la capa de observability esta desacoplada de los contracts y del frontend, y además tiene una capa de cache para no pegarle tanto al subgraph, lo que no debería ser un gran problema, pero me parece una buena práctica.

Qué metricas estoy exponiendo?

Me costó un poco decidir qué metricas exponer, porque no quería medir cosas que no aportan valor real. Al final, me enfoqué en:

• Usuarios verificados y revocados, con sus respectivos eventos: para tener una idea de la base de usuarios activos y su evolución.
• Transferencias de CLPc, para monitorear el volumen y detectar posibles anomalías.
• Mint y burn de CLPc, para entender la dinámica de emisión y quema de tokens.
• Claims de beneficios, para seguir la adopción y uso de los beneficios.
• Gas total (en wei y ETH), para tener una visión clara de los costos operativos y su evolución.

Además, y sólo porque era ultra facil, agregué unos buckets temporales con labels hourly y daily para ir viendo la evolución reciente, no sólo acumulados globales. Además de las métricas globales, en el hourly y el daily se puede obtener el delta neto de verificaciones por ventana de timepo.

Por qué The Graph?

Porque el nombre suena demasiado bien: THE Graph!

En realidad es un cambio arquitectnico relevante. Ya no es sólo “tener métricas”, sino que ya empieza a haber una separación entre capas. Ahora, el RPC está reservado para transacciones y consultas puntuales, lo que hace que la cuenta de infura no suba tanto, el subgraph se encarga de indexar y organizar los datos on-chain, y el worker de exponer métricas de forma eficiente. Esto hace que cada componente tenga una responsabilidad clara y que el sistema en su conjunto sea más robusto y escalable.

Y, de paso, elimina un problema que estaba viendo en la webapp con las queries directas al RPC: a medida que los usuarios crecen y los bloques pasan, las queries on-chain se hacen mas pesadas y lentas, lo que afecta la experiencia y termian en un no-tan-lindo 429.

Con todo esto, Admapu empieza a incluir componentes que apuntan a una operación más seria, auditable y sostenible.

Show me the code!

Por si alguien quiere revisar el código, el repo de observability es público (como todos) y las metrics están disponibles en observability.a.x/metrics.