LOGLEVEL - Detailbeschreibung

Open

Überblick

Parameter:LOGLEVEL
Kategorie: Logging
Standardwert: 1 (Warnungen)
Produkt: eTASK.Sonstige (Logging)

Was macht dieser Parameter?

Dieser Parameter steuert, wie detailliert das System Informationen ins Applikationsprotokoll (Application Log) schreibt. Er entscheidet, welche Art von Ereignissen aufgezeichnet werden – von kritischen Fehlern bis hin zu detaillierten Debug-Informationen für Entwickler.

Die Einstellung wirkt wie ein Filter: Je höher der Wert, desto mehr Informationen werden protokolliert.

Wofür wird dieser Parameter verwendet?

• Fehleranalyse: Aufzeichnung von Systemfehlern für spätere Untersuchungen

• Wartung und Überwachung: Erkennung von Warnungen, bevor sie zu Problemen werden

• Debugging: Detaillierte Informationen zur Fehlersuche bei Entwicklung oder komplexen Problemen

• Compliance und Audit: Nachvollziehbare Dokumentation von Systemereignissen

• Performance-Monitoring: Identifikation von Performance-Engpässen

• Sicherheitsüberwachung: Erkennung verdächtiger Aktivitäten

Technische Details (für Administratoren)

Format: Ganzzahl (0-3)
Standardwert: 1 (Warnungen)

Gültige Werte und ihre Bedeutung:

Wichtige Hinweise:

• Kumulativ: Höhere Werte enthalten automatisch alle niedrigeren Levels (z.B. 2 zeigt auch Warnungen und Fehler)

• Gilt systemweit: Betrifft das gesamte eTASK.FM-Portal

• Sofortige Wirkung: Änderungen greifen ohne Neustart

• Protokollspeicherort: Konfigurierbar über LOGFILENAME (Standard: etask_log) im Verzeichnis /neon/Log.Etask

• E-Mail-Benachrichtigung: Bei Error-Level kann automatische E-Mail-Benachrichtigung über EXNOTIFYEMAILFLAG aktiviert werden

• Log-Aufbewahrung: Steuerbar über KEEPLOGSDAYS Parameter

Zusammenspiel mit anderen Parametern:

• SENDLOGERRORMAIL / EXNOTIFYEMAILFLAG: E-Mail-Benachrichtigung bei Error-Level

• EXRECIPIENTMAIL: Empfänger-Adresse für Fehler-E-Mails

• KEEPLOGSDAYS: Aufbewahrungszeit für Log-Dateien

• LOGFILENAME: Name der Log-Datei (Standard: etask_log)

Wann sollten Sie diesen Wert ändern?

Wert erhöhen (auf 2 oder 3), wenn:

• Fehlersuche erforderlich ist: Ein Problem tritt sporadisch auf und Sie benötigen mehr Details

• Neue Features getestet werden: Bei Rollouts neue Funktionalität überwachen

• Performance-Probleme analysiert werden: Detaillierte Informationen zu Laufzeiten benötigt werden

• Support-Anfragen bearbeitet werden: Kundensupport benötigt detaillierte Logs

• Entwicklungsumgebung: Entwickler arbeiten an neuen Features

• Nach Updates/Upgrades: Überwachung des Systems nach größeren Änderungen

Wert verringern (auf 0), wenn:

• Log-Dateien zu groß werden: Speicherplatz ist begrenzt

• Performance-Optimierung nötig ist: Logging verursacht messbare Systemlast

• Nur kritische Fehler relevant sind: Produktivsystem läuft stabil

• Compliance erfordert minimale Logs: Datenschutz-Anforderungen

Wert auf 1 belassen (Standard), wenn:

• Normalbetrieb ohne besondere Probleme läuft

• Ausgewogenes Verhältnis zwischen Details und Performance gewünscht ist

• Warnungen frühzeitig erkannt werden sollen, bevor sie zu Fehlern werden

Wichtige Hinweise

1. Log-Größe überwachen bei hohen Werten
   LOGLEVEL=3 (Debug) kann in Produktivumgebungen mehrere Gigabyte pro Tag erzeugen. Stellen Sie sicher, dass ausreichend Speicherplatz vorhanden ist und alte Logs automatisch archiviert/gelöscht werden.

2. Performance-Impact bei Debug-Level
   LOGLEVEL=3 kann die Systemperformance reduzieren, da jede Operation detailliert protokolliert wird. Verwenden Sie Debug-Level nur temporär!

3. Sicherheit: Sensible Daten in Logs
   Höhere Log-Levels können sensible Informationen aufzeichnen (SQL-Queries, Benutzerdaten, API-Keys). Beachten Sie DSGVO-Anforderungen bei personenbezogenen Daten, Zugriffsbeschränkungen auf Log-Dateien und regelmäßiges Löschen sensibler Logs.

4. Temporäre Erhöhung für Debugging
   Best Practice: Erhöhen Sie den Wert auf 3 nur für kurze Zeiträume (Stunden, max. Tage) und setzen Sie ihn danach auf 1 zurück.

5. Log-Level ist nicht rückwirkend
   Änderungen betreffen nur zukünftige Ereignisse. Bereits geschriebene Logs bleiben unverändert.

6. Koordination bei Teamarbeit
   Informieren Sie Ihr Team, wenn Sie den Log-Level ändern – andere könnten sich auf bestimmte Log-Einträge verlassen oder von der erhöhten Log-Menge überrascht werden.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter ist sicherheitsrelevant – allerdings indirekt.

Sicherheits-Vorteile (PRO höhere Log-Levels):

• Angriffsserkennung: Verdächtige Aktivitäten werden detaillierter aufgezeichnet

• Forensik: Bei Sicherheitsvorfällen können Angriffe besser nachvollzogen werden

• Compliance: Erfüllung von Audit-Anforderungen (z.B. ISO 27001, DSGVO)

• Frühwarnung: Warnungen zeigen potenzielle Sicherheitsprobleme, bevor sie kritisch werden

• Nachvollziehbarkeit: Änderungen und Zugriffe werden dokumentiert

Sicherheits-Risiken (CONTRA höhere Log-Levels):

• Sensible Daten in Logs: SQL-Queries, personenbezogene Daten

• Log-Dateien als Angriffsziel: Umfangreiche Logs enthalten wertvolle Informationen für Angreifer

• DSGVO-Probleme: Übermäßiges Logging personenbezogener Daten kann datenschutzwidrig sein

• Denial-of-Service via Logging: Angreifer könnten absichtlich Log-Flooding auslösen

• Ungeschützte Logs: Wenn Log-Dateien unverschlüsselt oder falsch berechtigt sind

Empfehlung führender Sicherheitsorganisationen:

OWASP (Open Web Application Security Project): - Protokolliere Sicherheitsereignisse (Login-Versuche, Berechtigungsfehler) - Verwende strukturiertes Logging - Es werden nicht Passwörter oder Kontodaten geloggt

BSI (Bundesamt für Sicherheit in der Informationstechnik): - Log-Level an Schutzbedarf anpassen - Regelmäßige Überprüfung der Logs auf Anomalien - Sichere Speicherung und Zugriffskontrolle

Fazit: Der Parameter selbst ist nicht direkt sicherheitskritisch, aber die Handhabung der erzeugten Logs hat erhebliche Sicherheitsimplikationen. Erhöhen Sie den Log-Level für Sicherheitsüberwachung, schützen Sie Log-Dateien durch Zugriffsberechtigungen, vermeiden Sie Debug-Level in Produktion und implementieren Sie Log-Rotation.

Praktisches Beispiel

Szenario 1: Fehlersuche bei sporadischem Problem

Ausgangssituation:
Benutzer melden, dass gelegentlich beim Speichern von Aufträgen eine Fehlermeldung erscheint. Mit LOGLEVEL=1 sind nur allgemeine Warnungen sichtbar, die Ursache bleibt unklar.

Konfiguration:

Nach der Änderung:

• Das System protokolliert nun jeden Schritt beim Speichern eines Auftrags

• Sie können Details sehen: SQL-Befehle, Operationsdauer, Validierungen, Stack-Traces

• Nach 2 Tagen zeigen die Logs: Bei bestimmten Auftragswerten tritt ein Timeout zur Datenbank auf

• Der Hersteller identifiziert einen fehlenden Index auf einer Tabelle

• Problem gelöst! Sie setzen LOGLEVEL zurück auf 1

Ergebnis:
Debug-Logging hat ca. 15 GB in 2 Tagen erzeugt – wichtige Lektion: Immer temporär erhöhen, dann zurücksetzen!

Szenario 2: Produktivumgebung optimieren

Ausgangssituation:
Das Produktivsystem läuft mit LOGLEVEL=2 (Information) seit 3 Jahren. Die Log-Dateien sind riesig (200 GB), und das tägliche Backup dauert zu lange. Über 90% der Einträge sind reine Informationsmeldungen ohne Mehrwert.

Konfiguration:

Nach der Änderung:

• Log-Volumen sinkt um 85% (von 2 GB/Tag auf 300 MB/Tag)

• Backups sind 45 Minuten schneller

• Wichtige Warnungen und Fehler werden weiterhin protokolliert

• Log-Dateien sind übersichtlicher und schneller durchsuchbar

• Speicherkosten sinken um ca. 500 €/Jahr

Ergebnis:
Optimale Balance zwischen Details und Effizienz – ohne wichtige Informationen zu verlieren.

Szenario 3: Sicherheitsvorfall untersuchen

Ausgangssituation:
Die Sicherheitsabteilung meldet verdächtige Login-Versuche. Mit LOGLEVEL=0 (nur Fehler) sind nur gescheiterte Logins sichtbar, aber keine Details.

Konfiguration:

Nach der Änderung:

• Sie sehen nun: Erfolgreiche und gescheiterte Login-Versuche, IP-Adressen, Zeitpunkte, betroffene Benutzerkonten

• Die Logs zeigen ein Muster: Brute-Force-Angriff von 15 IP-Adressen

• Sie blockieren die IPs und aktivieren zusätzliche Sicherheitsmaßnahmen

• Nach 1 Woche senken Sie zurück auf 1

Ergebnis:
Sicherheitsvorfall erfolgreich analysiert und abgewehrt – Log-Level ist ein wertvolles Werkzeug für Security-Monitoring!

Empfohlene Einstellung

Für Produktivumgebungen:1(Warning)

Begründung: - Ausgewogenes Verhältnis zwischen Details und Performance - Warnungen werden erkannt, bevor sie zu Problemen werden - Kritische Fehler werden vollständig protokolliert - Log-Größe bleibt überschaubar (typisch 200-500 MB/Tag) - Minimaler Performance-Impact (<1%)

Dies ist der Standard und für die meisten Szenarien optimal.

Für Entwicklungs-/Testumgebungen:2 oder 3 (Information/Debug)

Begründung: - Entwickler erhalten detaillierte Informationen für Debugging - Neue Features können genau überwacht werden - Performance ist weniger kritisch als in Produktion - Log-Größe ist akzeptabel bei kurzer Aufbewahrungsdauer

Tipp: Auch in Test-Umgebungen gelegentlich auf 1 reduzieren, um produktionsnahe Bedingungen zu simulieren.

Temporär für Fehlersuche:3(Debug)

Begründung: - Maximale Details für komplexe Problemanalysen - Vollständige Nachvollziehbarkeit aller Systemoperationen - NUR für kurze Zeiträume (Stunden bis wenige Tage) - Danach UNBEDINGT auf 1 zurücksetzen

Checkliste bei Debug-Level: 1. Zeitfenster definieren (z.B. "nur heute von 9-17 Uhr") 2. Speicherplatz prüfen (mindestens 10 GB frei) 3. Log-Rotation aktivieren 4. Reminder setzen zum Zurücksetzen 5. Team informieren

Für Minimal-Logging:0(Error)

Begründung: - Minimale Log-Größe (~50 MB/Tag) - Maximale Performance - Nur kritische Fehler sichtbar - Warnungen werden übersehen - Fehlersuche ist schwieriger

Nur verwenden, wenn: - Speicherplatz extrem begrenzt ist - System nachweislich sehr stabil läuft - Andere Monitoring-Tools im Einsatz sind

Nicht empfohlen für normale Produktivumgebungen!

Zusammenfassung:

Faustregel: Wenn Sie sich unsicher sind, verwenden Sie 1 (Warning) – das ist fast immer die richtige Wahl.

IC2880