Telemetría

El objetivo de la función de telemetría es recopilar métricas y establecer una infraestructura para visualizar información valiosa de la red. Algunas de las métricas que recopilamos en Interledger Foundation incluyen las siguientes:

La cantidad total de dinero transferido a través de paquetes de datos en un tiempo específico (diario, semanal, mensual).
El número de transacciones que han sido al menos parcialmente exitosas.
El número de paquetes ILP que fluyen a través de la red.
La cantidad promedio de dinero retenido en la red por transacción.
El tiempo promedio que tarda en completarse un pago saliente.

Nuestros objetivos son:

Hacer un seguimiento del crecimiento de la red en términos del tamaño de las transacciones y la cantidad de transacciones procesadas.
Utilizar los datos para nuestros propios análisis.
Permitirle obtener sus propios análisis.

Privacidad y opcionalidad

La privacidad es una preocupación primordial para Interledger Foundation. La función de telemetría de Rafiki está diseñada para proporcionar información valiosa de la red sin vulnerar la privacidad ni facilitar actividades maliciosas por parte de las ASE. Consulte la sección Privacidad a continuación para obtener más información.

Actualmente, la función de telemetría está habilitada de forma predeterminada en los entornos de prueba (entornos que no manejan dinero real). Cuando está activa, la función transmite métricas al recopilador de testnet. Puede optar por compartir sus métricas con un recopilador de livenet cuando opere en un entorno de livenet de producción (con dinero real). Independientemente del entorno, también puede optar por desactivar la telemetría por completo. Revise las variables de entorno de telemetría para obtener más información.

Arquitectura

Diagrama de arquitectura para la telemetría de Rafiki

OpenTelemetry (OTEL)

Interledger Foundation ha adoptado OpenTelemetry (OTEL) para garantizar el cumplimiento de un marco estandarizado compatible con una variedad de conjuntos de herramientas. OTEL permite utilizar las herramientas de análisis de datos que prefiera, mientras que Rafiki está instrumentado y puede observarse mediante un formato de métricas estandarizado.

Clúster de Elastic Container Service (ECS) de telemetría

El servicio de réplica de telemetría está alojado en AWS ECS Fargate y está configurado para la disponibilidad y el equilibrio de carga de las tareas de ECS personalizadas del recopilador ADOT (AWS Distro for OpenTelemetry).

Cuando opta por la telemetría, las métricas se envían a nuestro servicio de Telemetría. Para que pueda crear sus propias soluciones de telemetría, Rafiki instrumentado puede enviar datos a múltiples puntos finales. Esto permite integrar un contenedor local de OTEL Collector que puede admitir requisitos personalizados. La comunicación de métricas se facilita a través de gRPC.

SDK de OTEL - Instrumentación de Rafiki

El SDK de OTEL está integrado en Rafiki para crear, recopilar y exportar métricas. El SDK se integra a la perfección con el OTEL Collector.

Prometheus - AMP

Interledger Foundation utiliza Amazon Managed Service para Prometheus (AMP) para recopilar datos del clúster de telemetría.

Grafana - Grafana Cloud

Grafana Cloud se utiliza para paneles de visualización de datos y ofrece múltiples herramientas que amplían Promql de Prometheus.

Tipos de cambio

Para fines de telemetría, todos los importes recopilados por Rafiki instrumentado deben convertirse a una moneda base.

Si una ASE no proporciona el tipo de cambio necesario para una transacción, la solución de telemetría igualmente convierte el importe a la moneda base utilizando tipos de cambio externos. Una función Lambda en AWS recupera y almacena los tipos de cambio externos. La función se activa mediante un evento diario de CloudWatch y almacena los tipos de cambio en un bucket público de S3. El bucket de S3 no tiene control de versiones, y los datos se sobrescriben diariamente para garantizar aún más la privacidad.

Instrumentación

Rafiki tiene las siguientes métricas. Todos los puntos de datos (incrementos del contador) se exportan a los puntos finales de recopilación en un intervalo configurable. El intervalo predeterminado es de 15 segundos.

Métrica	Tipo	Descripción	Comportamiento
`transactions_total`	Contador	Cantidad de transacciones salientes financiadas	Aumenta en 1 por cada recurso de pago saliente financiado correctamente
`packet_count_prepare`	Contador	Cantidad de paquetes ILP Prepare enviados	Aumenta en 1 por cada paquete Prepare enviado
`packet_count_fulfill`	Contador	Cantidad de paquetes ILP Fulfill	Aumenta en 1 por cada paquete Fulfill recibido
`packet_count_reject`	Contador	Cantidad de paquetes ILP Reject	Aumenta en 1 por cada paquete Reject recibido
`packet_amount_fulfill`	Contador	Importe enviado a través de la red	Aumenta según el importe enviado en cada paquete ILP
`transaction_fee_amounts`	Contador	Importe de comisiones enviado a través de la red	Aumenta según el importe enviado menos el importe recibido por un pago saliente
`ilp_pay_time_ms`	Histograma	Tiempo para completar un pago ILP	Registra el tiempo necesario para realizar un pago ILP

La implementación actual solo recopila métricas en el lado de ENVÍO de una transacción. No se recopilan las métricas de las transacciones externas de Open Payments RECIBIDAS por una instancia de Rafiki en la red.

Privacidad

La telemetría de Rafiki está diseñada con un fuerte énfasis en la privacidad. El sistema anonimiza los datos de los usuarios y se abstiene de recopilar información identificable. Dado que las transacciones pueden originarse desde cualquier usuario hacia una instancia de Rafiki, las medidas de privacidad se implementan directamente en el origen (cada instancia de Rafiki). Esto significa que, a nivel individual, los datos ya son anónimos, ya que las instancias individuales de Rafiki procesan transacciones de múltiples usuarios.

Privacidad diferencial y privacidad diferencial local (LDP)

La privacidad diferencial es un sistema para compartir públicamente información sobre un conjunto de datos mediante la descripción de los patrones de los grupos en el conjunto de datos, sin revelar información sobre las personas incluidas en el conjunto de datos. La privacidad diferencial local (LDP) es una variante de la privacidad diferencial en la que se agrega ruido al punto de datos de cada persona antes de que este se envíe al servidor. Esto garantiza que el servidor nunca vea los datos reales, lo que proporciona una garantía de privacidad sólida.

Técnica de redondeo y agrupación por intervalos

La implementación de telemetría de Rafiki utiliza una técnica de redondeo que básicamente agrega múltiples transacciones en un mismo valor, lo que las hace indistinguibles. Esto se logra dividiendo los valores de las transacciones en intervalos y redondeando los valores al intervalo más cercano.

El tamaño del intervalo se calcula en función del valor bruto de la transacción. Para las transacciones de menor valor, que se espera que ocurran con mayor frecuencia, los tamaños de los intervalos se determinan de forma lineal para lograr una mayor granularidad. Sin embargo, después de un determinado umbral, el cálculo del tamaño del intervalo cambia a una función logarítmica para garantizar la privacidad de las transacciones de mayor valor (que son menos frecuentes pero suponen mayores preocupaciones de privacidad).

Para gestionar los valores atípicos, se implementa una técnica de recorte que limita los intervalos. Cualquier valor que supere un umbral determinado se coloca en un único intervalo. Asimismo, cualquier valor que se encuentre por debajo de un mínimo determinado también se coloca en un único intervalo. Esto garantiza que tanto los valores atípicos altos como los bajos no afecten de manera desproporcionada los datos generales, lo que proporciona mayores garantías de privacidad para estas transacciones.

Distribución de Laplace

La distribución de Laplace se utiliza con frecuencia en la privacidad diferencial debido a su propiedad de doble decaimiento exponencial. Esta propiedad garantiza que un pequeño cambio en los datos no afecte significativamente la distribución de probabilidad del resultado, lo que proporciona una garantía de privacidad sólida.

Para lograr la privacidad diferencial local (LDP), se selecciona ruido de la distribución de Laplace y se agrega a los valores redondeados. El ruido se genera en función de un parámetro de privacidad, que se calcula utilizando la sensibilidad de la función.

La sensibilidad de una función en la privacidad diferencial es la cantidad máxima en la que una única observación puede modificar el resultado de la función. En este caso, se considera que la sensibilidad es el valor máximo entre el valor redondeado y el tamaño del intervalo.

El parámetro de privacidad se calcula como una décima parte de la sensibilidad. Este parámetro controla el equilibrio entre privacidad y utilidad: un parámetro de privacidad más pequeño significa mayor privacidad pero menor utilidad, mientras que un parámetro de privacidad más grande significa menor privacidad pero mayor utilidad.

El ruido, seleccionado de la distribución de Laplace, se genera utilizando este parámetro de privacidad y luego se agrega al valor redondeado. Si el valor resultante es cero, se establece en la mitad del tamaño del intervalo para garantizar que el ruido no oculte por completo el valor de la transacción.

Conversión de moneda

Otro factor que oculta los datos confidenciales es la conversión de moneda. En las transacciones entre distintas monedas, usted, como ASE, proporciona los tipos de cambio internamente. De este modo, los tipos de cambio no se pueden correlacionar con una transacción individual. Si no proporciona o no puede proporcionar los tipos de cambio necesarios, se utiliza una API externa para los tipos de cambio. En este caso, los tipos de cambio obtenidos se sobrescriben con frecuencia, sin control de versiones ni acceso al historial. Esto introduce una capa adicional de ruido y protege aún más la privacidad de las transacciones.

Valores experimentales de las transacciones al utilizar el algoritmo

La siguiente tabla muestra los valores del algoritmo al ejecutar transacciones por diferentes importes. El valor bruto aumenta a medida que se desciende por las filas de la tabla. Todos los valores están en la escala 4.

Valor bruto	Tamaño del intervalo	Valor redondeado	Parámetro de privacidad	Ruido de Laplace	Valor final
8300	10000	10000	1000	2037	12037
13200	15000	15000	1500	1397	16397
147700	160000	160000	16000	-27128	132872
1426100	2560000	2560000	256000	-381571	2178429
1788200	2560000	2560000	256000	463842	3023842
90422400	10000000	90000000	1000000	2210649	92210649
112400400	10000000	100000000	1000000	407847	100407847
222290500	10000000	100000000	1000000	-686149	99313851

Referencias

La solución de telemetría de Rafiki es una combinación de técnicas descritas en diversos documentos técnicos sobre la recopilación de datos con preservación de la privacidad. Se puede obtener más información en los siguientes documentos:

Implementación de telemetría personalizada

Rafiki le permite crear su propia solución de telemetría basada en el formato de métricas estandarizado de OpenTelemetry (OTEL) que expone Rafiki.

Debe implementar su propio OTEL Collector que actúe como un contenedor sidecar para Rafiki, y luego proporcionar el punto final de ingesta del OTEL Collector para que Rafiki pueda comenzar a enviar métricas al recopilador.

Variables de entorno de telemetría

Obligatorio

Cuando la variable ENABLE_TELEMETRY está establecida en true, se requiere lo siguiente.

Nombre de la variable	Tipo	Descripción
`INSTANCE_NAME`	Cadena	Nombre de la instancia de Rafiki utilizado para comunicarse con fines de telemetría e interconexión automática. Para la telemetría, se utiliza para distinguir entre las diferentes instancias que envían datos al recopilador de telemetría.

Opcional

Nombre de la variable	Tipo	Descripción
`ENABLE_TELEMETRY`	Booleano	Habilita el servicio de telemetría en Rafiki. El valor predeterminado está establecido en `true`.
`LIVENET`	Booleano	Determina el destino al que se enviarán las métricas. El valor predeterminado está establecido en `false`, lo que hace que las métricas se envíen al OTEL Collector de testnet. Establezca este valor en `true` en entornos de producción que gestionan dinero real.
`OPEN_TELEMETRY_COLLECTOR_URLS`	Cadena	Un CSV de URL para OTEL Collectors (por ejemplo, `http://otel-collector-NLB-e3172ff9d2f4bc8a.elb.eu-west-2.amazonaws.com:4317,http://happy-life-otel-collector:4317`).
`OPEN_TELEMETRY_EXPORT_INTERVAL`	Número	Indica, en milisegundos, con qué frecuencia la instancia instrumentada de Rafiki debe enviar métricas. El valor predeterminado está establecido en `15000`.
`TELEMETRY_EXCHANGE_RATES_URL`	Cadena	Define el punto final que Rafiki consulta para obtener los tipos de cambio. Se utiliza como alternativa si/cuando no se proporcionan los tipos de cambio. Cuando se establece, el formato de respuesta de la API externa de tipos de cambio debe ser del tipo `rates`, tal como lo espera el servicio de tipos de cambio. Está establecido de forma predeterminada en `https://telemetry-exchange-rates.s3.amazonaws.com/exchange-rates-usd.json`, que apunta a un bucket público de S3 que tiene el formato requerido mencionado anteriormente, actualizado diariamente.

Ejemplo de imagen Docker de OTEL Collector y su configuración

A continuación, se muestra un ejemplo de una imagen Docker de OTEL Collector y su configuración, que se integra con Rafiki y envía datos a un punto final de escritura remota de Prometheus.

Puede probar la configuración en nuestro Local Playground agregando las variables de entorno indicadas en la tabla anterior a happy-life-backend en el archivo docker-compose.yml.

Configuración de Docker Compose

# Serves as example for optional local collector configuration
happy-life-otel-collector:
  image: otel/opentelemetry-collector-contrib:latest
  command: ['--config=/etc/otel-collector-config.yaml', '']
  environment:
  - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID-''}
  - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY-''}
  volumes:
  - ../collector/otel-collector-config.yaml:/etc/otel-collector-config.yaml
  networks:
  - rafiki
  expose:
  - 4317
  ports:
  - '13132:13133' # health_check extension

Configuración de OTEL Collector

Encontrará documentación complementaria en la documentación de configuración de OTEL Collector.

# Serves as example for the configuration of a local OpenTelemetry Collector that sends metrics to an AWS Managed Prometheus Workspace
# Sigv4auth required for AWS Prometheus Remote Write access (USER with access keys needed)

extensions:
  sigv4auth:
  assume_role:
    arn: 'arn:aws:iam::YOUR-ROLE:role/PrometheusRemoteWrite'
    sts_region: 'YOUR-REGION'

receivers:
  otlp:
  protocols:
    grpc:
    http:
      cors:
        allowed*origins:
          - http://*
          - https://\_

processors:
  batch:

exporters:
  logging:
  verbosity: 'normal'
  prometheusremotewrite:
  endpoint: 'https://aps-workspaces.YOUR-REGION.amazonaws.com/workspaces/ws-YOUR-WORKSPACE-IDENTIFIER/api/v1/remote_write'
  auth:
    authenticator: sigv4auth

service:
  telemetry:
  logs:
    level: 'debug'
  metrics:
    level: 'detailed'
    address: 0.0.0.0:8888
  extensions: [sigv4auth]
  pipelines:
  metrics:
    receivers: [otlp]
    processors: [batch]
    exporters: [logging, prometheusremotewrite]