# Operations
## Logging and Monitoring
- Wichtig, was in Production passiert
  - Business kann Feedback bekommen
  - Wenn etwas schiefgeht, können die Operatoren direkt benachrichtigt werden
  - Historische Daten sind wichtig für zukünftige Planungen

### Collecting Data
- Hardware
  - Temperatur, Lüftergeschwindigkeit, Stromverbrauch, ...
- Server, Infrastruktur
  - Memory-, Swap-, CPU-Verbrauch, Speicherplatz, I/O-Bandbreite, ...
- Middleware
  - Ressourcennutzung, Antwortzeit, Datenbankverbindungen, ...
- Anwendungen
  - Anwendungsspezifische Logs
    - Gesundheitsspezifisch, Status
  - Daten, die Businessuser interessieren

#### Zentralisierte Logging Infrastruktur
- Logs sollten irgendwo aufgezeichnet werden
  - nicht dort lassen, wo sie generiert werden

## Application Logging
- Wofür?
  - Debugging
  - unnormales Verhalten aufzeichnen
  - Security
- Sollten für den Menschen lesbar sein 

### Log Levels
![image_863.png](image_863.png)
#### Trace
- Primär für Devs
- technische Steps einer Transaktion

#### Debug
- sämtliche Debugging-Aktivitäten
- enthalten häufig (zu) viele Informationen
  - in Produktion am besten nicht mehr sichtbar

#### Info
- Diagnostiziert, ob System korrekt läuft

#### Warning
- Wenn Dinge nicht laufen, wie gewünscht
  - Risiko, dass Error entsteht, Software läuft weiter
- Erfordern keine direkte Intervention

#### Error
- Events, die Interventionen erfordern
  - bspw. _nullpointerexception_
- Logevents sollten Errorursache mit aufzeichnen

#### Fatal
- Exceptionelle Error-Events
- Anwendung muss plötzlich stoppen
- möglichst viele Informationen sollten angezeigt werden


### Good Practices
- Frameworks nutzen, wenn möglich
  - Struktur bleibt gleich
  - Es kann gezielt ausgewählt werden, wie viele Log-Levels ausgegeben werden sollen
- Klare Sprache
  - Maschinen und Menschenlesbar
- Kontext ist essenziell
  - Was ist passiert
  - Wann ist es passiert
  - Wo ist es passiert
  - Warum ist es passiert
  - Wer hat es ausgelöst