Wazuh-Feldlimit korrekt bewerten: Warum 12.760 Felder nicht automatisch das 10.000er-Limit überschreiten

Einleitung

Eine hohe Anzahl erkannter Felder in einem Wazuh-Datenbestand wirkt auf den ersten Blick wie ein unmittelbar bevorstehendes Indexierungsproblem. Besonders kritisch erscheint die Situation, wenn das Wazuh Dashboard mehr als 10.000 Felder meldet, während im Index-Template ein index.mapping.total_fields.limit von 10.000 konfiguriert ist.

Die beiden Werte lassen sich jedoch nicht direkt miteinander vergleichen. Das Mapping-Limit gilt für jeden einzelnen Index. Eine Abfrage über das Indexmuster wazuh-alerts-* liefert dagegen die Vereinigungsmenge aller Felder aus sämtlichen einbezogenen Tagesindizes.

Diese Unterscheidung ist für den SIEM-Betrieb entscheidend. Eine unnötige Erhöhung des Limits kann Mapping-Probleme verdecken und die Belastung des Wazuh Indexers steigern. Ein tatsächlich erreichtes Limit kann hingegen dazu führen, dass vollständige Alert-Dokumente nicht mehr indexiert werden und dadurch eine Überwachungslücke entsteht.

Ausgangslage / Problemstellung

Die betrachtete Umgebung besteht aus einem Wazuh-Manager-Cluster und einem mehrknotigen Wazuh-Indexer-Cluster. Alert-Daten werden in täglich angelegten Indizes gespeichert, beispielsweise:

wazuh-alerts-4.x-2026.07.23
wazuh-alerts-4.x-2026.07.24
wazuh-alerts-4.x-2026.07.25

Dieses tägliche Indexierungsschema entspricht dem üblichen Aufbau der Wazuh-Alert-Indizes.

Im Dashboard beziehungsweise über eine _field_caps-Abfrage auf das gesamte Indexmuster wurden rund 12.760 unterschiedliche Feldnamen ermittelt:

curl -k -u '<INDEXER_USER>:<INDEXER_PASSWORD>' \
  'https://127.0.0.1:9200/wazuh-alerts-4.x-20*/_field_caps?fields=*' \
  | jq '.fields | length'

Eine Abfrage für einen einzelnen Tagesindex ergab dagegen lediglich ungefähr 1.800 Felder:

curl -k -u '<INDEXER_USER>:<INDEXER_PASSWORD>' \
  'https://127.0.0.1:9200/wazuh-alerts-4.x-2026.07.23/_field_caps?fields=*' \
  | jq '.fields | length'

Zusätzlich wurden mehrere Felder als Typkonflikte angezeigt. Ein identischer Feldname war also in unterschiedlichen Tagesindizes mit verschiedenen Datentypen hinterlegt.

Daraus ergeben sich drei zentrale Fragen:

Ist das Mapping-Limit von 10.000 Feldern bereits überschritten?
Muss das Limit vorsorglich auf 15.000 oder 20.000 erhöht werden?
Welche Auswirkungen haben die Gesamtfeldzahl und die Typkonflikte auf Indexierung, Suche und SIEM-Funktionalität?

Technische Analyse

Das Mapping-Limit gilt pro Index

Die Einstellung

"index.mapping.total_fields.limit": 10000

begrenzt die Anzahl der Mapping-Einträge eines einzelnen Index. Dazu zählen reguläre Felder, Objekt-Mappings und Feld-Aliase. Das Limit wird nicht auf die Vereinigungsmenge eines Indexmusters angewendet.

In einer Wazuh-Umgebung mit Tagesindizes besitzt daher jeder Index sein eigenes Mapping und sein eigenes Limit:

wazuh-alerts-4.x-2026.07.23 → maximal 10.000 Mapping-Felder
wazuh-alerts-4.x-2026.07.24 → maximal 10.000 Mapping-Felder
wazuh-alerts-4.x-2026.07.25 → maximal 10.000 Mapping-Felder

Ein Datenbestand darf über alle Indizes hinweg deutlich mehr als 10.000 unterschiedliche Feldnamen enthalten, solange kein einzelner Index das konfigurierte Limit überschreitet.

Die gemessenen Werte bedeuten deshalb:

Messwert	Bedeutung
Etwa 1.800 Felder	Feldanzahl eines einzelnen Tagesindex
Etwa 12.760 Felder	Vereinigungsmenge über alle abgefragten Tagesindizes
10.000 Felder	Limit für jeden einzelnen Index

Bei ungefähr 1.800 Feldern im aktuellen Tagesindex besteht noch erheblicher Abstand zum 10.000er-Limit. Die Gesamtzahl von 12.760 Feldern liefert keinen Hinweis darauf, dass ein einzelner Index das Limit überschritten hat.

Warum die Vereinigungsmenge größer ist

Die Field-Capabilities-API sammelt Informationen über Felder aus einem oder mehreren Indizes. Bei einer Wildcard-Abfrage enthält die Antwort alle Feldnamen, die in mindestens einem der angesprochenen Indizes vorkommen. Die API zeigt außerdem, in welchen Indizes ein Feld mit welchem Datentyp vorhanden ist.

Ein vereinfachtes Beispiel:

Tag 1: data.source.ip, data.user.name, data.cloud.region
Tag 2: data.source.ip, data.user.name, data.application.id
Tag 3: data.source.ip, data.container.name, data.process.hash

Jeder Tagesindex enthält in diesem Beispiel nur drei Felder. Die Vereinigungsmenge über alle drei Indizes enthält jedoch sechs unterschiedliche Feldnamen.

Je länger die Aufbewahrungsdauer und je heterogener die angebundenen Logquellen sind, desto größer kann diese Vereinigungsmenge werden. Eine hohe Gesamtzahl ist daher nicht automatisch eine Mapping Explosion. Sie ist zunächst ein Hinweis darauf, dass sich die Schemas der Tagesindizes über die Zeit verändert haben.

Was bei einer tatsächlichen Überschreitung passiert

Erreicht ein einzelner Index sein Mapping-Limit, werden bereits bestehende Felder nicht gelöscht. Auch Dokumente, die ausschließlich bekannte Felder enthalten, können weiterhin indexiert werden.

Problematisch ist ein Dokument, das mindestens ein neues dynamisches Feld einführen würde. Kann dieses Feld wegen des Limits nicht mehr zum Mapping hinzugefügt werden, schlägt die Indexierung des betroffenen Dokuments im Standardfall fehl. Typische Fehlermeldungen enthalten:

illegal_argument_exception
Limit of total fields [10000] has been exceeded

Dabei geht normalerweise nicht nur das zusätzliche Feld verloren. Das vollständige Dokument wird für diesen Indexierungsvorgang abgelehnt.

Für Wazuh bedeutet das: Der Alert kann auf dem Manager erzeugt und lokal in der Alert-Datei vorhanden sein, aber im Wazuh Indexer und damit im Dashboard fehlen. Fehler dieser Art sollten im Filebeat- beziehungsweise Indexer-Logging sichtbar sein. Filebeat schreibt seine Logs standardmäßig unter /var/log/filebeat, während der Wazuh Indexer seine Logs unter /var/log/wazuh-indexer ablegt.

Solange die Tagesindizes nur ungefähr 1.800 bis 2.000 Felder enthalten und keine entsprechenden Indexierungsfehler auftreten, gibt es keinen technischen Hinweis darauf, dass Alerts aufgrund des Feldlimits verloren gehen.

Mapping-Konflikte sind ein separates Problem

Werden beispielsweise elf konfliktbehaftete Felder angezeigt, hat dies nichts mit dem 10.000er-Limit zu tun.

Ein Konflikt entsteht, wenn derselbe Feldname in verschiedenen Indizes unterschiedliche Datentypen besitzt:

wazuh-alerts-4.x-2026.07.23:
data.event.result = keyword

wazuh-alerts-4.x-2026.07.24:
data.event.result = long

Mögliche Ursache ist eine inkonsistente Datenquelle:

{
  "event": {
    "result": "200"
  }
}

und an einem anderen Tag:

{
  "event": {
    "result": 200
  }
}

OpenSearch legt das Mapping normalerweise anhand des zuerst verarbeiteten Wertes fest. Da jeder Tagesindex unabhängig erstellt wird, kann derselbe Feldname an unterschiedlichen Tagen mit unterschiedlichen Typen angelegt werden.

Der Alert wird dadurch nicht zwangsläufig verworfen. Über ein gemeinsames Indexmuster können jedoch Funktionen beeinträchtigt sein, die einen eindeutigen Datentyp voraussetzen. Dazu gehören insbesondere:

Sortierungen
numerische Berechnungen
Aggregationen
Visualisierungen
Feldfilter in Discover
Regeln oder Abfragen mit typabhängigen Operatoren

Die Field-Capabilities-API weist für solche Felder mehrere Typen und die jeweils betroffenen Indizes aus.

Performance-Auswirkungen vieler Felder

Mappings sind Metadaten, die der Indexer verwalten muss. Eine große Zahl von Mapping-Einträgen kann den Speicherbedarf erhöhen, Suchvorgänge verlangsamen und Wiederherstellungsprozesse erschweren. OpenSearch bezeichnet ein unkontrolliertes Wachstum dynamischer Felder als Mapping Explosion.

Mögliche Auswirkungen sind:

höherer JVM-Heap-Verbrauch
größere Mapping- und Cluster-Metadaten
aufwendigere Mapping-Aktualisierungen
langsamere Feldauflistung im Dashboard
längere Ladezeiten für Datenansichten
höhere Belastung bei Cluster-Recovery und Failover
komplexere Abfragen über viele heterogene Indizes

Dabei ist jedoch nicht allein die Vereinigungsmenge von 12.760 Feldern entscheidend. Relevant sind unter anderem:

Feldanzahl pro Index
Anzahl gleichzeitig geöffneter Indizes
Größe der einzelnen Mappings
Geschwindigkeit des Feldwachstums
Anzahl dynamischer Mapping-Updates
Anzahl der Shards
JVM-Heap-Auslastung
Such- und Indexierungsvolumen

Eine Vereinigungsmenge von 12.760 Feldern bei etwa 1.800 Feldern pro Tagesindex ist deshalb anders zu bewerten als ein einzelner Index mit 9.800 Feldern.

Lösung / Best Practices

1. Das tatsächlich konfigurierte Limit prüfen

Zunächst sollte das aktive Limit direkt aus den Indexeinstellungen gelesen werden:

curl -k -u '<INDEXER_USER>:<INDEXER_PASSWORD>' \
  'https://127.0.0.1:9200/wazuh-alerts-4.x-*/_settings?filter_path=*.settings.index.mapping.total_fields.limit&pretty'

Falls die Einstellung nicht explizit im Index erscheint, können die Standardwerte einbezogen werden:

curl -k -u '<INDEXER_USER>:<INDEXER_PASSWORD>' \
  'https://127.0.0.1:9200/wazuh-alerts-4.x-2026.07.23/_settings?include_defaults=true&filter_path=*.defaults.index.mapping.total_fields.limit,*.settings.index.mapping.total_fields.limit&pretty'

Wazuh verwendet in seinem Alert-Template üblicherweise ein Feldlimit von 10.000. Das von Filebeat verwendete JSON-Template befindet sich standardmäßig unter /etc/filebeat/wazuh-template.json.

2. Die Feldzahl für jeden Index einzeln ermitteln

Eine Wildcard-Abfrage allein reicht nicht aus. Zur zuverlässigen Bewertung sollten alle Alert-Indizes einzeln geprüft und nach Feldanzahl sortiert werden:

export INDEXER_URL='https://127.0.0.1:9200'
export INDEXER_AUTH='<INDEXER_USER>:<INDEXER_PASSWORD>'

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/_cat/indices/wazuh-alerts-4.x-*?h=index&format=json" \
  | jq -r '.[].index' \
  | while read -r index; do
      count=$(
        curl -ksS -u "$INDEXER_AUTH" \
          "$INDEXER_URL/$index/_field_caps?fields=*" \
          | jq '.fields | length'
      )

      printf '%s\t%s\n' "$count" "$index"
    done \
  | sort -nr \
  | head -20

Die Ausgabe zeigt die Indizes mit den meisten Feldern zuerst:

2014    wazuh-alerts-4.x-2026.07.21
1987    wazuh-alerts-4.x-2026.07.22
1832    wazuh-alerts-4.x-2026.07.23

Für Produktivsysteme sollte die TLS-Prüfung nach Möglichkeit nicht mit -k deaktiviert werden. Auf einem standardmäßig installierten Indexer kann stattdessen das Root-CA-Zertifikat verwendet werden:

--cacert /etc/wazuh-indexer/certs/root-ca.pem

Wazuh verwendet HTTPS für die Indexer-API und legt das vertrauenswürdige Root-CA-Zertifikat standardmäßig in diesem Verzeichnis ab.

3. Nach realen Indexierungsfehlern suchen

Ein überschrittenes Feldlimit sollte nicht aus der Dashboard-Feldzahl abgeleitet, sondern über Fehlermeldungen bestätigt werden:

grep -RniE \
  'Limit of total fields|illegal_argument_exception|mapping.*limit' \
  /var/log/filebeat/ \
  /var/log/wazuh-indexer/

Zusätzlich kann der Filebeat-Service geprüft werden:

journalctl -u filebeat \
  | grep -Ei 'Limit of total fields|illegal_argument_exception|mapping'

Sind keine entsprechenden Fehler vorhanden und bleibt die höchste Pro-Index-Feldzahl deutlich unter 10.000, besteht kein Anlass, das Limit allein aufgrund der Gesamtfeldzahl zu verändern.

4. Mapping-Konflikte gezielt identifizieren

Folgende Abfrage listet Felder auf, die über das Indexmuster hinweg mehr als einen Datentyp besitzen:

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/wazuh-alerts-4.x-*/_field_caps?fields=*" \
  | jq '
      .fields
      | to_entries[]
      | select((.value | keys | length) > 1)
      | {
          field: .key,
          types: (.value | keys)
        }
    '

Für ein einzelnes Konfliktfeld können anschließend die betroffenen Indizes ermittelt werden:

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/wazuh-alerts-4.x-*/_field_caps?fields=data.event.result&pretty"

Die Ausgabe zeigt beispielsweise:

{
  "fields": {
    "data.event.result": {
      "keyword": {
        "type": "keyword",
        "indices": [
          "wazuh-alerts-4.x-2026.07.23"
        ]
      },
      "long": {
        "type": "long",
        "indices": [
          "wazuh-alerts-4.x-2026.07.24"
        ]
      }
    }
  }
}

Die nachhaltige Lösung besteht darin, den Datentyp bereits an der Quelle oder während der Normalisierung zu vereinheitlichen. Alternativ müssen semantisch unterschiedliche Werte getrennte Feldnamen erhalten:

data.event.result_text
data.event.result_code

Der Datentyp eines bereits gemappten Feldes lässt sich in einem bestehenden Index nicht einfach ändern. Die Korrektur wirkt deshalb auf neu angelegte Indizes. Historische Daten müssten bei Bedarf mit einem korrigierten Mapping reindexiert werden.

5. Das Feldlimit nicht vorsorglich erhöhen

Bei ungefähr 2.000 Feldern pro Tagesindex sollte das Limit nicht allein aufgrund einer Vereinigungsmenge von 12.760 Feldern erhöht werden.

Ein sinnvolles operatives Vorgehen ist:

unter 70 Prozent Auslastung: reguläres Monitoring
ab etwa 70 bis 80 Prozent: Feldwachstum und Datenquellen untersuchen
ab etwa 85 bis 90 Prozent: kurzfristige Gegenmaßnahmen vorbereiten
bei tatsächlichen Rejections: Ursache beheben oder kontrolliert erhöhen

Diese Werte sind keine festen Herstellervorgaben, sondern praktische Warnschwellen. Entscheidend sind Wachstumsgeschwindigkeit und Ressourcenentwicklung.

Das Limit ist eine Schutzvorrichtung gegen unkontrollierte Mappings und sollte nicht als Zielwert betrachtet werden.

6. Eine notwendige Erhöhung kontrolliert durchführen

Ist ein aktiver Tagesindex tatsächlich nahe am Limit und kann das Schema nicht kurzfristig bereinigt werden, sollte zunächst moderat auf 15.000 statt unmittelbar auf 20.000 erhöht werden.

Für zukünftige Indizes muss die Einstellung im passenden Index-Template hinterlegt werden. Wazuh dokumentiert dafür ein benutzerdefiniertes Template wie wazuh-custom mit einer höheren Reihenfolge, damit es nicht durch das von Filebeat geladene Standard-Template überschrieben wird.

Vor jeder Änderung müssen die vorhandenen Templates gesichert werden:

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/_template/wazuh?pretty" \
  > wazuh-template-backup.json

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/_template/wazuh-custom?pretty" \
  > wazuh-custom-template-backup.json

Im bestehenden Custom-Template kann anschließend die Einstellung angepasst werden:

{
  "order": 1,
  "index_patterns": [
    "wazuh-alerts-4.x-*"
  ],
  "settings": {
    "index.mapping.total_fields.limit": 15000
  }
}

Ein bereits vorhandenes wazuh-custom-Template darf nicht blind mit diesem Minimalbeispiel überschrieben werden. Bestehende Einstellungen für Shards, Replikate, Refresh-Intervalle oder weitere Indexmuster müssen erhalten bleiben.

Das vorbereitete Template kann anschließend geladen werden:

curl -ksS -u "$INDEXER_AUTH" \
  -X PUT "$INDEXER_URL/_template/wazuh-custom" \
  -H 'Content-Type: application/json' \
  --data-binary @w-indexer-template.json

Die Einstellung im Template gilt nur für künftig angelegte Indizes.

Da index.mapping.total_fields.limit eine dynamische Indexeinstellung ist, kann das Limit bei Bedarf zusätzlich für den aktuell geöffneten Tagesindex geändert werden, ohne ihn neu anzulegen:

curl -ksS -u "$INDEXER_AUTH" \
  -X PUT \
  "$INDEXER_URL/wazuh-alerts-4.x-<YYYY.MM.DD>/_settings" \
  -H 'Content-Type: application/json' \
  -d '{
    "index.mapping.total_fields.limit": 15000
  }'

Eine pauschale Aktualisierung aller historischen Indizes ist normalerweise nicht notwendig. Sie erhöht keinen Nutzen für bereits unveränderliche Daten und erschwert die Nachvollziehbarkeit der Konfiguration.

7. Cluster-Auswirkungen überwachen

Nach einer Änderung sollten mindestens folgende Schnittstellen beobachtet werden:

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/_cluster/health?pretty"

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/_cluster/pending_tasks?pretty"

curl -ksS -u "$INDEXER_AUTH" \
  "$INDEXER_URL/_nodes/stats/jvm,breaker,thread_pool,indices?pretty"

Wichtige Indikatoren sind:

JVM-Heap-Auslastung
ausgelöste Circuit Breaker
abgelehnte Write- oder Bulk-Operationen
anwachsende Pending Tasks
Indexierungsdauer
Suchlatenz
Cluster-Status
Dauer von Node-Neustarts und Shard-Recovery
Ladezeit der Datenansichten im Dashboard

Eine Erhöhung sollte zunächst in einer Testumgebung und anschließend während einer Phase mit niedrigerem Ingest-Volumen umgesetzt werden.

8. Retention richtig einordnen

Eine Index-State-Management- beziehungsweise Retention-Policy ist weiterhin sinnvoll. Wazuh unterstützt automatisierte Lösch- und Rollover-Aktionen für Alert-Indizes.

Das Löschen alter Indizes kann:

Speicherplatz freigeben
die Zahl geöffneter Indizes reduzieren
Cluster-Metadaten verkleinern
die Vereinigungsmenge der Dashboard-Felder reduzieren
historische Typkonflikte aus der aktiven Datenansicht entfernen

Retention verhindert jedoch nicht, dass ein einzelner aktueller Index durch dynamische Feldnamen stark wächst. Das Feldwachstum innerhalb eines Tagesindex muss deshalb unabhängig von der Aufbewahrungsdauer untersucht werden.

Lessons Learned / Best Practices

Pro-Index-Werte und Gesamtwerte getrennt überwachen

Für den operativen Betrieb sollten mindestens zwei unterschiedliche Kennzahlen erfasst werden:

Maximale Feldzahl eines einzelnen aktiven Index

und

Vereinigungsmenge aller Felder des Dashboard-Indexmusters

Nur die erste Kennzahl lässt sich direkt mit index.mapping.total_fields.limit vergleichen. Die zweite Kennzahl beschreibt Schemaheterogenität und beeinflusst unter anderem die Dashboard-Nutzung.

Feldwachstum als Zeitreihe erfassen

Eine einzelne Messung liefert nur eine Momentaufnahme. Aussagekräftiger ist die Entwicklung über mehrere Tage:

Montag:     1.820 Felder
Dienstag:   1.835 Felder
Mittwoch:   1.842 Felder
Donnerstag: 3.910 Felder

Ein plötzlicher Sprung weist häufig auf eine neu angebundene Logquelle, eine geänderte Integration oder variable JSON-Schlüssel hin.

Dynamische Feldnamen vermeiden

Besonders problematisch sind JSON-Strukturen, bei denen veränderliche Werte als Schlüssel verwendet werden:

{
  "sessions": {
    "session-8f93a1": {
      "status": "active"
    },
    "session-a177c4": {
      "status": "closed"
    }
  }
}

Jede Session-ID kann dabei zu einem neuen Mapping-Feld werden. Stabiler ist eine feste Struktur:

{
  "sessions": [
    {
      "id": "session-8f93a1",
      "status": "active"
    },
    {
      "id": "session-a177c4",
      "status": "closed"
    }
  ]
}

IDs, Zeitstempel, Benutzernamen, Hostnamen oder Hashwerte sollten grundsätzlich Feldwerte und keine Feldnamen sein.

Datentypen verbindlich definieren

Für häufig verwendete Felder sollte ein konsistentes Schema festgelegt werden:

IP-Adressen       → ip
Zeitstempel       → date
Statuscodes       → integer oder long
Bezeichner        → keyword
Freitext          → text
Wahrheitswerte    → boolean

Ein Statuscode sollte nicht abwechselnd als Zahl, Text oder leerer String gesendet werden. Können Quellen nicht vereinheitlicht werden, sind getrennte Feldnamen sicherer als ein polymorphes Feld.

Indexierungsfehler aktiv alarmieren

Mapping- und Indexierungsfehler dürfen nicht nur in Logdateien verbleiben. Für ein SIEM ist es sinnvoll, Warnungen für folgende Muster einzurichten:

Limit of total fields
mapper_parsing_exception
illegal_argument_exception
failed to index
bulk request failed

Dadurch wird eine mögliche Lücke zwischen lokal erzeugten Wazuh-Alerts und tatsächlich indexierten Dokumenten frühzeitig sichtbar.

Template-Anpassungen versionssicher verwalten

Änderungen an /etc/filebeat/wazuh-template.json können bei Paketaktualisierungen überschrieben werden. Benutzerdefinierte Templates sollten daher:

gesichert werden
versioniert vorliegen
eine dokumentierte Template-Reihenfolge besitzen
nach Wazuh-Upgrades überprüft werden
vor dem Rollout mit einem neuen Testindex validiert werden

Index-Templates initialisieren neue Indizes mit definierten Einstellungen und Mappings. Änderungen am Template wirken nicht automatisch rückwirkend auf bereits vorhandene Indizes.

Fazit

Eine Gesamtanzeige von 12.760 Feldern bedeutet nicht, dass das Wazuh-Feldlimit von 10.000 überschritten wurde. Die Gesamtanzeige beschreibt die Vereinigungsmenge aller Felder über mehrere Tagesindizes. Das Limit gilt dagegen separat für jeden einzelnen Index.

Liegt der aktuelle Tagesindex bei ungefähr 1.800 bis 2.000 Feldern, besteht kein Grund, das Limit vorsorglich auf 15.000 oder 20.000 anzuheben. Zunächst sollten die Feldzahlen aller einzelnen Indizes, das tägliche Wachstum, mögliche Indexierungsfehler und die JVM- beziehungsweise Cluster-Metriken überwacht werden.

Die angezeigten Typkonflikte sind unabhängig vom Feldlimit zu behandeln. Sie entstehen durch inkonsistente Datentypen in verschiedenen Tagesindizes und sollten durch ein stabiles Quellschema, angepasste Decoder oder getrennte Feldnamen behoben werden.

Eine Limiterhöhung ist erst dann sinnvoll, wenn ein einzelner aktiver Index tatsächlich in die Nähe des Grenzwerts wächst und eine kurzfristige Schemakorrektur nicht möglich ist. In diesem Fall sollte die Änderung schrittweise, templatebasiert, überwacht und zunächst auf 15.000 Felder begrenzt erfolgen.