ForHosting KIT · Entwickler-Tools

Speicherbedarf für die Log-Aufbewahrung berechnen

Rechnen Sie Tagesvolumen und Aufbewahrungsdauer in den nötigen Speicher um: 250 GB pro Tag über 30 Tage sind 7.500 GB roh, und mit einem Faktor von 0,4 bleiben 3.000 GB, also 3 TB. Kostenlos in Ihrem Browser.

  • Kostenlos
  • Läuft in Ihrem Browser
  • Ohne Anmeldung
  • Ihre Daten bleiben auf Ihrem Gerät
Nutzen Sie es über WebAPIE-MailTelegramApp bald
Wenn Sie eingeben
Durchschnittliches Tagesvolumen (GB)
250
Aufbewahrungstage
30
Kompressionsverhältnis
0,4
Erhalten Sie
Rohspeicher (GB)
7.500
Geschätzter Speicher (GB)
3.000
Geschätzter Speicher (TB)
3
Eingespeicherter Speicher (GB)
4.500

Der Rechner für den Speicherbedarf bei der Log-Aufbewahrung macht aus einem durchschnittlichen täglichen Datenvolumen und einer Aufbewahrungsfrist eine praktische Kapazitätsschätzung. Geben Sie das täglich erzeugte Rohvolumen ein, wählen Sie die Anzahl der Tage, an denen die Daten verfügbar bleiben müssen, und berücksichtigen Sie bei Bedarf den erwarteten Größenfaktor nach der Kompression. Das Ergebnis zeigt Rohkapazität, geschätzten Speicher in Gigabyte und Terabyte sowie die erwartete Einsparung. So erhalten Infrastruktur-, Sicherheits- und Finanzteams eine gemeinsame Zahl für die erste Planung.

Beginnen Sie mit einem repräsentativen Tagesvolumen

Verwenden Sie das durchschnittliche Rohvolumen aus einem Zeitraum, der den normalen Betrieb abbildet, und geben Sie es in dezimalen Gigabyte an. Ein einzelner ungewöhnlich ruhiger Tag setzt den Bedarf zu niedrig an, während eine Spitze am Einführungstag die dauerhafte Nachfrage überzeichnen kann. Ein Wochen- oder Monatsmittel eignet sich deshalb meist besser für die Planung.

Beziehen Sie alle Quellen ein, die unter die Aufbewahrungsrichtlinie fallen: Anwendungsereignisse, Infrastrukturtelemetrie, Audit-Datensätze, Sicherheitsfeeds und separat gespeicherte replizierte Datenströme. Der Rechner multipliziert dieses Tagesvolumen mit der Aufbewahrungsdauer und ermittelt daraus den Rohspeicher. Wachstum, Replikate, Indizes, Dateisystemaufschläge und Sicherheitsreserven werden nicht automatisch berücksichtigt.

Diese Faktoren hängen von Ihrer Log-Plattform ab und sollten nach der Ermittlung der Basis hinzugerechnet werden. Wenn ein steigendes Volumen zu erwarten ist, rechnen Sie ein zweites Szenario mit dem prognostizierten Tageswert, statt das Wachstum im Kompressionsfaktor zu verstecken. Getrennte Annahmen zu Aufnahme, Aufbewahrung und Zusatzbedarf lassen sich bei Kapazitäts- und Budgetgesprächen leichter prüfen, aktualisieren und erklären.

Deuten Sie den Kompressionsfaktor stets einheitlich

Der optionale Kompressionsfaktor ist ein Multiplikator für die gespeicherte Größe und keine Angabe wie „drei zu eins“. Tragen Sie 0.4 ein, wenn die komprimierten Daten voraussichtlich 40 Prozent der Rohgröße belegen; dies entspricht einer Speichereinsparung von 60 Prozent. Lassen Sie das Feld aus, wird 1 verwendet.

Dieser Wert steht für keine Kompression, sodass die geschätzte Speicherkapazität dem Rohbedarf entspricht. Der Faktor muss größer als null und darf höchstens eins sein, weil dieser Rechner Kompression und keine Vergrößerung modelliert. Nutzen Sie nach Möglichkeit Messwerte repräsentativer Logs.

Sich wiederholender Text lässt sich oft stark komprimieren, verschlüsselte Werte, Stacktraces, Kennungen oder bereits komprimierte Nutzdaten dagegen möglicherweise weniger gut. Prüfen Sie außerdem, ob Ihre Plattform die Kompression vor oder nach der Indizierung ausweist, denn Indizes und Metadaten können die physische Nutzung erheblich erhöhen. Die angezeigte Einsparung ist einfach die Differenz zwischen Rohkapazität und komprimierter Kapazität.

Dadurch ist genau erkennbar, welcher Anteil der Schätzung von dieser Annahme abhängt.

Machen Sie aus der Basis einen umsetzbaren Kapazitätsplan

Betrachten Sie das Ergebnis als Datenspeicher-Basis für das gewählte Aufbewahrungsfenster. Die Angabe in Gigabyte eignet sich für kleinere Umgebungen und den direkten Vergleich mit dem Tagesvolumen; dezimale Terabyte erleichtern Gespräche über größere Mengen. Für eine Produktionsumgebung sind meistens zusätzliche Reserven für Replikate, durchsuchbare Indizes, Metadaten, temporären Zusammenführungsspeicher, Snapshots, Notfallkopien und Lastspitzen erforderlich.

Wenden Sie diese plattformspezifischen Faktoren nach der Berechnung ausdrücklich an, damit jede Annahme sichtbar bleibt. Ein replizierter Suchcluster kann beispielsweise ein Mehrfaches der physischen Basiskapazität benötigen, obwohl die Menge der logisch aufbewahrten Log-Daten unverändert ist. Vergleichen Sie mehrere Berechnungen, um eine kürzere Aufbewahrung, bessere Filterung oder gemessene Verbesserungen der Kompression zu bewerten, bevor Sie Ausgaben festlegen.

Die Dauer muss eine positive ganze Anzahl von Tagen sein; null und negative Werte werden abgelehnt. Aktualisieren Sie die Schätzung bei veränderten Aufnahmemustern oder Vorschriften und bestätigen Sie endgültige Beschaffungen anhand beobachteter Plattformmetriken.

Einen neuen Log-Cluster dimensionieren

Berechnen Sie die logische Speicherbasis, bevor Sie Replikation, Indizes, Snapshots und Betriebsreserven addieren.

Aufbewahrungsrichtlinien vergleichen

Testen Sie verschiedene Tageszahlen und zeigen Sie deren Auswirkungen auf Kapazität und Infrastrukturkosten.

Kompressionsannahmen bewerten

Vergleichen Sie gemessene Größenfaktoren und beziffern Sie die Einsparung für denselben Rohdatenstrom.

Was bedeutet ein Kompressionsfaktor von 0.4?

Die gespeicherten Logs belegen voraussichtlich 40% ihrer Rohgröße, was einer geschätzten Einsparung von 60% entspricht.

Was geschieht, wenn ich den Kompressionsfaktor weglasse?

Der Rechner nutzt 1; der geschätzte Speicher entspricht dann dem Rohvolumen pro Tag multipliziert mit den Aufbewahrungstagen.

Sind Replikate und Indizes in der Schätzung enthalten?

Nein. Ergänzen Sie Replikation, Indizes, Metadaten, Snapshots und plattformspezifische Reserven separat.

Welches Tagesvolumen sollte ich eingeben?

Das durchschnittliche Rohvolumen eines normalen Zeitraums, am besten einen Wochen- oder Monatsdurchschnitt, in dezimalen Gigabyte. Ein ruhiger Tag unterschätzt den Bedarf, eine Lastspitze am Starttag überschätzt ihn. Berücksichtigen Sie alle Quellen der Aufbewahrungsregel, etwa Audit- und Sicherheitsdaten.

Wie wähle ich einen realistischen Kompressionsfaktor?

Messen Sie ihn möglichst an repräsentativen Logs. Sich wiederholender Text lässt sich meist stark komprimieren, verschlüsselte Werte, Stacktraces, Kennungen oder bereits komprimierte Daten dagegen deutlich weniger. Ein übernommener Faktor kann die Schätzung verfälschen.

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

POSThttps://api.kit.forhosting.com/dev/log-retention-storage-estimate

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

curl -X POST https://api.kit.forhosting.com/dev/log-retention-storage-estimate \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"average_daily_volume_gb":250,"retention_days":30}'
{
  "average_daily_volume_gb": 250,
  "retention_days": 30
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.log_retention_storage_estimate",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

HTTPCodeBedeutung
401unauthorizedDer API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
402insufficient_balanceIhr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
404unknown_typeUnbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
429rate_limitedZu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Wie hoch sind die Kosten?

Eine API-Anfrage kostet $0.002; auf dieser Seite können Sie die Berechnung auch kostenlos im Browser ausführen.

Darf die Aufbewahrungsdauer null oder negativ sein?

Nein. Sie muss eine positive ganze Anzahl von Tagen sein; ungültige Werte ergeben den Fehler invalid_input.

Vollständige KIT-Dokumentation lesen →