Hi hab nochmal die Quellen gesucht und zusammengefasst,
Warum der Crash passiert
Die ASA r2-Serie (A20, A30, A50, A70, A90, A1K) verwendet eine grundlegend andere ONTAP-Persönlichkeit, die ausschließlich für block-basierte SAN-Workloads ausgelegt ist. Anders als bei klassischen ONTAP-Systemen gibt es auf ASA r2 keine benutzer-verwalteten Volumes oder
Aggregates — der Storage wird automatisch über sogenannte “Storage Availability Zones” verwaltet.
Daher existiert der Endpoint, den der Checkmk-Agent aufruft, schlicht nicht:
/api/cluster/counter/tables/volume/rows → 404
Dass der Agent dabei crasht statt den fehlenden Endpoint graceful zu überspringen, ist ein separates Problem — das im Code sogar kommentiert ist:
# our @utils.api wrapper cannot help us generically catch this error
# since this is a generator function and not a normal function
Dein Workaround ist korrekt
Den Abschnitt “Volume counters” in der Regel zu deaktivieren ist aktuell der richtige Weg. Alle anderen Endpoints (Cluster Health, Disk, Node, SVM etc.) die nicht von Volume-Level-Countern abhängen, sollten weiterhin funktionieren.
Was ein korrekter ASA r2 Agent stattdessen verwenden müsste
NetApp dokumentiert, welche Endpoints auf ASA r2 die klassischen Volume-basierten ersetzen:
| Statt… | Auf ASA r2 verwenden |
|---|---|
| /api/storage/volumes | /api/storage/storage-units |
| /api/storage/luns + /api/storage/namespaces | /api/storage/storage-units |
| /api/storage/aggregates | /api/storage/availability-zones |
| /api/cluster/counter/tables/volume/rows | nicht verfügbar (kein RestPerf) |
Für Performance-Daten gilt: ASA r2 unterstützt den Standard-RestPerf Counter Collector gar nicht.
Tools wie NetApp Harvest lösen das über einen separaten “KeyPerf Collector” für Latenz, IOPS und Durchsatz auf Storage-Unit-Ebene. (ASA r2 - Harvest)
Quellen:
- REST API support for ASA r2
- https://www.netapp.com/media/136585-tr-5008-restfulapi-transition-guide-asa-r2.pdf (TR-5008)
VG Bernd