Lesen Sie, wie GoDaddy von in Silos eingeschlossenen Clustern auf eine zentralisierte Elasticsearch-Umgebung umgestiegen ist, um mithilfe von Machine Learning

Dieser Blogpost ist eine Zusammenfassung eines Community Talks bei der <a href="/de/elasticon/conf/2018/sf">Elastic{ON} 2018</a>. Sind Sie an ähnlichen Talks wie diesem interessiert? Sehen Sie sich im Konferenzarchiv um oder informieren Sie sich über anstehende <a href="/de/elasticon">Elastic{ON} Tour</a>-Termine in Ihrer Nähe.
GoDaddy ist ein Anbieter von Web-Hosting- und Domain-Management-Diensten, der regelmäßigen Super Bowl-Zuschauern bekannt sein dürfte. Aber mit mehr als 17 Millionen Kunden, 75 Millionen Domains und 10 Millionen gehosteten Websites ist das Unternehmen auch im Bereich Big Data sehr gut aufgestellt. Wer für einen problemlosen Betrieb von Websites zuständig ist, braucht Erkenntnisse zu jeder einzelnen Komponente der eigenen Infrastruktur, vom Patch-Level der virtuellen Server über eventuelle Netzwerkprobleme bis hin zu Hackerangriffen. Bei mehr als 200.000 Meldungen (DNS-Abfragen, Systemlogeinträgen, Ereignismeldungen und so weiter) pro Sekunde ist das kein einfaches Unterfangen, aber der Elastic Stack ist dieser Aufgabe aufgrund seiner Verarbeitungsgeschwindigkeit auch bei großen Datenvolumen problemlos gewachsen.
Die Geschichte von Elasticsearch und GoDaddy fing ähnlich an wie bei vielen Unternehmen, bei denen Open-Source-Software im Einsatz ist: Die verschiedenen Teams im Unternehmen setzen jedes seinen eigenen Cluster auf, um die speziellen Bedürfnisse dieses einen Teams zu befriedigen. Das funktioniert fürs einzelne Team, aber dieses unverwaltete Deployment-Modell führt im Endergebnis zu Hunderten von Clustern mit den unterschiedlichsten Versionen von Elasticsearch, die Daten in Silos analysieren. Wohl wissend, dass es auch anders geht, bildete GoDaddy 2014 ein Team, das für die Verwaltung des Elasticsearch-Deployments zuständig ist. Dieses Team kümmert sich heute um mehr als 60&nbsp;Elasticsearch-Cluster mit über 700 Docker-Containern und Feeds von Teams aus dem gesamten Unternehmen. Diese Cluster beherbergen mehr als 270&nbsp;TB Daten aus der (11 PB)-HDFS-Umgebung von GoDaddy.
Zu den ersten Anwendungsfällen, die das neue Elasticsearch-Team in Angriff nahm, gehörte die Verwaltung der Patch-Compliance im gesamten Ökosystem. Ohne die Möglichkeit, auf <a href="/de/products/beats">Beats</a> zurückzugreifen (wir sprechen von 2014), entwickelte GoDaddy Windows- und Linux-Agents (ähnlich <a href="/de/products/beats/auditbeat">Auditbeat</a> und <a href="/de/products/beats/winlogbeat">Winlogbeat</a>), über die Systemdaten an Elasticsearch gesendet werden konnten. Dank dieser Agents, die GoDaddy auf allen seinen Servern installiert hatte (physisch und virtuell), konnte GoDaddy wertvolle Erkenntnisse zu den Patching-Leveln und zur Compliance in der gesamten Infrastruktur gewinnen. Und die Nutzung unterschiedlicher Dashboards und Visualisierungen in Kibana ermöglichte es, den Administratoren und Technikern detaillierte Patch-Informationen sowie der Geschäftsleitung Berichte mit zusammengefassten Übersichtsdaten bereitzustellen – alles auf der Basis derselben zentralisierten Daten, sodass jeder Beteiligte ständig auf dem neuesten Stand ist.
Die Pflege der Server-Patch-Level ist eine wichtige Voraussetzung dafür, dass der Website-Traffic flüssig fließt, und damit dafür, dass die Nutzer am Ball gehalten werden. Wenn eine Website nur langsam lädt, sehen sich die Besucher anderswo um. Im Sinne der Aufrechterhaltung eines positiven Nutzungserlebnisses für seine Millionen von Kunden brauchte GoDaddy eine Möglichkeit, die Performance der Rechenzentren und deren Auswirkungen auf die Website-Besucher nachzuverfolgen. Die benötigten Daten waren bereits vorhanden, da die Systemkomponenten alle Ereignisse in Logs protokollierten, aber es fehlte eine Möglichkeit, diese Daten ganzheitlich zu betrachten.
<h2>Zentralisiertes Logging mit Machine Learning für die Anomalieerkennung</h2>GoDaddy suchte nach einem Weg, die verschiedenen Arten von Performance- und Engagement-Daten zentralisieren und analysieren zu können, und der Elastic Stack war die Lösung. Durch das Senden von Netflow-Daten, sFlow-Daten, RUM-Daten (Real User Management) sowie Peering-Beziehungs- und Routing-Daten an Elasticsearch konnte ein wesentlich detaillierteres Bild der Nutzungserlebnis- und System-Performance-Daten gewonnen werden. Dieser Grad an Detailliertheit lässt sich nur erreichen, wenn man all die verschiedenen Datenquellen auf einmal analysiert. Seither ist GoDaddy einen Schritt weiter gegangen und setzt jetzt zur Analyse auch <a href="/de/products/stack/machine-learning">Elastic-Machine-Learning</a>-Funktionen ein.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb09951bb4979ea15/5c304e986e9992e16f52993d/go_daddy_RUM.jpg" data-sys-asset-uid="bltb09951bb4979ea15" style="display: block; margin: auto;">
Während ein zentralisierter Zugriff auf haufenweise Systemdaten zweifelsohne eine schöne Sache ist, kann sich das Aufspüren von Problemen schnell als Problem erweisen. GoDaddy verfolgt zwar jeden Klick und jede Website-Interaktion, aber bei Millionen von Seiten, verteilt über die ganze Welt, ist es schlicht unmöglich, alle Daten von menschlichen Teams durchsehen zu lassen. Hier kommen die Machine-Learning-Funktionen von Elastic ins Spiel – mit ihnen wird die Anomalieerkennung fast schon zum Kinderspiel. Zusammen mit den Machine-Learning-Experten von Elastic gelang es GoDaddy, RUM-fokussierte Machine-Learning-Jobs zu implementieren, die die Anomalieerkennung vereinfacht haben.
<blockquote>„Wer seinen Gesamtaufwand verringern möchte, sollte sich das Elastic-Team ins Boot holen. Die Experten dort sind außerordentlich hilfreich. Wir haben sehr partnerschaftlich zusammengearbeitet, oft miteinander geredet und die komplett offenen Kommunikationswege im Zusammenhang mit allen Updates genossen. Es wird nicht alles glattlaufen, aber das Team steht bereit zu helfen. Und das kann es richtig gut.“ – Felix Gorodishter, Principal Architect, GoDaddy
</blockquote>Das GoDaddy-Team hat einen Grenzwert für Seitenladezeiten sowie Parameter für den Seiten-Traffic festgelegt und überlässt nun den Elastic-Machine-Learning-Funktionen zu lernen, was normal und was als Anomalie zu betrachten und daher als Problem zu melden ist. Machine Learning übernimmt das Aussortieren und GoDaddy kann sich auf das konzentrieren, was wichtig ist.
Wenn Sie mehr darüber erfahren möchten, wie GoDaddy die Machine-Learning-Funktionen von Elastic nutzt, um die Performance gehosteter Websites zu überwachen, sehen Sie sich die Präsentation <a href="/de/elasticon/conf/2018/sf/stories-from-the-trenches-at-godaddy-how-big-data-insights-equal-big-money">Stories from the Trenches at GoDaddy: How Big Data Insights Equal Big Money</a> an, die auf der <a href="/de/elasticon/conf/2018/sf">Elastic{ON} 2018</a> gehalten wurde. Darin erfahren Sie auch etwas über die interessanten Methoden, mit denen GoDaddy Machine Learning für das Monitoring von Geschäfts-KPIs rund um Produktübernahmen verwendet und welche Erfahrungen dabei gemacht wurden.
<a href="/de/elasticon/conf/2018/sf/stories-from-the-trenches-at-godaddy-how-big-data-insights-equal-big-money"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1004b59c5e7fde10/5c304e93ad674d236e76489e/go_daddy_cohort_ml.jpg" data-sys-asset-uid="blt1004b59c5e7fde10" alt="" style="display: block; margin: auto;"></a>

go_daddy_banner.jpg

go_daddy_thumb.jpg

Improving the GoDaddy User Experience with Elastic Machine Learning

Elastic Machine Learning hilft GoDaddy, das Nutzungserlebnis zu verbessern

Hier erfahren Sie, warum der Fahrdienstvermittler Lyft mithilfe von Self-Managed Elasticsearch Verantwortung für die eigene Vorgangsprotokolllösung übernommen

Dieser Blogpost ist eine Zusammenfassung eines Anwendertalks bei der <a href="/de/elasticon/conf/2018/sf">Elastic{ON} 2018</a>. Sind Sie an ähnlichen Talks wie diesem interessiert? Schauen Sie sich im Konferenzarchiv um oder informieren Sie sich über anstehende <a href="/de/elasticon">Elastic{ON} Tour</a>-Termine in Ihrer Nähe.
Wenn Sie mehr über die Unterschiede zwischen dem Amazon Elasticsearch Service und unserem offiziellen Elasticsearch Service erfahren möchten, sehen Sie sich unseren <a href="/de/aws-elasticsearch-service#full-comparison">AWS-Elasticsearch-Vergleich</a> an.
Der Fahrdienstvermittler Lyft benötigt eine leistungsstarke Technologieinfrastruktur, um jedes Jahr weltweit Hunderte von Millionen Fahrten abzuwickeln und um sicherzustellen, dass alle Kunden an ihr gewünschtes Ziel gelangen. Allein im Jahr 2017 waren es mehr als 375&nbsp;Millionen Fahrten und dies bedeutete mehr als 200&nbsp;Microservices, die über mehr als 10.000 EC2-Instanzen verteilt waren. An Tagen wie Silvester (mit mehr als 2&nbsp;Millionen Fahrten an einem Tag) und Halloween (mit mehr als 2.000&nbsp;Fahrten pro Minute in Spitzenzeiten) schnellten die Zahlen in die Höhe. Für eine reibungslose Abwicklung der Fahrten und für den unterbrechungsfreien Betrieb der Systeme ist es unerlässlich, dass die Ingenieure von Lyft Zugriff auf alle Vorgangsprotokolle haben. Aus diesem Grund müssen Michael Goldsby und sein Observability-Team dafür sorgen, dass ihr Protokoll-Pipelinedienst unterbrechungsfrei läuft. 
Zu Beginn der Protokollanalyse bei Lyft nutzen sie Splunk Cloud als ihren Serviceanbieter. Doch die vertraglich festgelegten Aufbewahrungslimits, Ingestbackups von bis zu 30&nbsp;Minuten in Spitzenzeiten und die mit der Skalierung verbundenen Kosten veranlassten Lyft dazu, zu Elasticsearch zu wechseln.
Ende&nbsp;2016 gelang es einem Team aus zwei Ingenieuren, Lyft innerhalb von einem Monat von Splunk zu Amazon Elasticsearch Service auf AWS zu migrieren. Die Migration zu Elasticsearch war ein Erfolg, einige Teile des AWS-Angebots erfüllten jedoch nicht alle Ansprüche. So wünschte das Team um Michael Goldsby beispielsweise ein Upgrade auf Elasticsearch&nbsp;5.x, doch AWS bot zu dieser Zeit nur die Version&nbsp;2.3 an. Darüber hinaus war die Speicherung für neue Instanzen auf Amazon EBS beschränkt, was bei der von Lyft benötigten Größenordnung nur suboptimale Ergebnisse im Hinblick auf Leistung und Zuverlässigkeit lieferte. Zudem waren auch nicht alle Elasticsearch API auf AWS verfügbar. Doch trotz dieser AWS-Einschränkungen überwogen die Vorteile der Migration von Splunk Cloud zu Amazon Elasticsearch Service auf AWS.
Nachdem die Ingestlimits aufgehoben (oder zumindest drastisch reduziert) worden waren, entschied sich das Observability-Team zu mehr Offenheit und einem völlig neuen Ansatz: „Senden Sie uns all Ihre Protokolle“. Auf diese Weise erhöhten sich die Ingest-Raten schnell von 100.000&nbsp;Ereignissen pro Minute auf 1,5&nbsp;Millionen Ereignisse pro Minute. Dieser neue Ansatz war vier&nbsp;Monate lang erfolgreich. Als Probleme mit Ingesttimeouts, geringerer Aufbewahrung oder langsamen Kibana-Dashboards auftraten, musste das Team um Michael Goldsby lediglich ein Scale-up durchführen. Und als das AWS-Knotenlimit von 20&nbsp;Knoten erreicht wurde, wurde Lyft eine spezielle Ausnahme gewährt, mit der das Limit auf 40&nbsp;Knoten erhöht wurde.
Doch selbst mit 40&nbsp;Knoten traten Probleme auf: Probleme im Zusammenhang mit roten Clustern.
Michael Goldsbys Team wusste jedoch, wie sie Probleme im Zusammenhang mit roten Clustern beheben konnten (Neustart, Ersetzen von Knoten usw.). Das eigentliche Problem bestand darin, dass sie keinen direkten Zugriff auf ihre Cluster hatten. Stattdessen mussten sie ein Ticket auf Amazon öffnen und dabei manchmal, während der Spitzenzeiten für den Support, stundenlang warten. Dann musste das Ticket eskaliert werden, weil die ersten Ansprechpartner im Support nicht auf die Cluster zugreifen konnten. Mit der Zeit lernte das Lyft-Team, dass sie den Eskalationsvorgang beschleunigen konnten, indem sie sich direkt an ihren Technical Account Manager (TAM) wandten. Der TAM sorgte dann dafür, dass das Cluster wieder in den grünen Zustand gelangte.
In Anbetracht der unvermeidbaren Supportmaßnahmen, der Beschränkung auf die Version&nbsp;2.3, der EBS-Anforderung und anderer durch AWS verursachten Einschränkungen (Roundrobin-Lastenausgleich, 60-Sekunden-Timeouts, API-Obfuskation usw.) entschied sich das Observability-Team zu einer erneuten Migration – dieses Mal zu einem Self-Managed Elasticsearch-Deployment. „[Auf AWS] stehen uns nicht alle Funktionen zur Verfügung. Es ist nicht möglich, alle Schaltflächen auszuwählen“, sagte Michael Goldsby. „Wir wussten, dass wir intern genügend praktische Erfahrungen mit Elasticsearch hatten, ... um es durchzuziehen.“
Mit einem etwas größeren Team als bei der Splunk-Migration war Lyft in der Lage, innerhalb von nur zwei Wochen von Amazon Elasticsearch Service zu Self-Managed Elasticsearch zu migrieren. Nun verfügen sie über ihr eigenes Deployment sowie über all die Funktionen, die ihnen zuvor in AWS vorenthalten waren. Dies bedeutet auch, dass sie für alle betrieblichen Aspekte des Elastic&nbsp;Stack verantwortlich sind, einschließlich der Aufrechterhaltung des grünen Zustands ihrer Cluster und der Zufriedenheit ihrer Anwender (ihrer Kollegen und Kolleginnen).
Schauen Sie sich den auf der <a href="/de/elasticon">Elastic{ON} 2018</a> gehaltenen Talk <a href="/de/elasticon/conf/2018/sf/lyfts-wild-ride-from-amazon-es-to-self-managed-elasticsearch">Lyft's Wild Ride from Amazon ES to Self-Managed Elasticsearch for Operational Log Analytics</a> an, um mehr darüber zu erfahren, wie das Self-Managed Elasticsearch-Deployment bei Lyft implementiert wurde. Sie erfahren alles über die Hardwareauswahl sowie über die Entscheidungen hinsichtlich des Index-Lifecycle-Managements und vieles mehr – u.&nbsp;a. auch, warum „alles protokollieren“ nicht das Gleiche ist wie „irgendetwas protokollieren“ („log everything ≠ log anything“).
<a href="/de/elasticon/conf/2018/sf/lyfts-wild-ride-from-amazon-es-to-self-managed-elasticsearch"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt666fd2101df677e6/5c57e1848c741b010cbf6af9/lyft_thumb_play.jpg" data-sys-asset-uid="blt666fd2101df677e6" alt="lyft_thumb_play.jpg" style="display: block; margin: auto;"></a>

lyft_banner.jpg

lyft_thumb.jpg

Operational Logging at Lyft: Migrating from Splunk Cloud to Amazon ES to Self-Managed Elasticsearch

Vorgangsprotokollierung beim Fahrdienstvermittler Lyft: Migration von Splunk Cloud über Amazon ES zu Self-Managed Elasticsearch

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Tony Sleva

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/elastic-cloud-account-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">ausgewählte Nachrichten und Informationen</a> an die oben von Ihnen bereitgestellten Kontaktangaben zu senden. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/serverless-preview-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

Beim Absenden akzeptieren Sie die <a href="/de/agreements/global/cloud-services-monthly" rel="nofollow">Nutzungsbedingungen von Elastic Cloud</a>. Die Verarbeitung Ihrer personenbezogenen Daten unterliegt der <a href="/de/legal/privacy-statement">Datenschutzerklärung von Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/terms-of-use" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

Der Inhalt dieser Seite ist in der ausgewählten Sprache nicht verfügbar. Wir bei Elastic arbeiten daran, die bereitgestellten Inhalte in verschiedenen Sprachen anzubieten. Bis dahin bitten wir Sie um etwas Geduld und hoffen auf Ihr Verständnis!

Author

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Articles by

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Sie können nicht dabei sein? Registrieren Sie sich, damit wir Ihnen die Aufzeichnung zukommen lassen können. Außerdem erhalten Sie eine E‑Mail mit Begleitmaterial.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Learn More

Read less

You'll also receive an email with related content

Wir schicken Ihnen zudem relevante Informationen, die von Interesse sein könnten.

Thank you for registering. We will send you a confirmation email soon.

Vielen Dank für Ihre Registrierung. Sie erhalten in Kürze eine Bestätigungs-E‑Mail von uns.

Author

Articles by Tony Sleva

Elastic Machine Learning hilft GoDaddy, das Nutzungserlebnis zu verbessern

Vorgangsprotokollierung beim Fahrdienstvermittler Lyft: Migration von Splunk Cloud über Amazon ES zu Self-Managed Elasticsearch

Sign up for Elastic Cloud free trial