En este documento se explica cómo encontrar datos de registro y cómo solucionar problemas de fallos de monitor sintético y de comprobación del tiempo de actividad:
- Buscar registros
- Solucionar problemas con las notificaciones
- Solucionar problemas de comprobaciones de disponibilidad públicas
- Solucionar problemas de comprobaciones de disponibilidad privadas
- Solucionar problemas de los monitores sintéticos
Buscar registros
En esta sección se explica cómo encontrar los registros de sus monitorizaciones sintéticas y comprobaciones de tiempo de actividad:
-
En la Google Cloud consola, ve a la página Explorador de registros:
Ve al Explorador de registros.
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
- En la barra de herramientas de la Google Cloud consola, selecciona tu Google Cloud proyecto. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
Sigue uno de estos métodos:
Para encontrar todos los registros asociados a tus monitores sintéticos o comprobaciones de tiempo de actividad, consulta por tipo de recurso. Puede usar el menú Recurso o introducir una consulta.
En el caso de las comprobaciones de tiempo de actividad, en el menú Recurso, seleccione URL de comprobación de tiempo de actividad o introduzca la siguiente consulta en el editor de consultas y, a continuación, haga clic en Ejecutar consulta:
resource.type="uptime_url"
En el caso de los monitores sintéticos, en el menú Recurso, selecciona Revisión de Cloud Run o introduce la siguiente consulta en el editor de consultas y, a continuación, haz clic en Ejecutar consulta:
resource.type="cloud_run_revision"
Para buscar los registros que contengan información sobre la respuesta recibida durante la ejecución de un monitor sintético o una comprobación del tiempo de actividad, haz lo siguiente:
Para hacer una consulta usando el ID del monitor sintético o de la comprobación de tiempo de actividad, utiliza el siguiente formato al introducir el ID en el editor de consultas y, a continuación, haz clic en Ejecutar consulta.
labels.check_id="my-check-id"
Para consultar los registros que contienen datos de respuesta de las solicitudes emitidas por monitores sintéticos y comprobaciones de tiempo de actividad, introduce la siguiente consulta en el editor de consultas y haz clic en Ejecutar consulta.
"UptimeCheckResult"
La consulta anterior coincide con todas las entradas de registro que incluyen la cadena
"UptimeCheckResult"
.
Estos registros incluyen lo siguiente:
ID del monitor sintético o de la comprobación de disponibilidad, que se almacena en el campo
labels.check_id
.En el caso de los monitores sintéticos, el nombre de tu función de Cloud Run, que se almacena en el campo
resource.labels.service_name
.Cuando se recogen datos de trazas, el ID de una traza asociada, que se almacena en el campo
trace
.
Para verificar que tu servicio ha recibido solicitudes de servidores Google Cloud , copia la siguiente consulta en el editor de consultas y haz clic en Ejecutar consulta:
"GoogleStackdriverMonitoring-UptimeChecks"
El campo
protoPayload.ip
contiene una de las direcciones usadas por los servidores de comprobación del tiempo de actividad. Para obtener información sobre cómo enumerar todas las direcciones IP, consulta Listar direcciones IP.
Solucionar problemas con las notificaciones
En esta sección se describen algunos errores que pueden surgir al configurar políticas de alertas y se proporciona información para resolverlos.
Una comprobación ha fallado, pero otras no
Estás revisando las métricas de comprobación del tiempo de actividad y observas que una de las comprobaciones ha fallado, mientras que el resto se han completado correctamente.
No es necesario que hagas nada para solucionar esta situación.
Si solo un comprobador informa de un fallo, es posible que se deba a que el comando del comprobador ha agotado el tiempo de espera debido a un problema de red. Es decir, en lugar de fallar, el comando no se completa en el tiempo de espera especificado.
Las políticas de alertas que usan la configuración predeterminada requieren fallos de al menos dos comprobadores para crear un incidente y enviar una notificación. Si un solo comprobador informa de un fallo, no se enviará ninguna notificación.
Has recibido una notificación y quieres depurar el error
Para identificar cuándo empezó el fallo, haz una de las siguientes acciones:
En el caso de las comprobaciones de disponibilidad, para determinar cuándo se ha producido el fallo, consulta la página Detalles de disponibilidad:
-
En la Google Cloud consola, ve a la página
Comprobaciones de tiempo de actividad:
Ve a Comprobaciones de disponibilidad del servicio.
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.
- En la barra de herramientas de la Google Cloud consola, selecciona tu Google Cloud proyecto. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
Busca y selecciona la comprobación de disponibilidad.
El gráfico Comprobaciones superadas muestra el historial de las comprobaciones. Para saber cuándo falló por primera vez la comprobación de disponibilidad, es posible que tengas que modificar el periodo del gráfico. El selector de periodo se encuentra en la barra de herramientas de la página Detalles del tiempo de actividad.
-
En el caso de los monitores sintéticos, para determinar cuándo se produjo el fallo, consulta la página Detalles del tiempo de actividad:
-
En la Google Cloud consola, ve a la página
Monitorización sintética:
Ve a Monitorización sintética.
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.
- En la barra de herramientas de la Google Cloud consola, selecciona tu Google Cloud proyecto. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
- Busca y selecciona el monitor sintético.
-
Para obtener información sobre cómo encontrar datos de registro asociados, consulta la sección Buscar registros de esta página.
No recibes ninguna notificación cuando falla una comprobación de disponibilidad del servicio
Has configurado una comprobación de disponibilidad y estás viendo la página Detalles de la disponibilidad de esa comprobación. Observas que el gráfico Comprobaciones superadas muestra que al menos una comprobación ha fallado. Sin embargo, no has recibido ninguna notificación.
De forma predeterminada, la política de alertas está configurada para crear un incidente y enviar una notificación cuando los comprobadores de al menos dos regiones no reciban una respuesta a una comprobación de disponibilidad. Estos errores deben producirse simultáneamente.
Puede editar la condición de la política de alertas para que se le notifique cuando una sola región no reciba una respuesta. Sin embargo, te recomendamos que uses la configuración predeterminada, que reduce el número de notificaciones que puedes recibir debido a fallos transitorios.
Para ver o editar una política de alertas, haz lo siguiente:
-
En la Google Cloud consola, ve a la página notifications Alertas:
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.
- En la barra de herramientas de la Google Cloud consola, selecciona tu Google Cloud proyecto. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
- En el panel Políticas, haga clic en Ver todas las políticas.
Busque la política que quiera ver o editar y haga clic en su nombre.
Puedes ver y editar la política en la página Detalles de la política.
Solucionar problemas de comprobaciones de disponibilidad del servicio públicas
En esta sección se describen algunos errores que pueden producirse al usar comprobaciones de tiempo de actividad públicas y se proporciona información para resolverlos.
Tus comprobaciones de disponibilidad públicas están fallando
Configuras una comprobación de disponibilidad pública, pero se produce un error al realizar el paso de verificación.
A continuación, se indican algunas de las posibles causas de un error en la comprobación del tiempo de actividad:
- Error de conexión: rechazada: si usas el tipo de conexión HTTP predeterminado, comprueba que tengas instalado un servidor web que responda a las solicitudes HTTP. Puede producirse un error de conexión en una instancia nueva si no has instalado un servidor web. Consulta la guía de inicio rápido de Compute Engine. Si utilizas el tipo de conexión HTTPS, es posible que tengas que seguir pasos de configuración adicionales. Si tienes problemas con el cortafuegos, consulta Mostrar direcciones IP de servidores de comprobaciones de disponibilidad del servicio.
- Nombre o servicio no encontrado: puede que el nombre de host sea incorrecto.
- 403 Forbidden: el servicio devuelve un código de error al comprobador de tiempo de actividad. Por ejemplo, la configuración predeterminada del servidor web Apache devuelve este código en Amazon Linux, pero devuelve el código 200 (Éxito) en otras versiones de Linux. Consulta el tutorial de LAMP para Amazon Linux o la documentación de tu servidor web.
- 404 No encontrado: puede que la ruta sea incorrecta.
- Tiempo de espera agotado de la solicitud (408) o no hay respuesta: es posible que el número de puerto sea incorrecto, que el servicio no se esté ejecutando, que no se pueda acceder al servicio o que el tiempo de espera sea demasiado bajo. Comprueba que tu cortafuegos permita el tráfico de los servidores de comprobación de disponibilidad del servicio. Consulta la lista de direcciones IP de servidores de comprobación de disponibilidad del servicio. El límite de tiempo de espera se especifica en las opciones de validación de respuestas.
Para ayudarte a solucionar problemas con las comprobaciones de disponibilidad públicas fallidas, puedes configurar tus comprobaciones de disponibilidad para que envíen hasta 3 pings ICMP durante la comprobación. Los pings pueden ayudarte a distinguir entre los errores causados, por ejemplo, por problemas de conectividad de red y por los tiempos de espera de tu aplicación. Para obtener más información, consulta Usar pings ICMP.
Solucionar problemas de comprobaciones de disponibilidad privadas
En esta sección se describen algunos errores que pueden producirse al usar comprobaciones de tiempo de actividad privadas y se proporciona información para resolverlos.
Fallo al crear una comprobación de disponibilidad del servicio
Es posible que la configuración de tu proyecto de Google Cloud impida que se modifiquen los roles asignados a la cuenta de servicio que usan las comprobaciones de tiempo de actividad para gestionar las interacciones con el servicio Service Directory. En esta situación, no se puede crear la comprobación de disponibilidad.
En esta sección se describe cómo puedes conceder los roles que requiere la cuenta de servicio:
Google Cloud consola
Cuando usas la Google Cloud consola para crear la comprobación de tiempo de actividad privada, la Google Cloud consola ejecuta los comandos para asignar los roles de Directorio de servicios a la cuenta de servicio.
Para obtener información sobre cómo asignar roles a una cuenta de servicio, consulta el artículo Autorizar la cuenta de servicio.
API: proyecto de alcance
La primera vez que crees una comprobación de tiempo de actividad privada para un servicio de Service Directory y recursos privados en un solo Google Cloud proyecto Google Cloud , la solicitud puede completarse correctamente o no. El resultado depende de si has inhabilitado la concesión automática de roles a las cuentas de servicio en tu proyecto:
La primera creación de una comprobación de tiempo de actividad se realiza correctamente si tu proyecto permite la concesión automática de roles a las cuentas de servicio. Se crea una cuenta de servicio y se le asignan los roles necesarios.
La primera creación de una comprobación de tiempo de actividad falla si tu proyecto no permite las concesiones automáticas de roles a las cuentas de servicio. Se crea una cuenta de servicio, pero no se le asigna ningún rol.
Si no se puede crear la comprobación de disponibilidad, haz lo siguiente:
- Autoriza la cuenta de servicio.
- Espera unos minutos a que se propaguen los permisos.
- Prueba a crear de nuevo la comprobación de tiempo de actividad privada.
API: proyecto monitorizado
La primera vez que creas una comprobación de tiempo de actividad privada que tiene como destino un servicio de Directory de servicios en un proyecto monitorizado o recursos privados en un proyecto de Google Cloud diferente, la solicitud falla y se crea una cuenta de servicio de Monitoring.
La forma de autorizar la cuenta de servicio depende del número deGoogle Cloud proyectos que utilices y de sus relaciones. Puede haber hasta cuatro proyectos implicados:
- El proyecto en el que has definido la comprobación de disponibilidad privada.
- El proyecto monitorizado en el que has configurado el servicio Directorio de servicios.
- El proyecto en el que has configurado la red de VPC.
- El proyecto en el que se configuran los recursos de red, como las máquinas virtuales o los balanceadores de carga. Este proyecto no tiene ningún rol en la autorización de cuentas de servicio que se describe aquí.
Si no se puede crear la primera comprobación de disponibilidad, haz lo siguiente:
- Autoriza la cuenta de servicio.
- Espera unos minutos a que se propaguen los permisos.
- Prueba a crear de nuevo la comprobación de tiempo de actividad privada.
Acceso denegado
Las comprobaciones de tiempo de actividad fallan y devuelven resultados VPC_ACCESS_DENIED
. Este resultado significa que algún aspecto de la configuración de tu red o de la autorización de la cuenta de servicio no es correcto.
Comprueba la autorización de tu cuenta de servicio para usar un proyecto de cobertura o un proyecto monitorizado, tal como se describe en Falla la creación de una comprobación de tiempo de actividad.
Para obtener más información sobre cómo acceder a redes privadas, consulta el artículo Configurar el proyecto de red.
Resultados anómalos de comprobaciones de disponibilidad privadas
Tienes un servicio de Service Directory con varias VMs y la configuración del servicio contiene varios endpoints. Cuando apagas una de las VMs, la comprobación del tiempo de actividad sigue indicando que se ha completado correctamente.
Si la configuración de tu servicio contiene varios endpoints, se elige uno al azar. Si la VM asociada al endpoint elegido está en ejecución, la comprobación del tiempo de actividad se realizará correctamente aunque una de las VMs esté inactiva.
Encabezados predeterminados
Tus comprobaciones de disponibilidad devuelven errores o resultados inesperados. Esto puede ocurrir si ha anulado los valores predeterminados de los encabezados.
Cuando se envía una solicitud de comprobación de tiempo de actividad privada a un endpoint de destino, la solicitud incluye los siguientes encabezados y valores:
Header | Valor |
---|---|
HTTP_USER_AGENT |
GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring) |
HTTP_CONNECTION |
keep-alive |
HTTP_HOST |
IP del endpoint de Service Directory |
HTTP_ACCEPT_ENCODING |
gzip , deflate , br |
CONTENT_LENGTH |
Se calcula a partir de los datos de publicación de la disponibilidad |
Si intentas anular estos valores, puede ocurrir lo siguiente:
- La comprobación de disponibilidad del servicio informa de errores
- Los valores de anulación se eliminan y se sustituyen por los valores de la tabla.
No se ven datos
No ves ningún dato en el panel de control de comprobación del tiempo de actividad cuando la comprobación del tiempo de actividad está en un proyecto diferente al del servicio Service Directory. Google Cloud
Asegúrate de que el Google Cloud proyecto que contiene la comprobación de tiempo de actividad monitoriza el Google Cloud proyecto que contiene el servicio Service Directory.
Para obtener más información sobre cómo enumerar los proyectos monitorizados y añadir otros, consulta el artículo Configurar un ámbito de métricas para varios proyectos.
Solucionar problemas de monitores sintéticos
En esta sección se proporciona información que puede ayudarte a solucionar problemas con tus monitores sintéticos.
Mensaje de error después de habilitar las APIs
Abres el flujo de creación de un monitor sintético y se te pide que habilites al menos una API. Después de habilitar las APIs, se mostrará un mensaje similar al siguiente:
An error occurred during fetching available regions: Cloud Functions API has not been used in project PROJECT_ID before or it is disabled.
En el mensaje de error se recomienda que verifiques que la API esté habilitada y, a continuación, que esperes y vuelvas a intentar realizar la acción.
Para comprobar que la API esté habilitada, vaya a la página APIs y servicios de su proyecto:
Una vez que hayas verificado que la API está habilitada, puedes continuar con el flujo de creación. La condición se resuelve automáticamente después de que la habilitación de la API se propague por el backend.
No se está haciendo un seguimiento de las solicitudes HTTP salientes
Configura tu monitor sintético para recoger datos de traza de las solicitudes HTTP de salida. Los datos de la traza solo muestran un intervalo, como se ve en la siguiente captura de pantalla:
Para resolver esta situación, asegúrate de que se haya concedido a tu cuenta de servicio el rol de agente de Cloud Trace (roles/cloudtrace.agent
).
También es suficiente con el rol Editor (roles/editor
).
Para ver los roles concedidos a tu cuenta de servicio, haz lo siguiente:
-
En la Google Cloud consola, ve a la página Gestión de identidades y accesos:
Ve a Gestión de identidades y accesos.
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo sea IAM y administrador.
- En la barra de herramientas de la Google Cloud consola, selecciona tu Google Cloud proyecto. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
- Selecciona Incluir concesiones de roles proporcionadas por Google.
Si la cuenta de servicio que usa tu monitor sintético no aparece en la lista o no tiene asignado un rol que incluya los permisos del rol Agente de Cloud Trace (
roles/cloudtrace.agent
), asigna este rol a tu cuenta de servicio.Si no sabes el nombre de tu cuenta de servicio, en el menú de navegación, selecciona Cuentas de servicio.
Estado En curso
En la página Monitores sintéticos se muestra un monitor sintético con el estado In progress
. El estado In progress
significa que el monitor sintético se ha creado recientemente y no hay datos que mostrar o que no se ha podido implementar la función.
Para determinar si la función no se ha desplegado, prueba lo siguiente:
Asegúrate de que el nombre de tu función de Cloud Run no contenga un guion bajo. Si hay un guion bajo, quítalo y vuelve a desplegar la función de Cloud Run.
Abre la página Detalles del monitor sintético del monitor sintético.
Si ves el siguiente mensaje, elimina el monitor sintético.
Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
El mensaje de error indica que la función se ha eliminado y, por lo tanto, el monitor sintético no puede ejecutarla.
Abre la página de Cloud Run Functions de la función. Para abrir esta página desde la página Detalles del monitor sintético, haz clic en Código y, a continuación, en el nombre de la función.
Si ves un mensaje similar al siguiente, significa que no se ha podido implementar la función.
This function has failed to deploy and will not work correctly. Please edit and redeploy
Para resolver este error, revisa el código de la función y corrige los errores que impiden que se compile o se implemente.
Cuando creas un monitor sintético, la función puede tardar varios minutos en desplegarse y ejecutarse.
Estado de la advertencia
En Monitores sintéticos se muestra un monitor sintético con el estado Warning
. El estado Warning
significa que los resultados de la ejecución no son coherentes. Esto podría indicar que hay un problema de diseño en la prueba o que el elemento que se está probando tiene un comportamiento incoherente.
Estado de error
En la lista Monitores sintéticos se muestra un monitor sintético con el estado Failing
. Para obtener más información sobre el motivo del fallo, consulta el historial de ejecuciones más reciente.
Si se muestra el mensaje de error
Request failed with status code 429
, significa que el destino de la solicitud HTTP ha rechazado el comando. Para solucionar este error, debe cambiar el destino de su monitor sintético.El endpoint
https://www.google.com
rechaza las solicitudes realizadas por monitores sintéticos.Si el error devuelve un tiempo de ejecución de
0ms
, es posible que la función de Cloud Run se quede sin memoria. Para solucionar este error, edita tu función de Cloud Run y aumenta la memoria a al menos 2 GiB. Después, asigna el valor1
al campo de CPU.
Falla al eliminar un monitor sintético
Usas la API Cloud Monitoring para eliminar un monitor sintético, pero la llamada a la API falla y devuelve una respuesta similar a la siguiente:
{ "error": { "code": 400, "message": "Request contains an invalid argument.", "status": "INVALID_ARGUMENT", "details": [ { "@type": "type.googleapis.com/google.rpc.DebugInfo", "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again." } ] } }
Para resolver el problema, elimine las políticas de alertas que monitorizan los resultados del monitor sintético y, a continuación, elimine el monitor sintético.
No se puede editar la configuración de un comprobador de enlaces rotos
Has creado un comprobador de enlaces rotos mediante la Google Cloud consola y quieres cambiar los elementos HTML que se prueban o modificar el tiempo de espera de URI, los reintentos, el tiempo de espera del selector y las opciones por enlace. Sin embargo, cuando editas el comprobador de enlaces rotos, la consola Google Cloud no muestra los campos de configuración.
Para solucionar este problema, sigue estos pasos:
-
En la Google Cloud consola, ve a la página
Monitorización sintética:
Ve a Monitorización sintética.
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.
- En la barra de herramientas de la Google Cloud consola, selecciona tu Google Cloud proyecto. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
- Busca el monitor sintético que quieras editar, haz clic en more_vert Más opciones y, a continuación, selecciona Editar.
- Haz clic en Editar función.
Edita el objeto
options
en el archivoindex.js
y, a continuación, haz clic en Aplicar función.Para obtener información sobre los campos y la sintaxis de este objeto, consulta
broken-links-ok/index.js
.Haz clic en Guardar.
Google Cloud La consola muestra que no se pueden guardar las capturas de pantalla
Has creado un comprobador de enlaces rotos y lo has configurado para que guarde capturas de pantalla. Sin embargo, la consola Google Cloud muestra uno de los siguientes mensajes de advertencia junto con información más detallada:
InvalidStorageLocation
StorageValidationError
BucketCreationError
ScreenshotFileUploadError
Para solucionar estos errores, prueba lo siguiente:
Si ves el mensaje
InvalidStorageLocation
, verifica que existe el segmento de Cloud Storage especificado en el campooptions.screenshot_options.storage_location
.Consulta los registros relacionados con tu función de Cloud Run. Para obtener más información, consulta el artículo sobre cómo buscar registros.
Verifica que la cuenta de servicio que se usa en la función de Cloud Run correspondiente tenga un rol de Gestión de Identidades y Accesos que le permita crear, acceder y escribir en segmentos de Cloud Storage.