Los tests gRPC te permiten monitorizar de forma proactiva tus servicios y sus servidores gRPC. Puedes elegir entre dos opciones:
Checks de comportamiento
Envía solicitudes gRPC a los endpoints de API de tus aplicaciones para verificar las respuestas y las condiciones definidas, como el tiempo de respuesta general, la cabecera o el contenido del cuerpo.
Checks de estado
Los checks de estado de gRPC son un estándar para informar sobre el estado de servicios gRPC. Determina si tus servidores y servicios gRPC responden, funcionan y son capaces de gestionar llamadas a procedimientos remotos (RPC).
Mediante la implementación de checks de estado de gRPC, puedes ejecutar tests de checks de estado de gRPC sin tener que proporcionar un archivo .proto a Datadog. Para obtener más información, consulta el archivo .proto de checks de estado de ejemplo compartido por la comunidad gRPC.
Los tests gRPC pueden ejecutarse tanto desde localizaciones gestionadas como de localizaciones privadas dependiendo de tu preferencia de ejecución de tests desde fuera o dentro de tu red. Los tests gRPC pueden ejecutarse de forma programada, bajo demanda o directamente dentro de tus pipelines CI/CD.
Puedes crear un test utilizando una de las siguientes opciones:
Crea un test a partir de una plantilla:
Pasa el ratón por encima de una de las plantillas ya rellenadas y haz clic en View Template (Ver plantilla). Se abrirá un panel lateral en el que se mostrará la información de configuración rellenada previamente, que incluye: detalles de tests, detalles de solicitudes, aserciones, condiciones de alerta y parámetros de monitor.
Haz clic en +Create Test (+Crear test) para abrir la página Definir solicitud, en la que podrás revisar y editar las opciones de configuración rellenadas previamente. Los campos presentados son idénticos a aquellos disponibles cuando se crea un test desde cero.
Haz clic en Save Details (Guardar detalles) para enviar tu test de API.
Crea un test desde cero:
Para crear un test desde cero, haz clic en la plantilla + Start from scratch (+ Empezar desde cero) y selecciona el tipo de solicitud gRPC.
Especifica el Host y el Puerto donde se ejecutará el test. De forma predeterminada, el puerto gRPC es 50051.
Selecciona Check de comportamiento para realizar una llamada unaria o Check de estado para realizar un check de estado.
Para un check de comportamiento, especifica la Reflexión del servidor o carga un Archivo Proto que define tu servidor gRPC. Selecciona un método e incluye un mensaje de solicitud. Datadog no admite métodos de streaming.
Para un check de estado, introduce el nombre del servicio. Deja este campo vacío, si quieres enviar un check de estado del servidor gRPC.
Tiempo de espera: Especifica la cantidad de tiempo en segundos antes de que se inicie un tiempo de espera en el test.
Ignorar error de certificado del servidor: Selecciona esta opción para que tu test gRPC continúe con la conexión, aunque se produzcan errores al validar el certificado SSL.
Metadatos gRPC: Añade y define metadatos para tu solicitud gRPC, para pasar metadatos entre servicios.
Certificado de cliente: Autentícate a través de mTLS cargando tu certificado de cliente (.crt) y la clave privada asociada (.key) en formato PEM.
Puedes utilizar la biblioteca openssl para convertir tus certificados. Por ejemplo, puedes convertir un certificado PKCS12 en certificados y claves privadas en formato PEM.
Añade etiquetas (tags) de entorno así como cualquier otra etiqueta a tu test gRPC. A continuación, puedes utilizar estas etiquetas para filtrar tus tests Synthetic en la página de monitorización Synthetic y tests continuos.
Haz clic en Invoke (Invocar) para probar la configuración de la solicitud. Aparecerá una vista previa de la respuesta en la parte derecha de la pantalla.
Haz clic en Create Test (Crear test) para enviar tu test de API.
When setting up a new Synthetic Monitoring API test, use snippets to automatically fill in basic auth, performance, and regions, rather than selecting these options manually. The following snippets are available:
Basic Auth: Automatically test your APIs using pre-populated basic auth headers, JavaScript, bearer token, and API/app key auth variables.
Performance: Automatically configure a test with the shortest frequency (one minute), perform a gRPC health check, and test for overall response time latency with a breakdown of network timing.
Regions: Automatically test your API endpoint against a location in each of the three primary geographic regions (AMER, APAC and EMEA).
Las aserciones definen cuál es el resultado esperado de un test. Después de hacer clic en Enviar, se añade una aserción response time basada en la respuesta obtenida. Debes definir al menos una aserción para que sea monitorizada por tu test.
Puedes crear hasta 20 aserciones por test de API haciendo clic en Nueva aserción o haciendo clic directamente en la vista previa de la respuesta:
Tipo
Operador
Tipo de valor
tiempo de respuesta
is less than
Entero (ms)
estado del check de estado
is, is not
Entero (ms)
Metadatos gRPC
is, is not, contains, does not contain, matches regex, does not match regex, does not exist
Entero (ms)
Puedes crear hasta 20 aserciones por test de API haciendo clic en Nueva aserción o haciendo clic directamente en la vista previa de la respuesta:
Si un test no contiene una aserción en el cuerpo de la respuesta, la carga útil del cuerpo cae y devuelve un tiempo de respuesta asociado para la solicitud dentro del límite de tiempo de espera establecido por el worker de Synthetics.
Si un test contiene una aserción en el cuerpo de la respuesta y se alcanza el límite de tiempo de espera, aparecerá el error Assertions on the body/response cannot be run beyond this limit.
Selecciona las Localizaciones desde donde ejecutar tu test gRPC. Los tests gRPC pueden ejecutarse desde localizaciones gestionadas y también privadas, en función de si prefieres ejecutar el test desde fuera o desde dentro de tu red.
Datadog’s out-of-the-box managed locations allow you to test public-facing websites and endpoints from regions where your customers are located.
Americas
APAC
EMEA
Canada Central (AWS)
Hong Kong (AWS)
Cape Town (AWS)
Northern California (AWS)
Mumbai (AWS)
Frankfurt (AWS)
Northern Virginia (AWS)
Seoul (AWS)
Ireland (AWS)
Ohio (AWS)
Singapore (AWS)
London (AWS)
Oregon (AWS)
Sydney (AWS)
Paris (AWS)
São Paulo (AWS)
Tokyo (AWS)
Stockholm (AWS)
Virginia (Azure)
Osaka (AWS)
Milan (AWS)
Jakarta (AWS)
Bahrain (AWS)
The Datadog for Government site (US1-FED) uses the following managed location:
De forma programada para garantizar que los servicios más importantes siempre resulten accesibles para tus usuarios. Selecciona la frecuencia con la que quieres que Datadog ejecute tu test gRPC.
En tus pipelines CI/CD para empezar a realizar envíos sin temer que un código defectuoso pueda afectar a la experiencia de tus clientes.
Bajo demanda para ejecutar tus tests cuando sea más conveniente para tu equipo.
When you set the alert conditions to: An alert is triggered if any assertion fails for X minutes from any n of N locations, an alert is triggered only if these two conditions are true:
At least one location was in failure (at least one assertion failed) during the last X minutes;
At one moment during the last X minutes, at least n locations were in failure.
Your test can trigger retries X times after Y ms in case of a failed test result. Customize the retry interval to suit your alerting sensibility.
Location uptime is computed on a per-evaluation basis (whether the last test result before evaluation was up or down). The total uptime is computed based on the configured alert conditions. Notifications sent are based on the total uptime.
A notification is sent by your test based on the alerting conditions previously defined. Use this section to define how and what to message your team.
Similar to how you configure monitors, select users and/or services that should receive notifications either by adding an @notification to the message or by searching for team members and connected integrations with the dropdown menu.
Show when the monitor matches priority (P1 to P5).
{{ ^is_priority }}
Show unless the monitor matches priority (P1 to P5).
Specify how often you want your test to re-send the notification message in case of test failure. To prevent renotification on failing tests, leave the option as Never renotify if the monitor has not been resolved.
Click Create to save your test configuration and monitor.
To create a local variable, click Create a Local Variable. You can select one of the following available builtins to add to your variable string:
{{ numeric(n) }}
Generates a numeric string with n digits.
{{ alphabetic(n) }}
Generates an alphabetic string with n letters.
{{ alphanumeric(n) }}
Generates an alphanumeric string with n characters.
{{ date(n unit, format) }}
Generates a date in one of Datadog’s accepted formats with a value corresponding to the UTC date the test is initiated at + or - n units.
{{ timestamp(n, unit) }}
Generates a timestamp in one of Datadog’s accepted units with a value corresponding to the UTC timestamp the test is initiated at +/- n units.
{{ uuid }}
Generates a version 4 universally unique identifier (UUID).
{{ public-id }}
Injects the Public ID of your test.
{{ result-id }}
Injects the Result ID of your test run.
To obfuscate local variable values in test results, select Hide and obfuscate variable value. Once you have defined the variable string, click Add Variable.
Un test se considera FAILED si no satisface una o más aserciones o si la solicitud ha fallado prematuramente. En algunos casos, el test puede fallar sin comprobar las aserciones respecto al endpoint.
El servidor remoto ha finalizado bruscamente la conexión. Entre las posibles causas se incluyen que el servidor web haya encontrado un error o falla al responder, o que se haya perdido la conectividad del servidor web.
DNS:
No se ha encontrado la entrada DNS para la URL del test. Entre las posibles causas se incluyen una URL de test mal configurada o una configuración incorrecta de las entradas DNS.
INVALID_REQUEST
La configuración del test no es válida (por ejemplo, un error tipográfico en la URL).
La solicitud no se ha podido completar en un plazo razonable. Pueden ocurrir dos tipos de TIMEOUT:
TIMEOUT: The request couldn't be completed in a reasonable time. indica que la duración de la solicitud ha alcanzado el tiempo de espera definido en el test (por defecto se define en 60 segundos).
Para cada solicitud, en la cascada de la red sólo se muestran las etapas completadas de la solicitud. Por ejemplo, en el caso de que sólo se muestre Total response time, el tiempo de espera se produjo durante la resolución DNS.
TIMEOUT: Overall test execution couldn't be completed in a reasonable time. indica que la duración del test (solicitud + aserciones) alcanza la duración máxima de 60,5 segundos.
De manera predeterminada, sólo los usuarios con los roles de administrador de Datadog y estándar de Datadog pueden crear, editar y eliminar tests gRPC Synthetic. Para crear, editar y eliminar tests gRPC Synthetic, actualiza tu usuario a uno de esos dos roles predeterminados.
Si utilizas la función rol personalizado, añade tu usuario a cualquier rol personalizado que incluya permisos de synthetics_read y synthetics_write.
