Guía del administrador

El servicio RPC te permite comunicarte directamente con Soroban a través de una interfaz JSON RPC.

Por ejemplo, puedes desarrollar una aplicación y hacer que envíe una transacción, obtenga entradas de ledger y datos de eventos, o simule transacciones.

Alternativamente, puedes utilizar uno de los SDKs de cliente de Soroban, como el @stellar/stellar-sdk, que necesitará comunicarse con una instancia RPC para acceder a la red.

Ejecutar tu propia instancia para desarrollo

Para el desarrollo local, recomendamos descargar y ejecutar una instancia local a través de Docker Quickstart y ejecutar una red independiente o comunicarte con un Testnet de desarrollo en vivo.

advertencia

No recomendamos ejecutar la imagen Quickstart en producción. Consulta la sección desplegar tu propia instancia RPC.

La imagen Quickstart con el servicio RPC puede ejecutarse en una laptop estándar con 8GB de RAM y tiene requisitos mínimos de almacenamiento y CPU. Es un único contenedor que ejecuta todo lo que necesitas para probar contra una red completamente funcional. Contiene:

• Stellar Core - Software de nodo que ejecuta la red, coordina el consenso y finaliza los ledgers.
• [Servidor Stellar RPC] - Servidor JSON RPC para interactuar con contratos de Soroban.
• Servidor Horizon - API HTTP para acceder al estado del ledger y las transacciones históricas.
• Servidor Friendbot - API HTTP para crear y financiar nuevas cuentas en redes de prueba.

Independiente

Para ejecutar una red independiente local con la imagen de Docker Stellar Quickstart, ejecuta el siguiente comando:

docker run --rm -it \
    -p 8000:8000 \
    --name stellar \
    stellar/quickstart:testing \
    --standalone \
    --enable-soroban-rpc

Una vez que la imagen esté iniciada, puedes verificar su estado consultando la API de Horizon:

curl "http://localhost:8000"

Puedes interactuar con este nodo local utilizando el Stellar CLI. Primero, agrégalo como una red configurada:

stellar network add standalone \
    --rpc-url "http://localhost:8000/soroban/rpc" \
    --network-passphrase "Standalone Network ; February 2017"

Luego genera una identidad única (keypair pública/privada) y financia utilizando:

stellar keys generate alice

Identidades solo para pruebas

Es una buena práctica nunca usar las mismas claves para pruebas y desarrollo que usas para la red pública de Stellar. Genera nuevas claves para pruebas y desarrollo y evita usarlas para otros propósitos.

Ahora que tienes una red configurada y una identidad financiada, puedes usar estas dentro de otros comandos de Stellar CLI. Por ejemplo, desplegar un contrato:

stellar contract deploy \
    --wasm target/wasm32-unknown-unknown/release/[project_name].wasm \
    --source alice \
    --network standalone

O invocar un contrato:

stellar contract invoke \
    --id C... \
    --source alice \
    --network standalone \
    -- \
    hello \
    --to friend

Cuando termines con tu nodo independiente, puedes cerrarlo con ctrlc (no cmd). Esto eliminará completamente el contenedor (eso es lo que hace la opción --rm al comando docker), lo que significa que necesitarás volver a desplegar tu contrato y volver a financiar tu identidad la próxima vez que lo inicies. Si trabajas a menudo con nodos locales, es posible que desees crear scripts para facilitar estos pasos de inicialización. Por ejemplo, consulta el initialize.sh del dapp de ejemplo.

Testnet

Ejecutar tu propio nodo Testnet funciona de manera muy similar a ejecutar un nodo Quickstart, como se describió anteriormente. Necesitarás modificaciones menores para algunos comandos. Primero, necesitas --testnet para la instancia de docker, en lugar de --standalone:

docker run --rm -it \
    -p 8000:8000 \
    --name stellar \
    stellar/quickstart:testing \
    --testnet \
    --enable-soroban-rpc

Y querrás configurarla para usar con la opción --network en Stellar CLI:

stellar network add testnet \
    --rpc-url "http://localhost:8000/soroban/rpc" \
    --network-passphrase "Test SDF Network ; September 2015"

Reemplaza testnet en ese comando con el nombre de tu elección si deseas dejar el nombre testnet disponible para usarlo con un proveedor RPC público (consulta a continuación). O haz un uso inteligente de las configuraciones --global para proveedores públicos y configuraciones locales (hechas con el comando network add sin decorar arriba) para nodos locales.

Ahora puedes reemplazar --network standalone con --network testnet (o como lo nombraste) en todos tus comandos que necesiten una red, como los comandos deploy e invoke que se muestran arriba.

Futurenet

También puedes desarrollar tus contratos de Soroban contra la red Futurenet. Puedes elegir esto si deseas probar características de vanguardia que aún no han llegado a Testnet. Ejecutar tu propio nodo Futurenet funciona igual que ejecutar un nodo Testnet, como se describió anteriormente.

docker run --rm -it \
    -p 8000:8000 \
    --name stellar \
    stellar/quickstart:soroban-dev \
    --futurenet \
    --enable-soroban-rpc

Y querrás configurarla para usar con la opción --network en Stellar CLI:

stellar network add futurenet \
    --rpc-url "http://localhost:8000/soroban/rpc" \
    --network-passphrase "Test SDF Future Network ; October 2022"

Reemplaza futurenet en ese comando con el nombre de tu elección, si deseas dejar el nombre futurenet disponible para usarlo con un proveedor RPC público (consulta a continuación). O haz un uso inteligente de las configuraciones --global para proveedores públicos y configuraciones locales (hechas con el comando network add sin decorar arriba) para nodos locales.

Ahora puedes reemplazar --network standalone con --network futurenet (o como lo nombraste) en todos tus comandos que necesiten una red, como los comandos deploy e invoke que se muestran arriba.

Desplegar tu propia instancia RPC

Recomendamos las siguientes formas de desplegar tu propia instancia RPC:

1. Desplegar en Kubernetes usando Helm
2. Ejecutar la imagen docker stellar-rpc directamente

Requisitos de hardware

Para despliegues que esperan hasta 1000 solicitudes por segundo al Stellar RPC, recomendamos al menos 4GB de RAM y al menos un CPU de doble núcleo con velocidad de reloj de 2.4GHz.

Para despliegues que esperan entre 1000-10000+ solicitudes por segundo al Stellar RPC, recomendamos al menos 8GB de RAM y al menos un CPU de cuatro núcleos con velocidad de reloj de 2.4GHz.

Para todos los despliegues, recomendamos al menos 10GB de espacio de almacenamiento/disco.

Tipo de nodo	CPU	RAM	Disco	SKU de AWS	SKU de Google Cloud
Stellar RPC	2 vCPU	4-8 GB	30 GB de volumen persistente >= 3K IOPS	c5.large	n4-highcpu-2

* Suponiendo una ventana de retención de 7 días para el almacenamiento de datos.

Kubernetes con Helm

Si tu entorno de despliegue incluye infraestructura de Kubernetes, esta es la forma preferida de desplegar tu instancia RPC. Esto es lo que debes hacer:

1. Instala la herramienta de línea de comandos Helm (versión mínima 3)

2. Agrega el repositorio Stellar a la lista de repositorios del cliente helm, actualízalo a las versiones publicadas más recientes

helm repo add stellar https://helm.stellar.org/charts
helm repo update stellar

3. Desplegar la instancia RPC en Kubernetes usando nuestro gráfico Helm:

helm install my-rpc stellar/stellar-rpc \
--namespace my-rpc-namespace-on-cluster \
--set global.image.sorobanRpc.tag=20.0.0-rc4-40 \
--set sorobanRpc.ingress.host=myrpc.example.org \
--set sorobanRpc.persistence.enabled=true \
--set sorobanRpc.persistence.storageClass=default \
--set sorobanRpc.resources.limits.cpu=1 \
--set sorobanRpc.resources.limits.memory=2560Mi

Este ejemplo del uso del gráfico Helm destaca algunos aspectos clave:

• Establece el global.image.sorobanRpc.tag a una etiqueta del repositorio dockerhub stellar-rpc para la versión de imagen que deseas ejecutar. Consulta la página de versiones de software para encontrar la etiqueta correcta para la versión de Soroban que estás ejecutando.

• El servidor RPC almacena una ventana rotativa de datos recientes de ledgers de la red en disco. El tamaño de esos datos varía dependiendo de la red y sus volúmenes de transacción, pero se estima que está en un rango de 10 a 100 MB. Para asegurar que el pod RPC tiene acceso constante al espacio de almacenamiento en disco y al rendimiento de lectura/escritura, este ejemplo demuestra cómo habilitar opcionalmente el despliegue del gráfico Helm para utilizar un PersistentVolumeClaim (PVC) de 100MB de la clase de almacenamiento default en Kubernetes habilitando estos parámetros de persistencia:

--set sorobanRpc.persistence.enabled=true
--set sorobanRpc.persistence.storageClass=default

Por defecto, esto está deshabilitado (sorobanRpc.persistence.enabled=false) y el despliegue RPC utilizará almacenamiento efímero de pod a través de emptyDir, que probablemente será adecuado para volúmenes de transacción de futurenet y testnet. Sin embargo, vale la pena resaltar la compensación de no tener limitaciones de almacenamiento impuestas en el clúster (probablemente por debajo de 100MB).

• Los ajustes de red se definen en values.yaml, que actualmente establece la configuración de red específica para futurenet. Puedes sobrescribir este valor predeterminado y usar otros archivos values.yaml "enlatados" que se hayan publicado para otras redes. Por ejemplo, hay un archivo values-testnet.yaml para configurar el despliegue del servidor RPC con la red testnet. Incluye este parámetro --values en tu helm install para especificar la red deseada:

--values https://raw.githubusercontent.com/stellar/helm-charts/main/charts/soroban-rpc/values-testnet.yaml

• Configurar RPC para usar otras redes personalizadas se puede lograr descargando el values.yaml localmente y actualizando las configuraciones bajo sorobanRpc.sorobanRpcConfig y sorobanRpc.coreConfig. Esto es aplicable al conectarse a redes específicas diferentes de los archivos existentes como values.yaml, como tu propia red independiente. Incluye el archivo values.yaml local en helm install:

--values my-custom-values.yaml

• Verifica los valores predeterminados de LimitRange en el espacio de nombres objetivo en Kubernetes para el despliegue. LimitRange es opcional en la configuración del clúster. Si se define, asegúrate de que los valores predeterminados proporcionen al menos límites mínimos de recursos para el servidor RPC de 2.5Gi de memoria y 1 CPU. De lo contrario, incluye los límites explícitamente en el comando helm install a través de los parámetros sorobanRpc.resources.limits.*:

--set sorobanRpc.resources.limits.cpu=1
--set sorobanRpc.resources.limits.memory=2560Mi

Incluso si no estás desplegando Stellar RPC usando Kubernetes, los manifiestos generados por los gráficos aún pueden ser una buena referencia para mostrar cómo configurar y ejecutar Stellar RPC como un contenedor docker. Simplemente ejecuta el comando helm template para imprimir la configuración del contenedor en la pantalla:

helm template my-rpc stellar/stellar-rpc

Imagen de Docker

Si usar Kubernetes no es una opción, esta es la forma preferida de desplegar tu propia instancia RPC.

advertencia

Aunque tenemos una imagen Quickstart, es solo para desarrollo y pruebas locales. No es adecuada para despliegues de calidad de producción.

Aquí está cómo ejecutar la imagen docker stellar-rpc:

1. Descarga la imagen en la versión que deseas ejecutar desde las etiquetas:

docker pull stellar/stellar-rpc

2. Crea un archivo de configuración para Stellar Core. Aquí hay un archivo de configuración de ejemplo para Testnet:

HTTP_PORT=11626
PUBLIC_HTTP_PORT=false

NETWORK_PASSPHRASE="Test SDF Network ; September 2015"

DATABASE="sqlite3://stellar.db"

# Stellar Testnet Validators
[[HOME_DOMAINS]]
HOME_DOMAIN="testnet.stellar.org"
QUALITY="HIGH"

[[VALIDATORS]]
NAME="sdftest1"
HOME_DOMAIN="testnet.stellar.org"
PUBLIC_KEY="GDKXE2OZMJIPOSLNA6N6F2BVCI3O777I2OOC4BV7VOYUEHYX7RTRYA7Y"
ADDRESS="core-testnet1.stellar.org"
HISTORY="curl -sf http://history.stellar.org/prd/core-testnet/core_testnet_001/{0} -o {1}"

[[VALIDATORS]]
NAME="sdftest2"
HOME_DOMAIN="testnet.stellar.org"
PUBLIC_KEY="GCUCJTIYXSOXKBSNFGNFWW5MUQ54HKRPGJUTQFJ5RQXZXNOLNXYDHRAP"
ADDRESS="core-testnet2.stellar.org"
HISTORY="curl -sf http://history.stellar.org/prd/core-testnet/core_testnet_002/{0} -o {1}"

[[VALIDATORS]]
NAME="sdftest3"
HOME_DOMAIN="testnet.stellar.org"
PUBLIC_KEY="GC2V2EFSXN6SQTWVYA5EPJPBWWIMSD2XQNKUOHGEKB535AQE2I6IXV2Z"
ADDRESS="core-testnet3.stellar.org"
HISTORY="curl -sf http://history.stellar.org/prd/core-testnet/core_testnet_003/{0} -o {1}"

3. Ejecuta la imagen, asegurándote de montar un volumen en tu contenedor donde se almacena la configuración anterior. Un ejemplo para Testnet:

docker run -p 8001:8001 -p 8000:8000 \
-v <STELLAR_CORE_CONFIG_FOLDER>:/config stellar/stellar-rpc \
--captive-core-config-path="/config/<STELLAR_CORE_CONFIG_PATH>" \
--captive-core-storage-path="/var/lib/stellar/captive-core" \
--captive-core-use-db=true \
--stellar-core-binary-path="/usr/bin/stellar-core" \
--db-path="/var/lib/stellar/soroban-rpc-db.sqlite" \
--stellar-captive-core-http-port=11626 \
--friendbot-url="https://friendbot-testnet.stellar.org/" \
--network-passphrase="Test SDF Network ; September 2015" \
--history-archive-urls="https://history.stellar.org/prd/core-testnet/core_testnet_001" \
--admin-endpoint="0.0.0.0:8001" \
--endpoint="0.0.0.0:8000"

Configuración

Para producción, recomendamos ejecutar Stellar RPC con un archivo de configuración TOML en lugar de opciones de línea de comandos. Esto es similar a crear un archivo de configuración para Stellar-Core como hicimos previamente. Por ejemplo, usando nuestra imagen docker:

docker run -p 8001:8001 -p 8000:8000 \
-v <CONFIG_FOLDER>:/config stellar/stellar-rpc \
--config-path <RPC_CONFIG_FILENAME>

Puedes utilizar Stellar RPC mismo para generar un archivo de configuración inicial:

docker run stellar/stellar-rpc gen-config-file > soroban-rpc-config.toml

La configuración resultante debería verse así:

# Admin endpoint to listen and serve on. WARNING: this should not be accessible
# from the Internet and does not use TLS. "" (default) disables the admin server
# ADMIN_ENDPOINT = "0.0.0.0:8001"

# path to additional configuration for the Stellar Core configuration file used
# by captive core. It must, at least, include enough details to define a quorum
# set
# CAPTIVE_CORE_CONFIG_PATH = ""

# Storage location for Captive Core bucket data
CAPTIVE_CORE_STORAGE_PATH = "/"

# informs captive core to use on disk mode. the db will by default be created in
# current runtime directory of stellar-rpc, unless DATABASE=<path> setting is
# present in captive core config file.
# CAPTIVE_CORE_USE_DB = false

# establishes how many ledgers exist between checkpoints, do NOT change this
# unless you really know what you are doing
CHECKPOINT_FREQUENCY = 64

# SQLite DB path
DB_PATH = "soroban_rpc.sqlite"

# Default cap on the amount of events included in a single getEvents response
DEFAULT_EVENTS_LIMIT = 100

# Endpoint to listen and serve on
ENDPOINT = "0.0.0.0:8000"

# The friendbot URL to be returned by getNetwork endpoint
# FRIENDBOT_URL = ""

# comma-separated list of stellar history archives to connect with
HISTORY_ARCHIVE_URLS = []

# Ingestion Timeout when bootstrapping data (checkpoint and in-memory
# initialization) and preparing ledger reads
INGESTION_TIMEOUT = "30m0s"

# format used for output logs (json or text)
# LOG_FORMAT = "text"

# minimum log severity (debug, info, warn, error) to log
LOG_LEVEL = "info"

# Maximum amount of events allowed in a single getEvents response
MAX_EVENTS_LIMIT = 10000

# The maximum duration of time allowed for processing a getEvents request. When
# that time elapses, the rpc server would return -32001 and abort the request's
# execution
MAX_GET_EVENTS_EXECUTION_DURATION = "10s"

# The maximum duration of time allowed for processing a getHealth request. When
# that time elapses, the rpc server would return -32001 and abort the request's
# execution
MAX_GET_HEALTH_EXECUTION_DURATION = "5s"

# The maximum duration of time allowed for processing a getLatestLedger request.
# When that time elapses, the rpc server would return -32001 and abort the
# request's execution
MAX_GET_LATEST_LEDGER_EXECUTION_DURATION = "5s"

# The maximum duration of time allowed for processing a getLedgerEntries
# request. When that time elapses, the rpc server would return -32001 and abort
# the request's execution
MAX_GET_LEDGER_ENTRIES_EXECUTION_DURATION = "5s"

# The maximum duration of time allowed for processing a getNetwork request. When
# that time elapses, the rpc server would return -32001 and abort the request's
# execution
MAX_GET_NETWORK_EXECUTION_DURATION = "5s"

# The maximum duration of time allowed for processing a getTransaction request.
# When that time elapses, the rpc server would return -32001 and abort the
# request's execution
MAX_GET_TRANSACTION_EXECUTION_DURATION = "5s"

# maximum ledger latency (i.e. time elapsed since the last known ledger closing
# time) considered to be healthy (used for the /health endpoint)
MAX_HEALTHY_LEDGER_LATENCY = "30s"

# The max request execution duration is the predefined maximum duration of time
# allowed for processing a request. When that time elapses, the server would
# return 504 and abort the request's execution
MAX_REQUEST_EXECUTION_DURATION = "25s"

# The maximum duration of time allowed for processing a sendTransaction request.
# When that time elapses, the rpc server would return -32001 and abort the
# request's execution
MAX_SEND_TRANSACTION_EXECUTION_DURATION = "15s"

# The maximum duration of time allowed for processing a simulateTransaction
# request. When that time elapses, the rpc server would return -32001 and abort
# the request's execution
MAX_SIMULATE_TRANSACTION_EXECUTION_DURATION = "15s"

# Network passphrase of the Stellar network transactions should be signed for.
# Commonly used values are "Test SDF Future Network ; October 2022", "Test SDF
# Network ; September 2015" and "Public Global Stellar Network ; September 2015"
# NETWORK_PASSPHRASE = ""

# Number of workers (read goroutines) used to compute preflights for the
# simulateTransaction endpoint. Defaults to the number of CPUs.
PREFLIGHT_WORKER_COUNT = 16

# Maximum number of outstanding preflight requests for the simulateTransaction
# endpoint. Defaults to the number of CPUs.
PREFLIGHT_WORKER_QUEUE_SIZE = 16

# Maximum number of outstanding GetEvents requests
REQUEST_BACKLOG_GET_EVENTS_QUEUE_LIMIT = 1000

# Maximum number of outstanding GetHealth requests
REQUEST_BACKLOG_GET_HEALTH_QUEUE_LIMIT = 1000

# Maximum number of outstanding GetLatestsLedger requests
REQUEST_BACKLOG_GET_LATEST_LEDGER_QUEUE_LIMIT = 1000

# Maximum number of outstanding GetLedgerEntries requests
REQUEST_BACKLOG_GET_LEDGER_ENTRIES_QUEUE_LIMIT = 1000

# Maximum number of outstanding GetNetwork requests
REQUEST_BACKLOG_GET_NETWORK_QUEUE_LIMIT = 1000

# Maximum number of outstanding GetTransaction requests
REQUEST_BACKLOG_GET_TRANSACTION_QUEUE_LIMIT = 1000

# Maximum number of outstanding requests
REQUEST_BACKLOG_GLOBAL_QUEUE_LIMIT = 5000

# Maximum number of outstanding SendTransaction requests
REQUEST_BACKLOG_SEND_TRANSACTION_QUEUE_LIMIT = 500

# Maximum number of outstanding SimulateTransaction requests
REQUEST_BACKLOG_SIMULATE_TRANSACTION_QUEUE_LIMIT = 100

# The request execution warning threshold is the predetermined maximum duration
# of time that a request can take to be processed before a warning would be
# generated
REQUEST_EXECUTION_WARNING_THRESHOLD = "5s"

# HTTP port for Captive Core to listen on (0 disables the HTTP server)
STELLAR_CAPTIVE_CORE_HTTP_PORT = 11626

# path to stellar core binary
STELLAR_CORE_BINARY_PATH = "/usr/bin/stellar-core"

# Timeout used when submitting requests to stellar-core
STELLAR_CORE_TIMEOUT = "2s"

# URL used to query Stellar Core (local captive core by default)
# STELLAR_CORE_URL = ""

# Enable strict toml configuration file parsing. This will prevent unknown
# fields in the config toml from being parsed.
# STRICT = false

# configures the transaction retention window expressed in number of ledgers,
# the default value is 1440 which corresponds to about 2 hours of history
TRANSACTION_RETENTION_WINDOW = 1440

Ten en cuenta que la configuración generada contiene los valores predeterminados y debes sustituirlos con valores apropiados para ejecutar la imagen.

Construir desde fuente

Las instrucciones para construir Stellar RPC desde la fuente se pueden encontrar aquí.

Usar la instancia RPC

Puedes configurar Stellar CLI para usar un endpoint RPC remoto:

stellar network add --global testnet \
    --rpc-url https://soroban-testnet.stellar.org:443 \
    --network-passphrase 'Test SDF Network ; September 2015'

Y financiar tus cuentas/identidades con el Friendbot de acceso público:

curl "https://friendbot.stellar.org/?addr=$(stellar keys address alice)"

Consulta el consejo anterior sobre la expansión de comandos (esa es la nota sobre $(...)) si no estás usando una shell basada en bash.

advertencia

Cuando interactúes con la red en producción, deberías ejecutar tu propio stellar-rpc o utilizar un proveedor de infraestructura de terceros.

Verifica la instancia RPC

Después de la instalación, valdrá la pena verificar que la instalación de Stellar RPC está sana. Hay dos métodos:

1. Accede al endpoint de estado de salud del servicio JSON RPC usando un cliente HTTP
2. Usa nuestra imagen de prueba del sistema construida previamente como herramienta para ejecutar un conjunto de pruebas en vivo contra Stellar RPC

Endpoint del estado de salud

Si envías una solicitud HTTP JSON RPC a tu instancia en ejecución de Stellar RPC:

curl --location 'http://localhost:8000' \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc":"2.0",
"id":2,
"method":"getHealth"
}'

Deberías recibir una respuesta HTTP 200 si la instancia está sana:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "status": "healthy"
  }
}

Imagen de prueba del sistema

Esta prueba compilará, desplegará e invocará contratos de ejemplo a la red a la que está conectada tu instancia RPC. Aquí hay un ejemplo para verificar tu instancia si está conectada a Testnet:

docker run --rm -t --name e2e_test \
docker.io/stellar/system-test:soroban-preview11 \
--VerboseOutput true \
--TargetNetworkRPCURL <your rpc url here> \
--TargetNetworkPassphrase "Test SDF Network ; September 2015" \
--TargetNetworkTestAccountSecret <your test account StrKey encoded key here > \
--TargetNetworkTestAccountPublic <your test account StrKey encoded pubkey here> \
--SorobanExamplesGitHash v21.6.0

Asegúrate de configurar correctamente la prueba del sistema:

• Utiliza una etiqueta de prueba del sistema publicada que esté alineada con la versión desplegada de Stellar RPC. Para cada versión, se publicarán dos etiquetas para diferentes arquitecturas de CPU. Asegúrate de usar la etiqueta que coincida con la arquitectura de CPU de tu máquina host:
  • docker.io/stellar/system-test:<nombre de la versión> para máquinas con CPUs basadas en AMD/Intel
  • docker.io/stellar/system-test:<nombre de la versión>-arm64 para máquinas con CPUs ARM
• Establece --TargetNetworkRPCURL a tu URL HTTP RPC
• Establece --TargetNetworkPassphrase a la misma red a la que está conectada tu instancia RPC:
  • "Test SDF Network ; September 2015" para Testnet
  • "Test SDF Future Network ; October 2022" para Futurenet
• Establece --SorobanExamplesGitHash a la etiqueta de lanzamiento correspondiente en el repositorio de Ejemplos de Soroban
• Crea y financia una cuenta que se usará para propósitos de prueba en la misma red a la que está conectada tu instancia RPC
  • Esta cuenta necesita un pequeño saldo de XLM para enviar transacciones Soroban
  • Las pruebas se pueden ejecutar repetidamente con la misma cuenta
  • Establece --TargetNetworkTestAccountPublic a la clave pública codificada StrKey de la cuenta
  • Establece --TargetNetworkTestAccountSecret al secreto codificado StrKey de la cuenta

Monitorea la instancia RPC

Si ejecutas Stellar RPC con el --admin-endpoint configurado y expones el puerto, tendrás acceso a las métricas de Prometheus a través del endpoint /metrics. Por ejemplo, si el endpoint de administración es 0.0.0.0:8001 y estás ejecutando la imagen Docker de Stellar RPC:

curl localhost:8001/metrics

Verás muchas de las métricas predeterminadas de Go y de Procesos (precedidas por go_ y process_ respectivamente) tales como uso de memoria, uso de CPU, número de hilos, etc.

También exponemos métricas relacionadas con Stellar RPC (precedidas por soroban_rpc). Hay muchas, pero algunas notables son:

• soroban_rpc_transactions_count - cuenta de transacciones procesadas con una ventana deslizante de 10m
• soroban_rpc_events_count - cuenta de eventos procesados con una ventana deslizante de 10m
• soroban_rpc_ingest_local_latest_ledger - último ledger procesado
• soroban_rpc_db_round_trip_time_seconds - tiempo requerido para ejecutar la consulta SELECT 1 en la BASE DE DATOS

Stellar RPC también proporciona registro en la consola para:

• Actividad de inicio
• Ingestar, aplicar y cerrar ledgers
• Manejar solicitudes JSON RPC
• Cualquier error

Los registros tienen el formato:

time=<timestamp in YYYY-MM-DDTHH:MM:SS.000Z format> level=<debug|info|error> msg=<Actual message> pid=<process ID> subservice=<optional if coming from subservice>