DevOps-Track auf der .conf20: Observability und mehr

Es war allgemein ein aufregendes Jahr für die DevOps-Community, insbesondere für uns bei Splunk. Allein im letzten Jahr konnten wir uns durch die Zusammenführung von Technologie und talentierten Fachkräften eine Führungsposition im Bereich Observability und DevOps erarbeiten.

Im August hat Splunk SignalFx übernommen, ein führendes Unternehmen in den Bereichen Infrastruktur-Monitoring und Application Performance Monitoring (APM, Überwachung der Anwendungsleistung).

Direkt im Anschluss folgte die Übernahme von Omnition, einem führenden Anbieter von OpenTelemetry. OpenTelemetry verändert die Erfassung von Telemetriedaten, insbesondere in modernen Umgebungen mit Cloud-Infrastruktur und Microservice-Anwendungen.

Parallel dazu hat Splunk seine Innovationen an der Incident Response-Front weiter vorangetrieben. VictorOps wird kontinuierlich durch neue Funktionen ergänzt, die es Teams aller Größenordnungen ermöglichen, die Eskalation von Incidents und die Zusammenarbeit an deren Lösung zu automatisieren.

Ebenso wichtig ist, dass ihr, die Splunk-Community, euch in den Bereichen DevOps und Observability auf den Weg macht und Cloud-native Ansätze verwendet, um eure Clouds und modernen Apps maßstabsgerecht zu überwachen. Genau darum geht es im Grunde in unserem .conf DevOps-Track: Wir möchten euch helfen, eure DevOps- und Observability-Fähigkeiten mit Unterstützung von Splunk und der Splunk-Community auszubauen.

Die umfassende Sammlung an Sessions innerhalb des DevOps-Tracks bietet einen Mix aus innovativem Denken, Produkteinführungen, Case Studies und weiteren Sessions mit praktischen Anleitungen, die unserer Ansicht nach für SREs, Entwickler und Plattform-/Cloud Operations-Teams interessant sind:

• DevOps und Observability:Welche Trends und Best Practices solltet ihr kennen, um euren Erfolg zu maximieren?
• Infrastruktur-Monitoring:Umdenken beim Monitoring der Cloud-Infrastruktur mit Blick auf Monitoring-Effizienz, blitzschnelle Warnmeldungen und punktgenaue Fehlerbehebung. Setzt ihr Kubernetes ein? Wir werden uns eingehend mit diesem Thema befassen.
• Anwendungs-Performance: Monitoring der Verfügbarkeit und Performance von Anwendungen, um SREs und Entwicklern die Erkenntnisse zu liefern, die sie für schnelle Problemlösungen und ein besseres Anwendungsdesign benötigen
• Incident Response:Automatisierte Meldung von Incidents an die jeweils richtigen Teams, damit Probleme schneller erkannt, gemeinsam angegangen und gelöst werden können
  
  

Die eingesendeten Beiträge und Themenvorschläge waren nicht nur gut durchdacht , sondern auch zahlreich. Jede Session im DevOps-Track ist absolut interessant. Um euch einen Vorgeschmack zu geben, findet ihr nachfolgend einige Beispiele für Sessions, die euch bei der .conf erwarten. Bitte beachtet, dass die Sessions in englischer Sprache stattfinden werden. Unten findet ihr aber dennoch eine kurze Zusammenfassung der Sessions auf Deutsch.

APP1246B - 5 Reasons Why OpenTelemetry is the Future of Observability
Es heißt, Open Source erobert die Welt, und im Bereich Observability heißt das Projekt hinter dieser Bewegung OpenTelemetry. Das OpenTelemetry-Projekt ist zwar neu, allerdings handelt es sich dabei um eine Kombination aus zwei ausgereiften Projekten, nämlich OpenCensus und OpenTracing. OpenTelemetry entwickelt sich rasch zum Standard für die Instrumentierung und Erfassung von Observability-Daten. Zum Thema Observability gibt es viele Meinungen, aber wenige Antworten. Dabei kommt es darauf an, zu verstehen, welche Daten erfasst werden sollten und wie sie richtig erfasst werden, um sicherzustellen, dass die Benutzer zum richtigen Zeitpunkt die richtigen Antworten erhalten. Der Schwerpunkt des OpenTelemetry-Ansatzes liegt auf offenen Standards, Open-Source-Instrumentierung und Datenerfassung. Warum ist ein auf offenen Standards und Open-Source basierender Ansatz für die Instrumentierung und Datenerfassung so überzeugend? Dieser Beitrag liefert fünf Gründe dafür, weshalb OpenTelemetry den Observability-Markt aufmischt.

APP1643B - Crossing the Streams: Integrating SignalFx and Splunk
Bei Yelp nutzen wir SignalFx und Splunk bereits seit einigen Jahren. In diesem Beitrag zeigen wir euch Schritt für Schritt, wie sich der Wert beider Tools durch die gemeinsame Nutzung maximieren lässt. Wir haben bei Yelp hervorragende Ergebnisse mit einem Workflow erzielt, in dem wir Symptome mit SignalFx erkennen und die Ursachen in Splunk analysieren. Splunk ermöglicht ausgesprochen tiefgreifende Einblicke in die erfassten Daten und deren Verwendung. Durch die Anwendung dieses Ansatzes auf SignalFx gewinnen wir weitreichende Erkenntnisse über unser Deployment. Dieser Beitrag hilft euch, Fragen wie die folgenden zu beantworten: Wie erkennt man Metriken mit hoher Kardinalität in der SignalFx-Nutzung? Würden diese Metriken mit hoher Kardinalität mehr Wert bieten als Splunk-Protokolle? Welche Kosten verursacht das Monitoring für mein Team, und wie wird die Nutzung über beide Systeme hinweg gemessen? Wir sprechen über Lektionen, die wir in fast einem Jahrzehnt über die Verwendung dieser beiden Tools im Tandem gelernt haben.

APP1571B - SignalFx at Scale: we learned the hard way so you don’t have to
Am Anfang ist Monitoring beängstigend, weil so viele Dinge schiefgehen können. Ihr seid drauf und dran, Microservices und Anwendungen Tür und Tor zu öffnen. Welche Vorkehrungen lassen sich für einen langfristigen Erfolg treffen? Der richtige Start ist entscheidend und hilft, Ziele schneller zu erreichen und eine bessere Observability-Erfahrung zu machen. Am Ende dieser Session werdet ihr wissen, was wir bei Atlassian noch nicht wussten, als wir diesen Weg beschritten, und was wir von Beginn an hätten anders machen sollen. Ihr werdet eine ganze Reihe umsetzbarer Ideen im Gepäck haben, die ihr gleich am nächsten Tag umsetzen könnt, oder wenn ihr euch dem Tipping-Point nähert. Ich werde erläutern, wie wir eine Observability-Kultur ins Leben gerufen haben, in der unsere Benutzer im Mittelpunkt stehen und jeder Mitarbeiter ein eigenständiger SignalFx-Experte ist. Dies ist eine Fortsetzung unseres Beitrags „Feed the Beast (Splunk)“ von der Splunk .conf19. Dieses Mal werden wir jedoch über unsere Erfahrungen mit der Skalierung von SignalFx berichten.

APP1894B - Microservices, a fairy tale with a „cautiously optimistic“ ending
Wenn sie richtig umgesetzt werden, können Microservice-Architekturen das Rückgrat schneller Innovation sein, denn sie ermöglichen Agilität und Skalierbarkeit. Unternehmen verlagern ihre traditionellen Anwendungen in die Cloud (Lift & Shift) und gestalten sie zu Microservices um. Doch ist wirklich alles Gold was glänzt? Ein weiser Mensch hat einmal gesagt: „Wir haben unsere monolithische Umgebung durch Microservices ersetzt, damit jeder Ausfall einem Rätselkrimi gleichkommt.“ In diesem Beitrag nehmen wir die Herausforderungen beim Monitoring und Troubleshooting von Microservice-Architekturen eingehend unter die Lupe und erläutern, wie Tracing-Instrumentierung als Ergänzung zu Infrastruktur-Monitoring, Metriken auf Anwendungsebene und Protokollen eingesetzt werden kann. Ihr erfahrt, wie ihr eine Observability-Strategie für eure Microservices entwickeln könnt, ohne in die Rätselkrimi-Falle zu geraten.

Dieses Jahr gibt es bei der .conf ungeheuer viel zu entdecken, insbesondere im DevOps-Track, und wir freuen uns schon darauf, euch dort (virtuell) zu sehen! In der Zwischenzeit könnt ihr euch schon mal für die Splunk .conf20 registrieren, und zwar am besten gleich heute. Es dauert nur zwei Minuten und ist kostenlos!

Viel Spaß beim Splunken!
Bill

Allen Unterhaltungen auf der #splunkconf20 folgen!

@splunkde folgen

----------------------------------------------------
Thanks!
Bill Emmett