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/

1. Hystrix + ELK
Markus Rodi
Karlsruhe, 29.01.2015

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
●
Implementierung von Patterns zur Ausfallsicherheit
- Graceful Degradation
- Fail Fast
- Fail Silent
- Circuit Breaker
- Bulkheading
Hystrix
Was ist das überhaupt?

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
●
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
●
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
●
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
Hystrix
Das Dashboard

9. 9
Arichtektur
Dezentral

10. 10
Arichtektur
Zentral

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
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
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
Kibana
Das Ergebnis

15. 15
Kibana
Verbindungsdaten zu externen Dienstleister

16. 16
Kibana
CircuitBreakerOpen

17. 17
Kibana
CircuitBreakerOpen

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
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!