Ist eine Loganalyse für eine Bachelorarbeit geeignet?

Hallo,
ich suche noch ein Thema für meine Bachelorarbeit, aktuell ist im Gespräch wie man Logeinträge die von vielen Softwareanwendungen im Unternehmen produziert wurden zu analysieren und zu verknüpfen (größte Schwierigkeit!!).
Als Beispiel gibt es mehrere abhängige Komponenten die verteilt sind, eine abhängige Komponente wirf eine Exception und loggt diese, die aufrufende Komponente fängt die Exception ab und loggt auch usw. Es soll diese Kette über Anwendungen hinweg auf der Datenbank analysiert und Verknüpfungen erkannt werden.

Falls möglich sollte dann eine Anwendung realisiert werden, die z.B. den Ursprungsfehler und die Folgefehler protokolliert:
**
*SourceError: Application A
***Error: Application Backend B
***Error: Application Backend C
*Error: Application Backend D

Hierbei spielen viele Faktoren eine Rolle, die Zeit, die Daten usw.

Kann man sich das als Bachelorarbeit für 3 Monate vorstellen?

Naja..meiner Ansicht nach muss Du erst mal definieren, was für Dich zum Log alles gehört.
Für eine größere Anwendung gehört dazu auch das Tracing, Metriken und Co. Fehler wären mir zu wenig.

Wenn der Fehler auftaucht ist es manchmal schon zu spät.
Ziel ist es ja Fehler vorzubeugen, weshalb man so viele Daten im Rahmen von Metrics sammelt.

Je nachdem, was das werden soll und wie der Rahmen und Dein Skill-Level aussieht können 3 Monate ausreichen.
Was genau nun der wissenschaftliche Hintergrund im Rahmen eines Bachelors ist - seh ich jetzt rein bei Fehlern nicht. Da sind wir ja heute schon mit Application Insights, Health Monitor und Co viel viel viel weiter.

@Abt, wenn ich ihn richtig interpretiere, geht's nicht um die Erfassung (was interessanter wäre), sondern um die Analyse vorhandener Daten. Das ginge dann mehr in Richtung Business Intelligence und hat nach meinem Verständnis nur begrenzt was mit Softwareentwicklung zu tun.

• Analyse der vorhandenen Daten und Entwickeln von geeigneten Datenstrukturen
• Entwicklung eines Konzepts für die Erfassung der vorhandenen Daten und deren Konvertierung in die in Schritt 1 vorgeschlagenen Strukturen (und an der Stelle käme dann die logische Verknüpfung, die af243r2 angesprochen hat)
• Festlegen der zu überwachenden Kenngrößen
• Ausschen und Anpassen einer geeigneten BI-Lösung

Ja, kann man machen. Wissenschaftlicher Anspruch sollte ausreichen, umfangstechnisch kann man 'ne Menge rausholen. Muss man dann sehen, wo man den Schwerpunkt legt. Die Datenkonvertierung ist jetzt allein für sich eher unspannend.

LaTino

Aus meiner Sicht kannst Du sicher dazu eine Arbeit schreiben. Gibt genug Punkte darin, um wissenschaftlich zu arbeiten. Ich habe so etwas ähnliches auch mal bei einem ehemaligen Kunden gesehen, der den Diplomanden dann danach fest eingestellt hat.
Ganz ungefährlich ist die Arbeit nicht, da Du es mit einem klassischen Eisberg-Problem zu tun hast.
Zurzeit gibt es eine Spitze, die herausschaut/bekannt ist, wenn Du dann mehr lernst, wird das Problem viel größer/komplexer. Beim Eisberg sind 90 % versteckt. Das solltest Du von vornherein beachten, insbesondere damit Du die Erwartung Deiner Betreuer steuerst.

Hallo af243r2,

jede Software-Entwicklung setzt eine mehr oder weniger eingehende Analyse des Problems voraus. Bei komplexen, noch nicht (vollständig) verstandenen Problemen (z.B. natürlichsprachliches Verstehen, Bilderkennung u.a.), kann schon die Analyse(-phase) mehrere Monate (oder sogar Jahre und im Extremfall Jahrzehnte) beanspruchen, ohne dass in dieser Zeit auch nur eine einzige Zeile Code geschrieben wird. Software-Entwicklung auf die Produktion von Code oder eines fertigen Programms zu beschränken, würde mir zu kurz greifen. Selbst wenn die Lösung des Problems später in der Konfiguration oder dem Einsatz von existierenden Tools besteht, bleibt doch die dafür nötige Analyse vergleichbar einer Analyse wie sie für die Entwicklung eines eigenen Tools nötig ist.

Daher sehe ich keine prinzipiellen Gründe, aus denen das Thema ungeeignet wäre. Klar besteht, wie es weismat gesagt hat, bei einer reinen Analyse viel eher das Problem, dass man auf (unüberwindliche) Hindernisse stößt, als wenn man sich ein so überschaubares Projekt sucht, dass man in den drei Monaten sicher analysieren, designen, implementieren und testen kann. Aber das musst du wissen, ob das Risiko (und die darin liegenden Chancen) es dir Wert sind. Wäre ja langweilige, wenn alle immer nur die gleichen schon abgegrasten Felder behandeln würden.

Ich würde das Problem zudem von zwei Seiten angehen. Zum einen, welche Schlüsse über Zusammenhänge kann man aus vorhandenen Logs mit ausreichender Zuverlässigkeit erschließen. Zum anderen, wie müssten Log-Einträge idealerweise aussehen und welche Informationen müssten sie enthalten, damit die Zusammenhänge explizit ermittelbar sind. Zum Beispiel könnte beim Auftreten des initialen Fehlers eine GUID generiert werden, die bei dieser Meldung und bei allen darauf aufbauenden ausgegeben wird. Dann wäre der Zusammenhang der Meldungen eindeutig. Am Ende kann man dann quantitativ ermitteln, wie viel schon ohne solche Maßnahmen erkennbar/erschließbar ist und hätte somit einen schönen wissenschaftlichen Vergleich, egal wie schlecht die Erfolge beim Erkennen von Zusammenhängen in bestehenden Logfiles sind.

herbivore

Man könnte sich hier mehr in Richtung Clustering (https://de.wikipedia.org/wiki/Clusteranalyse) von Daten fokussieren, zusammenhängende Daten analysieren und in unterschiedliche Cluster zuweisen. Konkret würde das bedeuten, dass gewisse Logs in einer gegebenen Zeitspanne je nach bestimmten Informationen zusammengefasst werden. Aktuell gibt es bereits Logs in einer zentralen Datenbank mit verschiedenen Attributen, wie die Zeitpunkt der Erstellung, Anwendung, Fehler-/Infotext, usw.
Da stellt sich mir die Frage, was kann man hier clustern, weil die Daten ja schon bereits aufbereitet sind und man nur nach bestimmten Kriterien gruppieren müsste?! Habt ihr weitere Ideen?