Log Analytics Workspace Design
Warum Workspace-Design wichtig ist
Section titled “Warum Workspace-Design wichtig ist”Der Log Analytics Workspace ist nicht nur ein Speicherort – er bestimmt Kosten, Datenzugriff, Aufbewahrung und teilweise auch die organisatorische Trennung (wer darf was sehen?). Ein späterer Umbau ist möglich, aber meist schmerzhaft.
Grundentscheidungen
Section titled “Grundentscheidungen”1) Ein Workspace oder mehrere?
Section titled “1) Ein Workspace oder mehrere?”Ein zentraler Workspace ist sinnvoll, wenn:
- du zentralen Betrieb und Cross-Resource-Queries willst,
- Zugriffsmodelle einfach sind (z. B. Plattformteam + Reader für Workload-Teams),
- regulatorische Anforderungen nicht nach Trennung verlangen.
Mehrere Workspaces sind sinnvoll, wenn:
- Datenzugriff streng getrennt werden muss (z. B. unterschiedliche Betriebsdienstleister),
- unterschiedliche Retention/Cost-Profile existieren,
- du mandantenähnliche Separation innerhalb eines Tenants brauchst.
Heuristik: Mehr Workspaces lösen selten technische Probleme – sie lösen organisatorische und Compliance-Probleme.
1a) Pro Region oder global?
Section titled “1a) Pro Region oder global?”Ein zusätzliches, oft unterschätztes Thema ist Region/Data Residency:
- Wenn Daten in einer Region verbleiben müssen, ist “ein globaler Workspace” ggf. nicht zulässig.
- Bei vielen Regionen kann ein Workspace pro Region sinnvoll sein, wenn du lokale Ingestion/Retention sauber steuern willst.
Wenn du global korrelieren willst, plane bewusst, wie du Queries/SIEM-Aggregation machst (z. B. zentraler Security-Workspace oder Export).
2) Retention und Kosten
Section titled “2) Retention und Kosten”Kosten entstehen primär durch Ingestion und Retention. Gute Praxis:
- Retention als bewusste Policy (nicht Default überall).
- High-volume Logs filtern/transformieren (DCR/AMA), statt “alles sammeln”.
Praktische Ergänzung:
- Nicht jede Tabelle braucht die gleiche Retention.
- Plane “Verbose”-Quellen (z. B. Diagnostics mancher PaaS-Dienste) separat – sonst ist der Workspace der Kostentreiber.
3) Zugriff: wer darf welche Logs sehen?
Section titled “3) Zugriff: wer darf welche Logs sehen?”Plane RBAC nicht erst nachträglich.
- Plattformbetrieb: benötigt meist breiten Zugriff (Troubleshooting).
- Workload-Teams: Zugriff auf ihre Ressourcen/Workspaces.
- Security: ggf. zusätzliche Export-/SIEM-Anforderungen.
Überlege zusätzlich:
- Werden Logs als Betriebsdaten (Ops) oder als Sicherheitsdaten (SecOps) genutzt?
- Brauchst du Trennung nach Mandanten/Teams (betrieblich) oder nach Sensitivität (regulatorisch)?
Operational Patterns
Section titled “Operational Patterns”- Daten-Routing: Definiere, welche Ressourcen wohin schreiben (einheitliche Diagnostics Settings).
- Namenskonvention: Workspace-Namen sollten Umgebung/Region/Scope sichtbar machen.
- Export: Für Compliance/SIEM kann Data Export oder Sentinel relevant sein – plane das früh.
Entscheidungshilfe (Daumenregeln)
Section titled “Entscheidungshilfe (Daumenregeln)”- Wenn du hauptsächlich Plattformbetrieb machst: eher wenige Workspaces, dafür sauberes RBAC und klare Ingestion-Regeln.
- Wenn du Compliance-/Mandantentrennung brauchst: eher mehrere Workspaces, aber mit Standardisierung, sonst driftet die Konfiguration.
Wichtig ist, die Betriebsfolgen mitzudenken: jedes zusätzliche Ziel (Workspace, Export, Sentinel) braucht Ownership und Budget.
Stolperfallen
Section titled “Stolperfallen”- Workspaces “pro Team” ohne klare Gründe: erhöht Kosten und erschwert zentrale Korrelation.
- Unkontrollierte Diagnostics: Ein Dienst rollt “verbose” Logs aus und sprengt Budget.
- Zugriff nur über “Workspace Contributor”: zu breit; nutze Reader/Log Analytics Reader wo möglich.