Saltar a contenido

📊 Métricas y KPIs de Monitoreo

El monitoreo efectivo del P2P Dashboard va más allá de simplemente registrar eventos; implica la recolección y análisis de métricas clave (Key Performance Indicators - KPIs) que reflejan la salud, el rendimiento y la eficiencia del sistema. Estas métricas son esenciales para la toma de decisiones operativas y estratégicas.

Métricas Clave a Monitorear

1. Métricas de Ingesta de Datos

Estas métricas se centran en el proceso de recolección y almacenamiento de datos en la Capa de Ingesta.

  • total_offers_processed: Número total de ofertas P2P procesadas exitosamente por la API de Ingesta en un período de tiempo. Indica el volumen de datos manejado.
  • offers_saved_to_db: Número de ofertas que fueron guardadas correctamente en la base de datos. Debería ser igual o muy cercano a total_offers_processed.
  • ingestion_errors_count: Número de errores ocurridos durante el proceso de ingesta (ej. errores de validación, problemas de base de datos). Un aumento en esta métrica indica problemas en la fuente de datos o en la Capa de Ingesta.
  • last_successful_ingestion_timestamp: Marca de tiempo de la última vez que se completó una ingesta de datos sin errores. Crucial para saber si el sistema está recibiendo datos actualizados.
  • ingestion_latency_seconds: Tiempo que tarda una solicitud de ingesta en ser procesada de principio a fin. Un aumento puede indicar cuellos de botella.

2. Métricas de Base de Datos

Relacionadas con el rendimiento y la salud de la base de datos PostgreSQL.

  • db_connections_active: Número de conexiones activas a la base de datos. Un número excesivo puede indicar problemas de configuración o fugas de conexión.
  • db_query_duration_ms: Tiempo promedio de ejecución de las consultas a la base de datos. Las consultas lentas impactan el rendimiento de ambas APIs.
  • db_disk_usage_gb: Espacio en disco utilizado por la base de datos. Importante para la planificación de capacidad.
  • db_replication_lag_seconds: (Si se usa replicación) Retraso entre la base de datos primaria y las réplicas. Un lag alto puede afectar la consistencia de los datos en las réplicas.

3. Métricas de API (Capa de Analítica)

Estas métricas evalúan el rendimiento y la disponibilidad de la API de Analítica.

  • api_request_count: Número total de solicitudes recibidas por la API de Analítica.
  • api_error_rate_percentage: Porcentaje de solicitudes a la API que resultan en un error (ej. HTTP 5xx). Un valor alto indica problemas de estabilidad.
  • api_response_time_ms: Tiempo promedio que tarda la API en responder a una solicitud. Un tiempo de respuesta alto afecta la experiencia del usuario.
  • api_cache_hit_rate_percentage: (Si se usa caché) Porcentaje de solicitudes que son servidas desde la caché. Un hit rate alto indica que la caché está siendo efectiva.
  • api_throttled_requests_count: Número de solicitudes que fueron limitadas por el throttling. Indica si los límites de tasa están siendo alcanzados.

4. Métricas de Negocio / Dominio

Estas métricas son específicas del negocio P2P y proporcionan insights sobre el mercado.

  • average_spread_percentage: El spread promedio entre ofertas de compra y venta para pares de activo/fiat específicos. Un KPI clave para la rentabilidad.
  • total_volume_traded_usd: Volumen total de criptomonedas (en equivalente USD) que se está ofertando en el mercado P2P.
  • active_advertisers_count: Número de comerciantes activos que publican ofertas.
  • payment_method_distribution: Distribución de las ofertas por método de pago. Útil para identificar la liquidez en diferentes canales.

Implementación de Métricas

Las métricas pueden ser recolectadas de varias maneras:

  • Logging: Los logs detallados pueden ser parseados para extraer métricas (ej. contando ocurrencias de ciertos mensajes).
  • Instrumentación de Código: Añadir contadores, medidores y temporizadores directamente en el código (ej. con librerías como Prometheus client para Python).
  • Herramientas de Monitoreo: Utilizar herramientas como Prometheus para recolectar métricas, Grafana para visualizarlas y Alertmanager para configurar alertas.

La función get_run_stats(db) y el endpoint /admin/monitoring/summary (descritos en la sección de Endpoint de Monitoreo) son ejemplos de cómo se exponen algunas de estas métricas directamente desde la API.

Un dashboard de monitoreo bien diseñado, alimentado por estas métricas, es esencial para mantener el P2P Dashboard funcionando de manera óptima y para identificar oportunidades de mejora.