Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Hystrix + ELK
Markus Rodi
Karlsruhe, 29.01.2015
2
1. Hystrix
2. Use Cases
3. Problemstellungen
4. Hystrix Dashboard
5. Architektur
6. Softwarekomponenten
7. Konfiguration...
3
●
Implementierung von Patterns zur Ausfallsicherheit
- Graceful Degradation
- Fail Fast
- Fail Silent
- Circuit Breaker
...
4
●
Empfehlungen für Kunden durch externes System
●
Fehler/Timeouts schlagen sofort auf der Webseite auf
Lösung mit Hystri...
5
●
Begrenzte Ressourcen werden gebunden
●
Aufwand für Connection-Handling steigt rapide
●
z.B.: DB Verbindungen werden fü...
6
●
Hystrix bietet eine Echtzeit-API aber keine Historisierung
●
Dashboard bietet nur eine Übersicht der letzten 2 Minuten...
7
●
Datenmenge für klassisches Monitoring (Zabbix, Nagios) nicht zu bewältigen
- 50 Werte pro Komponente
- 12 Werte pro Th...
8
Hystrix
Das Dashboard
9
Arichtektur
Dezentral
10
Arichtektur
Zentral
11
●
Ausrollen der Pakete und Konfigs per Puppet
●
Software-Stack:
- ELK
- Tomcat
- hystrix-dashboard.war
- trubine.war
- ...
12
data: {"type":"HystrixThreadPool",
"name":"PlaybackGroup",
"currentActiveCount":0,
"currentCompletedTaskCount":0,
"curr...
13
Logstash Konfiguration
Die Magie
input {
pipe {
type => "short"
tags => ["mw-01"]
command => "curl -s --url 'http://my....
14
Kibana
Das Ergebnis
15
Kibana
Verbindungsdaten zu externen Dienstleister
16
Kibana
CircuitBreakerOpen
17
Kibana
CircuitBreakerOpen
18
●
Schnell und einfach aufzusetzen
●
Datenmenge nicht unterschätzen
●
Skalierung sehr einfach
●
Redis als Cache um Daten...
19
Kontakt
Markus Rodi
Linux System Engineer
inovex GmbH
Office Karlsruhe
Ludwig-Erhard-Allee 6
76131, Karlsruhe
Mobil: 01...
Nächste SlideShare
Wird geladen in …5
×

Hystrix + ELK - Event-basierte Daten != Logfiles in ELK

1.229 Aufrufe

Veröffentlicht am

Ein typischer und etablierter Use-Case für ELK ist das prozessieren, aggregieren und analysierbar machen diverser Logfiles. Aber ELK kann prinzipiell für alle möglichen, event-basierte Daten (strukturiert oder unstrukturiert) verwendet werden. Wir werden an Hand von zwei Projekten betrachten.

• ELK und JMeter

• ELK und Hystrix

Um es vorweg zu nehmen: ja, es geht und ELK rockt ;)

Der Vortrag wurde beim inovex Search-Meetup in Karlsruhe am 29.01.2015 gehalten.
Speaker: Markus Rodi (inovex)

Mehr inovex-Meetups:
Karlsruhe: http://www.meetup.com/inovex-karlsruhe/
Köln: http://www.meetup.com/inovex-cologne
München: http://www.meetup.com/inovex-munich/

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Hystrix + ELK - Event-basierte Daten != Logfiles in ELK

  1. 1. Hystrix + ELK Markus Rodi Karlsruhe, 29.01.2015
  2. 2. 2 1. Hystrix 2. Use Cases 3. Problemstellungen 4. Hystrix Dashboard 5. Architektur 6. Softwarekomponenten 7. Konfiguration 8. Kibana Dashboards 9. Fazit und Ausblick Agenda
  3. 3. 3 ● Implementierung von Patterns zur Ausfallsicherheit - Graceful Degradation - Fail Fast - Fail Silent - Circuit Breaker - Bulkheading Hystrix Was ist das überhaupt?
  4. 4. 4 ● Empfehlungen für Kunden durch externes System ● Fehler/Timeouts schlagen sofort auf der Webseite auf Lösung mit Hystrix: ● Fallback auf lokales System ● Empfehlungen werden von statischen Regeln erstellt Use Case Kundenspezifische Empfehlungen
  5. 5. 5 ● Begrenzte Ressourcen werden gebunden ● Aufwand für Connection-Handling steigt rapide ● z.B.: DB Verbindungen werden für andere Dienste blockiert Lösung mit Hystrix: ● Direkte Fehlerrückgabe ● Verhindert weitere Laufzeitprobleme Use Case Fehler-Kaskaden
  6. 6. 6 ● Hystrix bietet eine Echtzeit-API aber keine Historisierung ● Dashboard bietet nur eine Übersicht der letzten 2 Minuten ● Keine Filtermöglichkeit ● Keine Möglichkeit zur schrittweisen Verfeinerung der Analyse Problemstellungen Historie und Analyse
  7. 7. 7 ● Datenmenge für klassisches Monitoring (Zabbix, Nagios) nicht zu bewältigen - 50 Werte pro Komponente - 12 Werte pro Threadpool => bei 10 Komponenten + 3 Threadpools ca. 2 Mio Events/Stunde/Server ● Datenmenge wächst proportional zu: - Anzahl der Server - Anzahl der Komponenten Problemstellungen Datenmenge
  8. 8. 8 Hystrix Das Dashboard
  9. 9. 9 Arichtektur Dezentral
  10. 10. 10 Arichtektur Zentral
  11. 11. 11 ● Ausrollen der Pakete und Konfigs per Puppet ● Software-Stack: - ELK - Tomcat - hystrix-dashboard.war - trubine.war - nginx - Kibana ● Types long/short → aggregierte Streams/einzelne Streams Softwarekomponenten Wie läuft das denn?
  12. 12. 12 data: {"type":"HystrixThreadPool", "name":"PlaybackGroup", "currentActiveCount":0, "currentCompletedTaskCount":0, "currentCorePoolSize":10, "currentLargestPoolSize":0, "currentMaximumPoolSize":10, "currentPoolSize":0, "currentQueueSize":0, "currentTaskCount":0," ...} Hystrix Event Stream Die Basis
  13. 13. 13 Logstash Konfiguration Die Magie input { pipe { type => "short" tags => ["mw-01"] command => "curl -s --url 'http://my.server/hystrix.stream' | cut -c 7- | sed 's/type/hystrixType/g'" codec => json {} }
  14. 14. 14 Kibana Das Ergebnis
  15. 15. 15 Kibana Verbindungsdaten zu externen Dienstleister
  16. 16. 16 Kibana CircuitBreakerOpen
  17. 17. 17 Kibana CircuitBreakerOpen
  18. 18. 18 ● Schnell und einfach aufzusetzen ● Datenmenge nicht unterschätzen ● Skalierung sehr einfach ● Redis als Cache um Datenverlust zu vermeiden ● Curl ersetzen durch Programmierung auf Hystrix API Fazit und Ausblick
  19. 19. 19 Kontakt Markus Rodi Linux System Engineer inovex GmbH Office Karlsruhe Ludwig-Erhard-Allee 6 76131, Karlsruhe Mobil: 0173-3181-063 Mail: markus.rodi@inovex.de Vielen Dank für Ihre Aufmerksamkeit!

×