Prosty mechanizm, który zabezpieczy Ci kolektor logów np. Logstash

Planując system bierzemy pod uwagę ewentualne awarie (Design for Failure). W przypadku agregacji logów, oprócz rozwiązań typu Elasticsearch czy Splunk, korzystamy również z kolejek np. Apache Kafka. Działa w klastrze, pełni rolę bufora i pozwala na zastosowanie wielu konsumentów typu Logstash lub Fluentd. Czasami jednak zapominamy o zabezpieczeniu kolektora, który zasila kolejkę. W tym wpisie dowiesz się jak użyć keepalived, by zapewnić failover.

Plan

Załóżmy, że zbieramy syslog z końcówek po UDP i wrzucamy go na Apache Kafka. Wszystko wydaje się piękne i przemyślane. Niestety, jak padnie nam Log Shipper (np. pojedyncza instancja Logstash), to mamy problem.

Dlatego potrzebujemy więcej niż jednego Logstash’a. Gdyby logi wysyłały Beats’y, które potrafią rozmawiać z wieloma Logstash’ami, problemu by nie było. W tym przypadku wykorzystamy aplikację keepalived implementującą protokół VRRP na dwóch Ubuntu.

Logi będą wysyłane na dynamiczne/pływające IP. To, do której maszyny trafi ruch, będzie zależeć od konfiguracji keepalived. Pierwsza maszyna będzie główną (master), druga zapasową (backup). Jeśli jest taka potrzeba, zapasowych może być więcej. Czasami maszyna działa, a logstash nie, więc dodamy też prosty skrypt, który będzie informował keepalived o gotowości do działania.

Implementacja

Czy logstash działa?

Keepalived musi wiedzieć, czy Logstash żyje i funkcjonuje. Sam PID procesu to za mało, więc wykorzystamy jego API z metrykami. Domyślnie jest to port 9600.

#!/bin/bash
logstash_response="$(curl --silent localhost:9600)"
if echo $logstash_response | grep -q '"status":"green"'
then
        echo "Logstash is green. It's ok :-)"
        exit 0
else
        echo "Logstash is not green :-( plz help"
        exit 1
fi

Zasada działania jest prosta. Jak grep znajdzie w odpowiedzi “status”:”green” to znaczy, że działa.

Konfiguracja keepalived

Maszyna nr 1 (master)

global_defs {
  enable_script_security
}

vrrp_script chk_logstash {
  script       "/etc/keepalived/logstash_check.sh" # path of the script to execute
  interval 1   # seconds between script invocations
  timeout 1    # seconds after which script is considered to have failed
}

vrrp_instance VI_1 {
  interface ens33
  state MASTER
  virtual_router_id 51
  priority 101
  virtual_ipaddress {
    192.168.1.10
  }
  track_script {
    chk_logstash
  }
}

Używanie skryptów przez keepalived wymaga użytkownika keepalived_script w systemie i włączenie script_security. Różnica między configiem master i backup to priority (master musi mieć większy) i state. Oba configi muszą mieć ten sam virtual_router_id.

Maszyna nr 2 (backup)

global_defs {
  enable_script_security
}

vrrp_script chk_logstash {
  script       "/etc/keepalived/logstash_check.sh" # path of the script to execute
  interval 1   # seconds between script invocations
  timeout 1    # seconds after which script is considered to have failed
}

vrrp_instance VI_1 {
  interface ens33
  state BACKUP
  virtual_router_id 51
  priority 100
  virtual_ipaddress {
    192.168.1.10
  }
  track_script {
    chk_logstash
  }
}

Keepalived w akcji

Logi keepalived z perspektywy maszyny backup. W pierwszej maszynie wyłączam logstasha, a backup przechodzi w tryb master.

Jak to skalować?

W przypadku UDP nie możemy zastosować HAProxy. Jedną z opcji jest dołożenie maszyn, skopiowanie rozwiązania na drugi wirtualny adres IP i konfiguracja części źródeł by wysyłały UDP na nowy adres. W ten sposób z rozwiązania active-passive utworzymy rozwiązanie active-active.

Znasz lepszy sposób? Podziel się w komentarzu ?.