Zabbix Server

Suporte de auto scaling # especialista

Como funciona o auto scaling da AWS com o Zabbix?

Para lidar com o auto scaling a partir do Zabbix há três pontos distintos a considerar:

1. Adicionar uma nova instância no Zabbix quando aparece. Pode ser feito através do auto-registo de agentes Zabbix ativos (6.4, 6.0, 4.0). Assim, quando uma nova instância aparece, o Zabbix adiciona-a automaticamente como um novo equipamento.
2. Guardar o ID da instância no inventário do Zabbix. Quando a instância desaparece (scale in) recebemos uma mensagem com o seu ID, por isso precisamos de o ter associado no inventário do host para o procurar e apagar.
3. Receber as mensagens de escalamento da AWS. Quando a AWS produz um evento de escalamento envia uma mensagem SNS para um tópico definido por si. Ligando esse SNS a uma fila SQS podemos ler as mensagens a partir do Zabbix e eliminar as instâncias que saem dos grupos de escalamento.

Configurar o cliente

São necessários dois passos para preparar os seus clientes para o auto scaling no Zabbix: configurar o agente do Zabbix e adicionar um ficheiro com um parâmetro de utilizador para o item instance_id.

Configuração do agente Zabbix

Além de qualquer outra alteração de que precise, há seis pontos a mudar no ficheiro de configuração local do agente Zabbix, normalmente em /etc/zabbix/zabbix_agentd.conf:

• Comentar a opção Server.
• Adicionar ServerActive=YOUR__ZABBIX__IP__ADDRESS para configurar o servidor ativo.
• Comentar a opção Hostname.
• Colocar a opção StartAgents a 0.
• Colocar a opção HostnameItem a system.hostname.
• Colocar a opção HostMetadataItem a system.uname.

Com esta configuração colocamos o cliente Zabbix em modo ativo (o cliente envia informação ao servidor e não recebe verificações dele). Além disso, definimos que o Zabbix use o nome da máquina como nome de equipamento, evitando ter de o mudar sempre que um novo servidor arranca. Por fim, definimos que o Zabbix envie o valor do comando uname como metadados: como as instâncias na AWS usam um kernel especial, o valor aws aparece aí e podemos usá-lo para registar o servidor.

Parâmetro instance_id

Por omissão, quando um novo servidor de um auto scaling aparece no Zabbix, este é ligado a um template especial chamado AWS EC2 Template, que contém um item chamado instance_id associado ao campo alias do inventário. Para o alimentar, adicione ao cliente Zabbix um parâmetro de utilizador criando o ficheiro:

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

Configurar o servidor

Configurados os clientes, o passo seguinte é configurar o servidor para apagar as instâncias eliminadas. A forma mais rápida e simples tem dois passos: enviar as mensagens de escalamento para uma fila SQS e configurar o servidor para a ler.

Enviar as mensagens de escalamento para uma fila SQS

Queremos que as notificações enviadas pelo serviço de auto scaling fiquem guardadas numa fila SQS, para garantir durabilidade e escala. Como o auto scaling da AWS envia as notificações para um tópico SNS, precisamos de:

• Criar um tópico SNS.
• Criar uma fila SQS.
• Configurar o SNS para enviar as mensagens para o SQS.
• Criar um utilizador IAM que possa ler as mensagens.

Como esta configuração é complicada, pode usar a nossa stack de CloudFormation para criar todos os elementos na região que quiser. Depois de aplicar a stack, no separador Outputs encontrará quatro valores a anotar:

• SNSTopicARN: o ARN do tópico SNS criado.
• SQSQueueURL: o URL da fila SQS.
• SQSReadIAMUserAccessKey e SQSReadIAMUserSecretKey: o utilizador e a chave do utilizador IAM.

Precisa desses dados para a configuração. Edite o ficheiro /etc/zabbix/zabbix_ami.yml, no bloco semelhante a:

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

Para cada SQS com notificações de escalamento é preciso adicionar um elemento ao array semelhante ao existente, com os dados indicados pelo CloudFormation. Há mais informação sobre este ficheiro na secção ficheiros importantes.

Ficheiros importantes # especialista

A AMI de Zabbix contém um conjunto de ficheiros especiais que deve conhecer.

/etc/zabbix/zabbix_ami.yml

É o ficheiro mais importante, porque controla a configuração dos aspetos especiais, como as verificações de escalamento ou as notificações SNS. Um exemplo (com dados 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

Atualmente este ficheiro contém três secções distintas:

• zabbix: como precisamos de ligar ao servidor Zabbix para apagar os equipamentos antigos, precisamos de acesso à API. Para isso criamos um utilizador específico, cujos dados de ligação constam aqui.
• sns: a configuração necessária para enviar alarmes através de SNS. Aqui configuramos os dados do utilizador IAM e os tópicos SNS que vamos usar.
• sqs: a configuração para controlar as mensagens de escalamento na AWS. Aqui definimos de quanto em quanto tempo verificar a fila (delay_seconds) e as diferentes filas a consultar.

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

Este ficheiro regista os vários eventos de auto scaling lidos a partir do SQS.

Antes de fazer a configuração verá a mensagem Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes. — é normal, e desaparece quando configurar o ficheiro zabbix_ami.yml.

Atualizações da AMI # especialista

Como o Zabbix lança novas versões com novas funcionalidades e melhorias, a melhor opção é ir atualizando a nossa AMI de tempos a tempos. Infelizmente, essas mesmas funcionalidades incluem alterações na base de dados e internas que podem ser problemáticas ao atualizar a sua instalação.

A nossa AMI de Zabbix é a melhor forma de evitar estes problemas, já que oferecemos uma maneira de atualizar entre versões maiores mais rápida, simples e segura do que a habitual.

Resumo da atualização

O processo de atualização da nossa AMI é bastante simples e resume-se aos seguintes passos:

• Fazer um dump da nossa base de dados atual.
• Lançar uma nova AMI com a última versão estável.
• Carregar o dump da base de dados na nova instância.
• Executar o nosso script de migração.

Assim mantemos ao mesmo tempo a versão atual e a nova, e podemos fazer os testes necessários para garantir que tudo funciona corretamente, para depois mudar os EIP associados a essa instância, ou migrar os clientes aos poucos.

Processo de atualização

Passo 1: cópia de segurança do servidor de origem

O primeiro passo é criar uma imagem do servidor de origem, para evitar qualquer perda acidental de dados. Pode seguir o manual da AWS para criar uma AMI.

Passo 2: dump da base de dados e versão do Zabbix

Entramos por SSH na instância e passamos a root:

sudo /bin/su -

Depois fazemos o dump da base de dados para um ficheiro:

mysqldump zabbix > zabbix_origin_database.sql

Por fim descarregamos o ficheiro criado para a nossa máquina, para depois o enviar para o novo servidor. Também devemos anotar a versão atual do Zabbix: pode vê-la na interface web, e deve ser um número semelhante a 4.0, 4.2, 4.4 ou 5.4.

Passo 3: lançar uma nova instância Zabbix

O passo seguinte é criar uma nova instância de Zabbix, usando a última versão estável da AMI que pode encontrar no nosso perfil do AWS Marketplace. No mínimo, deve usar a versão 6.0 da nossa AMI de Zabbix.

Esta nova instância será o servidor de destino para onde moveremos os dados, e já vem com a última versão instalada e atualizada. Assim que arrancar, copiamos para ela o dump da base de dados do servidor de origem.

Passo 4: atualizar a base de dados

Para inserir a nossa base de dados atual, atualizá-la para a nova versão e adicionar as configurações necessárias, usamos o script /opt/tools/bin/zabbix-ami-upgrade.sh, que deve ser executado como utilizador ubuntu, indicando-lhe a versão original do Zabbix e o ficheiro com o dump. Por exemplo, migrando a partir de Zabbix 4.0:

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

O processo vai informando dos passos que executa e, uma vez terminado, podemos continuar a trabalhar com o novo servidor Zabbix.

Passo 5: aceder à interface web

Quando a migração terminar já poderemos aceder à interface web e ver a situação geral do servidor. É importante ter em conta que devemos usar os mesmos utilizadores e palavras-passe que tínhamos no servidor anterior.

Passo 6: migrar configurações especiais e configurar clientes

Uma vez a base de dados operacional, devemos ter em conta outro tipo de configurações que possamos ter instalado no servidor, como por exemplo:

• Scripts de monitorização.
• Pacotes de sistema adicionais.
• Certificados SSL que tenhamos instalado.

Também teremos de mover o EIP que tenhamos configurado para essa instância, de forma que os clientes não precisem de alterações.

Se não estivermos a usar EIP, é um bom momento para começar, já que de outro modo teremos de mudar o IP do novo servidor em todos os clientes.