Skip to content

Celery und Worker Runtime

IntegraMon betreibt sowohl klassische Celery-Worker als auch einen dedizierten Controller-Prozess in backend/src/cpi/worker.py.

Prozessmodell

Supervisor startet nach den Migrationen:

  • Gunicorn-Web-Worker
  • mehrere Celery-Worker, gruppiert nach Queue-Typ
  • einen Python-Controller-Prozess namens worker

Der Controller-Loop ist wichtig, weil er:

  • Tenant-Polling-Jobs dispatcht
  • verwaiste Worker-Runs nach Restarts reconciled
  • Thread-Health ueberwacht
  • Queue-Size- und Scheduling-Arbeit in Celery schiebt

Worker-Gruppen und Default-Concurrency

Gruppe Default-Concurrency Queues
celery-light 2 messagelog_read, payload_read, package_read
celery-light-cold 2 messagelog_read_cold
celery-api-details 3 messagelog_get_details_hot, payload_get_details
celery-api-details-cold 2 messagelog_get_details_cold
celery-alert-details 1 messagelog_get_details_alert
celery-alerts 1 trigger_alerts
celery-periodic 1 periodic_run, stats_cache
celery-ai 1 ai
celery-messagelog-process-batch 2 messagelog_process_batch
celery-messagelog-process-batch-cold 2 messagelog_process_batch_cold
celery-medium 2 iflow_download, archive_data, messagelog_correlations, messagelog_customheaders

Alle nutzen --prefetch-multiplier=1. Das ist eine bewusste Fairness-Entscheidung fuer gemischte Task-Laufzeiten.

Wichtige Task-Familien

Tenant-Polling und CPI-Ingestion

  • read_message_logs
  • read_message_logs_cold
  • read_payloads
  • read_packages
  • deep_sync_iflow_artifacts

Alerting und Archive

  • check_and_create_alerts
  • archive_cpi_day
  • stats_update_t
  • periodic_jobs

Plattformbetrieb

  • dispatch_due_agent_reports_task
  • run_agent_report_task
  • cleanup_config_task
  • cleanup_pending_configs_task
  • storage_snapshot_quick_task
  • storage_snapshot_deep_task
  • storage_dispatch_task
  • host_metrics_collect_task
  • host_metrics_dispatch_task
  • django_metrics_collect_task
  • django_metrics_dispatch_task

AI

  • process_chat_task auf Queue ai

Periodic-Scheduling-Modell

Es gibt im aktuellen Code keine einzelne Celery-Beat-Datei. Scheduling ist verteilt auf:

  • den Controller-Loop in cpi/worker.py
  • Periodic-Konfiguration in cConfigExt
  • Plattform-Metric-Dispatch-Tasks
  • Report-Scheduling ueber cJobConfig.next_run_at

Betriebsfolge:

  • Queue-Delay und Worker-Health sind wichtiger als nur Cron-Syntax
  • Runtime-State lebt teilweise in der Datenbank und nicht nur im Prozessspeicher

Retry-Verhalten und Failure-Handling

Das Verhalten ist je Task-Familie gemischt:

  • archive_cpi_day laeuft explizit mit max_retries=0
  • manche Tasks reschedulen sich ueber Controller oder Periodic-Logik
  • mehrere Tasks schreiben Failure-State in cWorkerJobRun
  • Task-Results landen bei passender Konfiguration im Redis-Result-Backend

Eine generische Dead-Letter-Queue-Schicht gibt es in der aktuellen Supervisor-Konfiguration nicht.

Orphan- und Stale-Job-Recovery

cpi/worker.py hat Startup-Reconciliation fuer:

  • queued Runs, die zu lange queued blieben, ohne zu starten
  • laufende Rows, die von abgestuerzten oder neugestarteten Prozessen zurueckgelassen wurden

Aktueller Stale-Timeout:

  • 45 Minuten fuer queued Rows

Recovered Rows werden als skipped mit Reconciliation-Metadaten markiert.

Das ist ein nuetzlicher Self-Heal-Mechanismus nach Container-Restarts oder Broker-Stoerungen.

Monitoring-Flaechen

Nuetzliche Runtime-Sichten sind:

  • /superadmin/jobs
  • /superadmin/metrics
  • /superadmin/redis-metrics
  • /superadmin/worker-tuning

Relevante Persistenzmodelle sind:

  • cWorkerJobRun
  • cJobRun
  • cWorkerTuningSettings
  • cMetricSettings

Worker-Tuning-Profile

Die eingebauten Profile sind:

Safe

  • reduzierte Light-Queues
  • reduzierte Cold-Queues
  • Periodic und Alerting bleiben bei 1
  • gut fuer kleine Umgebungen oder knappe CPU-Ressourcen

Balanced

  • aktuelles Default-Profil
  • moderate Parallelitaet ueber Hot- und Cold-Pfade
  • guter erster Produktions-Baseline

Fast

  • mehr Hot-Reader und Batch-Prozessoren
  • nur sinnvoll, wenn Redis, DB und CPU genug Headroom haben

Sizing-Hinweise je Installationsgroesse

Klein

  • balanced oder safe
  • aggressive Cold-Backfills vermeiden
  • SQLite kann noch funktionieren, wenn der gesamte Write-Druck niedrig bleibt

Mittel

  • PostgreSQL empfohlen
  • externer Redis empfohlen
  • balanced ist meist der beste Startpunkt

Gross

  • externes PostgreSQL und Redis erwartet
  • fast oder custom erst nach evidenzbasiertem Tuning
  • Queue-Tiefen, DB-Write-Druck und Archive-Laufzeiten eng beobachten

Operative Anti-Patterns

Diese Kurzschluesse vermeiden:

  • Worker-Concurrency erhoehen, bevor Redis- und DB-Headroom validiert sind
  • internen Redis fuer wichtige Produktionsqueues behalten, ohne den Restart-Verlust bewusst zu akzeptieren
  • Queue-Wachstum rein als Celery-Problem behandeln, obwohl DB oder CPI-APIs der eigentliche Flaschenhals sind