[Epic] Erweiterte Nutzungsstatistiken (historische Daten / Logs / Veröffentlichung)
TODO: Beschreibung ist im Hinblick auf das Ziel zu überarbeiten
Warum
FIT-Connect ist ein Produkt des IT-Planungsrats. Es bekommt jährlich beträchtliche finanzielle Zuwendungen, um Betrieb und Pflege aufrechterhalten zu können. Im Umkehrschluss möchte die Außenwelt, nicht zuletzt auch der IT-Planungsrat selbst, wissen,
- ob und inwiefern das Produkt FIT-Connect genutzt wird,
- wie leistungsfähig FIT-Connect ist,
- wie weitgehend die Verbreitung von FIT-Connect ist und
- ob es Muster oder Tendenzen gibt, wer (Gruppen von Fachverfahrenshersteller, Onlinedienste) bspw. FIT-Connect (nicht) nutzen.
Vor diesem Hintergrund müssen neben statischen Metriken auch historische Daten aus Logs im Bereich der Nutzung von FIT-Connect definiert werden und Implementierungen vorgenommen werden, um die benötigten Kenngrößen nach Möglichkeit automatisiert zu ermitteln. Über eine programmatische Schnittstelle soll die Auswertung dieser Kenngrößen möglich sein.
Inhalt dieses Epics sind sowohl Metriken, die die strukturelle Größe von FIT-Connect beschreiben, als auch Metriken, die die dynamische Größe (Nutzungshäufigkeit) von FIT-Connect beschreiben. Dafür werden die Metriken aus den entsprechenden Logs ausgelesen. Zur Umsetzung dieser maschinellen Auslesung ist die Implementierung einer API notwendig.
Eine Liste der bislang identifizierten erforderlichen Kenngrößen ist unter Akzeptanzkriterium 1 zu entwickeln bzw. zu finden.
Die Metriken sollen auf allen Stages erfasst werden.
-
Der Zugriff auf diese Endpunkte ist auf einzelne User beschränkt (ggf. Benutzeradministration light notwendig). Es sind nicht die aktuellen SSP User. -
Daten und Verknüpfungen zwischen den Datenobjekten werden als Rohdaten exportiert, damit die Auswertungen und Konsolidierungen im Nachgelagerten Tool erfolgen können -
kein Performanceeinfluss auf den Zustelldienst – Rechenintensive Abfragen sollten separat über z.B. einen Nachtjob laufen und diese Ergebnisse dann bis zum nächsten Nachtjob ausgegeben werden (fachlich führt das dazu, dass es keine Echtzeitdaten gibt)
-
-
Die Metriken wurden bewertet und entschieden, welche Metriken schützenswert sind und welche nicht (DSB FITKO) #111 (comment 94177) -
Die Metriken werden in den entsprechenden Diensten erfasst -
Die nicht schützenswerten Metriken werden in einem zentralen öffentlich zugänglichen Dashboard und dahinter liegenden APIs zur Verfügung gestellt -
Der Zugriff auf das öffentliche Dashboard und die dahinterliegenden APIs beeinträchtigt den Regelbetrieb der FIT-Connect Infrastruktur nicht. -
Daten können exportiert werden in Excel- und/oder PDF-Format -
Daten können mindestens 1x die Woche exportiert werden (Optimal Verhalten per Knopfdruck zu jeder Zeit) -
Daten stellen den aktuellen Stand von der Minute dar -
Die Sprachauswahl der SDKs wird per Logs in den Nutzungsstatistiken abgebildet, sodass wir nachvollziehen können, wie viele Anbindungsprojekte Java bzw. .Net nutzen
Ablaufplan
- Log-Thema ist abgeschlossen
- API bauen mit Komponenten aus SSP und Zustelldienst (SDK ist aus dem Header auszulesen, Destinations, ARS, Leika und Antragsgrößen aus den Submissionstatistiken)
- Anbindungsreporting überarbeiten, sodass die neuen Daten eingearbeitet werden
Erste Ideen, welche in der ersten Evaluierungsphase aufgekommen sind:
- Wir loggen den User-Agent header. Daraus kann man zumindest ein bisschen was ableiten. Außerdem speichern wir für welche Leistungen Anträge an welche Fachverfahren verschickt werden (+Fachdaten/Attachmentgrößen). --> Log im Traefik
Ziel
Nutzungsstatistiken sollen auch der Öffentlichkeit maschinenlesbar, als auch in Form von Standardreports bereitgestellt werden.
In dem Zusammenhang sollen auch historische Daten auf Basis von Logs entsprechend intern oder extern auswertbar gemacht werden.
Links, Hinweise, Bemerkungen
Stories
Akzeptanzkriterien
-
... -
... -
... -
Definition of Done wurde überprüft.