LOGOWANIE ZDARZEŃ W ARCHITEKTURZE OPARTEJ NA MIKROSERWISACH Wzrost popularności architektur opartych na mikroserwisach skutecznie wystawia na próbę sposób, w jaki aplikacje rejestrują swoje zdarzenia. Bez przemyślanego podejścia łatwo doprowadzić do sytuacji, w której jakikolwiek troubleshooting okazuje się praktycznie niemożliwy. Podczas prezentacji przedstawimy zestaw narzędzi przydatnych w zarządzaniu logami generowanymi w środowiskach, w których pracuje wiele niezależnych aplikacji bądź systemów. Zademonstrujemy w praktyce wykorzystanie zestawu narzędzi Logstash, Elasticsearch oraz Kibana, a także wskażemy dostępne dla nich alternatywy. Opowiemy o rejestrowaniu metryk aplikacyjnych w bazach danych typu time-series, takich jak Graphite czy InfluxDB. Zahaczymy o kwestię wykorzystania tych narzędzi również do celów innych aniżeli rejestrowanie zdarzeń. Pokażemy również, w jaki sposób zmieniają się trendy co do sposobu logowania zdarzeń z aplikacji. Podpowiemy także, w jaki sposób rejestrować zdarzenia tak, aby nasza aplikacja była prostsza w utrzymaniu oraz by ułatwić rozwiązywanie potencjalnych problemów.

1. Logowanie zdarzeń w
architekturze opartej na
mikroserwisach
Paweł Grajewski
Łukasz Kamiński
Twitter: https://twitter.com/bms_devs
GitHub: https://github.com/bms-devs

2. Problem?
Serwer
App 3
App 2
…
App 1
Serwer
App 3
App 2
…
App 1
…
Serwer
App 3
App 2
…
App 1
ssh…? kopiowanie plików…?

3. Zdarzenia

4. Stos ELK
Serwer
App 1
App 2
…
Serwer
App 1
App 2
…

5. Logstash

6. Logstash
• Najprostsza konfiguracja:
input {
file {
path => “/some/logs/dir/*.log”
codec => "plain"
}
}
output {
elasticsearch {
host => es
port => 9300
cluster => "elk"
protocol => "transport"
}
}

7. Logstash
• Analiza logów tekstowych:

8. Structured logging
• Zamiast:
POST http://audit.service/trail (status:200 time:1.172s
correlationId:091dd542-ea27-46a2-a1c6-3c9111d2d9b9)
• Możemy użyć np. formatu JSON:
{
"app":"audit",
"method":"POST",
"url":"http://audit.service/trail",
"status":200,
"time":1.172,
"correlationId":"caaec80c-736e-4a42-954a-cb6748cdc9d7"
}

9. Kibana

10. Logstash
• Wiele węzłów generujących zdarzenia:
• broker np. Redis
• logstash-forwarder

11. The Twelve-Factor App
•

12. Logowanie przez sieć
• Syslog Protocol
• Text or JSON over TCP/UDP
• GELF (Graylog Extended Log Format)
• Wsparcie narzędziowe:
• logback-syslog4j, logback-gelf
• logstash-logback-encoder, gelfclient

13. Metryki

14. “If you can not
measure it, you can
not improve it.”

15. Po co zbieramy metryki?
• DevOps - monitorowanie stanu zdrowia
infrastruktury, wyszukiwanie słabych punktów,
reakcja na zwiększenie ruchu, etc.
• Business - śledzenie zachowań użytkowników,
zbieranie statystyk wartościowych z punktu
widzenia biznesu

16. Jakie metryki możemy
gromadzić?
App
https://www.datadoghq.com/blog/monitoring-101-collecting-data/

17. Które z metryk chcemy lub
powinniśmy gromadzić?

18. Które z metryk chcemy lub
powinniśmy gromadzić?

19. Narzędzia
App
Transmitter
App
Transmitter
App
Transmitter
Metrics Metrics
Data

20. Narzędzia
App
Transmitter
App
Transmitter
App
Transmitter
Metrics Metrics
Data
Graphite
fluentd StatsD PypeD
Whisper
+
Carbon
CollectD Telegraf

21. Narzędzia
App
Transmitter
App
Transmitter
App
Transmitter
Metrics Metrics
Data
StatsD
Graphite
fluentd StatsD PypeD
Whisper
+
Carbon
CollectD Telegraf

22. Bazy time-series
SQL
InfluxDB
indeksowane

23. Bazy time-series
• Analiza danych w locie
• Interfejs do przeglądania danych
• język zapytań
• generator wykresów

24. InfluxDB
Język zapytań
"SQL-like"

25. Analiza danych z Grafaną

26. Podsumowanie
• Istnieje darmowy, sprawdzony zestaw narzędzi
do zbierania zdarzeń i metryk z wielu aplikacji.
• Ich zastosowanie niesamowicie upraszcza
rozwiązywanie problemów; nie dowiecie się
dopóki nie spróbujecie ich wdrożyć!
• Nie należy bać się zbierania metryk, korzystając
z odpowiednich narzędzi można otrzymać duże
możliwości praktycznie za darmo (np. Spring Boot,
Spring Cloud).

27. Pytania?