Für ähnliche Funktionen wie Amazon Timestream für sollten Sie Amazon Timestream for LiveAnalytics InfluxDB in Betracht ziehen. Es bietet eine vereinfachte Datenaufnahme und Antwortzeiten im einstelligen Millisekundenbereich für Analysen in Echtzeit. [Erfahren](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html) Sie hier mehr.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Überwachung und Konfigurationsoptimierung für Timestream for InfluxDB 2
## -Übersicht
Effektive Überwachung und Konfigurationsoptimierung sind entscheidend für die Aufrechterhaltung einer optimalen Leistung, Zuverlässigkeit und Kosteneffizienz in Ihrer Timestream for InfluxDB-Bereitstellung. Dieser Leitfaden bietet umfassende Anleitungen zu CloudWatch Metriken, Leistungsschwellenwerten und Strategien zur Konfigurationsoptimierung, mit denen Sie Ihre InfluxDB-Instances proaktiv verwalten können.
## CloudWatch Referenz zu Metriken
Amazon CloudWatch bietet detaillierte Metriken für die Überwachung Ihres Timestreams für InfluxDB-Instances. Das Verständnis dieser Metriken und ihrer Schwellenwerte ist für die Aufrechterhaltung der Systemintegrität und -leistung unerlässlich.
### Kennzahlen zur Ressourcennutzung
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
| --- | --- | --- | --- | --- |
| CPUUtilization | DbInstanceName | Prozentsatz der verwendeten CPU | Prozent | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | Prozentsatz des verwendeten Speichers | Prozent | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | Menge des verwendeten Heap-Speichers | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | Aktuelle aktive Speicherzuweisung | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | Prozentsatz des belegten Festplattenspeichers | Prozent | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metriken zum I/O-Betrieb
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
| --- | --- | --- | --- | --- |
| ReadOpsPerSec | DbInstanceName | Anzahl der Lesevorgänge pro Sekunde | Anzahl/Sekunde | Halten Sie einen Headroom von ≥ 30% unter den bereitgestellten IOPSBeispiel: 12.000 IOPS → Behalten Sie insgesamt < 8.400 IOPS |
| WriteOpsPerSec | DbInstanceName | Anzahl der Schreibvorgänge pro Sekunde | Anzahl/Sekunde | Sorgen Sie für einen Headroom von ≥ 30% unter den bereitgestellten IOPSBeispiel: 12.000 IOPS → Behalten Sie insgesamt < 8.400 IOPS |
| Insgesamt IOps PerSec | DbInstanceName | Gesamtzahl der I/O Operationen pro Sekunde (Lesen \$1 Schreiben) | Anzahl/Sekunde | Sorgen Sie für einen Headroom von ≥ 30% unter den bereitgestellten IOPSÜberwachen Sie anhand der Funktionen der Instanzklasse |
### Durchsatz-Metriken
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
| --- | --- | --- | --- | --- |
| ReadThroughput | DbInstanceName | Durchsatz beim Lesen von Daten | Bytes/Sekunde | Überwachen Sie die Grenzwerte für den Speicherdurchsatz |
| WriteThroughput | DbInstanceName | Durchsatz beim Schreiben von Daten | Bytes/Sekunde | Überwachen Sie die Grenzwerte für den Speicherdurchsatz |
### API-Leistungskennzahlen
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
| --- | --- | --- | --- | --- |
| APIRequestRate | DbInstanceName, Endpunkt, Status | Rate der API-Anfragen an bestimmte Endpunkte mit Statuscodes (2xx, 4xx, 5xx) | Anzahl/Sekunde | Fehlerquoten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName, Endpunkt, Status | Anzahl der Abfrageantworten nach Endpunkt und Statuscode | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metriken zur Abfrageausführung
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
| --- | --- | --- | --- | --- |
| QueryRequestsTotal | DbInstanceName, Ergebnis | Gesamtzahl der Abfrageanfragen nach Ergebnistyp (success, runtime\$1error, compile\$1error, queue\$1error) | Anzahl | Erfolgsquote: > 99% Fehlerquoten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Kennzahlen zur Datenorganisation
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Kritische Schwellenwerte |
| --- | --- | --- | --- | --- |
| SeriesCardinality | DbInstanceName, Eimer | Anzahl der eindeutigen Zeitreihen in einem Bucket | Anzahl | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | Gesamtzahl der Buckets in der Instanz | Anzahl | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metriken zur Systemintegrität
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
| --- | --- | --- | --- | --- |
| EngineUptime | DbInstanceName | Zeit, zu der die InfluxDB-Engine gelaufen ist | Sekunden | Achten Sie auf unerwartete NeustartsWarnung: Uptime wird unerwartet zurückgesetzt |
| WriteTimeouts | DbInstanceName | Anzahl der Schreibvorgänge, bei denen das Zeitlimit überschritten wurde | Anzahl | Warnung: > 0,1% der SchreibvorgängeKritisch: Zunehmender Trend |
### Kennzahlen zur Aufgabenverwaltung
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
| --- | --- | --- | --- | --- |
| ActiveTaskWorkers | DbInstanceName | Anzahl der aktiven Sachbearbeiter | Anzahl | Überwachen Sie anhand des konfigurierten Task-Worker-LimitsWarnung: Konsistent auf Maximum |
| TaskExecutionFailures | DbInstanceName | Anzahl der fehlgeschlagenen Aufgabenausführungen | Anzahl | Warnung: > 1% der AufgabenausführungenKritisch: Steigende Ausfallrate |
### Grundlegendes zu den wichtigsten metrischen Beziehungen
#### Beziehung zwischen IOPS und Durchsatz
**Die 30-%-Headroom-Regel:** Halten Sie immer einen **Headroom von mindestens 30%** zwischen Ihrem kontinuierlichen Betrieb pro Sekunde und Ihren bereitgestellten IOPS ein. Dies bietet Puffer für:
+ Verdichtungsvorgänge (können die IOPS erheblich erhöhen)
+ Jeder Datenbankneustart, damit er reibungslos läuft
+ Abfrage-Bursts bei Spitzenauslastung
+ Schreibspitzen aufgrund der Batch-Aufnahme
+ Operationen zur Indexverwaltung
**Beispiel für eine Berechnung:**
+ Bereitgestellte IOPS: 12.000
+ Zielwert für maximale kontinuierliche IOPS (insgesamt IOpsPerSec): 8.400 (70% Auslastung)
+ Reservierter Headroom: 3.600 IOPS (30%)
Wenn die Gesamtsumme IOps PerSec durchweg 8.400 übersteigt: → Speicherstufe aktualisieren oder Arbeitslast optimieren
**Formel für die Überwachung:**
IOPS-Auslastung% = (ReadOpsPerSec \$1 WriteOpsPerSec)/Bereitgestellte IOPS × 100
+ Ziel: Halten Sie die IOPS-Auslastung unter 70%
+ Ziel: Halten Sie die IOPS-Auslastung auf 70%
+ Kritisch: IOPS-Auslastung > 90%
### Grundlegendes zu den Auswirkungen der Serienkardinalität auf die Leistung
Die Reihenkardinalität hat eine multiplikative Wirkung auf die Systemressourcen:
| **Anzahl der Serien** | **Auswirkung auf das Gedächtnis** | **Auswirkung auf die Abfrageleistung** | **Auswirkung auf die Indexgröße** | **Empfehlung** |
| --- | --- | --- | --- | --- |
| < 100.000 | Minimal | Vernachlässigbar | Small | Standardkonfiguration |
| 100 K — 1 M | Mittel | 10-20% langsamer | Mittel | Passen Sie die Cache-Einstellungen an |
| 1 M BIS 5 M | Erheblich | 30-50% langsamer | Large (Groß) | Aggressive Optimierung erforderlich |
| 5 M BIS 10 M | Hoch | 50-70% langsamer | Sehr groß | Maximales Tuning, erwägen Sie ein Redesign |
| > 10 M | Schwerwiegend | 70% \$1 langsamer | Übertrieben | Migrieren Sie zu InfluxDB 3.0 |
**Warum 10 M der kritische Schwellenwert ist:**
+ Die InfluxDB 2.x-Architektur verwendet In-Memory-Indizierung
+ Ab der 10M-Serie werden Indexoperationen unerschwinglich teuer
+ Der Speicherbedarf steigt nichtlinear
+ Der Aufwand für die Abfrageplanung nimmt dramatisch zu
+ InfluxDB 3.0 verwendet eine spaltenförmige Speicher-Engine, die auf hohe Kardinalität ausgelegt ist
## Richtlinien zur Größe und Leistung von Instanzen
Die folgende Tabelle enthält Hinweise zur geeigneten Instance-Größe auf der Grundlage Ihrer Serienkardinalität und Workload-Merkmale:
| **Max. Anzahl Serien** | **Schreibvorgänge (Zeilen/Sekunde)** | **Liest (Abfragen/Sek.)** | **Empfohlene Instanz** | **Speichertyp** | **Anwendungsfall** |
| --- | --- | --- | --- | --- | --- |
| < 100.000 | \$150.000 | < 10 | db.influx.large | Influx IO inklusive 3.000 | Kleine Bereitstellungen, Entwicklung, Tests |
| < 1 M | \$1150.000 | < 25 | db.influx.2xgroß | Influx IO inklusive 3.000 | Kleine bis mittlere Produktionsworkloads |
| \$11 M | \$1200.000 | \$125 | db.influx.4xlarge | Influx IO inklusive 3.000 | Mittlere Produktionsworkloads |
| < 5 M | \$1250.000 | \$135 | db.influx.4xlarge | Influx IO 12K enthalten | Große Produktionsworkloads |
| < 10 M | \$1500.000 | \$150 | db.influx.8xlarge | Influx IO 12K enthalten | Sehr große Produktionsworkloads |
| \$110 M | < 750.000 | < 100 | db.influx.12x groß | Influx IO 12K enthalten | Maximale InfluxDB 2.x-Kapazität |
| > 10 M | – | – | Migrieren Sie zu InfluxDB 3.0 | – | Jenseits des optimalen Bereichs von InfluxDB 2.x |
## Konfigurationsoptimierung durch Metric
### Hohe CPU-Auslastung (CPUUtilization > 70%)
**Symptome:**
+ **CPUUtilization**> 70% nachhaltig
+ **QueryRequestsTotal**(hohes Volumen oder langsame Abfragen)
+ **ActiveTaskWorkers**(hohe Aufgabenlast)
**Anpassungen der Konfiguration:**
**Priorität 1: Steuern der Parallelität von Abfragen**
+ Parallelität bei Abfragen: Auf 50-75% der vCPU-Anzahl eingestellt
+ Beispiel: 8-vCPU-Instanz → Query-Concurrency = 4-6
**Priorität 2: Beschränken Sie die Komplexität der Abfrage**
+ influxql-max-select-series: 10000 (verhindert unbegrenzte Abfragen)
+ influxql-max-select-point: 100000000
+ query-queue-size: 2048 (verhindert den Aufbau von Warteschlangen)
**Priorität 3: Aktivieren Sie die Abfrageanalyse**
+ flux-log-enabled: TRUE (vorübergehend zum Debuggen)
+ Log-Level: Info (oder Debug für eine detaillierte Analyse)
**Wichtige Überlegungen:**
Durch die Reduzierung `query-concurrency` wird die Anzahl der Abfragen, die gleichzeitig ausgeführt werden können, begrenzt, wodurch sich die Anzahl der Abfragen in der Warteschlange erhöhen und zu einer höheren Abfragelatenz in Spitzenzeiten führen kann. Bei Benutzern kann es zu langsameren Dashboard-Ladevorgängen kommen oder Timeouts melden, wenn die Nachfrage nach Abfragen das reduzierte Parallelitätslimit überschreitet.
**Das Festlegen von Schutzgrenzwerten (`influxql-max-select-series`,`influxql-max-select-point`) führt dazu, dass Abfragen, die diese Schwellenwerte überschreiten, mit der Angabe **compile\$1error** oder runtime\$1error fehlschlagen. **QueryRequestsTotal**** Dies schützt das System zwar vor Ressourcenerschöpfung, kann aber bestehende Abfragen, die zuvor funktionierten, unterbrechen.
**Bewährtes Verfahren:** Analysieren Sie Ihre Abfragemuster anhand **QueryResponseVolume**von **QueryRequestsTotal**Messwerten, bevor Sie diese Änderungen vornehmen. Identifizieren und optimieren Sie zuerst die teuersten Abfragen — suchen Sie nach Abfragen ohne Zeitbereichsfilter, Abfragen, die Reihen mit hoher Kardinalität umfassen, oder Abfragen, die zu viele Datenpunkte erfordern. Die Optimierung von Abfragen auf Anwendungsebene ist immer vorzuziehen, als feste Grenzwerte festzulegen, die die Funktionalität beeinträchtigen könnten.
**Hardware-Aktionen:**
+ Skalieren Sie zur nächsten Instanzklasse mit mehr V CPUs
+ Überprüfen Sie die Abfragemuster auf Optimierungsmöglichkeiten
### Hohe Speicherauslastung (MemoryUtilization > 70%)
**Symptome:**
+ **MemoryUtilization**> 70% nachhaltig
+ **HeapMemoryUsage**mit Aufwärtstrend
+ **ActiveMemoryAllocation**zeigt Stacheln
+ **SeriesCardinality**(hohe Kardinalität erhöht den Speicherverbrauch)
**Anpassungen der Konfiguration:**
**Priorität 1: Cache-Speicher reduzieren**
+ storage-cache-max-memory-Größe: Auf 10-15% des gesamten RAM eingestellt
+ Beispiel: 32 GB RAM → 3.355.443.200 bis 5.033.164.800 Byte
+ storage-cache-snapshot-memory-Größe: 26.214.400 (25 MB)
**Priorität 2: Begrenzen Sie den Abfragespeicher**
+ query-memory-bytes: Auf 60-70% des gesamten RAM eingestellt
+ query-max-memory-bytes: Gleich wie query-memory-bytes
+ query-initial-memory-bytes: 10% von query-memory-bytes
**Priorität 3: Serien-Cache optimieren**
+ storage-series-id-set-cache-size: Reduziert bei hoher Kardinalität
+ Hoher Speicher: 100-200
+ Normal: 500-1000
**Wichtige Überlegungen:**
Diese Änderungen verringern zwar den Speicherdruck, wirken sich jedoch direkt negativ auf die Anwendungsleistung aus. Eine Reduzierung `storage-cache-max-memory-size` bedeutet, dass weniger Daten im Arbeitsspeicher zwischengespeichert werden, was mehr Festplattenlesevorgänge erzwingt und die Abfragelatenz erhöht. Sie werden wahrscheinlich einen **ReadOpsPerSec**Anstieg und **QueryResponseVolume**eine Verschlechterung der Antwortzeiten feststellen.
Eine Einschränkung `query-memory-bytes` führt dazu, dass speicherintensive Abfragen mit **runtime\$1error** fehlschlagen **QueryRequestsTotal**, insbesondere Abfragen, die große Datenmengen aggregieren oder umfangreiche Ergebnismengen zurückgeben. Bei Abfragen, die zuvor erfolgreich waren, können Benutzer auf Fehler stoßen, dass nicht genügend Arbeitsspeicher zur Verfügung steht.
Eine Reduzierung `storage-series-id-set-cache-size` beeinträchtigt die Leistung bei Abfragen von Daten mit hoher Kardinalität, da das System Reihenergebnisse häufiger neu berechnen muss, anstatt sie aus dem Cache abzurufen. Dies wirkt sich insbesondere auf Dashboards aus, die wiederholt dieselben Serienkombinationen abfragen.
**Bewährte Methode:** Bevor Sie diese restriktiven Änderungen anwenden, analysieren Sie Ihre Abfragemuster und optimieren Sie sie zunächst:
+ Überprüfen **QueryResponseVolume**Sie, ob Abfragen zu viele Daten zurückgeben
+ Wird verwendet **QueryRequestsTotal**, um häufig ausgeführte Abfragen zu finden, die von einer Optimierung profitieren könnten
+ Fügen Sie Zeitbereichsfilter hinzu, um das Scannen von Daten auf das zu reduzieren, was für Ihre Arbeitslast erforderlich ist
+ Implementieren Sie das Zwischenspeichern von Abfrageergebnissen auf Anwendungsebene
+ Erwägen Sie, Daten mithilfe von Downsampling-Aufgaben vorab zu aggregieren
+ Überprüfen **SeriesCardinality**und optimieren Sie Ihr Datenmodell, um unnötige Tags zu reduzieren
Die Abfrageoptimierung sollte immer Ihr erster Ansatz sein — Konfigurationseinschränkungen sollten das letzte Mittel sein, wenn die Optimierung nicht ausreicht.
**Hardware-Aktionen:**
+ Erhöhen Sie die Instanzgröße für mehr RAM
### Hohe Speicherauslastung (DiskUtilization > 70%)
**CloudWatch Zu überwachende Metriken:**
+ **DiskUtilization**> 70%
+ **WriteThroughput**Muster
+ **TotalBuckets**(viele Buckets erhöhen den Overhead)
**Anpassungen der Konfiguration:**
**Priorität 1: Überprüfen Sie die Protokollierungskonfiguration**
+ Protokollebene: Stellen Sie sicher, dass die Einstellung auf „Info“ (nicht auf „Debug“) gesetzt ist
+ flux-log-enabled: Auf FALSE setzen, sofern nicht aktiv debuggt wird
**Priorität 2: Aggressive Aufbewahrung**
+ storage-retention-check-interval: 150 Minuten (häufigere Reinigung)
**Priorität 3: Optimieren Sie die Verdichtung**
+ storage-compact-full-write-Kältedauer: 20h0ms (häufiger)
+ storage-cache-snapshot-write-Kältedauer: 50 Minuten
**Priorität 4: Indexgröße reduzieren**
+ storage-max-index-log-Dateigröße: 524.288 (512 KB für schnellere Komprimierung)
**Wichtige Überlegungen:**
**Wichtiger erster Schritt — Überprüfen Sie Ihre Protokollierungskonfiguration:** Bevor Sie weitere Änderungen vornehmen, überprüfen Sie Ihre Protokollierungseinstellungen. **Debug-Logging und Flux-Abfrageprotokolle können genauso viel oder mehr Festplattenspeicher beanspruchen als Ihre tatsächlichen Zeitreihendaten**. Dies ist eine der häufigsten Ursachen für unerwartete Speichererschöpfung.
**Auswirkungen auf die Protokollierung:**
+ `log-level: debug`generiert extrem ausführliche Protokolle, möglicherweise Hunderte von MB pro Stunde
+ `flux-log-enabled: TRUE`protokolliert jede Flux-Abfrageausführung mit allen Details und erstellt riesige Protokolldateien
+ Diese Protokolle häufen sich schnell an und werden bei der Kapazitätsplanung oft übersehen
+ Protokolldateien können den Festplattenspeicher schneller füllen als die Datenaufnahme, insbesondere bei kleineren Instanzen
+ Im Gegensatz zu Zeitreihendaten werden Protokolle 24 Stunden lang im lokalen Speicher aufbewahrt, bevor sie gelöscht werden
**Sofortige Maßnahmen bei großen Protokollen:**
1. Set `log-level: info` (aus dem Debug)
1. Legen Sie `flux-log-enabled: FALSE` fest.
1. Überwachen Sie **DiskUtilization**die Situation auf sofortige Verbesserung
**Kompromisse bei der Konfiguration der Verdichtung:**
Diese Konfigurationsänderungen wurden speziell für Workloads mit **hohem Aufnahmedurchsatz und kurzen Aufbewahrungsfenstern entwickelt, bei denen die** Festplattennutzung stark schwankt. Sie zwingen den Verdichtungsmotor, aggressiver zu arbeiten, was nur in bestimmten Szenarien von Vorteil ist.
**Kritische Kompromisse: Eine Erhöhung der Verdichtungshäufigkeit wird den Ressourcenverbrauch erheblich erhöhen:**
+ **CPUUtilization**wird steigen, da Verdichtungsvorgänge CPU-Zyklen verbrauchen
+ **MemoryUtilization**nimmt während der Komprimierung zu, wenn Daten geladen und verarbeitet werden
+ **WriteOpsPerSec**und **WriteThroughput**wird während der Verdichtungsfenster stark ansteigen, sodass Ihr IOPS-Spielraum von 30% möglicherweise überschritten wird
+ **WriteTimeouts**kann zunehmen, wenn die Komprimierung mit den Schreibvorgängen der Anwendung konkurriert I/O
Diese Änderungen können zu einem kaskadierenden Leistungsproblem führen, bei dem eine aggressive Komprimierung Ressourcen verbraucht, die für Abfrage- und Schreibvorgänge benötigt werden, wodurch die Gesamtsystemleistung beeinträchtigt wird, obwohl gleichzeitig die Festplattennutzung reduziert wird.
**Bewährte Methode:** Bevor Sie die Komprimierungseinstellungen anpassen, sollten Sie sich auf die Daten- und Protokollierungsverwaltung konzentrieren:
1. **Überprüfen Sie zuerst die Protokollierung (häufigstes Problem):** Stellen Sie sicher, dass die Protokollebene „info“ und FALSE ist flux-log-enabled
1. **Überprüfen Sie Ihr Datenmodell:** Schreiben Sie Daten, die Sie eigentlich nicht benötigen? Können Sie die Mess- oder Feldgranularität reduzieren?
1. **Optimieren Sie die Aufbewahrungsrichtlinien:** Prüfen **TotalBuckets**und überprüfen Sie die Aufbewahrungseinstellungen für jeden Bereich
1. **Überwachen Sie die Auswirkungen der Komprimierung: Erstellen** Sie einen Überblick über Ihre **CPUUtilization**MemoryUtilization****, und **WriteOpsPerSec**vor den Änderungen
**Alternative Ansätze:**
+ Erhöhen Sie die Speicherkapazität (oft einfacher und kostengünstiger)
+ Implementieren Sie Strategien für das Downsampling oder die Aggregation von Daten
+ Konsolidieren Sie Bereiche (reduzieren **TotalBuckets**), um den Overhead zu senken
+ Überprüfen und durchsetzen Sie die Aufbewahrungsrichtlinien strenger
Wenden Sie aggressive Komprimierungseinstellungen nur an, wenn Sie das Datenmanagement optimiert und bestätigt haben, dass Ihre Instance über ausreichend CPU-, Arbeitsspeicher- und IOPS-Headroom verfügt, um die erhöhte Last zu bewältigen.
**Hardware-Aktionen:**
+ Erhöhen Sie die Speicherkapazität
### Hohe IOPS-Auslastung (ReadIOPS/WriteIOPS/TotalOperationsPerSecond> 70% der bereitgestellten)
**CloudWatch Zu überwachende Metriken:**
+ **ReadOpsPerSec**\$1 **WriteOpsPerSec**= **Insgesamt IOps PerSec**
+ **ReadThroughput** und **WriteThroughput**
+ Vergleich mit bereitgestellten IOPS (3.000, 12.000 oder 16.000)
**Anpassungen der Konfiguration:**
**Priorität 1: Steuern Sie die Verdichtungs-I/O**
+ storage-max-concurrent-compactions: 2-3 (Begrenzung gleichzeitiger Verdichtungen)
+ storage-compact-throughput-burst: Passen Sie die Einstellungen je nach Festplattenkapazität an
+ 3.000 IOPS: 25.165.824 (24 MB/s)
+ 12.000 IOPS: 50.331.648 (48 MB/s)
**Priorität 2: Optimieren Sie Schreibvorgänge**
+ storage-wal-max-concurrent-schreibt: 8-12
+ storage-wal-max-write-Verzögerung: 50 ms
**Priorität 3: Passen Sie das Snapshot-Timing an**
+ storage-cache-snapshot-write-Kältedauer: 150 ms (weniger häufig)
+ storage-compact-full-write-Kältedauer: 60 h 0 ms (weniger häufig)
**Wichtige Überlegungen:**
Diese Änderungen führen zu erheblichen Kompromissen zwischen I/O Auslastung und Systemleistung:
**Begrenzung der Compaction-I/O:**
+ Durch die Reduzierung `storage-max-concurrent-compactions` werden die Komprimierungsvorgänge verlangsamt, was dazu führt, dass sich TSM-Dateien ansammeln und schneller **DiskUtilization**zunehmen
+ Niedriger `storage-compact-throughput-burst` Wert verlängert die Verdichtungsdauer, wodurch der Verdichter länger aktiv bleibt und möglicherweise andere Vorgänge blockiert werden
+ Eine langsamere Komprimierung bedeutet, dass die Abfrageleistung im Laufe der Zeit abnimmt, da die Speicher-Engine aus mehr, kleineren TSM-Dateien statt aus konsolidierten Dateien lesen muss
+ Es kann sein, dass die **QueryRequestsTotal**runtime\$1error-Raten steigen, wenn Abfragen beim Warten auf I/O das Timeout überschreiten
**Reduzierung der Snapshot-Frequenz:**
+ Zunehmend `storage-cache-snapshot-write-cold-duration` `storage-compact-full-write-cold-duration` bedeutet, dass Daten länger im Write-Ahead-Log (WAL) verbleiben
+ Dies nimmt zu **MemoryUtilization**, je mehr Daten im Cache gespeichert werden, bevor sie auf die Festplatte gespeichert werden
+ Das Risiko eines Datenverlusts steigt leicht an, wenn die Instanz abstürzt, bevor die zwischengespeicherten Daten dauerhaft gespeichert werden
+ Die Wiederherstellungszeit nach einem Neustart nimmt zu, da mehr WAL-Daten wiedergegeben werden müssen
**Optimierung des Schreibvorgangs:**
+ Durch die Reduzierung `storage-wal-max-concurrent-writes` werden Schreibvorgänge stärker serialisiert, was in **WriteTimeouts**Zeiten mit hohem Durchsatz möglicherweise zunimmt
+ Eine Erhöhung `storage-wal-max-write-delay` bedeutet, dass Schreibvorgänge länger warten können, bevor sie zurückgewiesen werden. Dadurch können Kapazitätsprobleme verschleiert werden, die Benutzer werden jedoch durch langsame Antworten frustriert
**Bewährtes Verfahren:** Eine hohe IOPS-Auslastung deutet in der Regel eher darauf hin, dass Sie Ihrer Speicherebene zu wenig gewachsen sind, als dass es sich um ein Konfigurationsproblem handelt. Vor der Einschränkung von I/O, analyze I/O Mustern und Optimierung vor der Einschränkung.
**Hardware-Aktionen:**
+ Führen Sie ein Upgrade auf eine höhere IOPS-Speicherstufe durch (3.000 → 12.000)
+ Stellen Sie sicher, dass der IOPS-Headroom von 30% gewahrt bleibt
### Hohe Serien-Kardinalität (> 1 M) SeriesCardinality
**CloudWatch Zu überwachende Metriken:**
+ **SeriesCardinality**pro Bucket und insgesamt
+ **MemoryUtilization**(nimmt mit der Kardinalität zu)
+ **CPUUtilization**(Mehraufwand bei der Abfrageplanung)
+ **QueryRequestsTotal**(Die Runtime\$1Error-Rate kann steigen)
**Anpassungen der Konfiguration:**
**Priorität 1: Optimieren Sie die Handhabung von Serien**
+ storage-series-id-set-Cache-Größe: 1000-2000 (Cache vergrößern)
+ storage-series-file-max-concurrent-snapshot-compactions: 4-8
**Priorität 2: Schutzgrenzen festlegen**
+ influxql-max-select-series: 10000 (verhindert außer Kontrolle geratene Abfragen)
+ influxql-max-select-buckets: 1000
**Priorität 3: Optimieren Sie die Indexoperationen**
+ storage-max-index-log-Dateigröße: 2.097.152 (2 MB)
**Wichtige Überlegungen:**
Eine hohe Reihenkardinalität ist grundsätzlich ein Datenmodellierungsproblem, kein Konfigurationsproblem. Konfigurationsänderungen können nur die Symptome mildern — sie können das zugrundeliegende Problem nicht lösen.
**Kompromisse bei der Konfiguration:**
Durch die Erhöhung `storage-series-id-set-cache-size` wird die Abfrageleistung verbessert, da serielle Suchvorgänge zwischengespeichert werden, allerdings auf Kosten höherer Suchvorgänge. **MemoryUtilization** Jeder Cache-Eintrag verbraucht Speicherplatz, und bei Millionen von Serien kann dies erheblich sein. Überwachen **HeapMemoryUsage**und **ActiveMemoryAllocation**nach der Durchführung dieser Änderung.
Das Setzen von Schutzgrenzwerten (`influxql-max-select-series`,`influxql-max-select-buckets`) führt dazu, dass legitime Abfragen mit der Angabe **compile\$1error** fehlschlagen, **QueryRequestsTotal**wenn sie diese Schwellenwerte überschreiten. Dashboards, die zuvor funktionierten, funktionieren möglicherweise nicht mehr und Benutzer müssen ihre Abfragen ändern. Dies ist besonders problematisch für:
+ Monitoring-Dashboards, die sich über viele Hosts/Services erstrecken
+ Analytics-Abfragen, bei denen mehrere Entitäten verglichen werden müssen
+ Warnabfragen, bei denen die Bedingungen für die gesamte Flotte bewertet werden
Die Anpassung `storage-max-index-log-file-size` an kleinere Werte erhöht die Häufigkeit der Indexkomprimierung, was wiederum zunimmt, je häufiger der Index vom System verwaltet wird. **CPUUtilization**WriteOpsPerSec****
**Kritisches Verständnis:**
Bei einer **SeriesCardinality**Überschreitung von 5 Mio. erreichen Sie die architektonischen Grenzen von InfluxDB 2.x. Bei der Serie 10M\$1 nimmt die Leistung unabhängig von der Konfiguration exponentiell ab:
+ Die Planung von Abfragen wird unerschwinglich teuer (hoch) **CPUUtilization**
+ Der Speicherbedarf steigt nichtlinear (hoch) **MemoryUtilization**
+ Indexoperationen dominieren I/O (**ReadOpsPerSec**,) **WriteOpsPerSec**
+ **QueryRequestsTotal**Die runtime\$1error-Raten steigen, wenn Abfragen das Timeout überschreiten oder den Speicherplatz erschöpfen
**Bewährtes Verfahren:** Konfigurationsänderungen sind vorübergehende Notfälle. Sie müssen sich mit der Grundursache befassen:
1. **Analysieren Sie Ihr Datenmodell:**
+ Überprüfung **SeriesCardinality**pro Bereich, um Problembereiche zu identifizieren
+ Identifizieren Sie, welche Tags eine hohe Anzahl an Einzelwerten haben
+ Suchen Sie nach unbegrenzten Tag-Werten (UUIDs, Zeitstempel, Benutzer IDs, Sitzung) IDs
+ Suchen Sie nach Tags, die stattdessen Felder sein sollten
**Datenmodell-Aktionen:**
+ Überprüfen Sie das Tag-Design, um unnötige Kardinalität zu reduzieren
+ Erwägen Sie, ähnliche Serien zu konsolidieren
+ **Wenn > 10M-Serie:** Planen Sie die Migration zu InfluxDB 3.0
### Probleme mit der Abfrageleistung
**CloudWatch Zu überwachende Metriken:**
+ **QueryRequestsTotal**nach Ergebnistyp (Erfolg, Runtime\$1Error, Compile\$1Error, Warteschlangenfehler)
+ **APIRequestBewerten Sie mit Status=500 oder Status=499**
+ **QueryResponseVolume**(große Antworten deuten auf teure Abfragen hin)
**Anpassungen der Konfiguration:**
**Priorität 1: Erhöhung der Abfrageressourcen**
+ Parallelität von Abfragen: Erhöhung auf 75% von v CPUs
+ query-memory-bytes: Weist 70% des gesamten Arbeitsspeichers zu
+ query-queue-size: 4096
**Priorität 2: Optimieren Sie die Abfrageausführung**
+ storage-series-id-set-Cache-Größe: 1000 (für besseres Caching erhöhen)
+ http-read-timeout: 60s (verhindert vorzeitige Timeouts)
**Priorität 3: Setzen Sie angemessene Grenzwerte**
+ influxql-max-select-point: 100000000
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
**Wichtige Überlegungen:**
Die Erhöhung der Abfrageressourcen führt zu Ressourcenkonkurrenz und potenzieller Systeminstabilität:
**Kompromisse bei der Ressourcenzuweisung:**
`query-concurrency`Durch die Erhöhung können mehr Abfragen gleichzeitig ausgeführt werden, aber jede Abfrage konkurriert um CPU und Arbeitsspeicher:
+ **CPUUtilization**nimmt zu und erreicht in Spitzenzeiten bei Abfragen möglicherweise eine Sättigung
+ **MemoryUtilization**steigt, wenn mehr Abfragen gleichzeitig Speicher zuweisen
+ Wenn Sie die Parallelität erhöhen, ohne dass ausreichend Ressourcen zur Verfügung stehen, werden alle Abfragen langsamer, anstatt nur einige Warteschlangen zu bilden
+ Risiko eines kaskadierenden Fehlers, wenn gleichzeitige Abfragen die verfügbaren Ressourcen erschöpfen
Wenn mehr zugewiesen wird, `query-memory-bytes` steht weniger Speicher für das Zwischenspeichern und andere Operationen zur Verfügung:
+ **HeapMemoryUsage**wird zunehmen
+ `storage-cache-max-memory-size`muss möglicherweise reduziert werden, um dies zu kompensieren
+ Weniger Cache-Treffer bedeuten eine höhere **ReadOpsPerSec**und langsamere Abfrageleistung
+ Das System ist anfälliger für Speichererschöpfung, wenn Abfragen ihre volle Zuweisung verwenden
Eine Erhöhung verzögert das Problem `query-queue-size` nur — Kapazitätsprobleme werden dadurch nicht gelöst:
+ Abfragen warten länger in der Warteschlange, was die end-to-end Latenz erhöht
+ Benutzer nehmen das System als langsamer wahr, obwohl der Durchsatz möglicherweise unverändert bleibt
+ Große Warteschlangen können zugrundeliegende Kapazitätsprobleme verschleiern
+ **QueryRequestsTotal**Die Queue\$1Error-Rate sinkt, aber die Benutzererfahrung verbessert sich möglicherweise nicht
Eine Erhöhung `http-read-timeout` verhindert ein vorzeitiges Abbrechen von Abfragen, aber:
+ Abfragen mit langer Laufzeit verbrauchen länger Ressourcen, wodurch die Kapazität für andere Abfragen reduziert wird
+ Benutzer warten länger, bis sie Timeout-Fehler erhalten
+ Kann ineffiziente Abfragen verbergen, die optimiert werden sollten
+ Kann zur Erschöpfung der Ressourcen führen, wenn sich viele langsame Abfragen ansammeln
**Bewährte Methode:** Leistungsprobleme bei Abfragen werden in der Regel durch ineffiziente Abfragen und nicht durch unzureichende Ressourcen verursacht. Bevor Sie die Ressourcenzuweisung erhöhen:
1. **Abfragemuster analysieren:**
+ Überprüfung **QueryResponseVolume**, um Abfragen zu identifizieren, die zu viele Daten zurückgeben (> 1 MB)
+ Überprüfen Sie die **QueryRequestsTotal**Runtime\$1Error-Muster — was verursacht Fehler?
+ Suchen Sie nach **APIRequestRate** mit Status=499 (Client-Timeouts) — Abfragen sind zu langsam
+ Identifizieren Sie häufig ausgeführte teure Abfragen
1. **Optimieren Sie zuerst Abfragen:**
Allgemeine Anti-Muster für Abfragen:
+ Fehlende Zeitbereichsfilter → Explizite Zeitgrenzen hinzufügen
+ Alle Serien abfragen → Spezifische Tag-Filter hinzufügen
+ Zu viele Aggregationsfenster → Verwenden Sie geeignete Intervalle
+ Unnötige Felder in SELECT → Nur benötigte Daten anfordern
+ Keine LIMIT-Klauseln → Fügen Sie angemessene Grenzwerte hinzu
1. **Lösungen auf Anwendungsebene:**
+ Implementieren Sie das Zwischenspeichern von Abfrageergebnissen (Redis, Memcached)
+ Verwenden Sie Aufgaben, um allgemeine Muster vorab zu aggregieren
+ Fügen Sie Paginierung für große Ergebnismengen hinzu
+ Implementieren Sie eine Begrenzung der Abfragerate pro Benutzer/Dashboard
+ Verwenden Sie Downsampling-Daten für historische Abfragen
1. **Überprüfen Sie die Verfügbarkeit der Ressourcen:**
+ Prüfen Sie **CPUUtilization**: Wenn Sie bereits über 70% sind, wird eine Erhöhung der Parallelität die Situation noch schlimmer machen
+ Überprüfen Sie **MemoryUtilization**: Wenn bereits > 70% sind, führt die Zuweisung von mehr Abfragespeicher zu OOM
+ Stellen Sie sicher, dass **Total IOps PerSec** über 30% Spielraum verfügt, bevor Sie die Abfragelast erhöhen
**Empfohlener Ansatz:**
1. Optimieren Sie zunächst die 10 teuersten Abfragen (von **QueryResponseVolume**)
1. Implementieren Sie das Zwischenspeichern von Abfrageergebnissen auf Anwendungsebene
1. Erhöhen Sie die Ressourcenzuweisung nur, wenn Abfragen optimiert sind und die Metriken Spielraum zeigen
1. Skalieren Sie auf eine größere Instance-Klasse, wenn die Arbeitslast die aktuelle Kapazität übersteigt
**Hardware-Aktionen:**
+ Skalieren Sie Ihre Rechenkapazität, Abfragen profitieren von zusätzlicher Rechenleistung (vCPUs)
#### RegEx Leistungsprobleme bei Flux-Abfragen
Vermeiden Sie beim Filtern von Daten in Flux die Verwendung regulärer Ausdrücke für exakte Übereinstimmungen oder einfachen Musterabgleich, da dies zu erheblichen Leistungseinbußen führt. RegEx Operationen in Flux sind **Single-Thread-Operationen** und **umgehen den zugrunde liegenden TSM-Index vollständig**. Anstatt die optimierten Tag-Indizes von InfluxDB für schnelle Suchvorgänge zu nutzen, zwingen RegEx Filter die Abfrage-Engine, alle passenden Serien aus dem Speicher abzurufen und nacheinander Textvergleiche für jeden Wert durchzuführen. Dies wird besonders problematisch, wenn:
+ Nach **exakten Tag-Werten filtern** — Verwenden Sie den Gleichheitsoperator (`==`) oder die `contains()` Funktion anstelle von RegEx Mustern wie `/^exact_value$/`
+ **Abgleich mehrerer bestimmter Werte** — Verwenden Sie den `in` Operator mit einer Reihe von Werten anstelle von Alternationsmustern wie `/(value1|value2|value3)/`
+ **Einfacher Präfix- oder Suffixabgleich** — Erwägen Sie die Verwendung von `strings.hasPrefix()` `strings.hasSuffix()` OR-Funktionen, die effizienter sind als Anker RegEx
In Szenarien, die mehrere Musterübereinstimmungen erfordern, strukturieren Sie Ihre Abfrage neu, sodass mehrere Filterprädikate in Kombination mit logischen Operatoren verwendet werden, oder filtern Sie mithilfe der Tag-Gleichheit vorab, bevor Sie komplexere Zeichenkettenoperationen anwenden. Reservieren Sie RegEx sich ausschließlich für Fälle, in denen ein echter Musterabgleich erforderlich ist, der nicht durch einfachere Vergleichsoperatoren ausgedrückt werden kann.
### Leistungsprobleme beim Schreiben
**CloudWatch Zu überwachende Metriken:**
+ **WriteTimeouts**(steigende Anzahl)
+ **WriteOpsPerSec** und **WriteThroughput**
+ **APIRequestRate** mit Status=500 für Schreibendpunkte
+ **QueryRequestsTotal**mit result=runtime\$1error bei Schreibvorgängen
**Anpassungen der Konfiguration:**
**Priorität 1: Optimieren Sie WAL-Schreibvorgänge**
+ storage-wal-max-concurrent-schreibt: 12-16
+ storage-wal-max-write-Verzögerung: 100 ms
+ http-write-timeout: 60 s
**Priorität 2: Cache-Snapshots optimieren**
+ storage-cache-snapshot-memory-Größe: 52.428.800 (50 MB)
+ storage-cache-snapshot-write-Kältedauer: 100 ms
**Priorität 3: Überprüfung des Kontrollfeldes**
+ storage-no-validate-field-size: TRUE (wenn die Datenquelle vertrauenswürdig ist)
**Wichtige Überlegungen:**
Die Optimierung der Schreibleistung erfordert sorgfältige Kompromisse zwischen Durchsatz, Zuverlässigkeit und Ressourcenverbrauch:
**Kompromisse bei der WAL-Konfiguration:**
Eine Erhöhung `storage-wal-max-concurrent-writes` ermöglicht mehr parallel Schreiboperationen, aber:
+ **CPUUtilization**nimmt zu, je mehr Schreib-Threads um die CPU konkurrieren
+ **MemoryUtilization**steigt, wenn vor dem WAL-Flush mehr Daten im Speicher zwischengespeichert werden
+ **WriteOpsPerSec**wird stark ansteigen und möglicherweise Ihre 30-prozentige IOPS-Speicherkapazität überschreiten
+ Zunehmende Festplattenkonflikte I/O können einzelne Schreibvorgänge sogar verlangsamen
+ Wenn Sie die I/O Festplattenkapazität überschreiten, **WriteTimeouts**kann sie eher steigen als abnehmen
Eine Erhöhung `storage-wal-max-write-delay` bedeutet, dass Schreibvorgänge länger warten, bis ein Timeout eintritt:
+ Verschleiert Kapazitätsprobleme, indem Schreibvorgänge warten, anstatt schnell fehlzuschlagen
+ Benutzer erleben langsamere Antwortzeiten beim Schreiben, selbst wenn Schreibvorgänge letztendlich erfolgreich sind
+ Kann zum Aufbau von Schreibwarteschlangen und zu Speicherauslastung führen
+ Erhöht die Kapazität nicht wirklich, sondern verzögert nur den Timeout
Eine Erhöhung verzögert in `http-write-timeout` ähnlicher Weise Timeout-Fehler:
+ Ermöglicht das Abschließen größerer Batch-Schreibvorgänge
+ Ermöglicht aber auch langsame Schreibvorgänge, wodurch Ressourcen länger beansprucht werden
+ Kann zugrundeliegende Leistungsprobleme verbergen
+ Kann zur Erschöpfung der Ressourcen führen, wenn sich viele langsame Schreibvorgänge ansammeln
**Kompromisse beim Cache-Snapshot:**
Zunehmend `storage-cache-snapshot-memory-size` bedeutet, dass sich vor dem Leeren mehr Daten im Speicher ansammeln:
+ **MemoryUtilization**nimmt erheblich zu
+ Das Risiko eines Datenverlusts steigt, wenn die Instanz vor dem Snapshot abstürzt
+ Bei größeren Snapshots dauert das Schreiben länger, was zu größeren Datenspitzen führt **WriteOpsPerSec**
+ Kann den Schreibdurchsatz verbessern, indem mehr Daten gebündelt werden, allerdings auf Kosten des Speichers und der Zuverlässigkeit
Zunehmende `storage-cache-snapshot-write-cold-duration` Verzögerungen bei Snapshots:
+ Nimmt weiter zu **MemoryUtilization**, je länger die Daten im Cache bleiben
+ Erhöht das Risikofenster für Datenverlust
+ Reduziert die **WriteOpsPerSec**Häufigkeit, führt jedoch zu größeren Spitzen, wenn Schnappschüsse auftreten
+ Die Wiederherstellungszeit nach dem Neustart nimmt zu, da mehr WAL wiedergegeben werden muss
**Kompromiss bei der Feldvalidierung:**
Die Einstellung `storage-no-validate-field-size: TRUE` deaktiviert die Überprüfung der Feldgröße:
+ Verbessert den Schreibdurchsatz, indem Validierungsprüfungen übersprungen werden
+ **Kritisches Risiko:** Ermöglicht das Schreiben fehlerhafter oder bösartiger Daten
+ Kann zu Datenbeschädigungen führen, wenn Schreibvorgänge ungültige Feldgrößen enthalten
+ Macht das Debuggen von Datenproblemen erheblich schwieriger
+ **Verwenden Sie diese Option nur, wenn Sie die vollständige Kontrolle über Ihre Datenquelle haben und ihr vertrauen**
**Bewährte Methode:** Leistungsprobleme beim Schreiben deuten in der Regel auf Kapazitätsgrenzen oder ineffiziente Schreibmuster hin. Vor dem Optimieren der Konfiguration:
1. **Schreibmuster analysieren:**
+ Rückblick **WriteThroughput**und **WriteOpsPerSec**Trends
+ Überprüfen Sie die **WriteTimeouts**Korrelation mit der Schreiblast
+ Überwachen Sie die **APIRequestRate** für Schreibendpunkte anhand des Statuscodes
+ Identifizieren Sie die Größe und Häufigkeit von Schreibstapeln
1. **Optimieren Sie zuerst die Schreibvorgänge:**
Gängige Anti-Schreibmuster:
+ Einzelne Punkte schreiben → Batch-Schreibvorgänge (5.000-10.000 Punkte)
+ Zu häufige Schreibvorgänge → Puffer und Batch
+ Synchrone Schreibvorgänge → Implementieren Sie asynchrone Schreibwarteschlangen
+ Unbegrenzte Schreibbursts → Implementieren Sie eine Ratenbegrenzung
+ Unnötige Präzision schreiben → Zeitstempel richtig runden
1. ** I/O Kapazität überprüfen:**
+ Überprüfen Sie die **Gesamtanzahl**. Wenn Sie bereits über 70% sind, wird die Situation durch eine Erhöhung der IOps PerSec WAL-Parallelität noch schlimmer
+ Überprüfen Sie dies **WriteOpsPerSec**in Spitzenzeiten
+ Stellen Sie sicher, dass ein IOPS-Headroom von 30% besteht, bevor Sie die Schreibeinstellungen anpassen
+ Überlegen Sie, ob 3.000 IOPS ausreichend sind oder ob eine Stufe mit 12.000 IOPS erforderlich ist
1. **Verbesserungen auf Anwendungsebene:**
+ Implementieren Sie Schreibpufferung mit konfigurierbaren Batchgrößen
+ Fügen Sie eine Schreibwiederholungslogik mit exponentiellem Backoff hinzu
+ Verwenden Sie asynchrone Schreiboperationen
+ Implementieren Sie eine Begrenzung der Schreibrate in Spitzenzeiten
+ Überwachen Sie die Tiefe der Schreibwarteschlange und wenden Sie Gegendruck an
**Empfohlener Ansatz:**
1. Beginnen Sie mit der Optimierung der Schreibstapelgrößen auf Anwendungsebene (streben Sie 5.000 bis 10.000 Punkte pro Stapel an)
1. Implementieren Sie Schreibpufferung und asynchrone Operationen
1. Stellen Sie sicher, dass **Total IOps PerSec über ausreichend Spielraum** verfügt
1. Führen Sie ein Upgrade auf die nächste Speicherstufe (3.000 IOPS → 12.000 IOPS → 16.000 IOPS) durch, wenn die Auslastung konstant über 70% liegt
1. Passen Sie die WAL-Einstellungen nur an, wenn Schreibvorgänge optimiert sind und die Kapazität ausreichend ist I/O
1. Deaktivieren Sie **niemals** die Feldvalidierung, es sei denn, Sie haben die vollständige Kontrolle über die Datenquellen
**Hardware-Aktionen:**
+ Führen Sie ein Upgrade auf Speicher mit höherem IOPS-Wert durch (3.000 → 12.000 → 16.000)
+ Stellen Sie sicher, dass genügend Spielraum vorhanden ist I/O
+ Skalieren Sie auf eine größere Instance-Klasse, wenn CPU- oder Speicherbeschränkungen bestehen
## Bewährte Methoden für die Überwachung
### CloudWatch Konfiguration von Alarmen
**Kritische Alarme (Sofortiges Handeln erforderlich):**
**CPUUtilization:**
+ Schwellenwert: > 90% für 5 Minuten
+ Maßnahme: Implementieren Sie Maßnahmen zur Behebung des Datenverkehrs oder Compute Scaling
**MemoryUtilization:**
+ Schwellenwert: > 90% für 5 Minuten
+ Maßnahme: Implementieren Sie Maßnahmen zur Behebung des Datenverkehrs oder Compute Scaling
**DiskUtilization:**
+ Schwellenwert: > 85%
+ Maßnahme: Versuchen Sie, Speicherplatz freizugeben, indem Sie alte Buckets löschen, Aufbewahrungskonfigurationen aktualisieren oder Storage Scaling
**Insgesamt IOpsPerSec:**
+ Schwellenwert: > 90% der bereitgestellten Werte für 10 Minuten
+ Maßnahme: Implementieren Sie Maßnahmen zur Behebung des Datenverkehrs oder erhöhen Sie die IOPS
**SeriesCardinality:**
+ Schwellenwert: > 10.000.000
+ Maßnahme: Überprüfen Sie Ihr Datenmodell. Wenn keine Änderungen möglich sind, erkunden Sie, migrieren Sie zu InfluxDB 3 oder teilen Sie Ihre Daten
**EngineUptime:**
+ Schwellenwert: Unerwarteter Reset (< 300 Sekunden)
+ Maßnahme: Prüfen Sie, ob es mit einem Wartungsfenster übereinstimmt, falls nicht, erstellen Sie ein Ticket für den Timestream-Support.
**Warnmeldungen (Untersuchung erforderlich):**
**CPUUtilization:**
+ Schwellenwert: > 70% für 15 Minuten
+ Maßnahme: Überprüfen Sie Änderungen der Arbeitslast oder des Datenverkehrs
**MemoryUtilization:**
+ Schwellenwert: > 70% für 15 Minuten
+ Maßnahme: Überprüfen Sie Änderungen der Arbeitslast oder des Datenverkehrs
**DiskUtilization:**
+ Schwellenwert: > 70%
+ Maßnahme: Überprüfen Sie die Aufbewahrungsrichtlinien
**Insgesamt IOpsPerSec:**
+ Schwellenwert: > 70% der bereitgestellten Werte für 15 Minuten
+ Maßnahme: Überprüfen Sie Änderungen der Arbeitslast oder des Datenverkehrs
**QueryRequestsTotal (Laufzeitfehler):**
+ Schwellenwert: > 1% aller Abfragen
+ Maßnahme: Überprüfen Sie Änderungen der Arbeitslast oder des Datenverkehrs
**WriteTimeouts:**
+ Schwellenwert: > 1% der Schreibvorgänge
+ Maßnahme: Überprüfen Sie Änderungen der Arbeitslast oder des Datenverkehrs
**SeriesCardinality:**
+ Schwellenwert: > 5.000.000
+ Maßnahme: Überprüfen Sie die Optimierung des Datenmodells
### Checkliste für die proaktive Überwachung
**Täglich:**
+ Überprüfen APIRequest Sie die Rate für Fehlerspitzen (400, 404, 499, 500)
+ Prüfen Sie QueryRequestsTotal die Raten runtime\$1error und queue\$1error
+ Stellen WriteTimeouts Sie sicher, dass die Anzahl minimal ist
+ Suchen Sie nach kritischen Alarmen
+ Überprüfen Sie EngineUptime (keine unerwarteten Neustarts)
**Wöchentlich:**
+ Rückblick CPUUtilization MemoryUtilization und DiskUtilization Trends
+ Analysieren Sie QueryRequestsTotal Muster nach Ergebnistyp
+ Überprüfen Sie die SeriesCardinality Wachstumsrate pro Eimer
+ Sehen Sie sich die Trends zur IOps PerSec Gesamtnutzung an
+ Stellen Sie sicher, dass die Konfigurationsparameter optimal sind
+ Überprüfen Sie die TaskExecutionFailures Muster
**Monatlich:**
+ Überprüfung der Kapazitätsplanung (Projekt 3-6 Monate im Voraus)
+ Vergleichen Sie die aktuellen Kennzahlen mit der Größentabelle
+ Überprüfen und optimieren Sie die Aufbewahrungsrichtlinien
+ Analysieren Sie Abfragemuster aus APIRequest Rate und QueryResponseVolume
+ Überprüfung SeriesCardinality und Effizienz des Datenmodells
+ Beurteilen Sie den Bedarf an Instanzskalierung oder Konfigurationsänderungen
+ Überprüfung TotalBuckets und Konsolidierung der Möglichkeiten
## Anleitung zur Fehlerbehebung
### Szenario: Plötzlicher Leistungsabfall
**Schritte der Untersuchung:**
**Überprüfen Sie die letzten Änderungen:**
+ Änderungen der Konfigurationsparameter in der AWS Management Console
+ Änderungen bei der Anwendungsbereitstellung
+ Änderungen des Abfragemusters
+ Änderungen am Datenmodell
+ Änderungen an der Infrastruktur (Instanztyp, Speicher)
** CloudWatch Metriken überprüfen:**
+ **CPU-Spitze?** → Prüfen CPUUtilization, QueryRequestsTotal
+ **Speicherdruck?** → Prüfen MemoryUtilization HeapMemoryUsage, ActiveMemoryAllocation
+ **IOPS-Sättigung?** → Summe überprüfen IOpsPerSec, ReadOpsPerSec WriteOpsPerSec
+ **Serie: Kardinalitätssprung?** → Wachstum überprüfen SeriesCardinality
+ **Erhöhung der Fehlerquote?** → Prüfen QueryRequestsTotal (runtime\$1error), APIRequest Rate (Status=500)
+ **Unerwarteter Neustart?** → Prüfen EngineUptime
**Detaillierte Protokollierung aktivieren:**
Änderungen an der Konfiguration:
+ Protokollebene: Debuggen
+ flux-log-enabled: WAHR
Überwachen Sie für 1—2 Stunden und überprüfen Sie dann die Protokolle
Zurück zur Protokollebene: Informationen nach der Untersuchung
**Schritte zur Lösung:**
+ Wenden Sie auf der Grundlage der Ergebnisse die entsprechenden Konfigurationsänderungen an
+ Skalieren Sie Ressourcen, wenn Grenzwerte erreicht werden
+ Optimieren Sie bei Bedarf Abfragen oder Datenmodelle
+ Implementieren Sie eine Ratenbegrenzung bei plötzlichem Lastanstieg
### Szenario: Speichererschöpfung
**Symptome:**
+ MemoryUtilization > 90%
+ HeapMemoryUsage nähert sich dem Maximum
+ QueryRequestsTotal zeigt runtime\$1error (nicht genügend Speicher)
+ APIRequestRate mit Status=500
**Schritte zur Lösung:**
Sofortige Maßnahmen (falls kritisch):
1. Starten Sie die Instanz neu, um den Speicher zu löschen (sofern dies sicher ist)
1. Reduzieren Sie vorübergehend die Parallelität von Abfragen
1. Eliminieren Sie nach Möglichkeit lang andauernde Abfragen
Änderungen an der Konfiguration:
**Priorität 1: Cache-Speicher reduzieren**
+ storage-cache-max-memory-Größe: Auf 10% des RAM reduzieren
+ Beispiel: 32 GB → 3.355.443.200 Byte
+ storage-cache-snapshot-memory-Größe: 26.214.400 (25 MB)
**Priorität 2: Begrenzen Sie den Abfragespeicher**
+ query-memory-bytes: Auf 60% des gesamten RAM eingestellt
+ query-max-memory-bytes: Spiel query-memory-bytes
+ query-initial-memory-bytes: 10% von query-memory-bytes
**Priorität 3: Legen Sie Schutzgrenzen fest**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
+ Parallelität von Abfragen: Auf 50% von v reduzieren CPUs
**Langfristige Lösungen:**
+ Optimieren Sie das Datenmodell, um zu reduzieren **SeriesCardinality**
+ Implementieren Sie Größenbeschränkungen für Abfrageergebnisse auf Anwendungsebene
+ Erzwingung des Abfragetimeouts hinzufügen
+ Überprüfen Sie die häufigsten Abfragen, um sicherzustellen, dass sie den im Abschnitt genannten bewährten Methoden entsprechen [Probleme mit der Abfrageleistung](#query-performance-issues)
### Szenario: Auswirkung auf die Kardinalität hoher Datenreihen
**Kennzahlen überprüfen CloudWatch :**
+ **SeriesCardinality**> 5 M
+ **MemoryUtilization**hoch
+ **QueryRequestsTotal**zeigt einen erhöhten Runtime\$1Error
+ **CPUUtilization**erhöht aufgrund des Mehraufwands bei der Abfrageplanung
**Schritte der Untersuchung:**
**Analysieren Sie das Kardinalitätswachstum:**
+ SeriesCardinality Wachstumsrate (täglich/wöchentlich)
+ Projektion auf einen Schwellenwert von 10 Mio.
+ Identifizieren Sie Quellen mit hoher Kardinalität
+ Überprüfen Sie das Design und die Verwendung von Tags
**Beurteilen Sie die Auswirkungen auf die Leistung:**
+ Vergleich: **QueryRequestsTotal**Erfolgsquote, before/after Kardinalität, Steigerung
+ Korrelation überprüfen **MemoryUtilization**
+ Überprüfen Sie die **CPUUtilization**Muster
+ Analysieren Sie **QueryResponseVolume**Trends
**Identifizieren Sie die Quellen der Kardinalität:**
Datenmodell überprüfen:
+ Welche Buckets haben die höchsten SeriesCardinality?
+ Welche Tags haben eine hohe Anzahl an Einzelwerten?
+ Gibt es unnötige Tags?
+ Sind Tag-Werte unbegrenzt (UUIDs, Zeitstempel usw.)?
**Aktuelle Konfiguration überprüfen:**
Überprüfen Sie die Optimierungsparameter:
+ storage-series-id-set-cache-size: Aktueller Wert?
+ influxql-max-select-series: Beschränkt es außer Kontrolle geratene Abfragen?
+ storage-max-index-log-file-size: Geeignet für Kardinalität?
**Schritte zur Lösung:**
Sofortige Konfigurationsänderungen:
**Priorität 1: Optimieren Sie die Handhabung von Serien**
+ storage-series-id-set-Cache-Größe: 1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions: 6-8
+ storage-max-index-log- Dateigröße: 2.097.152 (2 MB)
**Priorität 2: Legen Sie Schutzgrenzen fest**
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
+ Query-Concurrency: Wird reduziert, wenn der Speicherplatz begrenzt ist
**Priorität 3: Erhöhung der Ressourcen**
+ Skalieren Sie auf die nächste Instanzstufe
+ Erhöhen Sie die Speicherzuweisung
+ Ziehen Sie eine Speicherstufe von 12.000 IOPS in Betracht
**Migrationsplanung (bei > 10M-Serie):**
+ **InfluxDB 3.0 bietet eine hervorragende Leistung bei hoher Kardinalität**
+ Planen Sie den Zeitplan für die Migration (2-3 Monate)
+ Testen Sie zuerst mit einer Teilmenge der Daten
+ Bereiten Sie die Anwendung für die Migration vor
+ InfluxDB 3.0 verwendet spaltenförmigen Speicher, der für Milliarden von Serien optimiert ist
### Szenario: Aufbau der Abfragewarteschlange
** CloudWatch Metriken überprüfen:**
+ **QueryRequestsTotal**mit steigendem result=queue\$1error (Abfragen werden abgelehnt)
+ **APIRequestRate** mit Status=429 oder Status=503 (viele Anfragen bearbeiten) unavailable/too
+ **CPUUtilization**kann erhöht sein (> 70%), was auf eine Ressourcensättigung hindeutet
+ **MemoryUtilization**kann hoch (> 70%) sein und die Abfragekapazität einschränken
+ **QueryResponseVolume**zeigt große Antwortgrößen an (Abfragen, die übermäßig viele Ressourcen beanspruchen)
**Schritte der Untersuchung:**
**Analysieren Sie die Kennzahlen für Warteschlangen und Parallelität:**
+ Überprüfen Sie die **QueryRequestsTotal**Aufschlüsselung nach Ergebnistyp:
+ Eine hohe Anzahl von queue\$1error weist darauf hin, dass Abfragen abgelehnt wurden
+ Vergleichen Sie die Erfolgsquote mit der Ausgangsrate — sinkt sie?
+ Prüfen Sie, ob runtime\$1error zunimmt (Abfragen schlagen nach dem Start fehl)
+ **Ratenmuster überwachenAPIRequest:**
+ Suchen Sie nach Status=429 (zu viele Anfragen) oder Status=503 (Dienst nicht verfügbar)
+ Identifizieren Sie, auf welchen Endpunkten Ablehnungen aufgetreten sind
+ Prüfen Sie die Trends der Anfragerate im Laufe der Zeit
**Überprüfen Sie die Ressourcenauslastung:**
+ **CPUUtilization**in Zeiten hoher Warteschlangen:
+ Bei > 70% sind Abfragen CPU-gebunden und können nicht schneller ausgeführt werden
+ Bei einem Wert von < 50% sind die Warteschlangenlimits möglicherweise zu restriktiv
+ **MemoryUtilization**Korrelation:
+ Ein hoher Arbeitsspeicher kann die Parallelität von Abfragen einschränken
+ Prüfen Sie **HeapMemoryUsage**und auf **ActiveMemoryAllocation**Speicherauslastung
+ IOpsPerSecMuster **insgesamt**:
+ Hoch I/O kann die Abfrageausführung verlangsamen
+ Prüfen Sie, ob Abfragen gebunden sind I/O
**Identifizieren Sie Abfragemuster:**
+ Rückblick **QueryResponseVolume**:
+ Geben Abfragen zu viele Daten zurück (> 1 MB)?
+ Identifizieren Sie Endgeräte mit dem größten Antwortvolumen
+ Suchen Sie bei teuren Abfragen nach Mustern
+ **QueryRequestsTotal**Rate analysieren:
+ Wie hoch ist die Rate der Abfragen pro Sekunde?
+ Gibt es Burst-Muster oder eine anhaltend hohe Auslastung?
+ Mit der Instanzkapazität aus der Größentabelle vergleichen
+ **APIRequestRate** nach Endpunkt überprüfen:
+ Welche Abfrage-Endpunkte haben den höchsten Traffic?
+ Gibt es doppelte oder redundante Abfragen?
**Überprüfen Sie die Verfügbarkeit der Ressourcen:**
+ Vergleichen Sie aktuelle Kennzahlen mit den Empfehlungen in der Größentabelle:
+ **SeriesCardinality**im Vergleich zur Kapazität der Instance-Klasse
+ Abfragerate im Vergleich zu empfohlenen Abfragen pro Sekunde
+ **CPUUtilization**und **MemoryUtilization**Kopffreiheit
+ Überprüfen Sie die IOPS-Kapazität:
+ **Insgesamt IOps PerSec** sollte eine Kopffreiheit von 30% bestehen
+ Prüfen Sie, ob Abfragen auf Festplatten-I/O warten
**Schritte zur Lösung:**
Änderungen an der Konfiguration:
**Priorität 1: Erhöhung der Warteschlangenkapazität**
+ query-queue-size: 4096 (von der Standardeinstellung 1024)
**Priorität 2: Erhöhen Sie die Parallelität (sofern die Ressourcen dies zulassen)**
+ Parallelität von Abfragen: Erhöhung auf 75% von v CPUs
+ Beispiel: 16 vCPU → Query-Concurrency = 12
+ Verify CPUUtilization bleibt nach der Änderung bei < 80%
+ Stellen Sie sicher MemoryUtilization , dass nach der Änderung ein Wert von < 80%
**Priorität 3: Optimieren Sie die Abfrageausführung**
+ query-memory-bytes: Sorgen Sie für eine angemessene Zuweisung
+ storage-series-id-set-Cache-Größe: 1000-1500
+ http-read-timeout: 120 s (verhindert vorzeitige Timeouts)
**Priorität 4: Legen Sie Schutzgrenzen fest**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
**Lösungen auf Anwendungsebene:**
+ **Implementieren Sie das Zwischenspeichern von Abfrageergebnissen (Redis, Memcached**)
+ Cache-Ergebnisse für häufig ausgeführte Abfragen
+ Je TTLs nach den Anforderungen an die Datenaktualität entsprechend festlegen
+ Überwachen von Cache-Zugriffsraten
+ **Verwenden Sie kontinuierliche Abfragen**, um gängige Muster vorab zu aggregieren
+ Allgemeine Aggregationen vorab berechnen
+ Fragen Sie voraggregierte Daten statt Rohdaten ab
+ **Fügen Sie Paginierung für große Ergebnismengen** hinzu
+ Beschränken Sie die anfängliche Abfragegröße
+ Laden Sie bei Bedarf zusätzliche Daten
+ **Implementieren Sie eine Begrenzung der Abfragerate** pro Benutzer/Dashboard
+ Verhindern Sie, dass einzelne Benutzer das System überfordern
+ Legen Sie Fair-Use-Kontingente fest
+ **Verwenden Sie Downsampling-Daten für historische Abfragen**
+ Fragen Sie Daten mit niedrigerer Auflösung für ältere Zeitbereiche ab
+ Reservieren Sie Abfragen mit voller Auflösung für aktuelle Daten
**Entscheidung zur Skalierung:**
+ Wenn mehr CPUUtilization als 70% aufrechterhalten werden: Skalierung auf eine größere Instanz
+ Wenn MemoryUtilization > 70% aufrechterhalten werden: Skalieren Sie auf eine speicheroptimierte Instanz
+ Wenn die Abfragerate die Instanzkapazität übersteigt: Skalieren Sie auf die nächste Stufe pro Größentabelle