Solución de problemas de instalación del agente

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 “Inhabilitado mediante metadatos”, es probable que se esté ejecutando una imagen de Cloud Marketplace, allí 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. Consulta la siguiente sección: Vuelve a instalar el agente.

  • 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 Cloud Console. 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 reinstalar 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 con normalidad, pero no hay datos o tus políticas de alertas no funcionan como esperabas, deberías verificar si las credenciales de tu instancia de VM son correctas y si especifican el proyecto correspondiente:

  • 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 Google 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 más información sobre las credenciales, consulta Autoriza el agente. 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 Google 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, que se suele denominar "AWS Link...". Para obtener más información sobre las credenciales, consulta Autoriza el agente. Para verificar tus credenciales, consulta Verifica credenciales de clave privada.

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

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 formulario de Explorador de API en la parte inferior de 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:

    • 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.

    • 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:

    Abrir la página 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, que suele tener un nombre que comienza con "AWS Link".

    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 CURMULATIVE. 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 Compute Engine > Instancias de VM de Cloud Console 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 de GCP actual 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:
    1. Si ves “Permitir acceso completo a todas las API de Cloud”, significa que tienes las credenciales adecuadas.
    2. Si ves que al lado de la API de Cloud Monitoring tienes el permiso completo o de solo escritura, 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 en la sección IAM y administración > Cuentas de servicio de Cloud Console. 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 GCP, 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 Cloud Console.

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

  • Verificas una instancia de Compute Engine, pero el proyecto de GCP en el archivo de credenciales no es el proyecto que contiene tu instancia.
  • Verificas una instancia de Amazon EC2, pero el proyecto de GCP en el archivo de credenciales no es el proyecto de conector (llamado AWS Link...) para tu cuenta de AWS.
  • La cuenta de servicio que se muestra 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 supervisión) 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 las instancias de Compute Engine creados sin el alcance de supervisión), 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 a tu espacio de trabajo, ve a Monitoring:

      Ir a Monitoring

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

      • Para AWS, usa el vínculo de navegación directa a Cloud Console del proyecto en cuestión.
      • En el caso de GCP, identifica el proyecto que contiene los recursos de Compute Engine en cuestión y ve a Cloud Console.
    3. Desde 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 sea 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.

Reinstala el agente

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.

  • Problema de error 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;
    

    Este mensaje es una advertencia inofensiva que se activa en la implementación del complemento de procesos actual y no es una indicación de pérdida de datos.

  • 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. Es posible que el agente se esté quedando sin memoria.

  • Problema de cuota de la API de 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 Monitoring. Sigue las instrucciones de la guía de cuotas a fin de obtener información para administrar el límite de cuota.