HPE Alletra 6000 Zabbix Monitoring

Python-Daemon der ein oder mehrere HPE Alletra 6000 Storage-Arrays per REST API überwacht und Metriken via zabbix_sender (Trapper Items) an Zabbix meldet.

Features

• Array & Group: Status, Kapazität, Usage, Compression
• Volumes: Kapazität, Status, IOPS, Latenz, Throughput (LLD)
• Disks: State, RAID-Status, Resync (LLD)
• Pools: Kapazität, Usage, Savings (LLD)
• Alarms: Severity, Status, Category (LLD)
• Shelves & Sensoren: PSU/Fan/Temp Status, Chassis-Sensoren (2-Level LLD)

Voraussetzungen

• Python 3.11+
• zabbix_sender Binary (im Docker-Image enthalten, für lokale Tests separat installieren)
• Zabbix Server mit Trapper-Support
• Netzwerkzugriff auf Alletra Management (Port 5392) und Zabbix Server (Port 10051)

Schnellstart

1. Template importieren

In Zabbix unter Data collection → Templates → Import die Datei templates/alletra_6000_template.yaml hochladen.

2. Host(s) anlegen

Pro Alletra in Zabbix unter Data collection → Hosts → Create Host:

• Host name: muss exakt mit zabbix_host_name in config.yaml übereinstimmen (z.B. HPE Alletra DC1)
• Template: HPE Alletra 6000 zuweisen
• Kein Interface nötig (alles Trapper)

3. Konfiguration

cp config.yaml.example config.yaml
cp .env.example .env

.env anpassen:

ALLETRA1_PASSWORD=passwort-dc1
ALLETRA2_PASSWORD=passwort-dc2
ZABBIX_SERVER=192.168.x.x
ZABBIX_SENDER_PATH=zabbix_sender

config.yaml anpassen — mehrere Alletras:

alletras:
  - name: "Alletra-DC1"
    host: "192.168.1.10"
    port: 5392
    username: "admin"
    password: "${ALLETRA1_PASSWORD}"
    ssl_verify: false
    zabbix_host_name: "HPE Alletra DC1"

  - name: "Alletra-DC2"
    host: "192.168.2.10"
    port: 5392
    username: "admin"
    password: "${ALLETRA2_PASSWORD}"
    ssl_verify: false
    zabbix_host_name: "HPE Alletra DC2"

zabbix:
  server: "${ZABBIX_SERVER}"
  port: 10051
  sender_path: "${ZABBIX_SENDER_PATH:zabbix_sender}"

poll_interval: 300
log_level: "INFO"

Das alte Single-Format (alletra: statt alletras:) funktioniert weiterhin.

Umgebungsvariablen in config.yaml werden über ${VAR} referenziert, mit optionalem Default: ${VAR:default}. Werte werden aus .env (neben config.yaml) und System-Umgebung geladen.

4a. Docker (Produktion)

docker-compose up -d

4b. Lokal (Test)

python -m venv .venv
source .venv/Scripts/activate   # Windows
# source .venv/bin/activate     # Linux/Mac
pip install -r requirements.txt

# Nur Datensammlung testen (ohne zabbix_sender):
python test_local.py config.yaml

# Voller Betrieb:
python -m src.main config.yaml

Zabbix Triggers

Bereich	Trigger	Severity
Array	Status unreachable	DISASTER
Array	Role failed	DISASTER
Array	No data (Daemon ausgefallen)	HIGH
Array	Usage über Schwellwert	HIGH / WARNING
Volume	Offline	HIGH
Volume	Space usage critical / warning	HIGH / WARNING
Volume	Latency über Schwellwert	HIGH / WARNING
Disk	State failed	DISASTER
Disk	State absent	HIGH
Disk	RAID faulty / resync	DISASTER / WARNING
Pool	Usage über Schwellwert	HIGH / WARNING
Shelf	PSU/Fan/Temp nicht OK	HIGH
Sensor	Status nicht OK	WARNING
Alarm	Severity critical / warning	HIGH / WARNING

Schwellwerte sind per Zabbix-Macros konfigurierbar (Template-Ebene oder pro Host überschreibbar):

Macro	Default	Beschreibung
{$ALLETRA.ARRAY.USAGE.WARN}	80	Array-Belegung Warning (%)
{$ALLETRA.ARRAY.USAGE.CRIT}	90	Array-Belegung Critical (%)
{$ALLETRA.POOL.USAGE.WARN}	80	Pool-Belegung Warning (%)
{$ALLETRA.POOL.USAGE.CRIT}	90	Pool-Belegung Critical (%)
{$ALLETRA.VOLUME.LATENCY.WARN}	10000	Volume-Latenz Warning (µs)
{$ALLETRA.VOLUME.LATENCY.CRIT}	20000	Volume-Latenz Critical (µs)
{$ALLETRA.NODATA.TIMEOUT}	600	No-Data Timeout (Sekunden)

Erreichbarkeit wird doppelt abgesichert:

1. Aktiv: Wenn alle Collectors fehlschlagen, sendet der Daemon alletra.array.status = "unreachable" → DISASTER-Trigger
2. Passiv: Wenn auch der Daemon selbst ausfällt, greift der nodata()-Trigger nach {$ALLETRA.NODATA.TIMEOUT} Sekunden → HIGH-Trigger

Projektstruktur

├── config.yaml.example      # Beispiel-Konfiguration
├── .env.example              # Beispiel-Umgebungsvariablen
├── Dockerfile
├── docker-compose.yml
├── requirements.txt
├── test_local.py             # Lokaler Test ohne zabbix_sender
├── src/
│   ├── main.py               # Entry point, Multi-Target Polling-Loop
│   ├── config.py             # YAML Config mit ${ENV_VAR} Support
│   ├── alletra_client.py     # REST API Client
│   ├── zabbix_sender.py      # zabbix_sender Binary Wrapper
│   ├── models.py             # ZabbixMetric, DiscoveryData
│   └── collectors/           # Ein Collector pro Ressourcentyp
│       ├── arrays.py
│       ├── groups.py
│       ├── volumes.py
│       ├── disks.py
│       ├── pools.py
│       ├── alarms.py
│       └── shelves.py
├── templates/
│   └── alletra_6000_template.yaml   # Zabbix Template
└── resources/
    └── (API PDF)

Hinweise

• Beim ersten Zyklus werden Discovery-Daten gesendet. Die daraus erzeugten Items nehmen erst ab dem zweiten Zyklus Metriken an.
• ssl_verify: false deaktiviert die SSL-Zertifikatsprüfung (Self-Signed Certs auf der Alletra).
• Graceful Shutdown per SIGTERM/SIGINT — der API-Token wird sauber abgemeldet.