Splunk to jeden z kilku najbardziej rozpoznawalnych komercyjnych produktów do gromadzenia i analizy logów. Nawet teraz, gdy nie prowadzi się już sprzedaży w Rosji, nie jest to powód, aby nie pisać instrukcji/poradników dla tego produktu.
Zadanie: zbiera logi systemowe z węzłów dokowanych w Splunk bez zmiany konfiguracji komputera hosta
Chciałbym zacząć od oficjalnego podejścia, które wygląda dziwnie podczas korzystania z okna dokowanego.
Co my mamy:
1. Wygląd Pullima
$ docker pull splunk/universalforwarder:latest2. Uruchamiamy kontener z niezbędnymi parametrami
$ docker run -d -p 9997:9997 -e 'SPLUNK_START_ARGS=--accept-license' -e 'SPLUNK_PASSWORD=<password>' splunk/universalforwarder:latest3. Wchodzimy do pojemnika
docker exec -it <container-id> /bin/bashNastępnie jesteśmy proszeni o udanie się pod adres znany z dokumentacji.
I skonfiguruj kontener po jego uruchomieniu:
./splunk add forward-server <host name or ip address>:<listening port>
./splunk add monitor /var/log
./splunk restart
Czekać. Co?
Ale to nie koniec niespodzianek. Jeśli uruchomisz kontener z oficjalnego obrazu w trybie interaktywnym, zobaczysz następujące informacje:
Trochę rozczarowania
$ docker run -it -p 9997:9997 -e 'SPLUNK_START_ARGS=--accept-license' -e 'SPLUNK_PASSWORD=password' splunk/universalforwarder:latest
PLAY [Run default Splunk provisioning] *******************************************************************************************************************************************************************************************************
Tuesday 09 April 2019 13:40:38 +0000 (0:00:00.096) 0:00:00.096 *********
TASK [Gathering Facts] ***********************************************************************************************************************************************************************************************************************
ok: [localhost]
Tuesday 09 April 2019 13:40:39 +0000 (0:00:01.520) 0:00:01.616 *********
TASK [Get actual hostname] *******************************************************************************************************************************************************************************************************************
changed: [localhost]
Tuesday 09 April 2019 13:40:40 +0000 (0:00:00.599) 0:00:02.215 *********
Tuesday 09 April 2019 13:40:40 +0000 (0:00:00.054) 0:00:02.270 *********
TASK [set_fact] ******************************************************************************************************************************************************************************************************************************
ok: [localhost]
Tuesday 09 April 2019 13:40:40 +0000 (0:00:00.075) 0:00:02.346 *********
Tuesday 09 April 2019 13:40:40 +0000 (0:00:00.067) 0:00:02.413 *********
Tuesday 09 April 2019 13:40:40 +0000 (0:00:00.060) 0:00:02.473 *********
Tuesday 09 April 2019 13:40:40 +0000 (0:00:00.051) 0:00:02.525 *********
Tuesday 09 April 2019 13:40:40 +0000 (0:00:00.056) 0:00:02.582 *********
Tuesday 09 April 2019 13:40:41 +0000 (0:00:00.216) 0:00:02.798 *********
included: /opt/ansible/roles/splunk_common/tasks/change_splunk_directory_owner.yml for localhost
Tuesday 09 April 2019 13:40:41 +0000 (0:00:00.087) 0:00:02.886 *********
TASK [splunk_common : Update Splunk directory owner] *****************************************************************************************************************************************************************************************
ok: [localhost]
Tuesday 09 April 2019 13:40:41 +0000 (0:00:00.324) 0:00:03.210 *********
included: /opt/ansible/roles/splunk_common/tasks/get_facts.yml for localhost
Tuesday 09 April 2019 13:40:41 +0000 (0:00:00.094) 0:00:03.305 *********
ну и так далее...
Świetnie. Na obrazie nie ma nawet artefaktu. Oznacza to, że przy każdym uruchomieniu pobranie archiwum z plikami binarnymi, rozpakowanie i konfiguracja zajmie trochę czasu.
Ale co z dokowaniem i tak dalej?
Nie, dziękuję. Pójdziemy w drugą stronę. A co jeśli wszystkie te operacje wykonamy już na etapie montażu? Więc chodźmy!
Aby nie zwlekać długo, od razu pokażę ostateczny obraz:
Dockerfile
# Тут у кого какие предпочтения
FROM centos:7
# Задаём переменные, чтобы каждый раз при старте не указывать их
ENV SPLUNK_HOME /splunkforwarder
ENV SPLUNK_ROLE splunk_heavy_forwarder
ENV SPLUNK_PASSWORD changeme
ENV SPLUNK_START_ARGS --accept-license
# Ставим пакеты
# wget - чтобы скачать артефакты
# expect - понадобится для первоначального запуска Splunk на этапе сборки
# jq - используется в скриптах, которые собирают статистику докера
RUN yum install -y epel-release
&& yum install -y wget expect jq
# Качаем, распаковываем, удаляем
RUN wget -O splunkforwarder-7.2.4-8a94541dcfac-Linux-x86_64.tgz 'https://www.splunk.com/bin/splunk/DownloadActivityServlet?architecture=x86_64&platform=linux&version=7.2.4&product=universalforwarder&filename=splunkforwarder-7.2.4-8a94541dcfac-Linux-x86_64.tgz&wget=true'
&& wget -O docker-18.09.3.tgz 'https://download.docker.com/linux/static/stable/x86_64/docker-18.09.3.tgz'
&& tar -xvf splunkforwarder-7.2.4-8a94541dcfac-Linux-x86_64.tgz
&& tar -xvf docker-18.09.3.tgz
&& rm -f splunkforwarder-7.2.4-8a94541dcfac-Linux-x86_64.tgz
&& rm -f docker-18.09.3.tgz
# С shell скриптами всё понятно, а вот inputs.conf, splunkclouduf.spl и first_start.sh нуждаются в пояснении. Об этом расскажу после source тэга.
COPY [ "inputs.conf", "docker-stats/props.conf", "/splunkforwarder/etc/system/local/" ]
COPY [ "docker-stats/docker_events.sh", "docker-stats/docker_inspect.sh", "docker-stats/docker_stats.sh", "docker-stats/docker_top.sh", "/splunkforwarder/bin/scripts/" ]
COPY splunkclouduf.spl /splunkclouduf.spl
COPY first_start.sh /splunkforwarder/bin/
# Даём права на исполнение, добавляем пользователя и выполняем первоначальную настройку
RUN chmod +x /splunkforwarder/bin/scripts/*.sh
&& groupadd -r splunk
&& useradd -r -m -g splunk splunk
&& echo "%sudo ALL=NOPASSWD:ALL" >> /etc/sudoers
&& chown -R splunk:splunk $SPLUNK_HOME
&& /splunkforwarder/bin/first_start.sh
&& /splunkforwarder/bin/splunk install app /splunkclouduf.spl -auth admin:changeme
&& /splunkforwarder/bin/splunk restart
# Копируем инит скрипты
COPY [ "init/entrypoint.sh", "init/checkstate.sh", "/sbin/" ]
# По желанию. Кому нужно локально иметь конфиги/логи, кому нет.
VOLUME [ "/splunkforwarder/etc", "/splunkforwarder/var" ]
HEALTHCHECK --interval=30s --timeout=30s --start-period=3m --retries=5 CMD /sbin/checkstate.sh || exit 1
ENTRYPOINT [ "/sbin/entrypoint.sh" ]
CMD [ "start-service" ]A więc to, co jest zawarte w
pierwszy_start.sh
#!/usr/bin/expect -f
set timeout -1
spawn /splunkforwarder/bin/splunk start --accept-license
expect "Please enter an administrator username: "
send -- "adminr"
expect "Please enter a new password: "
send -- "changemer"
expect "Please confirm new password: "
send -- "changemer"
expect eofPrzy pierwszym uruchomieniu Splunk pyta o nazwę użytkownika/hasło, ALE te dane są wykorzystywane tylko do wykonywania poleceń administracyjnych dla tej konkretnej instalacji, czyli wewnątrz kontenera. W naszym przypadku chcemy po prostu uruchomić kontener tak, żeby wszystko działało, a kłody płynęły jak woda. Oczywiście jest to kod stały, ale nie znalazłem innych sposobów.
W dalszej części skrypt jest wykonywany
/splunkforwarder/bin/splunk install app /splunkclouduf.spl -auth admin:changemesplunkclouduf.spl - To jest plik napisów końcowych dla Splunk Universal Forwarder, który można pobrać z interfejsu internetowego.
Gdzie kliknąć, aby pobrać (na zdjęciach)
Jest to zwykłe archiwum, które można rozpakować. Wewnątrz - certyfikaty i hasło do połączenia z naszym SplunkCloud i wyjścia.conf z listą naszych instancji wejściowych. Ten plik będzie aktualny do czasu ponownej instalacji Splunk lub dodania węzła wejściowego, jeśli instalacja odbywa się lokalnie. Dlatego nie ma nic złego w dodaniu go do pojemnika.
A ostatni to restart. Tak, aby zastosować zmiany, musisz go ponownie uruchomić.
W naszym inputy.conf dodaj logi, które chcemy wysłać do Splunk. Nie jest konieczne dodawanie tego pliku do obrazu, jeśli na przykład dystrybuujesz konfiguracje za pośrednictwem marionetki. Najważniejsze jest to, że Forwarder widzi konfiguracje podczas uruchamiania demona, w przeciwnym razie będzie potrzebny ./splunk, uruchom ponownie.
Co to są skrypty statystyk dokerów? Na githubie znajduje się stare rozwiązanie , skrypty są stamtąd pobierane i modyfikowane tak, aby działały z aktualnymi wersjami Dockera (ce-17.*) i Splunk (7.*).
Dzięki uzyskanym danym możesz zbudować takie
dashboardy: (kilka zdjęć)
Kod źródłowy myślników znajduje się w rzepie wskazanej na końcu artykułu. Należy pamiętać, że istnieją 2 pola wyboru: 1 - wybór indeksu (wyszukiwanie według maski), wybór hosta/kontenera. Maska indeksu najprawdopodobniej będzie wymagała aktualizacji w zależności od używanych nazw.
Podsumowując, chcę zwrócić uwagę na funkcję początek() в
punkt wejścia.sh
start() {
trap teardown EXIT
if [ -z $SPLUNK_INDEX ]; then
echo "'SPLUNK_INDEX' env variable is empty or not defined. Should be 'dev' or 'prd'." >&2
exit 1
else
sed -e "s/@index@/$SPLUNK_INDEX/" -i ${SPLUNK_HOME}/etc/system/local/inputs.conf
fi
sed -e "s/@hostname@/$(cat /etc/hostname)/" -i ${SPLUNK_HOME}/etc/system/local/inputs.conf
sh -c "echo 'starting' > /tmp/splunk-container.state"
${SPLUNK_HOME}/bin/splunk start
watch_for_failure
}W moim przypadku dla każdego środowiska i każdego pojedynczego bytu, czy to będzie aplikacja w kontenerze, czy na komputerze-hoście, używamy osobnego indeksu. Zatem prędkość wyszukiwania nie ucierpi ze względu na znaczną akumulację danych. Prosta zasada nazewnictwa indeksów jest następująca: _. Dlatego aby kontener był uniwersalny, przed uruchomieniem samego demona dokonujemy jego wymiany sed-ohm symbol wieloznaczny na nazwę środowiska. Zmienna z nazwą środowiska jest przekazywana przez zmienne środowiskowe. Brzmi zabawnie.
Warto również zauważyć, że z jakiegoś powodu obecność parametru docker nie wpływa na Splunk hosta. Mimo to nadal będzie wysyłać logi z identyfikatorem swojego kontenera w polu hosta. Jako rozwiązanie można zamontować / etc / hostname z komputera hosta i podczas uruchamiania dokonaj zamiany podobnej do nazw indeksów.
przykład docker-compose.yml
version: '2'
services:
splunk-forwarder:
image: "${IMAGE_REPO}/docker-stats-splunk-forwarder:${IMAGE_VERSION}"
environment:
SPLUNK_INDEX: ${ENVIRONMENT}
volumes:
- /etc/hostname:/etc/hostname:ro
- /var/log:/var/log
- /var/run/docker.sock:/var/run/docker.sock:roŁączny
Tak, być może rozwiązanie nie jest idealne i na pewno nie uniwersalne dla każdego, skoro jest ich wiele „kod twardy”. Ale na tej podstawie każdy może zbudować swój własny obraz i umieścić go w swoim prywatnym artefakcie, jeśli tak się składa, że potrzebujesz Splunk Forwardera w oknie dokowanym.
Linki:
Źródło: www.habr.com