Soluciona problemas del agente de Monitoring

En esta página, se te ayuda a diagnosticar problemas en la instalación o ejecución del agente de supervisión.

Lista de tareas

Si tienes problemas para instalar o usar el agente de Monitoring, aquí hay algunas cuestiones que debes verificar:

  • Si los comandos de instalación de Linux generan errores, asegúrate de usar el prefijo sudo en estos comandos.

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

    • Para una VM de Windows, usa el siguiente comando de PowerShell:

      Get-Service -Name StackdriverMonitoring

      Busca un servicio llamado Stackdriver Monitoring. Si el agente no se ejecuta, es posible que debas reiniciarlo.

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

      sudo service stackdriver-agent status

      Si el agente no se ejecuta, es posible que debas reiniciarlo con el siguiente comando:

      sudo service stackdriver-agent restart

      Si el reinicio falla, y el resultado del registro muestra el mensaje “Disabled via metadata” (Inhabilitado mediante metadatos), es probable que se esté ejecutando una imagen de Google Cloud Marketplace en la que 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, quita esa clave o configura el valor como 1 (consulta Establece metadatos de instancia).

      Si el agente no se inhabilitó mediante los metadatos, vuelve a instalarlo. Para obtener información sobre este proceso, consulta Vuelve a instalar el agente de Monitoring.

  • Observa si el agente escribió mensajes de error en los registros.

    • En Windows, el agente de Monitoring escribe mensajes en el registro de acontecimientos de Windows.

    • En Linux, el agente de Monitoring es un paquete collectd y registra los 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 excedido tus cuotas de la API de Monitoring. Para ver la cuota disponible, selecciona API y servicios > Panel en la consola de Google Cloud. Elige la API de Monitoring.

      • Si ves problemas con el proxy, verifica que hayas configurado tu proxy HTTP de forma correcta. Las instrucciones son parte de Instala en Linux y Windows.

      • Si ves problemas de autorización o acceso a la API, o mensajes de error como “No se puede determinar el extremo collectd”, consulta la siguiente sección: Verifica proyectos y credenciales.

      • Si ves errores en los registros de “No se admite la combinación de tipo o complemento de collectd” o “No se admite el ID de collectd”, es posible que hayas enviado métricas de agentes no admitidos. Esto puede suceder en las siguientes situaciones:

        • Modificaste una de las opciones de configuración de la aplicación de terceros del agente. Para revertir los cambios, puedes volver a instalar la configuración del complemento específico si sigues las instrucciones en la página de documentación relevante. Si deseas usar el agente para enviar esa métrica a Monitoring, considera convertirlos en métricas definidas por el usuario.

        • Uno de los complementos de las aplicaciones de terceros envía métricas nuevas desconocidas a Monitoring. Consulta la página de asistencia a fin de obtener detalles sobre cómo enviar una solicitud para que estas métricas se revisen y clasifiquen.

  • Si parece que el agente se ejecuta con normalidad, pero no obtienes datos o tus políticas de alertas no actúan como deberían, entonces debes verificar que el agente envíe los datos al proyecto correcto. Consulta la siguiente sección, Verifica proyecto y credenciales.

Verifica el proyecto y las credenciales

Si el agente de Monitoring informa errores de acceso o autorización, o si parece que el agente se ejecuta de forma normal, pero no hay datos o tus políticas de alertas no funcionan como esperabas, entonces deberías verificar si las credenciales de tu instancia de VM son correctas, incluso si especifican el proyecto correcto:

  • Si usas una instancia de VM de Compute Engine con credenciales estándar (no de clave privada), es poco probable que los datos vayan al proyecto incorrecto, pero tus credenciales aún pueden ser deficientes. Para obtener información sobre las credenciales, consulta Autoriza el agente de Monitoring. Si deseas verificar tus credenciales, consulta Verifica credenciales de Compute Engine.

  • Si usas una instancia de VM de Amazon EC2, o si usas credenciales de clave privada en tu instancia de Compute Engine, entonces las credenciales podrían no ser válidas o podrían ser del proyecto incorrecto. Para las cuentas de AWS, el proyecto que usa el agente debe ser el proyecto de Google Cloud al que envías las métricas. Para obtener información sobre las credenciales, consulta Autoriza el agente de Monitoring. Para verificar tus credenciales, consulta Verifica credenciales de clave privada.

Si aún no resolviste tu problema, consulta Vuelve a instalar el agente de Monitoring.

Verifica las credenciales de Compute Engine

Usa la página Instancias de VM de Compute Engine de la consola de Google Cloud para verificar que tu instancia de VM de Compute Engine tenga las credenciales adecuadas para el agente de Monitoring. Por lo general, las credenciales se agregan en la cuenta de servicio predeterminada de todas las nuevas instancias de VM de Compute Engine, pero es posible reemplazar esos valores predeterminados cuando creas una instancia.

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

Ir a Instancias de VM

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

  1. Si es necesario, cambia el proyecto actual de Google Cloud para que se asocie con tu instancia de VM de Compute Engine. Por ejemplo, si se te solicita Habilitar la facturación, significa que el proyecto actual no tiene ninguna instancia de VM de Compute Engine.
  2. En la página de Instancias de VM, haz clic en el nombre de tu instancia de VM. Aparecerá la página de detalles de tu instancia de VM.
  3. En la página Detalles de la instancia de VM, busca en el encabezado Permisos de acceso a la API de Cloud:
    • Si ves “Permitir acceso completo a todas las API de Cloud”, significa que tienes las credenciales adecuadas.
    • Si al lado de la API de Stackdriver Monitoring (un nombre anterior para la API de Cloud Monitoring) ves que tienes permiso de Solo escritura o Completo, entonces tienes las credenciales adecuadas.
    • De lo contrario, la cuenta de servicio predeterminada de tu instancia no tiene las credenciales que necesita el agente. Para usar el agente en tu instancia, debes agregar credenciales de cuenta de servicio de clave privada. Para obtener instrucciones, consulta Agrega credenciales.

Si tienes las credenciales predeterminadas correctas, ve directo a Instala en Linux y Windows.

Verifica las credenciales de clave privada

Para verificar que las credenciales válidas de clave privada estén instaladas en tu instancia de VM, primero verifica que el archivo de credenciales existe en tu ubicación esperada y luego que la información en el archivo de credenciales sea válida. Las credenciales que ya no son válidas se pueden revocar en la sección IAM y administración > Cuentas de servicio de la consola de Google Cloud. Si las credenciales válidas no están presentes, consulta Agrega credenciales para reemplazar las credenciales existentes o agregar nuevas.

¿Las credenciales están presentes?

Para ver si las credenciales de la cuenta de servicio de clave privada están en tu instancia, ejecuta los siguientes comandos de Linux en ella:

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 aparece a continuación, tu instancia podría tener credenciales de clave privada válidas. Si ambos comandos muestran un archivo, se usa 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 archivos de credenciales presentes, consulta Agrega credenciales.

¿Las credenciales son válidas?

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

El archivo de credenciales no es válido si se cumplen algunas de las siguientes condiciones:

  • Verificas una instancia de Compute Engine, pero el proyecto de Google Cloud en el archivo de credenciales no es el proyecto que contiene tu instancia.
  • Verificas una instancia de Amazon EC2, pero el proyecto de Google Cloud que figura en el archivo de credenciales no es aquel al que envías las métricas desde tu cuenta de AWS.
  • La cuenta de servicio de la lista no existe. Quizás se borró.
  • La cuenta de servicio listada no tiene las funciones correctas habilitadas. Debe tener al menos roles/monitoring.metricWriter (Escritor de métricas de Monitoring) para la recopilación de métricas y roles/logging.logWriter (Escritor de registros) para escribir registros.
  • La clave privada no existe. Quizás se revocó.

Si la cuenta de servicio es correcta, pero la clave privada se revocó, puedes crear una clave privada nueva y copiarla en tu instancia. De lo contrario, debes crear una cuenta de servicio nueva como se describe en la siguiente sección Agrega credenciales.

Genera credenciales nuevas

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

  1. Para cada proyecto conectado que contenga instancias que deban autorizarse con una clave privada (proyectos con instancias de Compute Engine que se crearon sin incluir el permiso de acceso https://www.googleapis.com/auth/monitoring.write), crea una cuenta de servicio y genera una clave privada, si aún no existen. Siga los pasos que se indican a continuación:

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

      Ir a Configuración

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

    2. Selecciona la pestaña Alcance de las métricas.
    3. Identifica el proyecto que contiene los recursos de Compute Engine en cuestión y ve a la consola de Google Cloud.
    4. Ve a la página Cuentas de servicio de IAM de la consola de Google Cloud, selecciona tu proyecto de Google Cloud, crea una cuenta de servicio nueva y, luego, genera una clave privada nueva para esa cuenta de servicio.

      Para seguir estos pasos, realiza una de las siguientes acciones:

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

        Ir a Cuentas de servicio de IAM

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

        Crea una cuenta de servicio y descarga una clave

        El botón anterior automatiza el proceso de creación y descarga de una clave a tu sistema local para la cuenta de servicio específica del agente. Si es necesario, el proceso también crea la cuenta de servicio requerida y garantiza que la cuenta de servicio tenga los permisos correctos. Las cuentas de servicio específicas del agente tienen un nombre similar a stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. Recibirás una notificación de la finalización de estas acciones con un cuadro de diálogo similar al siguiente:

        Un banner que notifica al usuario que se creó una cuenta de servicio y una clave.

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

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

  3. Reinicia el agente

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

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

Para verificar que la clave privada es correcta, consulta ¿Las credenciales están presentes? En particular, haz lo siguiente:

  • Lee el archivo JSON de claves privadas 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 supervisado para el que acabas de generar las credenciales.

Verifica los datos del agente

Para verificar que el agente envíe las métricas de forma correcta, usa el método timeSeries.list de la API de Monitoring a fin de buscar datos de series temporales recientes de la instancia de VM. Puedes llamar al método con el Explorador de API en la página de documentación del método. Si no ves ningún dato, es posible que el agente envíe los datos al proyecto incorrecto. Para comprobarlo, consulta Verifica proyectos y credenciales.

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

  1. Determina el ID de instancia de la instancia de VM donde instalaste el agente:

    • Instancias de Compute Engine: Ve a la página de detalles de Compute Engine para 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 para cada instancia se muestra en la lista de instancias. El ID es similar a i-1a2b3c4d.

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

  3. Llena el formulario del Explorador de API:

    1. Establece un nombre para el proyecto que contiene tu instancia de VM, con el prefijo projects/. Por ejemplo, projects/[YOUR_PROJECT_ID].

    2. Establece el filtro en la siguiente línea para elegir una métrica de agente de tu instancia de VM. Cópialo y pégalo en el Explorador de API, y luego cambia el ID de instancia de VM:

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

    3. Establece el intervalo de tiempo de búsqueda. Quieres un intervalo de aproximadamente cinco minutos:

      • Configura interval.endTime a la hora GMT actual, que puedes encontrar en time.is/GMT. La hora debe tener un formato como el del siguiente ejemplo. No coloques comillas alrededor de la hora:

        2016-10-31T14:10:00Z

      • Configura el interval.startTime aproximadamente cinco minutos antes de la hora de finalización con el mismo formato.

    4. Deja todos los otros campos en blanco.

  4. Haz clic en 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 muestra datos de series temporales de tu instancia de VM, como se muestra arriba, entonces tu agente funciona correctamente y habrás finalizado.

Si no ves ningún dato de series temporales, verifica lo siguiente:

  • Si tu llamada a la API da como resultado un mensaje de error, esto no indica un problema del agente. Comprueba que los campos del Explorador de API se hayan completado de forma correcta:

    • Los errores de “argumento no válido” probablemente indican un problema con la ortografía y el formato del ID del proyecto, el filtro o las dos marcas de tiempo.

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

      Para las métricas DELTA y CUMULATIVE, se requieren las horas de inicio y 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 finalización deben definir un intervalo distinto de cero.

    • Los errores de “No autorizado” pueden significar que el ID del proyecto no se escribió de manera correcta.

    • Los errores de “No encontrado” pueden indicar que omitiste el prefijo projects/ obligatorio en el campo “nombre”.

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

  • Si la llamada a la API se realiza de forma correcta, pero solo ves una respuesta vacía, { }, verifica que el filtro y el intervalo de tiempo sean adecuados. Los errores en el formato de las marcas de tiempo pueden hacer que no se muestren datos. Si todo parece correcto, pero no obtuviste los datos, entonces el agente no envió los datos de métrica o al menos no al proyecto que esperabas. Esto podría indicar un problema de credenciales. Consulta Verifica credenciales de clave privada.

Reinstala el agente de Monitoring

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

Determina cuáles VM de Linux tienen el agente instalado

  • Ejecuta cualquiera de las siguientes consultas para ver qué VM de Linux ejecutan el agente:

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

Reinicia el agente de manera automática

Puedes configurar una secuencia de comandos para comprobar si el agente está en ejecución y, luego, reiniciarlo en caso de que falle.

Por ejemplo, en Linux, puedes crear la siguiente entrada de crontab para verificar 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 problemas conocidos por el agente de Monitoring.

Problema de acceso a los datos del proceso (Windows)

Es posible que veas un mensaje de error de agente en el registro de acontecimientos de Windows como el 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. Si deseas dejar de ver este mensaje, puedes otorgar los permisos necesarios al usuario SYSTEM para leer los datos del proceso de los procesos y servicios enumerados en los mensajes de error. Si no necesitas estos datos, puedes ignorar estos mensajes informativos.

Problemas de 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 son un indicador de pérdida de datos. La implementación del complemento de procesos actual genera estos mensajes cuando hay una discrepancia en la marca de tiempo.

Problema de datos de valor infinito que se quitaron (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 descarta datos con formato incorrecto. Por lo general, es inofensivo y se puede ignorar.

Problema de limitación de 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 de estado de la limitación de memoria falla una vez. Por lo general, es inofensivo, pero podría ser una señal de que el agente se está quedando sin memoria, en especial 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 alcanzó el límite de cuota de la API de Cloud Monitoring. Sigue las instrucciones de la guía de cuotas a fin de obtener información para administrar el límite de cuota.

Uso de memoria alto debido a COLLECTD_INTERVAL bajo (Linux)

Es posible que veas un uso alto de memoria del agente cuando COLLECTD_INTERVAL esté configurado para ser más corto que el 60 seconds predeterminado, por ejemplo, 10 seconds. Esta es una limitación conocida del agente porque envía solicitudes en serie desde un solo subproceso. A fin de solucionar este problema, considera reducir COLLECTD_INTERVAL solo un subconjunto de métricas obligatorias y dejar el resto de las métricas en el intervalo predeterminado.

Problema de desbordamiento del búfer de token (Linux)

Es posible que veas un mensaje de error en el archivo de registro del sistema de Linux (/var/log/syslog on Debian / Ubuntu or /var/log/messages on Red Hat / CentOS / 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 supervisión debe actualizarse a la versión 6.1.2 o una superior.

El repositorio cambió su valor de "Origin" (Linux)

Es posible que veas un mensaje de error similar al siguiente cuando actualices el agente, instales el agente o ejecutes apt-get update en Debian/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 la caché del repositorio de paquetes puede diferir de su fuente. Para hacer esto, ejecuta el siguiente comando:

apt-get --allow-releaseinfo-change update

Luego, ejecuta la actualización o vuelve a instalar.

Se quitó el agente que la consola de Google Cloud informó como instalado

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

El agente de Monitoring no aparece en la lista Desinstalar un programa de Windows

Para desinstalar el agente de Monitoring cuando no está en la lista Desinstalar un programa del panel de control de Windows, ejecuta uninstall.exe desde el directorio en el que lo instalaste.