Skip to content

Redis und Queues

Redis ist in der aktuellen Architektur keine kleine optionale Optimierung, sondern uebernimmt mehrere Rollen gleichzeitig.

Wofuer Redis genutzt wird

Der Code nutzt Redis fuer:

  • Django-Cache ueber REDIS_CACHE_URL
  • Celery-Broker-Transport ueber CELERY_BROKER_URL
  • Celery-Result-Backend ueber CELERY_RESULT_BACKEND
  • Django-Channels-Websocket-Fan-out ueber CHANNELS_REDIS_URL
  • Lock- und Koordinations-Keys ueber Django-Cache und direkten Redis-Zugriff

Default-URL-Aufteilung

Die Defaults sind zwischen boot.py und Django-Fallbacks nicht vollstaendig konsistent. In Produktion deshalb besser immer explizit setzen.

Die beabsichtigte Trennung ist typischerweise:

  • Cache: eine DB oder ein Endpoint
  • Broker: eine DB oder ein Endpoint
  • Result-Backend: eine DB oder ein Endpoint
  • Channels: idealerweise eine eigene DB oder ein eigener Endpoint

Lokale Sample-JSONs nutzen Muster wie:

  • Broker redis://localhost:6379/0
  • Result-Backend redis://localhost:6379/1
  • Cache redis://localhost:6379/2
  • Channels redis://127.0.0.1:6379/3

Interner Redis-Modus

Wenn REDIS_LOCAL=true, startet Supervisor Redis mit:

  • --save ""
  • --appendonly no
  • --stop-writes-on-bgsave-error no

Das bedeutet: Der gebuendelte Redis ist bewusst nicht persistent.

Betriebsfolge:

  • Queue-State ist schnell und simpel
  • Broker-Memory geht bei Restart verloren
  • Cache-Inhalte gehen bei Restart verloren
  • fuer Entwicklung und kompakte Deployments brauchbar, aber kein dauerhafter Queue-Speicher

Was passiert ohne Redis

Fehlt Redis oder ist nicht erreichbar, sind sofort betroffen:

  • Celery-Worker koennen keine Broker-Queues konsumieren
  • Task-Results koennen nicht im Result-Backend landen
  • Cache-basierte Locks und Caches schlagen fehl
  • Websocket- und Channels-Funktionen brechen
  • Queue-Metriken und Worker-Lock-Cleanup werden unzuverlaessig

Anders gesagt:

  • das UI kann in einzelnen Faellen noch laden
  • aber Background-Processing, Realtime und grosse Teile des Betriebsverhaltens degradieren sehr schnell

Queue-Familien im Einsatz

Aktuelle Queue-Namen sind:

  • messagelog_read
  • messagelog_read_cold
  • payload_read
  • payload_get_details
  • package_read
  • messagelog_get_details_hot
  • messagelog_get_details_cold
  • messagelog_get_details_alert
  • messagelog_process_batch
  • messagelog_process_batch_cold
  • messagelog_correlations
  • messagelog_customheaders
  • iflow_download
  • archive_data
  • trigger_alerts
  • periodic_run
  • stats_cache
  • ai

Der Controller-Loop liest Queue-Laengen ausserdem direkt aus Redis aus, um Queue-Metriken aufzubauen.

Memory- und Persistenz-Aspekte

Redis-Memory wird getrieben durch:

  • gequeue-te Celery-Tasks
  • Task-Result-Retention
  • Cache-Eintraege mit langer TTL oder ohne Expiry
  • Websocket-Channel-Traffic
  • Lock-Keys

Der aktuelle Code haelt mehrere Caches unbegrenzt:

  • einige Application-Caches nutzen timeout=None
  • der Docs-Index-Cache ist kurzlebig
  • Worker-Pfad-Caches koennen ein Jahr leben

Redis waechst also nicht nur durch kurzen Broker-Traffic.

TLS-Support

Beginnt eine URL mit rediss://, aktiviert der Code automatisch CA-basiertes TLS ueber certifi.

Das gilt fuer:

  • CELERY_BROKER_URL
  • CELERY_RESULT_BACKEND
  • REDIS_CACHE_URL

CHANNELS_REDIS_URL bekommt in settings.py aktuell nicht denselben TLS-Options-Block. Managed-Redis-mit-TLS fuer Channels sollte daher bewusst getestet werden.

Empfohlene Betriebsmodelle

Kleine Installation

  • interner Redis ist akzeptabel
  • Queue-Tiefe und Restart-Haeufigkeit beobachten
  • Queue- und Cache-Verlust nach Restart einplanen

Mittlere Installation

  • externer Redis empfohlen
  • Cache, Broker und Channels auf getrennte DB-Nummern oder Endpoints legen
  • Queue-Wachstum in den Superadmin-Metriken beobachten

Grosse Installation

  • dedizierter oder gemanagter Redis ist stark empfohlen
  • Memory, Evictions und abgewiesene Verbindungen monitoren
  • Queue-Backlogs sichtbar und alertbar halten

Redis-Metrik-Defaults

Die Plattform-Metrik-Defaults sind:

  • Queue Warnung: 1000
  • Queue kritisch: 10000
  • Memory Warnung Prozent: 90
  • Memory kritisch Prozent: 98
  • Evicted Keys Warnung Minimum: 1
  • Evicted Keys kritisch Minimum: 10
  • Rejected Connections kritisch Minimum: 1

Das sind keine Redis-Server-Settings, sondern Application-seitige Schwellwerte in cMetricSettings.

Fehlerbilder

Typische Symptome fuer Redis-Probleme sind:

  • stehende oder wachsende Celery-Queues
  • fehlende Websocket-Updates
  • verzoegertes Alerting oder Report-Dispatch
  • wiederkehrende Worker-Lock-Warnungen
  • API-Antworten wie No cached templates found bei cache-basierten Reads

Recovery-Hinweise

Wurde Redis neugestartet und ist absichtlich nicht persistent:

  • Queue-Verlust erwarten
  • Cache-Verlust erwarten
  • Periodic-Jobs die Caches neu aufbauen lassen
  • pruefen, dass Worker reconnecten und Queue-Tiefen wieder normal werden

Ist Redis extern und unhealthy:

  • zuerst Connectivity reparieren
  • danach Broker-Queue-Konsum pruefen
  • dann Channels und cache-abhaengige Features validieren