Zabbix Server

Auto-Scaling-Unterstützung # Experte

Wie funktioniert AWS Auto Scaling mit Zabbix?

Um Auto Scaling aus Zabbix heraus zu handhaben, sind drei Punkte zu beachten:

1. Eine neue Instanz in Zabbix aufnehmen, sobald sie erscheint. Das geht über die Auto-Registrierung aktiver Zabbix-Agents (6.4, 6.0, 4.0). So nimmt Zabbix eine neu erscheinende Instanz automatisch als neuen Host auf.
2. Die Instanz-ID im Zabbix-Inventar speichern. Verschwindet die Instanz (Scale in), erhalten wir eine Nachricht mit ihrer ID — wir brauchen sie also im Host-Inventar, um den Host zu finden und zu löschen.
3. Die Scaling-Nachrichten von AWS empfangen. Bei einem Scaling-Ereignis veröffentlicht AWS eine SNS-Nachricht in einem von Ihnen definierten Topic. Verbindet man dieses Topic mit einer SQS-Queue, können wir die Nachrichten aus Zabbix lesen und die Instanzen entfernen, die die Scaling-Gruppen verlassen.

Den Client konfigurieren

Zwei Schritte sind nötig, um Ihre Clients auf Auto Scaling in Zabbix vorzubereiten: den Zabbix-Agent konfigurieren und eine Datei mit einem User-Parameter für das Item instance_id anlegen.

Konfiguration des Zabbix-Agents

Neben allen anderen Änderungen, die Sie brauchen, sind sechs Punkte in der lokalen Konfigurationsdatei des Zabbix-Agents zu ändern, normalerweise /etc/zabbix/zabbix_agentd.conf:

• Die Option Server auskommentieren.
• ServerActive=YOUR__ZABBIX__IP__ADDRESS ergänzen, um den aktiven Server zu setzen.
• Die Option Hostname auskommentieren.
• Die Option StartAgents auf 0 setzen.
• Die Option HostnameItem auf system.hostname setzen.
• Die Option HostMetadataItem auf system.uname setzen.

Damit läuft der Zabbix-Client im aktiven Modus (er sendet Informationen an den Server und empfängt keine Prüfungen von ihm). Außerdem nutzt Zabbix den Maschinennamen als Hostnamen, sodass er nicht bei jedem Serverstart geändert werden muss. Schließlich sendet Zabbix die Ausgabe von uname als Metadaten: AWS-Instanzen nutzen einen speziellen Kernel, sodass dort der Wert aws auftaucht und sich zur Registrierung des Servers verwenden lässt.

Parameter instance_id

Standardmäßig wird ein neuer Auto-Scaling-Server in Zabbix mit einem speziellen Template namens AWS EC2 Template verknüpft, das ein Item instance_id enthält, das mit dem Inventarfeld alias verbunden ist. Um es zu befüllen, ergänzen Sie im Zabbix-Client einen User-Parameter, indem Sie diese Datei anlegen:

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

Den Server konfigurieren

Sind die Clients konfiguriert, folgt der Server: Er soll entfernte Instanzen löschen. Der schnellste und einfachste Weg hat zwei Schritte — die Scaling-Nachrichten in eine SQS-Queue schicken und den Server so konfigurieren, dass er sie liest.

Die Scaling-Nachrichten in eine SQS-Queue schicken

Die Benachrichtigungen des Auto-Scaling-Dienstes sollen in einer SQS-Queue liegen, für Dauerhaftigkeit und Skalierung. Da AWS Auto Scaling die Benachrichtigungen an ein SNS-Topic sendet, brauchen wir:

• Ein SNS-Topic anlegen.
• Eine SQS-Queue anlegen.
• SNS so konfigurieren, dass die Nachrichten an SQS gehen.
• Einen IAM-Benutzer anlegen, der die Nachrichten lesen darf.

Da diese Konfiguration aufwendig ist, können Sie unseren CloudFormation-Stack nutzen, um alle Elemente in der gewünschten Region anzulegen. Nach dem Deployment finden Sie im Reiter Outputs vier Werte, die Sie notieren sollten:

• SNSTopicARN: der ARN des angelegten SNS-Topics.
• SQSQueueURL: die URL der SQS-Queue.
• SQSReadIAMUserAccessKey und SQSReadIAMUserSecretKey: Schlüssel und Secret des IAM-Benutzers.

Diese Werte brauchen Sie für die Konfiguration. Bearbeiten Sie /etc/zabbix/zabbix_ami.yml im Block, der so aussieht:

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

Für jede SQS-Queue mit Scaling-Benachrichtigungen ergänzen Sie einen Array-Eintrag wie den vorhandenen, mit den Werten aus CloudFormation. Mehr zu dieser Datei im Abschnitt wichtige Dateien.

Wichtige Dateien # Experte

Die Zabbix-AMI enthält einige besondere Dateien, die Sie kennen sollten.

/etc/zabbix/zabbix_ami.yml

Sie ist die wichtigste, denn sie steuert die Konfiguration der Sonderfunktionen wie Scaling-Prüfungen oder SNS-Benachrichtigungen. Ein Beispiel (mit erfundenen Daten):

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

Derzeit hat die Datei drei verschiedene Abschnitte:

• zabbix: Da wir uns mit dem Zabbix-Server verbinden müssen, um veraltete Hosts zu löschen, brauchen wir API-Zugriff. Dafür legen wir einen eigenen Benutzer an, dessen Zugangsdaten hier stehen.
• sns: die Konfiguration, die zum Versand von Alarmen über SNS nötig ist. Hier stehen die Zugangsdaten des IAM-Benutzers und die verwendeten SNS-Topics.
• sqs: die Konfiguration für die AWS-Scaling-Nachrichten. Hier legen wir fest, wie oft die Queue abgefragt wird (delay_seconds), und welche Queues zu prüfen sind.

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

Diese Datei protokolliert die aus SQS gelesenen Auto-Scaling-Ereignisse.

Vor der Konfiguration sehen Sie die Meldung Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes. — das ist normal und verschwindet, sobald zabbix_ami.yml konfiguriert ist.

Aktualisierungen der AMI # Experte

Da Zabbix regelmäßig neue Versionen mit neuen Funktionen veröffentlicht, ist es am besten, unsere AMI von Zeit zu Zeit zu aktualisieren. Leider bringen genau diese Neuerungen Datenbank- und interne Änderungen mit sich, die beim Aktualisieren einer bestehenden Installation problematisch sein können.

Unsere Zabbix-AMI ist der beste Weg, diese Probleme zu vermeiden, denn wir bieten einen Pfad zwischen Hauptversionen, der schneller, einfacher und sicherer ist als der übliche.

Die Aktualisierung im Überblick

Der Aktualisierungsprozess unserer AMI ist recht einfach:

• Einen Dump der aktuellen Datenbank erstellen.
• Eine neue AMI mit der neuesten stabilen Version starten.
• Den Datenbank-Dump auf die neue Instanz hochladen.
• Unser Migrationsskript ausführen.

So laufen die alte und die neue Version parallel, und Sie können ausgiebig testen, bevor Sie die mit der Instanz verbundenen EIPs umziehen oder die Clients nach und nach migrieren.

Aktualisierungsprozess

Schritt 1: den Quellserver sichern

Der erste Schritt ist ein Image des Quellservers, um versehentlichen Datenverlust zu vermeiden. Folgen Sie dazu dem AWS-Handbuch zum Erstellen einer AMI.

Schritt 2: Datenbank-Dump und Zabbix-Version

Wir melden uns per SSH an der Instanz an und werden root:

sudo /bin/su -

Danach exportieren wir die Datenbank in eine Datei:

mysqldump zabbix > zabbix_origin_database.sql

Zuletzt laden wir die Datei auf unseren Rechner herunter, um sie später auf den neuen Server zu übertragen. Notieren Sie außerdem die aktuell verwendete Zabbix-Version: Sie ist in der Weboberfläche sichtbar und sollte eine Zahl wie 4.0, 4.2, 4.4 oder 5.4 sein.

Schritt 3: eine neue Zabbix-Instanz starten

Als Nächstes erstellen wir eine neue Zabbix-Instanz mit der neuesten stabilen AMI-Version aus unserem AWS-Marketplace-Verkäuferprofil. Mindestens erforderlich ist Version 6.0 unserer Zabbix-AMI.

Diese neue Instanz ist der Zielserver, auf den wir die Daten verschieben; sie bringt die neueste Version bereits installiert und aktualisiert mit. Sobald sie läuft, kopieren wir den Datenbank-Dump des Quellservers darauf.

Schritt 4: die Datenbank aktualisieren

Um die aktuelle Datenbank einzuspielen, auf die neue Version zu heben und die nötigen Konfigurationen zu ergänzen, nutzen wir das Skript /opt/tools/bin/zabbix-ami-upgrade.sh. Es wird als Benutzer ubuntu ausgeführt, mit der ursprünglichen Zabbix-Version und der Dump-Datei als Argumente. Beispiel für eine Migration von Zabbix 4.0:

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

Der Prozess meldet jeden ausgeführten Schritt; danach können Sie mit dem neuen Zabbix-Server weiterarbeiten.

Schritt 5: die Weboberfläche öffnen

Nach der Migration können Sie die Weboberfläche öffnen und den Gesamtzustand des Servers prüfen. Wichtig: Sie müssen dieselben Benutzer und Passwörter wie auf dem vorherigen Server verwenden.

Schritt 6: Sonderkonfigurationen migrieren und Clients umstellen

Läuft die Datenbank, denken Sie an weitere Konfigurationen, die Sie auf dem Server installiert haben könnten, zum Beispiel:

• Monitoring-Skripte.
• Zusätzliche Systempakete.
• Installierte SSL-Zertifikate.

Außerdem sollten Sie die für diese Instanz konfigurierte EIP umziehen, damit die Clients unverändert bleiben können.

Wenn Sie keine EIP nutzen, ist jetzt ein guter Zeitpunkt dafür — sonst müssen Sie die IP des neuen Servers auf allen Clients ändern.