Solucionar problemas del agente de Monitoring

Esta página te ayuda a diagnosticar problemas en la instalación o la ejecución del agente de monitorización.

Lista de comprobación

Si tienes problemas para instalar o usar el agente de Monitoring, comprueba lo siguiente:

  • Si los comandos de instalación de Linux dan como resultado errores, asegúrate de prefijar los comandos de instalación con sudo.

  • Verifica que el servicio del agente se esté ejecutando en tu instancia de VM:

    • En una máquina virtual Windows, usa el siguiente comando de PowerShell:

      Get-Service -Name StackdriverMonitoring

      Busca un servicio llamado Stackdriver Monitoring. Si el agente no se está ejecutando, es posible que tengas que reiniciarlo.

    • En una VM de Linux, usa el siguiente comando:

      sudo service stackdriver-agent status

      Si el agente no se está ejecutando, es posible que tengas que reiniciarlo con el siguiente comando:

      sudo service stackdriver-agent restart

      Si el reinicio falla y el registro muestra "Disabled via metadata" (Inhabilitado mediante metadatos), es probable que estés ejecutando una imagen de Google Cloud Marketplace, donde el agente de Monitoring está inhabilitado de forma predeterminada. Esto se controla mediante la clave de metadatos de instancia google-monitoring-enable (con el valor 0). Para volver a habilitar el agente, quite esa clave o asigne el valor 1 (consulte Definir metadatos de instancia).

      Si el agente no se ha inhabilitado mediante metadatos, vuelve a instalarlo. Para obtener información sobre este proceso, consulta Reinstalar el agente de Monitoring.

  • Comprueba si el agente ha escrito mensajes de error en los registros.

    • En Windows, el agente de monitorización escribe mensajes en el registro de eventos de Windows.

    • En Linux, el agente de Monitoring es un paquete collectd y registra mensajes en /var/log/syslog o /var/log/messages. Los mensajes de registro tienen el prefijo collectd o stackdriver-agent:

      • Si ves errores HTTP 429, es posible que hayas superado las cuotas de la API Monitoring. Para ver la cuota disponible, selecciona APIs y servicios > Panel de control en laGoogle Cloud consola. Elige la API de Monitoring.

      • Si tienes problemas con el proxy, comprueba que hayas configurado correctamente el proxy HTTP. Las instrucciones forman parte de la sección Instalación en Linux y Windows.

      • Si tienes problemas de acceso o autorización a la API, o bien aparecen mensajes de error como "Unable to determine collectd endpoint" (No se puede determinar el endpoint de collectd), consulta la sección Verificar el proyecto y las credenciales.

      • Si ves errores del tipo "Unsupported collectd plugin/type combination" (Combinación de tipo o complemento de collectd no admitida) o "Unsupported collectd id" (ID de collectd no admitido) en los registros, es posible que estés enviando métricas de agente no admitidas. Esto puede ocurrir en los siguientes casos:

        • Has modificado una de las configuraciones de la aplicación de terceros del agente. Para deshacer los cambios, puedes volver a instalar la configuración del complemento específico siguiendo las instrucciones de la página de documentación correspondiente. Si quieres usar el agente para enviar esa métrica a Monitoring, considera la posibilidad de convertirla en una métrica definida por el usuario.

        • Uno de los complementos de la aplicación de terceros está enviando nuevas métricas que Monitoring no reconoce. Consulta la página de asistencia para obtener información sobre cómo enviar una solicitud para que se revisen y categoricen estas métricas.

  • Si el agente parece funcionar con normalidad, pero no recibes datos o tus políticas de alertas no actúan como crees que deberían, debes comprobar que el agente esté enviando datos al proyecto correcto. Consulta la sección Verificar el proyecto y las credenciales.

Verificar el proyecto y las credenciales

Si el agente de Monitoring informa de errores de acceso o autorización, o si el agente parece funcionar con normalidad, pero no hay datos o las políticas de alertas no funcionan como esperas, comprueba que las credenciales de tu instancia de VM sean correctas y que especifiquen el proyecto adecuado:

  • Si usas una instancia de VM de Compute Engine con credenciales estándar (no de clave privada), es poco probable que los datos se envíen al proyecto incorrecto, pero es posible que tus credenciales sigan siendo insuficientes. Para obtener información sobre las credenciales, consulta Autorizar el agente de Monitoring. Para verificar tus credenciales, consulta Verificar las credenciales de Compute Engine.

  • Si usas una instancia de VM de Amazon EC2 o credenciales de clave privada en tu instancia de Compute Engine, es posible que las credenciales no sean válidas o que pertenezcan al proyecto incorrecto. En el caso de las cuentas de AWS, el proyecto que usa el agente debe ser el Google Cloud proyecto al que envías las métricas. Para obtener información sobre las credenciales, consulta Autorizar el agente de monitorización. Para verificar tus credenciales, consulta Verificar credenciales de clave privada.

Si aún no has resuelto el problema, consulta Reinstalar el agente de monitorización.

Verificar las credenciales de Compute Engine

Usa la página Instancias de VM de Compute Engine de la consola de Google Cloud para comprobar que tu instancia de VM de Compute Engine tiene las credenciales adecuadas para el agente de Monitoring. Las credenciales se suelen añadir a la cuenta de servicio predeterminada de todas las instancias de VM de Compute Engine nuevas, pero es posible sobrescribir esos valores predeterminados al crear una instancia.

En la Google Cloud consola, ve a la página Instancias de VM:

Ve a Instancias de VM.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo sea Compute Engine.

  1. Si es necesario, cambia el proyecto actual Google Cloud para que sea el asociado a tu instancia de VM de Compute Engine. Por ejemplo, si se te pide que habilite la facturación, significa que el proyecto actual no tiene ninguna instancia de VM de Compute Engine.
  2. En la página Instancias de VM, haz clic en el nombre de tu instancia de VM. Aparecerá la página de detalles de la instancia de VM.
  3. En la página Detalles de la instancia de VM, busca la sección Ámbitos de acceso a la API Cloud:
    • Si ves el mensaje "Permitir el acceso completo a todas las APIs de Cloud", significa que tienes las credenciales adecuadas.
    • Si ves, junto a API Stackdriver Monitoring, un nombre anterior de la API Cloud Monitoring y tienes permiso Solo escritura o Completo, significa que tienes las credenciales adecuadas.
    • De lo contrario, la cuenta de servicio predeterminada de tu instancia no tendrá las credenciales que necesita el agente. Para usar el agente en tu instancia, debes añadir credenciales de cuenta de servicio de clave privada. Para obtener instrucciones, consulta Añadir credenciales.

Si tienes las credenciales predeterminadas correctas, ve a la sección Instalar en Linux y Windows.

Verificar credenciales de clave privada

Para verificar que las credenciales de clave privada válidas están instaladas en tu instancia de VM, primero comprueba que el archivo de credenciales se encuentra en la ubicación esperada y, a continuación, verifica que la información del archivo de credenciales es válida. Las credenciales que eran válidas anteriormente se pueden revocar en la sección IAM y administración > Cuentas de servicio de la consola de Google Cloud . Si no hay credenciales válidas, consulta la sección Añadir credenciales para sustituir las credenciales actuales o añadir nuevas.

¿Están presentes las credenciales?

Para comprobar si tu instancia tiene credenciales de cuenta de servicio con clave privada, ejecuta los siguientes comandos de Linux en tu instancia:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Si alguno de los comandos muestra un archivo como el que se muestra a continuación, es posible que tu instancia tenga credenciales de clave privada válidas. Si ambos comandos muestran un archivo, se usará el archivo indicado por GOOGLE_APPLICATION_CREDENTIALS.

{
  "type": "service_account",
  "project_id": "{your-project-id}",
  "private_key_id": "{your-private-key-id}",
  "private_key": "{your-private-key}",
  "client_email": "{your-project-number}-{your-key}@developer.gserviceaccount.com",
  "client_id": "{your-client-id}",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Si no hay ningún archivo de credenciales, consulta la sección Añadir credenciales.

¿Son válidas las credenciales?

En el archivo de credenciales, el campo project_id es tu Google Cloud proyecto, client_email identifica la cuenta de servicio del proyecto y private_key_id identifica la clave privada de la cuenta de servicio. Compara esta información con la que se muestra en la sección IAM y administración > Cuentas de servicio de la consolaGoogle Cloud .

El archivo de credenciales no es válido si se cumple alguna de las siguientes condiciones:

  • Estás comprobando una instancia de VM de Compute Engine, pero elGoogle Cloud proyecto del archivo de credenciales no es el proyecto que contiene tu instancia.
  • Estás comprobando una instancia de Amazon EC2, pero el proyecto Google Cloud del archivo de credenciales no es el proyecto Google Cloud al que envías las métricas desde tu cuenta de AWS.
  • La cuenta de servicio indicada no existe. Puede que se haya eliminado.
  • La cuenta de servicio que aparece en la lista no tiene habilitados los roles adecuados. Debe tener al menos roles/monitoring.metricWriter (Escritor de métricas de monitorización) para recoger métricas y roles/logging.logWriter (Escritor de registros) para escribir registros.
  • La clave privada no existe. Es posible que se haya revocado.

Si la cuenta de servicio está bien, pero la clave privada se ha revocado, puedes crear una clave privada nueva y copiarla en tu instancia. De lo contrario, debes crear una cuenta de servicio nueva, tal como se describe en la sección Añadir credenciales.

Generar credenciales

Si las credenciales no son válidas, sigue estos pasos:

  1. En cada proyecto conectado que contenga instancias que deban autorizarse con una clave privada (es decir, cada proyecto que contenga instancias de Compute Engine que se hayan creado sin incluir el ámbito de acceso https://www.googleapis.com/auth/monitoring.write), crea una cuenta de servicio y genera una clave privada, si aún no existen. Sigue estos pasos:

    1. En la Google Cloud consola, ve a la página  Configuración:

      Ve a Configuración.

      Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

    2. Selecciona la pestaña Ámbito de Netric.
    3. Identifica el proyecto que contiene los recursos de Compute Engine en cuestión y ve a la Google Cloud consola.
    4. Ve a la página Cuentas de servicio de gestión de identidades y accesos de la consola Google Cloud , selecciona tu proyecto, crea una cuenta de servicio y genera una clave privada para esa cuenta. Google Cloud

      Para llevar a cabo estos pasos, haz una de las siguientes acciones:

      • Ve a la página Cuentas de servicio de IAM, selecciona tu Google Cloud proyecto y, a continuación, sigue los pasos que se indican en Crear una cuenta de servicio:

        Ir a Cuentas de servicio de IAM

      • Haz clic en el botón siguiente y, a continuación, selecciona tu Google Cloud proyecto:

        Crear una cuenta de servicio y descargar la clave

        El botón anterior automatiza el proceso de crear y descargar una clave en tu sistema local para la cuenta de servicio específica del agente. Si es necesario, el proceso también crea la cuenta de servicio necesaria y se asegura de que tenga los permisos correctos. Las cuentas de servicio específicas de agentes tienen un nombre similar a stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. Se te notificará que se han completado estas acciones con un cuadro de diálogo similar al siguiente:

        Un banner que notifica al usuario que se han creado una cuenta de servicio y una clave.

  2. Sustituye la clave privada en las instancias que correspondan a la cuenta de servicio en cuestión.

    • En Linux, sustituye la clave privada ubicada en /etc/google/auth/application_default_credentials.json.
    • En Windows, sustituye la clave privada ubicada en C:\ProgramData\Google\Auth\application_default_credentials.json. Para obtener más información, consulta Copiar la clave privada en tu instancia.

  3. Reiniciar el agente

    • En Linux, ejecuta sudo service stackdriver-agent restart
    • En Windows, ve a la consola de gestión de servicios y reinicia el servicio Cloud Monitoring.

Si tienes varios proyectos que necesitan nuevas claves privadas, repite este procedimiento para cada uno de ellos.

Para verificar que la clave privada es correcta, consulta ¿Están presentes las credenciales? En concreto, este cambio afecta a las siguientes acciones:

  • Lee el archivo JSON de la clave privada en la instancia. Por ejemplo, en Linux: sudo cat /etc/google/auth/application_default_credentials.json
  • Asegúrate de que el valor del campo project_id coincida con el del proyecto monitorizado para el que acabas de generar las credenciales.

Verificar los datos del agente

Para verificar que el agente envía las métricas correctamente, usa el método timeSeries.list de la API Monitoring para buscar datos de series temporales recientes de la instancia de VM. Puedes llamar al método con el Explorador de APIs en la página de documentación del método. Si no ves ningún dato, puede que el agente esté enviando datos al proyecto incorrecto. Para comprobarlo, consulta Verificar el proyecto y las credenciales.

A continuación, se incluyen instrucciones detalladas para usar el método timeSeries.list:

  1. Determina el ID de instancia de la instancia de VM en la que has instalado el agente:

    • Instancias de Compute Engine: ve a la página de detalles de Compute Engine de tu instancia. En la parte inferior de la página, haz clic en REST equivalente. El ID es un número de 19 dígitos.

    • Instancias de Amazon EC2: el ID de cada instancia se muestra en la lista de instancias. El ID tiene el siguiente formato: i-1a2b3c4d.

  2. Ve a la página de documentación del método timeSeries.list.

  3. Rellena el formulario del Explorador de APIs:

    1. Asigna el valor name al proyecto que contiene tu instancia de VM, con el prefijo projects/. Por ejemplo, projects/[YOUR_PROJECT_ID].

    2. Define filter en la siguiente línea para elegir una métrica de agente de tu instancia de VM. Cópielo y péguelo en APIs Explorer. A continuación, cambie el ID de la instancia de VM:

      metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"

    3. Define el intervalo de tiempo de búsqueda. Quieres que haya un intervalo de unos cinco minutos:

      • Asigna a interval.endTime la hora GMT actual, que puedes consultar en time.is/GMT. La hora debe tener el formato del siguiente ejemplo. No incluyas la hora entre comillas:

        2016-10-31T14:10:00Z

      • Define interval.startTime como cinco minutos antes de la hora de finalización (aproximadamente) con el mismo formato.

    4. Deja el resto de los campos en blanco.

  4. Haz clic en la opción para ejecutar.

Deberías ver un resultado como el siguiente:

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

Si la llamada a la API devuelve datos de serie temporal de tu instancia de VM, como se muestra arriba, significa que tu agente funciona correctamente y has terminado.

Si no ves ningún dato de serie temporal, comprueba lo siguiente:

  • Si la llamada a la API devuelve un mensaje de error, no significa que haya un problema con el agente. Comprueba que los campos del Explorador de APIs estén rellenados correctamente:

    • Los errores "Invalid argument" probablemente indican que hay un problema con la ortografía y el formato del ID de proyecto, el filtro o las dos marcas de tiempo.

      Los requisitos de los argumentos de marca de tiempo dependen del tipo de métrica que especifiques. Un tipo de métrica registra datos GAUGE, DELTA o CUMULATIVE. Consulta MetricKind para obtener más información.

      En el caso de las métricas DELTA y CUMULATIVE, se deben indicar tanto la hora de inicio como la de finalización, y la hora de finalización debe ser posterior a la de inicio. Estos tipos de métricas registran los cambios medidos a lo largo del tiempo, por lo que las horas de inicio y de finalización deben definir un intervalo distinto de cero.

    • Los errores "No autorizado" pueden significar que has escrito mal el ID del proyecto.

    • Los errores "Not found" pueden indicar que has omitido el prefijo projects/obligatorio en el campo "name".

    Soluciona los problemas y vuelve a intentar la llamada a la API.

  • Si la llamada a la API se realiza correctamente, pero solo ves una respuesta vacía, { }, comprueba que el filtro y el intervalo de tiempo sean correctos. Si los formatos de las marcas de tiempo son incorrectos, no se devolverán datos. Si todo parece correcto, pero no recibes datos, significa que el agente no está enviando datos de métricas o, al menos, no al proyecto que esperas. Esto puede indicar que hay un problema con las credenciales. Consulta Verificar las credenciales de clave privada.

Reinstalar el agente de Monitoring

Instalar la versión más reciente del agente puede solucionar muchos problemas:

Determinar qué máquinas virtuales Linux tienen instalado el agente

  • Ejecuta una de las siguientes consultas para ver qué VMs Linux están ejecutando el agente:

    Ten en cuenta que, en cada consulta, debes introducir el nombre del proyecto y ajustar los límites de tiempo.

Reiniciar el agente automáticamente

Puedes configurar una secuencia de comandos para comprobar si el agente se está ejecutando y, a continuación, reiniciarlo en caso de que falle.

Por ejemplo, en Linux, puedes crear la siguiente entrada de crontab para comprobar el estado del agente cada 5 minutos:

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

Problemas conocidos

En las siguientes secciones se describen los problemas conocidos del agente de Monitoring.

Problema de acceso a datos de proceso (Windows)

Es posible que veas un mensaje de error del agente en el registro de eventos de Windows similar al siguiente:

Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)

Este mensaje indica que el agente no tiene acceso a estos datos en tu sistema. Para dejar de ver este mensaje, puedes conceder permisos suficientes al usuario SYSTEM para que lea los datos de los procesos y servicios que se indican en los mensajes de error. Si no necesitas estos datos, puedes ignorar estos mensajes informativos.

Problemas con la caché de metadatos (Linux)

Es posible que veas un mensaje de error en el archivo de registro del sistema Linux (/var/log/syslog en Debian o Ubuntu, o /var/log/messages en Red Hat, CentOS o SLES) similar al siguiente:

collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
value time = 1511345468.180; last cache update = 1511345468.180;
write_gcm: wg_update_stats failed.
write_gcm: uc_update returned an error.

Estos mensajes son advertencias inofensivas y no indican que se hayan perdido datos. Estos mensajes se generan mediante la implementación actual del complemento de procesos cuando hay una discrepancia en la marca de tiempo.

Se ha eliminado un punto de datos con un valor infinito (Linux)

Es posible que veas un mensaje de error en el archivo de registro del sistema Linux (/var/log/syslog en Debian o Ubuntu, o /var/log/messages en Red Hat, CentOS o SLES) similar al siguiente:

write_gcm: can not take infinite value

Este mensaje indica que se ha descartado un punto de datos con formato incorrecto. Normalmente, no supone ningún riesgo y se puede ignorar.

Problema de limitación de la clave de metadatos (Linux)

Es posible que veas un mensaje de error en el archivo de registro del sistema Linux (/var/log/syslog en Debian o Ubuntu, o /var/log/messages en Red Hat, CentOS o SLES) similar al siguiente:

collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed

Este mensaje indica que la actualización del estado de la limitación de memoria falla una vez. Normalmente, no es perjudicial, pero podría ser una señal de que el agente se está quedando sin memoria, sobre todo si ocurre con frecuencia.

Problema de cuota de la API de Cloud Monitoring (Linux)

Es posible que veas un mensaje de error en el archivo de registro del sistema Linux (/var/log/syslog en Debian o Ubuntu, o /var/log/messages en Red Hat, CentOS o SLES) similar al siguiente:

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

Este mensaje indica que se ha alcanzado el límite de cuota de la API Cloud Monitoring. Sigue la guía sobre Quota para obtener información sobre cómo gestionar tu límite de cuota.

Uso de memoria elevado debido a una COLLECTD_INTERVAL baja (Linux)

Es posible que el agente use mucha memoria cuando el COLLECTD_INTERVAL se configure para que sea más corto que el 60 seconds predeterminado (por ejemplo, 10 seconds). Esta es una limitación conocida del agente, ya que envía solicitudes de forma serial desde un solo hilo. Para evitarlo, puede reducir el COLLECTD_INTERVAL solo en un subconjunto de las métricas necesarias y dejar el resto de las métricas con el intervalo predeterminado.

Problema de desbordamiento de búfer de tokens (Linux)

Es posible que veas un mensaje de error en el archivo de registro del sistema Linux (/var/log/syslog en Debian o Ubuntu, o /var/log/messages en Red Hat, CentOS o SLES) similar al siguiente:

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

Estos mensajes indican que el agente de monitorización debe actualizarse a la versión 6.1.2 o una posterior.

El repositorio ha cambiado su valor "Origin" (Linux)

Es posible que veas un mensaje de error similar al siguiente al actualizar o instalar el agente, o al ejecutar apt-get update en Debian o Ubuntu Linux:

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

Este mensaje indica que es posible que la caché del repositorio de paquetes se haya desviado de su origen. Para solucionarlo, ejecuta el siguiente comando:

apt-get --allow-releaseinfo-change update

A continuación, vuelve a ejecutar la actualización o la instalación.

Se ha quitado el agente que la consola Google Cloud indicaba que estaba instalado

Después de desinstalar el agente, la consola Google Cloud puede tardar hasta una hora en registrar este cambio.

El agente de monitorización no aparece en la lista de programas para desinstalar de Windows

Para desinstalar el agente de monitorización cuando no aparece en la lista Desinstalar un programa del Panel de control de Windows, ejecuta uninstall.exe desde el directorio en el que lo hayas instalado.