Saltar al contenido principal

Monitoreo

Una vez que tu nodo esté en funcionamiento, es importante mantener un ojo en él para asegurarte de que se mantenga a flote y siga contribuyendo a la salud de la red en general. Para ayudar con eso, Stellar Core expone información vital que puedes usar para monitorear tu nodo y diagnosticar problemas potenciales.

Puedes acceder a esta información utilizando comandos e inspeccionando la salida de Stellar Core. La primera mitad de esta página cubrirá este enfoque. También puedes conectar Prometheus para facilitar el monitoreo, combinarlo con Alertmanager para automatizar la notificación, y usar tableros preconstruidos de Grafana para crear representaciones visuales del bienestar de tu nodo.

información

Stellarbeat, un panel de monitoreo administrado por la comunidad, también puede ser útil para ver la salud de la red en su conjunto. Debes mantener un ojo muy atento en tu(s) nodo(s) usando algunas de las herramientas sugeridas en esta página, pero monitorear el rendimiento de todos los nodos de la red también puede ser útil para entender cómo interactúan todos entre sí.

Sin importar cómo decidas monitorear, lo más importante es que tengas un sistema en marcha para asegurarte de que tu integración siga funcionando.

Información General del Nodo​

Si ejecutas $ stellar-core http-command 'info', la salida se verá algo así:

{
  "info": {
    "build": "v20.4.0",
    "ledger": {
      "age": 0,
      "baseFee": 100,
      "baseReserve": 100000000,
      "closeTime": 0,
      "hash": "39c2a3cd4141b2853e70d84601faa44744660334b48f3228e0309342e3f4eb48",
      "maxTxSetSize": 100,
      "num": 1,
      "version": 20
    },
    "network": "Public Global Stellar Network ; September 2015",
    "peers": {
      "authenticated_count": 8,
      "pending_count": 2
    },
    "protocol_version": 20,
    "quorum": {
      "node": "GCRQF",
      "qset": {
        "agree": 22,
        "cost": 37256128,
        "delayed": 0,
        "disagree": 0,
        "fail_at": 6,
        "hash": "5c464e",
        "lag_ms": 1942,
        "ledger": 51251628,
        "missing": 1,
        "phase": "EXTERNALIZE"
      },
      "transitive": {
        "critical": null,
        "intersection": true,
        "last_check_ledger": 51251539,
        "node_count": 24
      }
    },
    "startedOn": "2024-04-15T16:16:25Z",
    "state": "Synced!"
  }
}

Algunos campos destacados de este punto final info son:

  • build: el número de versión para esta instancia de Stellar Core
  • ledger: una representación del estado local de tu nodo, que puede ser diferente del estado de la red si tu nodo estuvo desconectado de la red, por ejemplo. Algunos subcampos importantes:
    • age: tiempo transcurrido desde que este ledger se cerró (durante la operación normal menos de 10 segundos)
    • num: número del ledger
    • version: versión del protocolo de este ledger
  • network la frase secreta de la red para la red que esta instancia de core está usando
  • peers: información sobre la conectividad a la red
    • authenticated_count: el número de conexiones en vivo
    • pending_count: el número de conexiones que aún no están completamente establecidas
  • protocol_version: la versión máxima del protocolo que esta instancia reconoce
  • state: el estado de sincronización del nodo con respecto a la red
  • quorum: resumen del estado de los participantes del protocolo SCP, que es la misma información devuelta por el comando quorum (ver abajo).

Información del Usuario​

El comando peers devuelve información sobre los usuarios a los que tu nodo está conectado.

Esta lista es el resultado de conexiones entrantes de otros usuarios y conexiones salientes de este nodo a otros usuarios. Si se usa compact=false en el comando, también devuelve algunas métricas extras sobre cada usuario, como el número de mensajes descartados.

stellar-core http-command 'peers'

La salida se verá algo así:

{
  "authenticated_peers": {
    "inbound": [
      {
        "address": "18.234.41.75",
        "elapsed": 6,
        "flow_control": {
          "local_capacity": {
            "flood": 200,
            "reading": 200
          },
          "local_capacity_bytes": {
            "flood": 300000
          },
          "peer_capacity": 175,
          "peer_capacity_bytes": 291340
        },
        "id": "SDF 1",
        "latency": 172,
        "olver": 32,
        "ver": "stellar-core 20.4.0 (7fc7671b8bc1ccc3b1f16a6ab83bc9f671db8b70)"
      }
    ],
    "outbound": [
      {
        "address": "3.238.239.100:11625",
        "elapsed": 105,
        "flow_control": {
          "local_capacity": {
            "flood": 200,
            "reading": 200
          },
          "local_capacity_bytes": {
            "flood": 300000
          },
          "peer_capacity": 175,
          "peer_capacity_bytes": 291340
        },
        "id": "SDF 3",
        "latency": 172,
        "olver": 32,
        "ver": "stellar-core 20.4.0 (7fc7671b8bc1ccc3b1f16a6ab83bc9f671db8b70)"
      },
      {
        "address": "85.190.254.217:11625",
        "elapsed": 295,
        "flow_control": {
          "local_capacity": {
            "flood": 200,
            "reading": 200
          },
          "local_capacity_bytes": {
            "flood": 300000
          },
          "peer_capacity": 169,
          "peer_capacity_bytes": 288408
        },
        "id": "SatoshiPay Frankfurt",
        "latency": 282,
        "olver": 32,
        "ver": "stellar-core 20.4.0 (7fc7671b8bc1ccc3b1f16a6ab83bc9f671db8b70)"
      }
    ]
  },
  "pending_peers": {
    "inbound": ["211.249.63.74:11625", "45.77.5.118:11625"],
    "outbound": ["178.21.47.226:11625", "178.131.109.241:11625"]
  }
}

Encuesta de Topología de Overlay​

Hay un mecanismo de encuesta en el overlay que permite a un validador solicitar información de conexión de otros nodos en la red. La encuesta puede ser activada por un validador y se difundirá a través de la red como cualquier otro mensaje, pero solicitará información de otros nodos sobre a qué nodos está conectado y un breve resumen de sus volúmenes de tráfico por conexión.

Por defecto, un nodo retransmitirá o responderá a un mensaje de encuesta si el mensaje se originó desde un nodo en el quórum transitorio del nodo receptor. Este comportamiento puede ser anulado configurando el campo SURVEYOR_KEYS en el archivo de configuración a un conjunto más restrictivo de nodos para retransmitir o responder. Establece SURVIVOR_KEYS a ["$self"] para optar por no responder a las solicitudes de encuesta en su totalidad.

La encuesta funciona en dos fases: la fase de recolección y la fase de reporte. Durante la fase de recolección, los nodos registran información sobre sí mismos y sus usuarios, como el número de mensajes enviados a un usuario dado. Durante la fase de reporte, el encuestador solicita los resultados de la fase de recolección a los nodos en la red.

El encuestador comienza la fase de recolección transmitiendo un TimeSlicedSurveyStartCollectingMessage. El encuestador termina la fase de recolección e inicia la fase de reporte transmitiendo un TimeSlicedSurveyStopCollectingMessage. Estos mensajes de "inicio/parar recolección" aseguran que la fase de recolección sea aproximadamente igual en duración para todos los nodos presentes durante toda la fase de recolección. Recomendamos enviar el mensaje de "parar recolección" aproximadamente 20 minutos después del mensaje de "iniciar recolección". Si pasan 30 minutos sin recibir un mensaje de "parar recolección", la encuesta pasará automáticamente a la fase de reporte.

Además, los mensajes de "parar/iniciar recolección" contienen un campo nonce que identifica la instancia de la encuesta. El nonce en el mensaje de "parar recolección" debe coincidir con el nonce del mensaje de "iniciar recolección". El encuestador debe elegir un entero sin signo aleatorio de 32 bits para el nonce.

Durante la fase de reporte, el encuestador envía mensajes TimeSlicedSurveyRequestMessage a nodos individuales para reunir la información que el nodo registró durante la fase de recolección.

Script de Encuesta de Overlay​

Para simplificar la ejecución de una encuesta de overlay, stellar-core incluye un script OverlaySurvey.py en el directorio scripts. Este script recorre la red utilizando los puntos finales HTTP de la encuesta de overlay para construir un grafo que contiene la topología de la red de overlay. El script genera este grafo en formato JSON, así como en GraphML. Puedes analizar el archivo GraphML usando un visor de GraphML como Gephi.

Un ejemplo de uso del script de encuesta para ejecutar una encuesta de overlay es el siguiente:

$ python3 OverlaySurvey.py survey -n http://127.0.0.1:11626 -c 20 -sr sr.json -gmlw gmlw.graphml

Los argumentos que usa este ejemplo son:

  • subcomando survey - ejecutar encuesta y analizar
    • -n NODE, --node NODE - dirección del nodo de encuesta inicial
    • -c DURATION, --collectDuration DURATION - duración de la fase de recolección de la encuesta en minutos
    • -gmlw GRAPHMLWRITE, --graphmlWrite GRAPHMLWRITE - archivo de salida para el archivo graphml
    • -sr SURVEYRESULT, --surveyResult SURVEYRESULT - archivo de salida para los resultados de la encuesta

Por lo tanto, este ejemplo ejecutará una encuesta desde un nodo de stellar-core que se ejecuta en la máquina local con una duración de fase de recolección de 20 minutos y generará los resultados en sr.json y gmlw.graphml.

Adjuntarse a una Encuesta en Ejecución​

Usa la opción --startPhase para adjuntar el script a una encuesta que ya está en ejecución. Esto puede ser necesario si algo sucedió durante la ejecución del script que provocó que el script terminara antes de tiempo (como perder la conexión con el nodo encuestador). --startPhase tiene tres valores posibles:

  • startCollecting: iniciar una encuesta desde el principio de la fase de recolección. Este es el valor predeterminado cuando --startPhase no está especificado. Indica que te gustaría iniciar una nueva encuesta desde el principio (es decir, no estás adjuntando el script a una encuesta existente).
  • stopCollecting: transmitir inmediatamente un TimeSlicedSurveyStopCollectingMessage para la encuesta actualmente en ejecución y comenzar a encuestar a nodos individuales por resultados. Usa esta opción si tu encuesta está actualmente en la fase de recolección y deseas moverla a la fase de reporte.
  • surveyResults: comenzar a encuestar a nodos individuales por resultados. Usa esta opción si tu encuesta está en la fase de reporte.

Más Opciones del Script de Encuesta​

El script de encuesta contiene subcomandos y opciones adicionales para analizar aún más los resultados de la encuesta. Puedes encontrar una lista completa de subcomandos ejecutando:

$ python3 OverlaySurvey.py -h

A partir de ahí, puedes ejecutar:

$ python3 OverlaySurvey.py <subcommand> -h

para más información sobre cualquier subcomando dado.

Ejemplo de Comando de Encuesta Usando Puntos Finales HTTP​

Esta sección describe un ejemplo de ejecución de una encuesta de overlay llamando directamente a los puntos finales HTTP de la encuesta. Te recomendamos encarecidamente utilizar el script de encuesta de overlay en su lugar. Esta sección puede ser útil para cualquiera que quiera modificar el script de encuesta, o para cualquiera que tenga curiosidad sobre los detalles de bajo nivel de cómo funciona la encuesta y los datos que incluye.

En este ejemplo, tenemos tres nodos GBBN, GDEX y GBUI (los mencionaremos por las primeras cuatro letras de sus claves públicas). Ejecutaremos los comandos a continuación desde GBUI, y ten en cuenta que GBBN tiene SURVEYOR_KEYS=["$self"] en su archivo de configuración, por lo que GBBN no retransmitirá ni responderá a ningún mensaje de encuesta.

# 1. Begin the surveyor collecting phase
stellar-core http-command 'startsurveycollecting?nonce=1234'
# 2. Stop the surveyor collecting phase, and begin the reporting phase
stellar-core http-command 'stopsurveycollecting?nonce=1234'
# 3. Request survey results from the `GBBN` node
stellar-core http-command 'surveytopologytimesliced?node=GBBNXPPGDFDUQYH6RT5VGPDSOWLZEXXFD3ACUPG5YXRHLTATTUKY42CL&inboundpeerindex=0&outboundpeerindex=0'
# 4. Request survey results from the `GDEX` node
stellar-core http-command 'surveytopologytimesliced?node=GDEXJV6XKKLDUWKTSXOOYVOYWZGVNIKKQ7GVNR5FOV7VV5K4MGJT5US4&inboundpeerindex=0&outboundpeerindex=0'
# 3. Retrieve and display the results of issued survey commands
stellar-core http-command 'getsurveyresult'

Una vez que se reciban las respuestas, el comando getsurveyresult devolverá un resultado como este:

{
  "backlog": [],
  "badResponseNodes": null,
  "surveyInProgress": true,
  "topology": {
    "GBBNXPPGDFDUQYH6RT5VGPDSOWLZEXXFD3ACUPG5YXRHLTATTUKY42CL": null,
    "GDEXJV6XKKLDUWKTSXOOYVOYWZGVNIKKQ7GVNR5FOV7VV5K4MGJT5US4": {
      "inboundPeers": [
        {
          "bytesRead": 26392,
          "bytesWritten": 26960,
          "duplicateFetchBytesRecv": 0,
          "duplicateFetchMessageRecv": 0,
          "duplicateFloodBytesRecv": 10424,
          "duplicateFloodMessageRecv": 43,
          "messagesRead": 93,
          "messagesWritten": 96,
          "nodeId": "GBBNXPPGDFDUQYH6RT5VGPDSOWLZEXXFD3ACUPG5YXRHLTATTUKY42CL",
          "secondsConnected": 22,
          "uniqueFetchBytesRecv": 0,
          "uniqueFetchMessageRecv": 0,
          "uniqueFloodBytesRecv": 11200,
          "uniqueFloodMessageRecv": 46,
          "version": "v12.2.0-46-g61aadd29"
        },
        {
          "bytesRead": 32204,
          "bytesWritten": 31212,
          "duplicateFetchBytesRecv": 0,
          "duplicateFetchMessageRecv": 0,
          "duplicateFloodBytesRecv": 11200,
          "duplicateFloodMessageRecv": 46,
          "messagesRead": 115,
          "messagesWritten": 112,
          "nodeId": "GBUICIITZTGKL7PUBHUPWD67GDRAIYUA4KCOH2PUIMMZ6JQLNVA7C4JL",
          "secondsConnected": 23,
          "uniqueFetchBytesRecv": 176,
          "uniqueFetchMessageRecv": 2,
          "uniqueFloodBytesRecv": 14968,
          "uniqueFloodMessageRecv": 62,
          "version": "v12.2.0-46-g61aadd29"
        }
      ],
      "numTotalInboundPeers": 2,
      "numTotalOutboundPeers": 0,
      "maxInboundPeerCount": 64,
      "maxOutboundPeerCount": 8,
      "addedAuthenticatedPeers": 0,
      "droppedAuthenticatedPeers": 0,
      "p75SCPFirstToSelfLatencyMs": 72,
      "p75SCPSelfToOtherLatencyMs": 112,
      "lostSyncCount": 0,
      "isValidator": false,
      "outboundPeers": null
    }
  }
}

En este ejemplo, ten en cuenta que el nodo GBBN bajo el campo topology tiene un valor null porque está configurado para no responder al mensaje de encuesta.

Algunos campos destacados de este punto final getsurveyresult son:

  • backlog: lista de nodos para los cuales aún no se han enviado las solicitudes de encuesta.
  • badResponseNodes: lista de nodos que enviaron una respuesta malformada.
  • topology: mapa de nodos a información de conexión.
    • inboundPeers/outboundPeers: lista de información de conexión por nodos.
      • averageLatencyMs: latencia promedio con este usuario en milisegundos.
      • bytesRead: el número total de bytes leídos de este usuario.
      • bytesWritten: el número total de bytes escritos a este usuario.
      • duplicateFetchBytesRecv: el número de bytes recibidos que eran conjuntos de transacciones duplicados y conjuntos de quórum.
      • duplicateFetchMessageRecv: el conteo de conjuntos de transacciones duplicados y conjuntos de quórum recibidos de este usuario.
      • duplicateFloodBytesRecv: el número de bytes recibidos que eran duplicados de transacciones y votos del SCP.
      • duplicateFloodMessageRecv: el conteo de transacciones duplicadas y votos SCP recibidos de este usuario.
      • messagesRead: el número total de mensajes leídos de este usuario.
      • messagesWritten: el número total de mensajes escritos a este usuario.
      • nodeId: clave pública del nodo.
      • secondsConnected: el número total de segundos que este usuario ha estado conectado al nodo encuestado.
      • uniqueFetchBytesRecv: el número de bytes recibidos que eran conjuntos de transacciones y conjuntos de quórum únicos.
      • uniqueFetchMessageRecv: el conteo de conjuntos de transacciones y conjuntos de quórum únicos recibidos de este usuario.
      • uniqueFloodBytesRecv: el número de bytes recibidos que eran transacciones únicas y votos del SCP.
      • uniqueFloodMessageRecv: el conteo de transacciones únicas y votos SCP recibidos de este usuario.
      • version: versión de stellar-core.
  • numTotalInboundPeers/numTotalOutboundPeers: el número de usuarios entrantes y salientes a los que este nodo está conectado. La respuesta tendrá un subconjunto aleatorio de 25 usuarios conectados por dirección (entrante/saliente). Estos campos te indican si te faltan nodos para que puedas enviar otra solicitud para obtener otro subconjunto aleatorio de nodos.
  • maxInboundPeerCount/maxOutboundPeerCount: el número total de usuarios entrantes y salientes que este nodo puede aceptar. Estos campos corresponden a las configuraciones de stellar-core MAX_ADDITIONAL_PEER_CONNECTIONS y TARGET_PEER_CONNECTIONS, respectivamente.
  • addedAuthenticatedPeers: el número de usuarios autenticados añadidos.
  • droppedAuthenticatedPeers: el número de usuarios autenticados descartados.
  • p75SCPFirstToSelfLatencyMs: latencia del percentil 75 para escuchar sobre nuevos mensajes de SCP en milisegundos.
  • p75SCPSelfToOtherLatencyMs: latencia del percentil 75 para que otros nodos escuchen los mensajes SCP de este nodo en milisegundos.
  • lostSyncCount: el número de veces que este nodo perdió la sincronización.
  • isValidator: ¿Es este nodo un validador?

Salud del Quórum​

Para ayudar a los operadores de nodos a monitorear sus conjuntos de quórum y mantener la salud de la red en general, Stellar Core también proporciona métricas sobre otros nodos en tu conjunto de quórum. Debes monitorearlos para asegurarte de que estén funcionando y de que tu conjunto de quórum mantenga una buena superposición con el resto de la red.

Diagnósticos del Conjunto de Quórum​

El comando quorum te permite diagnosticar problemas con el conjunto de quórum del nodo local.

Si ejecutas:

stellar-core http-command 'quorum'

La salida se verá algo así:

{
  "node": "GCTSF",
  "qset": {
    "agree": 6,
    "cost": 20883268,
    "delayed": null,
    "disagree": null,
    "fail_at": 2,
    "fail_with": ["sdf_watcher1", "sdf_watcher2"],
    "hash": "d5c247",
    "lag_ms": {
      "sdf_watcher1": 192,
      "sdf_watcher2": 215,
      "sdf_watcher3": 79,
      "stronghold1": 321,
      "eno": 266,
      "tempo.eu.com": 225,
      "satoshipay": 249
    },
    "ledger": 24311847,
    "missing": ["stronghold1"],
    "phase": "EXTERNALIZE",
    "value": {
      "t": 3,
      "v": [
        "sdf_watcher1",
        "sdf_watcher2",
        "sdf_watcher3",
        {
          "t": 3,
          "v": ["stronghold1", "eno", "tempo.eu.com", "satoshipay"]
        }
      ]
    }
  },
  "transitive": {
    "critical": [["GDM7M"]],
    "intersection": true,
    "last_check_ledger": 24311536,
    "node_count": 21
  }
}

Esta salida tiene dos secciones principales: qset y transitive. La primera describe el nodo y su conjunto de quórum. La última describe el cierre transitivo del conjunto de quórum del nodo.

Información por Nodo del Conjunto de Quórum​

Entradas a observar en la sección qset, que describen el nodo y su conjunto de quórum, son:

  • agree: el número de nodos en el conjunto de quórum que parecen estar funcionando como se espera. El nodo local no tiene razón para creer que este nodo esté delayed, disagree o missing. Ten en cuenta que agree no tiene nada que ver con términos de SCP como "accept" o "confirming".
  • delayed: los nodos que están participando en el consenso pero parecen estar atrasados.
  • disagree: los nodos que están participando pero no están de acuerdo con esta instancia.
  • fail_at: el número de nodos fallidos que causarían que esta instancia se detenga.
  • fail_with: un ejemplo de tal fallo potencial.
  • missing: los nodos que parecen estar fuera durante esta ronda de consenso.
  • value: el conjunto de quórum utilizado por este nodo (t es el umbral expresado como un número de nodos).

En el ejemplo anterior, 6 nodos están funcionando correctamente, uno está fuera (stronghold1), y la instancia fallará si fallan algún par de nodos que todavía están funcionando (o un nodo y un conjunto de quórum interno).

Si un nodo está atascado en el estado Joining SCP, este comando permite encontrar rápidamente la razón:

  • demasiados validadores faltantes (fuera o sin buena conectividad), las soluciones son:
  • la división de la red causaría que el SCP se quedara atascado debido a nodos que no están de acuerdo. Esto ocurriría si hay un error en el SCP, la red no tiene intersección de quórum o los nodos en desacuerdo están comportándose mal (comprometidos, etc.).

Ten en cuenta que el nodo que no puede alcanzar consenso no significa que la red en su conjunto no pueda alcanzar consenso (y lo opuesto es cierto, la red puede fallar debido a un conjunto diferente de validadores que fallan).

Puedes obtener una idea de la salud del conjunto de quórum de un nodo diferente utilizando:

# the `NAME` of a validator
stellar-core http-command 'quorum?node=$sdf1'
# OR the `PUBLIC_KEY` of a validator
stellar-core http-command 'quorum?node=@GABCDE'

La salud general de la red se puede evaluar recorriendo todos los nodos y observando su salud. Ten en cuenta que esto es solo una aproximación, ya que los nodos remotos pueden no haber recibido los mismos mensajes (en particular: missing para otros nodos no es fiable).

Información resumida de cierre transitivo​

Al mostrar información del conjunto de quórum sobre el nodo local en lugar de otro nodo, también se proporciona un resumen del cierre transitivo del conjunto de quórum en el campo transitive. Esto tiene varios subcampos importantes:

  • last_check_ledger: el último ledger en el que se verificó el cierre transitivo para la intersección de quórum. Esto se restablecerá cuando el nodo arranque y cada vez que un nodo en el quórum transitivo cambie su conjunto de quórum. Puede retrasarse respecto al último ledger cerrado por varias ledgers dependiendo del coste computacional de verificar la intersección de quórum.
  • node_count: el número de nodos en el cierre transitivo, que se consideran al calcular la intersección de quórum.
  • intersection: si el cierre transitivo disfrutó o no de la intersección de quórum en la última verificación. Esto es de máxima importancia para prevenir divisiones en la red. Siempre debería ser cierto. Si alguna vez es falso, uno o más nodos en el cierre transitivo del conjunto de quórum están actualmente mal configurados, y la red está en riesgo de dividirse. Se deben tomar medidas correctivas de inmediato, para lo cual se presentarán dos subcampos adicionales para ayudar a sugerir remedios:
    • last_good_ledger: esto anotará el último ledger para el cual el campo intersection se evaluó como verdadero; si algún nodo se reconfiguró en o alrededor de ese ledger, revertir ese cambio de configuración es la acción correctiva más fácil de tomar.
    • potential_split: esto contendrá un par de listas de identificadores de validadores, que es un par potencial de quórums disjuntos permitidos por la configuración actual. En otras palabras, una posible división en el consenso permitida por la configuración actual. Esto puede ayudar a delimitar la causa de la mala configuración: probablemente involucra un umbral de consenso demasiado bajo en uno de los dos quórums potenciales, y/o la ausencia de una relación de confianza obligatoria que uniría a los dos.
  • critical: un campo de "advertencia anticipada" que lista los nodos que podrían causar que la red no disfrute de la intersección de quórum, si estuvieran mal configurados suficientemente. En una configuración de red transitoria saludable, este campo será null. Si no es null, entonces la red está esencialmente "una mala configuración" (de los conjuntos de quórum de los nodos listados) lejos de no disfrutar más de la intersección de quórum, y de nuevo, se deben tomar medidas correctivas: ajuste cuidadoso de los conjuntos de quórum de nodos que dependen de los nodos listados, típicamente para fortalecer quórums que dependen de ellos.

Análisis detallado del quórum transitorio​

El punto final de quórum también puede recuperar información detallada sobre el quórum transitorio. Este es un formato que es más fácil de procesar que lo que devuelve scp, ya que no contiene todos los mensajes de SCP.

stellar-core http-command 'quorum?transitive=true'

La salida se ve algo así como:

{
  "critical": null,
  "intersection": true,
  "last_check_ledger": 121235,
  "node_count": 4,
  "nodes": [
    {
      "distance": 0,
      "heard": 121235,
      "node": "GB7LI",
      "qset": {
        "t": 2,
        "v": ["sdf1", "sdf2", "sdf3"]
      },
      "status": "tracking",
      "value": "[ txH: d99591, ct: 1557426183, upgrades: [ ] ]",
      "value_id": 1
    },
    {
      "distance": 1,
      "heard": 121235,
      "node": "sdf2",
      "qset": {
        "t": 2,
        "v": ["sdf1", "sdf2", "sdf3"]
      },
      "status": "tracking",
      "value": "[ txH: d99591, ct: 1557426183, upgrades: [ ] ]",
      "value_id": 1
    },
    {
      "distance": 1,
      "heard": 121235,
      "node": "sdf3",
      "qset": {
        "t": 2,
        "v": ["sdf1", "sdf2", "sdf3"]
      },
      "status": "tracking",
      "value": "[ txH: d99591, ct: 1557426183, upgrades: [ ] ]",
      "value_id": 1
    },
    {
      "distance": 1,
      "heard": 121235,
      "node": "sdf1",
      "qset": {
        "t": 2,
        "v": ["sdf1", "sdf2", "sdf3"]
      },
      "status": "tracking",
      "value": "[ txH: d99591, ct: 1557426183, upgrades: [ ] ]",
      "value_id": 1
    }
  ]
}

La salida comienza con la misma información resumida que en el bloque transitive de la consulta no transitoria (si se consulta para el nodo local), pero también incluye un array nodes que representa un recorrido del quórum transitorio centrado en el nodo de consulta.

Los campos notables contenidos en esta respuesta son:

  • node: la identidad del validador
  • distance: cuán lejos está ese nodo del nodo raíz (es decir, cuántas saltos del conjunto de quórum)
  • heard: el último número de secuencia de ledger en el que este nodo emitió un voto
  • qset: el conjunto de quórum del nodo
  • status: uno de behind|tracking|ahead (comparado con el nodo raíz) o missing|unknown (cuando no hay mensajes recientes de SCP para ese nodo)
  • value_id: un ID único para lo que el nodo está votando (te permite saber rápidamente si los nodos están votando por lo mismo)
  • value: por lo que el nodo está votando

Usando Prometheus​

Monitorear stellar-core usando Prometheus es, con mucho, la solución más simple, especialmente si ya tienes un servidor Prometheus dentro de tu infraestructura. Prometheus es una base de datos de series temporales de código abierto y gratuito con un lenguaje de consulta simple pero increíblemente poderoso PromQL. Prometheus también está estrechamente integrado con Grafana, por lo que puedes renderizar visualizaciones complejas con facilidad.

Para que Prometheus capture métricas de la aplicación stellar-core, necesitarás instalar el stellar-core-prometheus-exporter (apt-get install stellar-core-prometheus-exporter) y configurar tu servidor Prometheus para capturar este exportador (puerto por defecto: 9473). Además, Grafana se puede usar para visualizar métricas.

Instalar un servidor Prometheus dentro de tu infraestructura​

Instalar y configurar un servidor Prometheus está fuera del alcance de este documento, sin embargo es un proceso bastante simple: Prometheus es un único binario en Go que puedes descargar desde https://prometheus.io/docs/prometheus/latest/installation/.

Instalar el stellar-core-prometheus-exporter​

El stellar-core-prometheus-exporter es un exportador que captura el punto final de métricas stellar-core (http://localhost:11626/metrics) y presenta estas métricas en el formato basado en texto de Prometheus disponible para que Prometheus las capture y las almacene en su base de datos de series temporales.

El exportador necesita ser instalado en cada nodo Stellar Core que desees monitorear.

apt-get install stellar-core-prometheus-exporter

Necesitarás abrir el puerto 9473 entre tu servidor Prometheus y todos tus nodos Stellar Core para que tu servidor Prometheus pueda capturar métricas.

Apunta Prometheus al stellar-core-prometheus-exporter​

Apuntar tu instancia de Prometheus al exportador se puede lograr configurando manualmente un trabajo de captura; sin embargo, dependiendo del número de hosts que necesites monitorear, esto puede volverse rápidamente complicado. Afortunadamente, el proceso también se puede automatizar utilizando varios complementos de "descubrimiento de servicios" de Prometheus. Por ejemplo, con una instancia alojada en AWS puedes usar el complemento ec2_sd_config.

Manual​

- job_name: "stellar-core"
  scrape_interval: 10s
  scrape_timeout: 10s
  static_configs:
    - targets: [
          "core-node-001.example.com:9473",
          "core-node-002.example.com:9473",
        ] # stellar-core-prometheus-exporter default port is 9473
    - labels:
      application: "stellar-core"

Usando descubrimiento de servicios (EC2)​

- job_name: stellar-core
  scrape_interval: 10s
  scrape_timeout: 10s
  ec2_sd_configs:
    - region: eu-west-1
      port: 9473
  relabel_configs:
    # ignore stopped instances
    - source_labels: [__meta_ec2_instance_state]
      regex: stopped
      action: drop
    # only keep with `core` in the Name tag
    - source_labels: [__meta_ec2_tag_Name]
      regex: "(.*core.*)"
      action: keep
    # use Name tag as instance label
    - source_labels: [__meta_ec2_tag_Name]
      regex: "(.*)"
      action: replace
      replacement: "${1}"
      target_label: instance
    # set application label to stellar-core
    - source_labels: [__meta_ec2_tag_Name]
      regex: "(.*core.*)"
      action: replace
      replacement: stellar-core
      target_label: application

Crear reglas de alerta​

Una vez que Prometheus capture métricas, podemos agregar reglas de alerta. Las reglas recomendadas están aquí (requieren Prometheus 2.0 o posterior). Copia las reglas en /etc/prometheus/stellar-core-alerting.rules en el servidor Prometheus y agrega lo siguiente al archivo de configuración de prometheus para incluir el archivo:

rule_files:
  - "/etc/prometheus/stellar-core-alerting.rules"

Las reglas están documentadas en línea, y recomendamos encarecidamente que revises y verifiques todas ellas, ya que cada entorno es diferente.

Configurar notificaciones usando Alertmanager​

Alertmanager es responsable de enviar notificaciones. Instalar y configurar un servidor Alertmanager está fuera del alcance de este documento, sin embargo, es un proceso bastante simple. La documentación oficial está aquí.

Todas las reglas de alerta recomendadas tienen la etiqueta de "severidad":

  • critical normalmente requiere atención inmediata. Indican una interrupción en curso o muy probable. Recomendamos que las alertas críticas notifiquen a los administradores 24x7
  • warning normalmente puede esperar hasta las horas laborables. Las advertencias indican problemas que probablemente no tengan impacto en producción, pero que pueden llevar a alertas críticas o interrupciones si se dejan sin manejar

El siguiente ejemplo de configuración de Alertmanager demuestra cómo enviar notificaciones utilizando diferentes métodos basados en la etiqueta de severidad:

global:
  smtp_smarthost: localhost:25
  smtp_from: [email protected]
route:
  receiver: default-receiver
  group_by: [alertname]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  routes:
    - receiver: critical-alerts
      match:
        severity: critical
    - receiver: warning-alerts
      match:
        severity: warning
receivers:
  - name: critical-alerts
    pagerduty_configs:
      - routing_key: <PD routing key>
  - name: warning-alerts
    slack_configs:
      - api_url: https://hooks.slack.com/services/slack/warning/channel/webhook
  - name: default-receiver
    email_configs:
      - to: alerts-[email protected]

En los ejemplos anteriores, las alertas con severidad "critical" se envían a pagerduty y las advertencias se envían a slack.

Exportadores útiles​

Puedes encontrar útiles los siguientes exportadores para monitorear tu infraestructura, ya que proporcionan una increíble información sobre el sistema operativo y las métricas de la base de datos. Instalar y configurar estos exportadores está fuera del alcance de este documento, pero debería ser relativamente sencillo.

  • node_exporter se puede utilizar para rastrear todas las métricas del sistema operativo.
  • postgresql_exporter se puede utilizar para monitorear la base de datos local de stellar-core.

Visualizar métricas usando Grafana​

Una vez que hayas configurado Prometheus para capturar y almacenar métricas de tu stellar-core, querrás una buena manera de representar estos datos para el consumo humano. Grafana ofrece la manera más sencilla y efectiva de lograr esto. Instalar Grafana está fuera del alcance de este documento, pero es un proceso muy simple, especialmente al usar los paquetes apt preconstruidos

Recomendamos que los administradores importen los siguientes dos tableros en sus implementaciones de Grafana:

  • Stellar Core Monitoring - muestra las métricas más importantes, el estado del nodo y trata de resaltar problemas comunes. Es un buen punto de partida para solucionar problemas
  • Stellar Core Full - muestra un resumen simple de salud así como todas las métricas expuestas por el stellar-core-prometheus-exporter. Es mucho más detallado que el Stellar Core Monitoring y puede ser útil durante la solución de problemas en profundidad