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 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 |
|
| MemoryUtilization | DbInstanceName | Prozentsatz des verwendeten Speichers | Prozent |
|
| HeapMemoryUsage | DbInstanceName | Menge des verwendeten Heap-Speichers | Bytes |
|
| ActiveMemoryAllocation | DbInstanceName | Aktuelle aktive Speicherzuweisung | Bytes |
|
| DiskUtilization | DbInstanceName | Prozentsatz des belegten Festplattenspeichers | Prozent |
|
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 IOPS Beispiel: 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 IOPS Beispiel: 12.000 IOPS → Behalten Sie insgesamt < 8.400 IOPS |
| Insgesamt IOps PerSec | DbInstanceName | Gesamtzahl der I/O Operationen pro Sekunde (Lesen + 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:
|
| QueryResponseVolume | DbInstanceName, Endpunkt, Status | Anzahl der Abfrageantworten nach Endpunkt und Statuscode | Bytes |
|
Metriken zur Abfrageausführung
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Empfohlene Schwellenwerte |
|---|---|---|---|---|
| QueryRequestsTotal | DbInstanceName, Ergebnis | Gesamtzahl der Abfrageanfragen nach Ergebnistyp (success, runtime_error, compile_error, queue_error) | Anzahl |
Erfolgsquote: > 99% Fehlerquoten:
|
Kennzahlen zur Datenorganisation
| CloudWatch Metrikname | Dimensionen | Description | Einheit | Kritische Schwellenwerte |
|---|---|---|---|---|
| SeriesCardinality | DbInstanceName, Eimer | Anzahl der eindeutigen Zeitreihen in einem Bucket | Anzahl |
|
| TotalBuckets | DbInstanceName | Gesamtzahl der Buckets in der Instanz | Anzahl |
|
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 Neustarts Warnung: Uptime wird unerwartet zurückgesetzt |
| WriteTimeouts | DbInstanceName | Anzahl der Schreibvorgänge, bei denen das Zeitlimit überschritten wurde | Anzahl | Warnung: > 0,1% der Schreibvorgänge Kritisch: 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-Limits Warnung: Konsistent auf Maximum |
| TaskExecutionFailures | DbInstanceName | Anzahl der fehlgeschlagenen Aufgabenausführungen | Anzahl | Warnung: > 1% der Aufgabenausführungen Kritisch: 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 + 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% + 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 | ~50.000 | < 10 | db.influx.large | Influx IO inklusive 3.000 | Kleine Bereitstellungen, Entwicklung, Tests |
| < 1 M | ~150.000 | < 25 | db.influx.2xgroß | Influx IO inklusive 3.000 | Kleine bis mittlere Produktionsworkloads |
| ~1 M | ~200.000 | ~25 | db.influx.4xlarge | Influx IO inklusive 3.000 | Mittlere Produktionsworkloads |
| < 5 M | ~250.000 | ~35 | db.influx.4xlarge | Influx IO 12K enthalten | Große Produktionsworkloads |
| < 10 M | ~500.000 | ~50 | db.influx.8xlarge | Influx IO 12K enthalten | Sehr große Produktionsworkloads |
| ~10 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_error oder runtime_error 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 QueryResponseVolumevon QueryRequestsTotalMesswerten, 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
HeapMemoryUsagemit Aufwärtstrend
ActiveMemoryAllocationzeigt 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 ReadOpsPerSecAnstieg und QueryResponseVolumeeine Verschlechterung der Antwortzeiten feststellen.
Eine Einschränkung query-memory-bytes führt dazu, dass speicherintensive Abfragen mit runtime_error 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 QueryResponseVolumeSie, 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 SeriesCardinalityund 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%
WriteThroughputMuster
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: debuggeneriert extrem ausführliche Protokolle, möglicherweise Hunderte von MB pro Stundeflux-log-enabled: TRUEprotokolliert jede Flux-Abfrageausführung mit allen Details und erstellt riesige ProtokolldateienDiese 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:
Set
log-level: info(aus dem Debug)Legen Sie
flux-log-enabled: FALSEfest.Überwachen Sie DiskUtilizationdie 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:
CPUUtilizationwird steigen, da Verdichtungsvorgänge CPU-Zyklen verbrauchen
MemoryUtilizationnimmt während der Komprimierung zu, wenn Daten geladen und verarbeitet werden
WriteOpsPerSecund WriteThroughputwird während der Verdichtungsfenster stark ansteigen, sodass Ihr IOPS-Spielraum von 30% möglicherweise überschritten wird
WriteTimeoutskann 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:
Überprüfen Sie zuerst die Protokollierung (häufigstes Problem): Stellen Sie sicher, dass die Protokollebene „info“ und FALSE ist flux-log-enabled
Überprüfen Sie Ihr Datenmodell: Schreiben Sie Daten, die Sie eigentlich nicht benötigen? Können Sie die Mess- oder Feldgranularität reduzieren?
Optimieren Sie die Aufbewahrungsrichtlinien: Prüfen TotalBucketsund überprüfen Sie die Aufbewahrungseinstellungen für jeden Bereich
Überwachen Sie die Auswirkungen der Komprimierung: Erstellen Sie einen Überblick über Ihre CPUUtilizationMemoryUtilization, und WriteOpsPerSecvor 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+ 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-compactionswerden die Komprimierungsvorgänge verlangsamt, was dazu führt, dass sich TSM-Dateien ansammeln und schneller DiskUtilizationzunehmenNiedriger
storage-compact-throughput-burstWert verlängert die Verdichtungsdauer, wodurch der Verdichter länger aktiv bleibt und möglicherweise andere Vorgänge blockiert werdenEine 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 QueryRequestsTotalruntime_error-Raten steigen, wenn Abfragen beim Warten auf I/O das Timeout überschreiten
Reduzierung der Snapshot-Frequenz:
Zunehmend
storage-cache-snapshot-write-cold-durationstorage-compact-full-write-cold-durationbedeutet, dass Daten länger im Write-Ahead-Log (WAL) verbleibenDies 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-writeswerden Schreibvorgänge stärker serialisiert, was in WriteTimeoutsZeiten mit hohem Durchsatz möglicherweise zunimmtEine Erhöhung
storage-wal-max-write-delaybedeutet, 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:
SeriesCardinalitypro Bucket und insgesamt
MemoryUtilization(nimmt mit der Kardinalität zu)
CPUUtilization(Mehraufwand bei der Abfrageplanung)
QueryRequestsTotal(Die Runtime_Error-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 HeapMemoryUsageund ActiveMemoryAllocationnach 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_error fehlschlagen, QueryRequestsTotalwenn 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. CPUUtilizationWriteOpsPerSec
Kritisches Verständnis:
Bei einer SeriesCardinalityÜberschreitung von 5 Mio. erreichen Sie die architektonischen Grenzen von InfluxDB 2.x. Bei der Serie 10M+ 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
QueryRequestsTotalDie runtime_error-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:
Analysieren Sie Ihr Datenmodell:
Überprüfung SeriesCardinalitypro 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:
QueryRequestsTotalnach Ergebnistyp (Erfolg, Runtime_Error, Compile_Error, 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-concurrencyDurch die Erhöhung können mehr Abfragen gleichzeitig ausgeführt werden, aber jede Abfrage konkurriert um CPU und Arbeitsspeicher:
CPUUtilizationnimmt zu und erreicht in Spitzenzeiten bei Abfragen möglicherweise eine Sättigung
MemoryUtilizationsteigt, 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:
HeapMemoryUsagewird zunehmen
storage-cache-max-memory-sizemuss möglicherweise reduziert werden, um dies zu kompensierenWeniger Cache-Treffer bedeuten eine höhere ReadOpsPerSecund 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
QueryRequestsTotalDie Queue_Error-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:
Abfragemuster analysieren:
Überprüfung QueryResponseVolume, um Abfragen zu identifizieren, die zu viele Daten zurückgeben (> 1 MB)
Überprüfen Sie die QueryRequestsTotalRuntime_Error-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
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
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
Ü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:
Optimieren Sie zunächst die 10 teuersten Abfragen (von QueryResponseVolume)
Implementieren Sie das Zwischenspeichern von Abfrageergebnissen auf Anwendungsebene
Erhöhen Sie die Ressourcenzuweisung nur, wenn Abfragen optimiert sind und die Metriken Spielraum zeigen
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 diecontains()Funktion anstelle von RegEx Mustern wie/^exact_value$/Abgleich mehrerer bestimmter Werte — Verwenden Sie den
inOperator 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
QueryRequestsTotalmit result=runtime_error 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:
CPUUtilizationnimmt zu, je mehr Schreib-Threads um die CPU konkurrieren
MemoryUtilizationsteigt, wenn vor dem WAL-Flush mehr Daten im Speicher zwischengespeichert werden
WriteOpsPerSecwird 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, WriteTimeoutskann 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:
MemoryUtilizationnimmt 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 WriteOpsPerSecHä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:
Schreibmuster analysieren:
Rückblick WriteThroughputund WriteOpsPerSecTrends
Überprüfen Sie die WriteTimeoutsKorrelation mit der Schreiblast
Überwachen Sie die APIRequestRate für Schreibendpunkte anhand des Statuscodes
Identifizieren Sie die Größe und Häufigkeit von Schreibstapeln
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
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 WriteOpsPerSecin 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
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:
Beginnen Sie mit der Optimierung der Schreibstapelgrößen auf Anwendungsebene (streben Sie 5.000 bis 10.000 Punkte pro Stapel an)
Implementieren Sie Schreibpufferung und asynchrone Operationen
Stellen Sie sicher, dass Total IOps PerSec über ausreichend Spielraum verfügt
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
Passen Sie die WAL-Einstellungen nur an, wenn Schreibvorgänge optimiert sind und die Kapazität ausreichend ist I/O
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_error und queue_error
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_error), 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_error (nicht genügend Speicher)
APIRequestRate mit Status=500
Schritte zur Lösung:
Sofortige Maßnahmen (falls kritisch):
Starten Sie die Instanz neu, um den Speicher zu löschen (sofern dies sicher ist)
Reduzieren Sie vorübergehend die Parallelität von Abfragen
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
Szenario: Auswirkung auf die Kardinalität hoher Datenreihen
Kennzahlen überprüfen CloudWatch :
SeriesCardinality> 5 M
MemoryUtilizationhoch
QueryRequestsTotalzeigt einen erhöhten Runtime_Error
CPUUtilizationerhö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: QueryRequestsTotalErfolgsquote, before/after Kardinalität, Steigerung
Korrelation überprüfen MemoryUtilization
Überprüfen Sie die CPUUtilizationMuster
Analysieren Sie QueryResponseVolumeTrends
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:
QueryRequestsTotalmit steigendem result=queue_error (Abfragen werden abgelehnt)
APIRequestRate mit Status=429 oder Status=503 (viele Anfragen bearbeiten) unavailable/too
CPUUtilizationkann erhöht sein (> 70%), was auf eine Ressourcensättigung hindeutet
MemoryUtilizationkann hoch (> 70%) sein und die Abfragekapazität einschränken
QueryResponseVolumezeigt 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 QueryRequestsTotalAufschlüsselung nach Ergebnistyp:
Eine hohe Anzahl von queue_error weist darauf hin, dass Abfragen abgelehnt wurden
Vergleichen Sie die Erfolgsquote mit der Ausgangsrate — sinkt sie?
Prüfen Sie, ob runtime_error 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:
CPUUtilizationin 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
MemoryUtilizationKorrelation:
Ein hoher Arbeitsspeicher kann die Parallelität von Abfragen einschränken
Prüfen Sie HeapMemoryUsageund auf ActiveMemoryAllocationSpeicherauslastung
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
QueryRequestsTotalRate 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:
SeriesCardinalityim Vergleich zur Kapazität der Instance-Klasse
Abfragerate im Vergleich zu empfohlenen Abfragen pro Sekunde
CPUUtilizationund MemoryUtilizationKopffreiheit
Ü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
