[Epic] Logging-Infrastruktur (Konzept)

Warum?

Das Logging-Konzept definiert den Soll-Stand für das Einsammeln, Speichern und Zugänglich machen der Logausgaben aller Services, hier insbesondere die nötige Infrastruktur (vgl. auch Abgrenzung).

Relevante Links und Bemerkungen

Abgrenzung

Folgende Aspekte werden aktuell nicht abgedeckt, sie werden durch andere Epics umgesetzt

  • Integration mit allgemeinem Observability-Konzept von Fit-Connect (vgl. #86 (closed))
  • Nutzungsstatistiken (#111 (closed))
  • Inhaltliche Richtlinie zum Logging (#914)
  • Fachadministration (u.a. fachliche Logs, #165 (closed))
  • Visualisierung von Logs, soweit nicht durch verwendete Tools abgedeckt (z.B. per Kibana oder Grafan)

Akzeptanzkriterien

  1. Es existiert eine Architektur-Dokumentation (s.u.), wie die Logging-Infrastruktur aufgebaut ist (Logging-Konzept),
  2. Alle relevanten Informationen zum Logging sind im DV-Ressourcen der FitKo konzentriert: Wiki, NextCloud, oder GitLab (präferiert, da versioniert).
  3. Es existieren Issues, die das angedachte Logging-Konzept umsetzen

Die genannte Architektur-Dokumentation umfasst

  • Fachliche und Nicht-Funktionale Anforderungen, insb. Abgleich mit BSI OPS.1.1.5 Protokollierung
  • Diskussion der verschiedenen Ansätze inkl. Architektur-Entscheidung (ADR)
  • Für die finale Infrastruktur:
    • Kontextabgrenzung/-einordnung
    • Architektur-Sichten (Bausteinsicht, Laufzeit-Sicht der relevanten Prozesse, Verteilungssicht) inkl. Beschreibungen
    • Lösungsansatz und (regelmäßiger) Nachweis der Erfüllung nicht-fachlicher Anforderungen (insb. Sicherheit, Zuverlässigkeit, Effizienz)

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

  • ...
  • ...
  • Folge-Epics (Observability etc.) sind erstellt bzw. ergänzt
  • Definition of Done wurde geprüft
Edited by Andreas Huber