Einführung in Splunk Observability
Einführung in Splunk Observability
In diesem Blog bekommt ihr einen Überblick über Splunk Observability.
Unterschied zwischen IT Monitoring und Observability
Im Allgemeinen werden die Begriffe „monitoring“ und „oberservability“ oft synonym verwendet. Aber es gibt wichtige Unterschiede.
Monitoring bezieht sich auf das Sammeln und Analysieren von Daten von Anwendungen und Infrastrukturen, um die Leistung von individuellen IT-Systemen auf der Grundlage eines vordefinierten Satzes von logbasierten Messwerten zu verfolgen. Somit können Probleme erkannt, gelindert und behoben werden. Einfach gesagt ist Monitoring also ein fortlaufender Prozess, welcher den Output des Systems überwacht. Zum Beispiel kann überwacht werden, ob ein Systemprozess aktiv ist, einen Heartbeat erhält oder Verzögerungen den Service Level Agreements entspricht (SLA). Monitoring nutzt Dashboards zur Erfassung und Anzeige vorgegebener Daten, die IT-Teams dabei helfen, potenzielle Probleme und langfristige Leistungstrends zu erkennen.
Observability ist die Fähigkeit, den internen Zustand des Systems und der Infrastruktur auf Grundlage von externem Output wie Protokollen, Metriken, Ereignissen und Traces, die von der Anwendung oder dem System generiert werden, zu verstehen und zu erkennen. Observability bietet Kontext und ein tiefes Verständnis der Abhängigkeiten zwischen den verschiedenen Anwendungen in eurer IT-Umgebung. Probleme können so schneller, proaktiver und präziser erkannt werden.
Schlussendlich versucht Monitoring nicht das System zu verändern, welches überwacht wird. Es werden nur Aktionen überwacht, die passieren, ohne dass etwas am System gemacht wird. Damit ein System aber wirklich beobachtbar wird, muss es etwas Zusätzliches zur Offenlegung seines internen Zustandes tun. Und zwar muss ein Beobachtungscode in die Anwendung integriert werden. Ein Beispiel dafür ist die OpenTracing API, die Entwicklern dabei hilft, Tracing einfach in ihre Codebasis zu integrieren.
Zusammenfassend lässt sich sagen, dass das Monitoring ausreicht, wenn nur ein einziger Prozess auf einer Maschine läuft. Wenn jedoch mehrere Prozesse auf mehrere Maschinen laufen, obwohl metrische Messwerte aus dem System kommen, brauchen wir etwas, um sie zu kombinieren und eine zusammenhängende Ansicht zu erhalten, weshalb wir Observability benötigen.
Verwendete Daten für die Observability
Telemetry data wie Protokolle, Metriken und Traces, die von Anwendungen oder Systemen erzeugt werden, können für die Observability verwendet werden. Im Allgemeinen wird telemetry data mithilfe einer Sammlung von Ressourcen, einschließlich SDKs und APIs (wie OpenTelemetry), erzeugt. Es gibt verschiedene Arten von telemetry data
- Business Layer Metrics: z. B. Ergebnisse von A/B-Tests, Anzahl der neuen Nutzer, durchschnittliche Sitzungsdauer
- Application Layer Metrics: z. B. Antwortzeiten von Anwendungen, Dauer von Transaktionen
- Infrastructure Layer Metrics: wie Serververkehr, Festplatten-E/A-Vorgänge, Netzwerk-E/A-Vorgänge, RAM-, CPU- und Festplattennutzung
- Client Layer Metrics: Wie z. B. die Antwortzeiten von Client-Anwendungen und Client-Fehler bei Web-, Mobil-, JavaScript- und anderen Client-Anwendungen.
- Deployment Pipeline Layer Metrics: z. B. Check-Ins, Bereitstellungsfristen, Häufigkeit, Status der Umgebungen
Splunk-Produkte, die zu Observability gehören
Derzeit bietet Splunk die folgenden Observability-Produkte an
- Splunk Application Performance Monitoring
- Splunk Infrastructure Monitoring
- Splunk IT Service Intelligence
- Splunk Log Observer Connect
- Splunk Real User Monitoring
- Splunk Synthetic Monitoring
- Splunk On-Call