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

781 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
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

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

Keine Downloads
Aufrufe
Aufrufe insgesamt
781
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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!

×