Zabbix Server

Soporte de autoescalado # experto

¿Cómo funciona el escalado automático de AWS con Zabbix?

Para manejar el escalado automático desde Zabbix debemos tener en cuenta tres puntos distintos:

1. Añadir una nueva instancia en Zabbix cuando aparece. Esto puede hacerse usando el autoregistro de agentes Zabbix activos (6.4, 6.0, 4.0). De esta forma, cuando una nueva instancia aparece, Zabbix la añade automáticamente como un nuevo equipo.
2. Guardar el ID de la instancia en el inventario de Zabbix. Cuando la instancia desaparece (scale in) vamos a recibir un mensaje con el ID de esa instancia, así que necesitamos tenerlo asociado en el inventario del host para poder buscarlo y borrarlo.
3. Recibir los mensajes de escalado de AWS. Cuando AWS produce un evento de escalado envía un mensaje SNS a un tema que hayamos definido. Conectando ese SNS a una cola SQS podemos leer los mensajes desde Zabbix y eliminar las instancias que salgan de los grupos de escalado.

Configurar el cliente

Dos pasos son necesarios para configurar tus clientes para manejar autoescalados en Zabbix: configurar el agente de Zabbix y añadir un archivo con un parámetro de usuario para el elemento instance_id.

Configuración del agente Zabbix

Debemos cambiar (además de cualquier otro cambio que necesites) seis puntos en el archivo de configuración local de nuestro agente Zabbix, normalmente situado en /etc/zabbix/zabbix_agentd.conf:

• Comentar la opción Server.
• Añadir ServerActive=YOUR__ZABBIX__IP__ADDRESS para configurar el servidor activo.
• Comentar la opción Hostname.
• Poner la opción StartAgents a 0.
• Poner la opción HostnameItem a system.hostname.
• Poner la opción HostMetadataItem a system.uname.

Con esta configuración ponemos el cliente Zabbix en modo activo (el cliente manda información al servidor y no recibe chequeos de él). Además, definimos que Zabbix use el nombre de la máquina como nombre de equipo, así evitamos tener que cambiarlo cada vez que un nuevo servidor arranca. Por último, definimos que Zabbix envíe el valor del comando uname como metadatos: como las instancias en AWS usan un kernel especial, el valor aws aparece en él y podemos usarlo para registrar el servidor.

Parámetro instance_id

Por defecto, cuando un nuevo servidor de un autoescalado aparece en Zabbix, este se enlaza con un template especial llamado AWS EC2 Template, que contiene un elemento llamado instance_id asociado con el campo alias del inventario. Para eso necesitamos añadir en nuestro cliente Zabbix un parámetro de usuario que envíe ese valor, creando el archivo:

UserParameter=aws.ec2.instance_id,curl -s http://169.254.169.254/latest/meta-data/instance-id

Configurar el servidor

Una vez configurados los clientes, el siguiente paso es configurar el servidor para borrar las instancias eliminadas. La forma más rápida y simple consiste en dos pasos: enviar los mensajes de escalado a una cola SQS y configurar el servidor para leerla.

Enviar los mensajes de escalado a una cola SQS

Necesitamos que las notificaciones enviadas por el servicio de autoescalado se guarden en una cola SQS para garantizar la durabilidad y la escala. Como el autoescalado de AWS envía las notificaciones a un tema SNS, necesitamos:

• Crear un tema SNS.
• Crear una cola SQS.
• Configurar SNS para enviar los mensajes a SQS.
• Crear un usuario IAM que pueda leer los mensajes.

Como este tipo de configuración es complicada, puedes usar nuestro stack de CloudFormation para crear todos los elementos en la región que desees. Después de desplegar el stack, en la pestaña Outputs encontrarás cuatro valores que debes anotar:

• SNSTopicARN: el ARN del tema SNS creado.
• SQSQueueURL: la URL de la cola SQS.
• SQSReadIAMUserAccessKey y SQSReadIAMUserSecretKey: el usuario y la clave del usuario IAM.

Necesitas esos datos para la configuración. Para ello, edita el archivo /etc/zabbix/zabbix_ami.yml, en el código similar a:

sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url:
      access_key_id:
      secret_access_key:
      region:

Para cada SQS con notificaciones de escalado necesitaremos añadir un elemento al array similar al que ya existe, con los datos indicados por CloudFormation. Tienes más información sobre este archivo en la sección archivos importantes.

Archivos importantes # experto

La AMI de Zabbix contiene un número de archivos especiales que debes conocer.

/etc/zabbix/zabbix_ami.yml

Este es el archivo más importante, porque maneja la configuración de los aspectos especiales, como los chequeos de escalado o las notificaciones SNS. Un ejemplo (con datos falsos):

zabbix:
  api:
    user: autoscaler_api_user
    password: i-073672daf01037aea94
sns:
  aws:
    access_key_id: AKK4L6A3OXZZ5HE2POQRU7V
    secret_access_key: cICycAg26hSDpsJwbhZjbaaYlt4Tz3n1xqE7Oxp6X2Hf
    region: us-east-1
  topics:
    not_classified: arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    information:    arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    warning:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    average:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    high:           arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    disaster:       arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url: https://sqs.us-east-1.amazonaws.com/000000000/zabbix-pro-sqs-queue
      access_key_id: AKIA3OXZZ5HEWUR5A16CNWH
      secret_access_key: 8ttYO3Ba9K6p0C+aj3fH5cDt2eRLHmlkHbMtlrpv18S7KRbC
      region: us-east-1

Actualmente este archivo contiene tres secciones distintas:

• zabbix: como necesitamos conectar con el servidor Zabbix para borrar los equipos antiguos, necesitamos acceder a la API. Para eso generamos un usuario específico, y sus datos de conexión se indican aquí.
• sns: la configuración requerida para enviar alarmas mediante SNS. Aquí configuramos los datos del usuario IAM y los temas SNS que vamos a usar.
• sqs: la configuración para controlar los mensajes de escalado en AWS. Aquí definimos cada cuánto tiempo comprobar la cola (delay_seconds) y las distintas colas a revisar.

/var/log/zabbix-sqs-reader/zabbix-sqs-reader.log

Este archivo registra los distintos eventos de autoescalado leídos desde SQS.

Antes de hacer la configuración verás el mensaje Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes.: es normal, y desaparece cuando configures el archivo zabbix_ami.yml.

Actualizaciones de la AMI # experto

Como Zabbix lanza nuevas versiones con nuevas características y mejoras, la mejor opción es ir actualizando nuestra AMI cada cierto tiempo. Lamentablemente, esas mismas características incluyen cambios en la base de datos e internos que pueden ser problemáticos al actualizar tu instalación.

Nuestra AMI de Zabbix es la mejor manera de evitar estos problemas, ya que ofrecemos una forma de actualizar entre versiones mayores que es más rápida, simple y segura que la habitual.

Resumen de la actualización

El proceso de actualización para nuestra AMI es bastante simple, y se resume en los siguientes pasos:

• Hacer un volcado de nuestra base de datos actual.
• Lanzar una nueva AMI con la última versión estable.
• Subir el volcado de la base de datos a la nueva instancia.
• Ejecutar nuestro script de migración.

De esta forma mantenemos al mismo tiempo la versión actual y la nueva, y podemos hacer las pruebas necesarias para garantizar que todo funciona correctamente, para después cambiar las EIP asociadas a esa instancia, o migrar los clientes poco a poco.

Proceso de actualización

Paso 1: copia de seguridad del servidor origen

El primer paso es hacer una imagen de nuestro servidor origen, para evitar cualquier pérdida de datos accidental. Puedes seguir el manual de AWS para crear una AMI.

Paso 2: volcado de la base de datos y versión de Zabbix

Entramos por SSH en nuestra instancia y nos ponemos como root:

sudo /bin/su -

Después volcamos la base de datos a un archivo:

mysqldump zabbix > zabbix_origin_database.sql

Por último descargamos el archivo creado a nuestra máquina, para después subirlo al nuevo servidor. También debemos anotar la versión actual de Zabbix que estamos usando: puedes verla en la interfaz web, y debe ser un número similar a 4.0, 4.2, 4.4 o 5.4.

Paso 3: lanzar una nueva instancia Zabbix

El siguiente paso es crear una nueva instancia de Zabbix, usando la última versión estable de la AMI que puedes encontrar en nuestro perfil de AWS Marketplace. Como mínimo, debes usar la versión 6.0 de nuestra AMI de Zabbix.

Esta nueva instancia va a ser el servidor destino donde moveremos nuestros datos, y ya viene con la última versión instalada y actualizada. Una vez arrancada, copiamos en ella el volcado de la base de datos del servidor origen.

Paso 4: actualizar la base de datos

Para insertar nuestra base de datos actual, actualizarla a la nueva versión y añadir las configuraciones necesarias, usamos el script /opt/tools/bin/zabbix-ami-upgrade.sh, que hay que ejecutar como usuario ubuntu indicándole la versión original de Zabbix y el archivo con el volcado. Por ejemplo, migrando desde Zabbix 4.0:

/opt/tools/bin/zabbix-ami-upgrade.sh 4.0 zabbix_origin_database.sql

El proceso nos irá informando de los pasos que lleva a cabo, y una vez finalice podemos seguir trabajando con nuestro nuevo servidor Zabbix.

Paso 5: acceder a la interfaz web

Una vez que la migración ha terminado ya podremos acceder a la interfaz web y ver la situación general de nuestro servidor. Es importante tener en cuenta que debemos usar los mismos usuarios y contraseñas que teníamos en el servidor anterior.

Paso 6: migrar configuraciones especiales y configurar clientes

Una vez nuestra base de datos es operativa, debemos tener en cuenta otro tipo de configuraciones que hayamos podido instalar en el servidor, como por ejemplo:

• Scripts de monitorización.
• Paquetes de sistema adicionales.
• Certificados SSL que hayamos instalado.

También tendremos que mover la EIP que hayamos configurado para esa instancia, de forma que los clientes no necesiten modificarse.

Si no estamos usando EIP, es un buen momento para empezar a hacerlo, ya que si no deberemos cambiar la IP del nuevo servidor en todos los clientes.