Skip to content

Storage und Logs

IntegraMon speichert Daten gleichzeitig an mehreren Stellen. Ein Teil davon ist bewusst persistent, ein anderer bewusst temporaer.

Zentrale Storage-Roots

Globaler Runtime-Root

  • DATA_DIR
  • Default-Containerpfad: /app/data

Das ist die zentrale Basis fuer:

  • SQLite-Datenbankdateien
  • Tenant-Archivordner
  • Tenant-Job-Logs
  • storage-nahe Exporte und per-Tenant-Runtime-Dateien

Globaler Log-Root

  • LOG_DIR
  • Default: ${DATA_DIR}/logs

Supervisor schreibt hier die Service-Logs hinein.

Service-Log-Locations

Supervisor-verwaltete Logdateien sind typischerweise:

  • ${LOG_DIR}/postgres.log
  • ${LOG_DIR}/pg-init.log
  • ${LOG_DIR}/redis.log
  • ${LOG_DIR}/migrate.log
  • ${LOG_DIR}/gunicorn.log
  • ${LOG_DIR}/celery-light.log
  • ${LOG_DIR}/celery-light-cold.log
  • ${LOG_DIR}/celery-api-details.log
  • ${LOG_DIR}/celery-api-details-cold.log
  • ${LOG_DIR}/celery-alert-details.log
  • ${LOG_DIR}/celery-alerts.log
  • ${LOG_DIR}/celery-periodic.log
  • ${LOG_DIR}/celery-ai.log
  • ${LOG_DIR}/celery-messagelog-process-batch.log
  • ${LOG_DIR}/celery-messagelog-process-batch-cold.log
  • ${LOG_DIR}/celery-medium.log
  • ${LOG_DIR}/worker.log
  • ${LOG_DIR}/nginx.log
  • ${LOG_DIR}/login_activity.log

Das sind globale Plattform-Logs.

Tenant-Job-Log-Locations

Per-Tenant-Job-Logs werden durch core/worker_logging.py aufgeloest.

Default-Muster:

  • <DATA_DIR>/<config.name>/logs/jobs/<jobname>/<YYYY-MM-DD>.log
  • <DATA_DIR>/<config.name>/logs/runs/<jobname>/<run_id>.log

Das kann ueberschrieben werden ueber:

  • cConfigExt(name="global").value["data_dir"]
  • cConfigExt(name="jobs.logs").value["data_dir"]

Unterstuetzte Tokens:

  • {data_dir}
  • {config}

Archiv-Storage

Archive-Jobs erzeugen Tenant-spezifische Archivverzeichnisse unter:

  • <tenant data dir>/<config_name>/archive

Aktuelle Default-Namensmuster:

  • PostgreSQL-Export: <config>_YYYY_MM_DD.archive
  • SQLite-Export: <config>_YYYY_MM_DD.archive.sqlite
  • optional komprimiert: .gz

Das Archiv-Datenbankmodell ist cpiArchive.

Daten, die schnell wachsen

Die wichtigsten Growth-Treiber sind:

  • cpiMessageLog
  • cpiMessageLogRuns
  • cpiPayload
  • cpiMessageAttachment
  • cpiCustomHeaderProperties
  • Tenant-Archivdateien
  • Job- und Service-Logs
  • Metric-Snapshot-Tabellen ueber laengere Zeit

Temporaere versus persistente Daten

Bewusst persistent

  • SQLite-DB-Datei unter DATA_DIR
  • Tenant-Archive
  • Datenbankzeilen in PostgreSQL oder SQLite
  • Report-Artefakte, standardmaessig in der DB gespeichert
  • Metric-Snapshot-Tabellen

Temporaer oder rebuildbar

  • Redis-Cache-Inhalte
  • Redis-Broker-Queue-State bei internem Redis
  • Docs-Index-Cache
  • runtime-generierte Frontend-Konfiguration /var/www/html/app-config.js

Nicht automatisch persistent, solange nicht extra gemountet

  • /var/log/nginx/access.log
  • /var/log/nginx/error.log
  • in-Container-PostgreSQL-Clusterstorage bei lokalem DB-Betrieb ohne Volume

Cleanup-Verhalten

Log-Cleanup

Archive-Runs triggern auch Log-Cleanup:

  • aggregierte Job-Logs werden ueber das Dateidatum geloescht
  • Run-Logs werden ueber die File-Modification-Time geloescht
  • ENV-Fallback-Retention ist LOG_RETENTION_DAYS=3

Tenant-spezifisches jobs.logs kann diese Retention zur Laufzeit ueberschreiben.

Archive-Cleanup

archive_cpi_day unterstuetzt:

  • days_ago Default 10
  • delete_older_than Default 30

Archivverarbeitung und Archivloeschung sind also in derselben Task-Familie gekoppelt.

Config-Cleanup

Die Plattform-Cleanup-Tasks loeschen Tenant-bezogene Records in Batches und purgen auch Cache-Keys und Archiv-Referenzen. Relevante Modelle sind unter anderem:

  • cConfig
  • cConfigCleanupHistory
  • cWorkerJobRun
  • Archiv- und CPI-Datenmodelle, die am Tenant haengen

Rotation und harte Limits

Was heute existiert:

  • Supervisor-Logfile-Maxgroesse: 10MB
  • Supervisor-Logfile-Backups: 3
  • Log-Cleanup ueber Archive-Tasks

Was global nicht existiert:

  • zentrales Storage-Quota-System
  • harte Archiv-Groessenlimits
  • automatisches DB-Retention-Pruning fuer alle grossen Tabellen

Storage-Review ist damit eine aktive Betreiberaufgabe und kein vollautomatisches Thema.

Typische Growth-Muster

Storage-Wachstum wird vor allem getrieben durch:

  • Polling-Frequenz
  • Zahl der ueberwachten Tenants
  • Payload-Download-Tiefe
  • Archiv-Retention
  • Log-Volumen und Worker-Anzahl

Typisches Muster:

  • zuerst wachsen Message-Tabellen
  • danach Archive
  • Logs wachsen stetig mit Worker-Anzahl und Troubleshooting-Aktivitaet

Empfohlene Betreiberaktionen

  • DATA_DIR auf persistentem Storage mounten
  • Archivordnerwachstum pro Tenant beobachten
  • Tabellenwachstum ueber Superadmin-Storage-Sichten pruefen
  • Log-Retention kurz halten, solange keine Compliance laengeres Aufheben fordert
  • fuer mittlere bis grosse Umgebungen PostgreSQL und externen Storage nutzen