Zabbix Server

Supporto dell'Auto Scaling # esperto

Come funziona l'Auto Scaling di AWS con Zabbix?

Per gestire l’Auto Scaling da Zabbix ci sono tre aspetti da considerare:

1. Aggiungere una nuova istanza in Zabbix quando compare. Si può fare con l’auto-registrazione degli agent Zabbix attivi (6.4, 6.0, 4.0). Così, quando compare una nuova istanza, Zabbix la aggiunge automaticamente come nuovo host.
2. Salvare l’ID dell’istanza nell’inventario di Zabbix. Quando l’istanza sparisce (scale in) riceviamo un messaggio con il suo ID, quindi ci serve averlo nell’inventario dell’host per cercarlo ed eliminarlo.
3. Ricevere i messaggi di scaling di AWS. Quando AWS produce un evento di scaling pubblica un messaggio SNS su un topic che hai definito. Collegando quel topic a una coda SQS possiamo leggere i messaggi da Zabbix ed eliminare le istanze che escono dai gruppi di scaling.

Configurare il client

Servono due passi per preparare i tuoi client all’Auto Scaling in Zabbix: configurare l’agent Zabbix e aggiungere un file con un parametro utente per l’item instance_id.

Configurazione dell'agent Zabbix

Oltre a qualunque altra modifica ti serva, sei punti vanno cambiati nel file di configurazione locale dell’agent Zabbix, di solito /etc/zabbix/zabbix_agentd.conf:

• Commentare l’opzione Server.
• Aggiungere ServerActive=YOUR__ZABBIX__IP__ADDRESS per configurare il server attivo.
• Commentare l’opzione Hostname.
• Impostare l’opzione StartAgents a 0.
• Impostare l’opzione HostnameItem a system.hostname.
• Impostare l’opzione HostMetadataItem a system.uname.

Con questa configurazione mettiamo il client Zabbix in modalità attiva (il client invia informazioni al server e non riceve controlli da esso). Inoltre facciamo usare a Zabbix il nome della macchina come nome host, evitando di cambiarlo ogni volta che parte un nuovo server. Infine facciamo inviare a Zabbix l’output di uname come metadati: le istanze AWS usano un kernel particolare, quindi il valore aws compare lì e possiamo usarlo per registrare il server.

Parametro instance_id

Per impostazione predefinita, quando un nuovo server di un Auto Scaling compare in Zabbix, viene collegato a un template speciale chiamato AWS EC2 Template, che contiene un item instance_id associato al campo alias dell’inventario. Per alimentarlo aggiungi al client Zabbix un parametro utente creando il file:

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

Configurare il server

Configurati i client, il passo successivo è configurare il server per eliminare le istanze rimosse. La via più rapida e semplice ha due passi: inviare i messaggi di scaling a una coda SQS e configurare il server per leggerla.

Inviare i messaggi di scaling a una coda SQS

Vogliamo che le notifiche inviate dal servizio di Auto Scaling siano archiviate in una coda SQS, per durabilità e scalabilità. Poiché l’Auto Scaling di AWS pubblica le notifiche su un topic SNS, dobbiamo:

• Creare un topic SNS.
• Creare una coda SQS.
• Configurare SNS per consegnare i messaggi a SQS.
• Creare un utente IAM che possa leggere i messaggi.

Dato che questa configurazione è laboriosa, puoi usare il nostro stack CloudFormation per creare tutti gli elementi nella regione che preferisci. Dopo il deploy, nella scheda Outputs troverai quattro valori da annotare:

• SNSTopicARN: l’ARN del topic SNS creato.
• SQSQueueURL: l’URL della coda SQS.
• SQSReadIAMUserAccessKey e SQSReadIAMUserSecretKey: chiave e segreto dell’utente IAM.

Questi dati servono per la configurazione. Modifica il file /etc/zabbix/zabbix_ami.yml, nel blocco simile a:

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

Per ogni coda SQS con notifiche di scaling aggiungi un elemento all’array simile a quello esistente, con i dati forniti da CloudFormation. Trovi altre informazioni su questo file nella sezione file importanti.

File importanti # esperto

L’AMI di Zabbix contiene alcuni file speciali che conviene conoscere.

/etc/zabbix/zabbix_ami.yml

È il file più importante, perché governa la configurazione degli aspetti speciali, come i controlli di scaling o le notifiche SNS. Un esempio (con dati falsi):

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

Attualmente questo file contiene tre sezioni distinte:

• zabbix: poiché dobbiamo collegarci al server Zabbix per eliminare gli host obsoleti, ci serve l’accesso all’API. Creiamo un utente dedicato, e le sue credenziali stanno qui.
• sns: la configurazione necessaria per inviare allarmi tramite SNS. Qui impostiamo le credenziali dell’utente IAM e i topic SNS che useremo.
• sqs: la configurazione per gestire i messaggi di scaling su AWS. Qui definiamo ogni quanto interrogare la coda (delay_seconds) e le diverse code da controllare.

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

Questo file registra i vari eventi di Auto Scaling letti da SQS.

Prima di fare la configurazione vedrai il messaggio Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes. — è normale, e scompare quando configuri zabbix_ami.yml.

Aggiornamenti dell'AMI # esperto

Poiché Zabbix rilascia nuove versioni con nuove funzionalità e migliorie, la scelta migliore è aggiornare la nostra AMI di tanto in tanto. Purtroppo, quelle stesse novità comportano cambiamenti nel database e interni che possono essere problematici quando si aggiorna un’installazione esistente.

La nostra AMI di Zabbix è il modo migliore per evitare questi problemi, perché offriamo un percorso tra versioni maggiori più rapido, semplice e sicuro di quello abituale.

L'aggiornamento in sintesi

Il processo di aggiornamento della nostra AMI è piuttosto semplice:

• Fare un dump del database attuale.
• Avviare una nuova AMI con l’ultima versione stabile.
• Caricare il dump del database sulla nuova istanza.
• Eseguire il nostro script di migrazione.

Così manteniamo contemporaneamente la versione attuale e quella nuova, e possiamo fare tutti i test necessari per garantire che tutto funzioni prima di spostare gli EIP associati a quell’istanza, o di migrare i client poco a poco.

Processo di aggiornamento

Passo 1: backup del server di origine

Il primo passo è creare un’immagine del server di origine, per evitare qualsiasi perdita accidentale di dati. Puoi seguire il manuale AWS per creare un’AMI.

Passo 2: dump del database e versione di Zabbix

Entriamo via SSH nell’istanza e diventiamo root:

sudo /bin/su -

Poi esportiamo il database in un file:

mysqldump zabbix > zabbix_origin_database.sql

Infine scarichiamo il file creato sulla nostra macchina, per poi caricarlo sul nuovo server. Annotiamo anche la versione di Zabbix in uso: si vede nell’interfaccia web, e sarà un numero simile a 4.0, 4.2, 4.4 o 5.4.

Passo 3: avviare una nuova istanza Zabbix

Il passo successivo è creare una nuova istanza di Zabbix, usando l’ultima versione stabile dell’AMI che trovi nel nostro profilo venditore su AWS Marketplace. Come minimo devi usare la versione 6.0 della nostra AMI di Zabbix.

Questa nuova istanza sarà il server di destinazione dove sposteremo i dati, e arriva già con l’ultima versione installata e aggiornata. Una volta avviata, copiaci il dump del database del server di origine.

Passo 4: aggiornare il database

Per importare il database attuale, aggiornarlo alla nuova versione e aggiungere le configurazioni necessarie, usiamo lo script /opt/tools/bin/zabbix-ami-upgrade.sh, da eseguire come utente ubuntu indicando la versione originale di Zabbix e il file di dump. Per esempio, migrando da Zabbix 4.0:

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

Il processo informa di ogni passo eseguito e, una volta terminato, possiamo continuare a lavorare con il nuovo server Zabbix.

Passo 5: accedere all'interfaccia web

Terminata la migrazione potremo accedere all’interfaccia web e vedere la situazione generale del server. Importante: dobbiamo usare gli stessi utenti e password che avevamo sul server precedente.

Passo 6: migrare configurazioni speciali e puntare i client

Una volta che il database è operativo, teniamo conto di altre configurazioni che possiamo aver installato sul server, per esempio:

• Script di monitoraggio.
• Pacchetti di sistema aggiuntivi.
• Certificati SSL installati.

Dovremo anche spostare l’EIP configurato per quell’istanza, così che i client non debbano essere modificati.

Se non stiamo usando un EIP, è un buon momento per iniziare: altrimenti dovremo cambiare l’IP del nuovo server su tutti i client.