Splunk è uno dei pochi prodotti commerciali più riconoscibili per la raccolta e l'analisi dei log. Anche ora, quando le vendite in Russia non sono più effettuate, questo non è un motivo per non scrivere istruzioni/how-to su questo prodotto.
Compito: raccogliere i log di sistema dalle navi docker in Splunk senza modificare la configurazione della macchina host
Volevo iniziare con l'approccio ufficiale, che sembra un po' strano quando si utilizza Docker.
Cosa abbiamo quindi:
1. Pulliamo l'immagine
$ docker pull splunk/universalforwarder:latest2. Avviamo il contenitore con i parametri necessari
$ docker run -d -p 9997:9997 -e 'SPLUNK_START_ARGS=--accept-license' -e 'SPLUNK_PASSWORD=' splunk/universalforwarder:latest3. Entiamo nel contenitore
docker exec -it /bin/bashPoi ci viene chiesto di seguire un noto link nella documentazione.
E configurare il contenitore dopo il suo avvio:
./splunk add forward-server :
./splunk add monitor /var/log
./splunk restart
Aspetta. Cosa?
Ma le sorprese non finiscono qui. Se avvii il contenitore dall'immagine ufficiale in modalità interattiva, vedrai quanto segue:
Un po' di delusione
$ docker run -it -p 9997:9997 -e 'SPLUNK_START_ARGS=--accept-license' -e 'SPLUNK_PASSWORD=password' splunk/universalforwarder:latest
GIOCO [Esegui provisioning predefinito di Splunk] *******************************************************************************************************************************************************************************************************
Martedì 09 aprile 2019 13:40:38 +0000 (0:00:00.096) 0:00:00.096 *********
COMPITO [Raccolta di informazioni] ***********************************************************************************************************************************************************************************************************************
ok: [localhost]
Martedì 09 aprile 2019 13:40:39 +0000 (0:00:01.520) 0:00:01.616 *********
COMPITO [Ottieni nome host attuale] *******************************************************************************************************************************************************************************************************************
modificato: [localhost]
Martedì 09 aprile 2019 13:40:40 +0000 (0:00:00.599) 0:00:02.215 *********
Martedì 09 aprile 2019 13:40:40 +0000 (0:00:00.054) 0:00:02.270 *********
COMPITO [set_fact] ******************************************************************************************************************************************************************************************************************************
ok: [localhost]
Martedì 09 aprile 2019 13:40:40 +0000 (0:00:00.075) 0:00:02.346 *********
Martedì 09 aprile 2019 13:40:40 +0000 (0:00:00.067) 0:00:02.413 *********
Martedì 09 aprile 2019 13:40:40 +0000 (0:00:00.060) 0:00:02.473 *********
Martedì 09 aprile 2019 13:40:40 +0000 (0:00:00.051) 0:00:02.525 *********
Martedì 09 aprile 2019 13:40:40 +0000 (0:00:00.056) 0:00:02.582 *********
Martedì 09 aprile 2019 13:40:41 +0000 (0:00:00.216) 0:00:02.798 *********
incluso: /opt/ansible/roles/splunk_common/tasks/change_splunk_directory_owner.yml per localhost
Martedì 09 aprile 2019 13:40:41 +0000 (0:00:00.087) 0:00:02.886 *********
COMPITO [splunk_common : Aggiorna proprietario della directory di Splunk] *****************************************************************************************************************************************************************************************
ok: [localhost]
Martedì 09 aprile 2019 13:40:41 +0000 (0:00:00.324) 0:00:03.210 *********
incluso: /opt/ansible/roles/splunk_common/tasks/get_facts.yml per localhost
Martedì 09 aprile 2019 13:40:41 +0000 (0:00:00.094) 0:00:03.305 *********
e così via...
Ottimo. Nell'immagine non c'è nemmeno un artefatto. Cioè, ogni volta che viene avviato ci vorrà tempo per scaricare l'archivio con i binari, estrarlo e configurarlo.
E il docker-way e tutto il resto?
No, grazie. Prenderemo un'altra strada. E se eseguissimo tutte queste operazioni nella fase di assemblaggio? Allora andiamo!
Per non allungare il discorso, vi mostro subito l'immagine finale:
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" ]Quindi, cosa contiene
first_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 eofAl primo avvio, Splunk chiede di impostare un nome utente/password, MA questi dati vengono utilizzati solo per eseguire comandi amministrativi di questa specifica installazione, cioè, all'interno del contenitore. Nel nostro caso, vogliamo solo avviare il contenitore affinché tutto funzioni e i log fluiscano copiosamente. Certo, è un hardcode, ma non ho trovato altri modi.
Successivamente, nel copione vengono eseguiti
/splunkforwarder/bin/splunk install app /splunkclouduf.spl -auth admin:changemesplunkclouduf.spl — Questo è il file delle credenziali per Splunk Universal Forwarder, scaricabile dall'interfaccia web.
Dove cliccare per scaricare (nelle immagini)
Questo è un normale archivio che può essere estratto. All'interno ci sono i certificati e la password per connettersi al nostro SplunkCloud e outputs.conf con la lista delle nostre istanze di input. Questo file rimarrà valido finché non reinstallate la vostra istanza di Splunk o non aggiungete nodi di input, se l'installazione è on-premise. Quindi non c'è nulla di sbagliato nell'aggiungerlo all'interno del contenitore.
E infine — riavvio. Sì, per applicare le modifiche, è necessario riavviarlo.
Nel nostro inputs.conf aggiungiamo i log che vogliamo inviare a Splunk. Non è obbligatorio aggiungere questo file all'immagine, se state distribuendo le configurazioni tramite puppet, ad esempio. L'importante è che il Forwarder veda le configurazioni all'avvio del demone, altrimenti sarà necessario .\/splunk restart.
E quali sono gli script docker stats? Su GitHub c'è una vecchia soluzione di , gli script sono stati presi da lì e adattati per funzionare con le versioni attuali di Docker (ce-17.*) e Splunk (7.*).
Con i dati ottenuti è possibile creare dei
dashboard: (coppia di immagini)
Il codice sorgente dei dashboard si trova nel repository indicato alla fine dell'articolo. Si prega di notare che ci sono due campi di selezione: 1 — selezione dell'indice (cercati per maschera), selezione dell'host/contenitore. Molto probabilmente dovrete aggiornare la maschera dell'indice, a seconda dei nomi che utilizzate.
In conclusione, voglio sottolineare la funzione start() in
entrypoint.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
}Nel mio caso, per ogni ambiente e ogni singola entità, che sia un'applicazione in contenitore o una macchina host, utilizziamo un indice separato. In questo modo la velocità di ricerca non verrà compromessa con l'accumulo massiccio di dati. Per la denominazione degli indici viene utilizzata una semplice regola: _. Pertanto, affinché il contenitore sia universale, prima di avviare direttamente il demone, sostituiamo sed- il wildcard con il nome dell'ambiente. La variabile con il nome dell'ambiente viene passata tramite le variabili d'ambiente. Suona divertente.
È importante notare che, per qualche motivo, il parametro docker non influisce su Splunk. nome hostIn ogni caso, continuerà a inviare log con l'ID del proprio contenitore nel campo host. Come soluzione, è possibile montare /etc/hostname dalla macchina host e, all'avvio, effettuare una sostituzione simile a quella dei nomi degli indici.
Esempio di 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:roRisultato
Sì, è possibile che la soluzione non sia ideale e di certo non universale per tutti, poiché c'è molto «hardcoding». Ma ognuno può basarsi su di essa per creare la propria immagine e conservarla nel proprio artefatto privato, se, per caso, hai bisogno di un Splunk Forwarder proprio in Docker.
Link:
Fonte: habr.com
