Najlepsza architektura rejestrowania Docker przy użyciu stosu ELK

Question

Ostatnio próbuję znaleźć najlepszy mechanizm rejestrowania Docker przy użyciu stosu ELK. Mam kilka pytań dotyczących najlepszego przepływu pracy, jaki firmy wykorzystują w produkcji. Nasz system ma typowy stos oprogramowania, w tym Tomcat, PostgreSQL, MongoDB, Nginx, RabbitMQ, Couchbase itp. Na razie nasz stos działa w klastrze CoreOS. Proszę znaleźć moje pytania poniżej

1. jaka jest najlepsza metodologia do przesyłania logów - czy powinienem używać Lumberjack? Pytam o to, ponieważ widziałem przepływ pracy, w którym ludzie używają Syslog/Rsyslog do przekazywania dzienników do logstash.
2. Ponieważ wszystkie nasze elementy oprogramowania są konteneryzowane, czy powinienem zawrzeć Log-forwarder we wszystkich swoich kontenerach? Planuję to zrobić, ponieważ większość moich kontenerów przełącza węzły na podstawie stanu zdrowia, więc nie jestem zainteresowany instalowaniem systemu plików z kontenera do hosta.
3. Czy powinienem używać redis jako brokera do przesyłania dzienników? Jeśli tak, dlaczego?
4. Jak trudno jest napisać pliki log-config, które definiują format dziennika, który ma być przekazywany do log-stash?

To są subiektywne pytania, ale jestem pewien, że jest to problem, który ludzie rozwiązali dawno temu i nie jestem zainteresowany ponownym wynalezieniem koła.

Answer 1

Dobre pytania, a odpowiedź jak w wielu innych przypadkach - "to zależy".

1. Logi wysyłki - stosujemy rsyslog jako pojemniki Döcker wewnątrz i logstash-spedytora w niektórych przypadkach - zaletą logstash-spedytora jest to, że szyfruje dzienniki i kompresuje je więc w niektórych przypadkach, że to ważne. Uważam, że rsyslog jest bardzo stabilny i ma mało zasobów, więc używamy go jako domyślnego nadawcy. Pełny plik logstash może być ciężki dla małych maszyn (trochę więcej danych o logstash - http://logz.io/blog/5-logstash-pitfalls-and-how-to-avoid-them/)

2. Jesteśmy również w pełni zdeizeryzowani i używamy osobnego Dockera dla każdego rsyslog/lumberjack. Łatwy w utrzymaniu, aktualizacji wersji i poruszania się w razie potrzeby.

3. Tak, zdecydowanie używaj Redis. Napisałem bloga o tym, jak zbudować produkcję ELK (http://logz.io/blog/deploy-elk-production/) - mówiłem o tym, co uważam za odpowiednią architekturę do wdrożenia ELK w produkcji

4. Nie jestem pewien, co dokładnie chcesz osiągnąć dzięki temu.

HTH

Answer 2

Docker począwszy od sierpnia 2015 roku, ma "Logging Driver", dzięki czemu można wysyłać dzienniki w innych miejscach. Jest to obsługiwany sposób zdalnego wysyłania dzienników.

• syslog
• fluentd
• journald
• GELF
• etc ..

Answer 3

Polecam przed uruchomieniem spedytora zalogowaniu się do każdego Docker obrazu.To dodaje niepotrzebnej złożoności i przydaje się do twoich kontenerów Docker. Czyściejszym rozwiązaniem jest umieszczenie programu do przesyłania dzienników (najnowszy program do przesyłania dzienników z firmy Elastic o numerze FileBeat, który zastępuje forwarder programu logstash) do własnego kontenera i zamontowanie katalogu komputera hosta o numerze /var/lib/docker jako woluminu dla tego kontenera.

docker run --detach --name=docker-filebeat -v /var/lib/docker:/var/lib/docker

/var/lib/docker zawiera wszystkie dzienniki dla każdego pojemnika z systemem na Docker demon gospodarza. Dane plików dziennika w tym katalogu to te same dane, które można uzyskać, uruchamiając docker logs <container_id> na każdym kontenerze.

Następnie w pliku konfiguracyjnym filebeat.yml, umieścić:

filebeat: 
    prospectors: 
    - 
     paths: 
     - /var/lib/docker/containers/*/*.log 

Następnie config Filebeat do przekazania do końca swojego ELK stosie i zacząć pojemnik. Wszystkie dzienniki kontenera Docker na tym komputerze zostaną automatycznie przesłane do stosu ELK.

Fajną rzeczą w tym podejściu jest to, że pozwala to na dalsze przekazywanie pozostałych logów systemu hosta, jeśli chcesz. Po prostu dodaj kolejny wolumin, wskazując pliki dziennika systemu hosta, które chcesz przekazać dalej, i dodaj tę ścieżkę również do swojej konfiguracji filebeat.yml.

Metoda ta jest czystsza i bardziej elastyczna niż inne metody, takie jak używanie sterowników rejestrowania Docker, ponieważ pozostała część konfiguracji Docker pozostaje taka sama. Nie ma potrzeby dodawania flag sterownika rejestrowania do każdego polecenia uruchomienia Docker (lub do parametrów demona Docker).