Solucionar problemas del agente de Monitoring

En esta página, encontrarás ayuda para diagnosticar problemas en la instalación o ejecución del agente de Monitoring .

Lista de tareas

Si tienes problemas para instalar o usar el agente de Monitoring, estos son algunos aspectos que debes verificar:

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

  • 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 Reinstala 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 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 excedido tus cuotas de la API de Monitoring. Puedes ver tu cuota disponible si seleccionas API y servicios en la consola. 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 personalizadas.

        • 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 informa errores de acceso o autorización, o si parece que el agente se ejecuta normalmente, 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:

  • Para ver si los datos llegan a Monitoring, puedes leer algunos de los datos de las series temporales. Para obtener instrucciones, consulta Verifica la conexión de agente a proyecto. Si ves datos, entonces el problema no se relaciona con el agente.

  • 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 conector de AWS. 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 resuelves tu problema, consulta Vuelve a instalar el agente de Monitoring.

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]. Con las instancias de Amazon EC2, debes usar el proyecto de conector de AWS para tu cuenta de Amazon.

    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": "[GCP-OR-AWS-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.

Verifica las credenciales de Compute Engine

Usa la página Instancias de VM de Compute Engine de la consola a fin de 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.

Ir a la página Instancias de 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 de detalles de la instancia de VM, busca en el encabezado del nivel de acceso a la API de Cloud:
    1. Si ves “Permitir acceso completo a todas las API de Cloud”, significa que tienes las credenciales adecuadas.
    2. Si ves al lado de la API de Stackdriver Monitoring, un nombre anterior para la API de Cloud Monitoring, tienes Solo escritura o Completo, entonces tienes las credenciales adecuadas.
    3. 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 comprobar que las credenciales válidas de clave privada estén instaladas en tu instancia de VM, primero verifica que el archivo de credenciales exista en la 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 mediante la sección Cuentas de IAM y de administrador de la consola. 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, 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 que esta información coincida con lo que se muestra en la sección IAM & Admin &accounts de la consola.

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.
  • Verifica una instancia de Amazon EC2, pero el proyecto de Google Cloud en el archivo de credenciales no es el proyecto de conector de AWS para tu cuenta de AWS.
  • La cuenta de servicio de la lista no existe. Quizás se borró.
  • La cuenta de servicio que se muestra no tiene las funciones correctas habilitadas. Debe tener al menos roles/monitoring.metricWriter (escritor de métricas de Monitoring) para el agente de Monitoring y roles/logging.logWriter (escritor de registros) para el agente de Logging.
  • 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 (todos los proyectos del conector AWS y los proyectos de Compute Engine creados sin el alcance monitoring.write), crea una cuenta de servicio y genera una clave privada, si aún no existen. Sigue los pasos a continuación:

    1. Para ver la lista de proyectos conectados al alcance de tu métrica, ve a Monitoring:

      Ir a Monitoring

    2. En el panel de navegación de Monitoring, seleccione Configuración y, luego, la pestaña Resumen.

      • En el caso de AWS, usa el vínculo para ir directamente a Google Cloud Console del proyecto en cuestión.
      • Para Google Cloud, identifica el proyecto que contiene los recursos de Compute Engine en cuestión y navega a Google Cloud Console.
    3. En Google Cloud Console, navega a la página Cuentas de servicio de IAM.

    4. Crea una cuenta de servicio nueva y genera una clave privada nueva para ella.

      El enfoque más simple es descargar una clave privada con la configuración correcta. Esta clave se puede obtener mediante la modificación de la URL de la página actual: agrega &createStackdriverServiceAccount al final de la URL. Para obtener más información, consulta Crea una cuenta de servicio.

  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. Consulta Copia la clave privada en tu instancia para obtener más información.
  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 de project-id coincida con el del proyecto supervisado para el que acabas de generar las credenciales.

Vuelve a instalar 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

  • 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 vea un mensaje de error en el archivo de registro del sistema Linux (/var/log/syslog en Debian / Ubuntu o /var/log/messages en 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 posterior.

Se quitó el agente que Google Cloud Console informó como instalado

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