Splunk Universal Forwarder im Docker als Systemprotokollsammler

Splunk Universal Forwarder im Docker als Systemprotokollsammler

Splunk ist eines der bekanntesten kommerziellen Produkte zur Protokollsammlung und -analyse. Selbst jetzt, wo der Verkauf nicht mehr in Russland erfolgt, ist dies kein Grund, keine Anleitungen/Anleitungen für dieses Produkt zu schreiben.

Aufgabe: Systemprotokolle von Docker-Knoten in Splunk sammeln, ohne die Konfiguration des Host-Computers zu ändern

Ich möchte mit dem offiziellen Ansatz beginnen, der bei der Verwendung von Docker etwas seltsam aussieht.
Link zum Docker-Hub
Was haben wir:

1. Pullim-Bild

$ docker pull splunk/universalforwarder:latest

2. Starten Sie den Container mit den notwendigen Parametern

$ docker run -d  -p 9997:9997 -e 'SPLUNK_START_ARGS=--accept-license' -e 'SPLUNK_PASSWORD=<password>' splunk/universalforwarder:latest

3. Wir gehen in den Container

docker exec -it <container-id> /bin/bash

Als nächstes werden wir gebeten, zu einer in der Dokumentation bekannten Adresse zu gehen.

Und konfigurieren Sie den Container nach dem Start:


./splunk add forward-server <host name or ip address>:<listening port>
./splunk add monitor /var/log
./splunk restart

Warten. Was?

Aber damit sind die Überraschungen noch nicht zu Ende. Wenn Sie den Container vom offiziellen Image im interaktiven Modus ausführen, sehen Sie Folgendes:

Ein bisschen Enttäuschung


$ 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 *********

ну и так далее...

Großartig. Das Bild enthält nicht einmal ein Artefakt. Das heißt, dass es bei jedem Start einige Zeit dauert, das Archiv mit den Binärdateien herunterzuladen, zu entpacken und zu konfigurieren.
Was ist mit Docker-Way und all dem?

Nein danke. Wir gehen einen anderen Weg. Was wäre, wenn wir alle diese Vorgänge bereits in der Montagephase durchführen würden? Dann lass uns gehen!

Um nicht zu lange zu zögern, zeige ich euch gleich das finale Bild:

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" ]

Was ist also drin?

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 eof

Beim ersten Start fordert Splunk Sie dazu auf, ein Login/Passwort anzugeben, ABER diese Daten werden verwendet nur um Verwaltungsbefehle für diese bestimmte Installation auszuführen, also innerhalb des Containers. In unserem Fall wollen wir einfach den Container starten, damit alles funktioniert und die Protokolle wie ein Fluss fließen. Das ist natürlich Hardcode, aber ich habe keine anderen Möglichkeiten gefunden.

Weiter entsprechend wird das Skript ausgeführt

/splunkforwarder/bin/splunk install app /splunkclouduf.spl -auth admin:changeme

splunkclouduf.spl – Dies ist eine Anmeldeinformationsdatei für Splunk Universal Forwarder, die von der Weboberfläche heruntergeladen werden kann.

Wo zum Herunterladen klicken (in Bildern)Splunk Universal Forwarder im Docker als Systemprotokollsammler

Splunk Universal Forwarder im Docker als Systemprotokollsammler
Dies ist ein reguläres Archiv, das entpackt werden kann. Darin befinden sich Zertifikate und ein Passwort für die Verbindung zu unserer SplunkCloud und Ausgänge.conf mit einer Liste unserer Eingabeinstanzen. Diese Datei ist relevant, bis Sie Ihre Splunk-Installation neu installieren oder einen Eingabeknoten hinzufügen, wenn die Installation vor Ort erfolgt. Daher ist es nichts Falsches, es in den Behälter zu geben.

Und das Letzte ist ein Neustart. Ja, um die Änderungen zu übernehmen, müssen Sie es neu starten.

In unserer input.conf Wir fügen die Protokolle hinzu, die wir an Splunk senden möchten. Es ist nicht notwendig, diese Datei zum Image hinzuzufügen, wenn Sie beispielsweise Konfigurationen über Puppet verteilen. Das Einzige ist, dass Forwarder die Konfigurationen sieht, wenn der Daemon startet, andernfalls benötigt er sie ./splunk-Neustart.

Um welche Art von Docker-Statistikskripten handelt es sich? Es gibt eine alte Lösung auf Github von OutcoldmanDie Skripte wurden von dort übernommen und so geändert, dass sie mit aktuellen Versionen von Docker (ce-17.*) und Splunk (7.*) funktionieren.

Mit den erhaltenen Daten können Sie Folgendes erstellen

Dashboards: (ein paar Bilder)Splunk Universal Forwarder im Docker als Systemprotokollsammler

Splunk Universal Forwarder im Docker als Systemprotokollsammler
Der Quellcode für Bindestriche befindet sich im Link am Ende des Artikels. Bitte beachten Sie, dass es zwei Auswahlfelder gibt: 2 – Indexauswahl (durchsucht nach Maske), Host-/Containerauswahl. Abhängig von den von Ihnen verwendeten Namen müssen Sie wahrscheinlich die Indexmaske aktualisieren.

Abschließend möchte ich Sie noch auf die Funktion aufmerksam machen Start() в

Einstiegspunkt.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
}

In meinem Fall verwenden wir für jede Umgebung und jede einzelne Entität, sei es eine Anwendung in einem Container oder eine Hostmaschine, einen separaten Index. Auf diese Weise wird die Suchgeschwindigkeit bei einer großen Datenansammlung nicht beeinträchtigt. Zur Benennung von Indizes wird eine einfache Regel verwendet: _. Damit der Container universell ist, ersetzen wir ihn daher, bevor wir den Daemon selbst starten Durst-ter Platzhalter für den Namen der Umgebung. Die Umgebungsnamenvariable wird über Umgebungsvariablen übergeben. Hört sich lustig an.

Es ist auch erwähnenswert, dass Splunk aus irgendeinem Grund nicht durch das Vorhandensein des Docker-Parameters beeinflusst wird hostname. Er wird immer noch hartnäckig Protokolle mit der ID seines Containers im Host-Feld senden. Als Lösung können Sie montieren / etc / Hostname vom Host-Computer und nehmen beim Start Ersetzungen vor, die den Indexnamen ähneln.

Beispiel 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

Ergebnis

Ja, vielleicht ist die Lösung nicht ideal und schon gar nicht für jeden universell, da es viele davon gibt „Hardcode“. Aber darauf basierend kann jeder sein eigenes Image erstellen und es in sein privates Artefakt einfügen, wenn er Splunk Forwarder in Docker benötigt.

Links:

Lösung aus dem Artikel
Eine Lösung von Outcolman, die uns dazu inspiriert hat, einige der Funktionen wiederzuverwenden
Von. Dokumentation zum Einrichten von Universal Forwarder

Source: habr.com

Kommentar hinzufügen