Prise en main de la Suite Elastic et de Docker Compose : Première partie
Au fil des années, la Suite Elastic a crû et les ensembles de fonctionnalités ont augmenté ; parallèlement, la prise en main et les tentatives de démonstration de faisabilité en local sont devenues de plus en plus complexes. Et même si Elastic Cloud reste le moyen le plus rapide et le plus simple de bien démarrer avec Elastic, le besoin en développement et en tests en local est toujours bien présent. En tant que développeurs, nous sommes attirés par des configurations et un développement rapides, pour des résultats demandant peu d'efforts. Pour une configuration et une démonstration de faisabilité rapides, rien de tel que Docker ; c'est ce sur quoi nous allons nous concentrer pour prendre en main un développement local complet de la Suite Elastic.
Dans la première partie de cette série en deux volets, nous verrons comment configurer des composants d'une Suite Elastic standard incluant Elasticsearch, Logstash, Kibana et Beats (ELK-B), sur laquelle nous commencerons immédiatement à développer.
Dans la seconde partie, nous améliorerons notre configuration de base et ajouterons plusieurs des différentes fonctionnalités qui alimentent notre suite évolutive, comme APM, Agent, Fleet, Integrations et Enterprise Search. Nous étudierons également l'ajout d'instruments à ces fonctionnalités dans notre nouvel environnement local, à des fins de développement et de démonstration de faisabilité.
Si vous avez déjà étudié ça avant, n'hésitez pas à consulter le résumé et à passer au référentiel pour récupérer les fichiers.
Prérequis : Docker Desktop ou Docker Engine avec Docker-Compose devront être installés et configurés. Pour ce tutoriel, nous utiliserons Docker Desktop.
Pour ces conteneurs Docker, nous nous concentrerons principalement sur Elasticsearch et Kibana. Cependant, nous utiliserons Metricbeat pour avoir des informations sur le cluster, ainsi que Filebeat et Logstash pour les bases de l'ingestion.
Structure des fichiers
Nous commencerons par définir les contours de notre structure de fichiers.
├── .env
├── docker-compose.yml
├── filebeat.yml
├── logstash.conf
└── metricbeat.yml
Nous commencerons par faire simple. Elasticsearch et Kibana pourront se lancer à partir du fichier docker-compose, mais Filebeat, Metricbeat et Logstash auront tous besoin d'une configuration supplémentaire des fichiers yml.
Fichier d'environnement
Nous définirons ensuite les variables à passer dans le fichier docker-compose via le fichier .env. Ces paramètres nous aideront à établir des ports, des limites de mémoire, des versions de composants, etc.
.env
# Project namespace (defaults to the current folder name if not set)
#COMPOSE_PROJECT_NAME=myproject
# Password for the 'elastic' user (at least 6 characters)
ELASTIC_PASSWORD=changeme
# Password for the 'kibana_system' user (at least 6 characters)
KIBANA_PASSWORD=changeme
# Version of Elastic products
STACK_VERSION=8.7.1
# Set the cluster name
CLUSTER_NAME=docker-cluster
# Set to 'basic' or 'trial' to automatically start the 30-day trial
LICENSE=basic
#LICENSE=trial
# Port to expose Elasticsearch HTTP API to the host
ES_PORT=9200
# Port to expose Kibana to the host
KIBANA_PORT=5601
# Increase or decrease based on the available host memory (in bytes)
ES_MEM_LIMIT=1073741824
KB_MEM_LIMIT=1073741824
LS_MEM_LIMIT=1073741824
# SAMPLE Predefined Key only to be used in POC environments
ENCRYPTION_KEY=c34d38b3a14956121ff2170e5030b471551370178f43e5626eec58b04a30fae2
Veuillez noter que le mot d'espace réservé "changeme" pour tous les mots de passe, ainsi que l'exemple de clé, sont utilisés à des fins de démonstration uniquement. Ils doivent être modifiés, même pour vos besoins de démonstration de faisabilité locale.
Comme vous pouvez le voir ici, nous précisons les ports 9200 et 5601 pour Elasticsearch et Kibana respectivement. C'est également ici que vous pouvez modifier votre type de licence de "basique" à "essai" pour tester des fonctionnalités supplémentaires.
Nous utilisons ici la variable d'environnement "STACK_VERSION" pour la faire passer à chacun des services (conteneurs) de notre fichier docker-compose.yml. Lorsqu'on utilise Docker, un bon moyen de maintenir un contrôle positif sur l'environnement est de choisir de coder en dur le numéro de version plutôt que d'utiliser quelque chose comme la balise :latest. Pour les composants de la Suite Elastic, la balise :latest n'est pas prise en charge et nous avons besoin des numéros de version pour extraire les images.
Configuration et nœud Elasticsearch
L'une des premières difficultés souvent rencontrées lors de la prise en main est la configuration de la sécurité. À partir de la version 8.0, la sécurité est activée par défaut. Par conséquent, nous devons nous assurer que la configuration du certificat CA est correcte en utilisant un nœud "configuration" pour établir les certificats. Il est recommandé d'activer la sécurité et de ne pas la désactiver, et ce, même dans des environnements de démonstration de faisabilité.
docker-compose.yml (conteneur ‘setup')
version: "3.8"
volumes:
certs:
driver: local
esdata01:
driver: local
kibanadata:
driver: local
metricbeatdata01:
driver: local
filebeatdata01:
driver: local
logstashdata01:
driver: local
networks:
default:
name: elastic
external: false
services:
setup:
image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
volumes:
- certs:/usr/share/elasticsearch/config/certs
user: "0"
command: >
bash -c '
if [ x${ELASTIC_PASSWORD} == x ]; then
echo "Set the ELASTIC_PASSWORD environment variable in the .env file";
exit 1;
elif [ x${KIBANA_PASSWORD} == x ]; then
echo "Set the KIBANA_PASSWORD environment variable in the .env file";
exit 1;
fi;
if [ ! -f config/certs/ca.zip ]; then
echo "Creating CA";
bin/elasticsearch-certutil ca --silent --pem -out config/certs/ca.zip;
unzip config/certs/ca.zip -d config/certs;
fi;
if [ ! -f config/certs/certs.zip ]; then
echo "Creating certs";
echo -ne \
"instances:\n"\
" - name: es01\n"\
" dns:\n"\
" - es01\n"\
" - localhost\n"\
" ip:\n"\
" - 127.0.0.1\n"\
" - name: kibana\n"\
" dns:\n"\
" - kibana\n"\
" - localhost\n"\
" ip:\n"\
" - 127.0.0.1\n"\
> config/certs/instances.yml;
bin/elasticsearch-certutil cert --silent --pem -out config/certs/certs.zip --in config/certs/instances.yml --ca-cert config/certs/ca/ca.crt --ca-key config/certs/ca/ca.key;
unzip config/certs/certs.zip -d config/certs;
fi;
echo "Setting file permissions"
chown -R root:root config/certs;
find . -type d -exec chmod 750 \{\} \;;
find . -type f -exec chmod 640 \{\} \;;
echo "Waiting for Elasticsearch availability";
until curl -s --cacert config/certs/ca/ca.crt https://es01:9200 | grep -q "missing authentication credentials"; do sleep 30; done;
echo "Setting kibana_system password";
until curl -s -X POST --cacert config/certs/ca/ca.crt -u "elastic:${ELASTIC_PASSWORD}" -H "Content-Type: application/json" https://es01:9200/_security/user/kibana_system/_password -d "{\"password\":\"${KIBANA_PASSWORD}\"}" | grep -q "^{}"; do sleep 10; done;
echo "All done!";
'
healthcheck:
test: ["CMD-SHELL", "[ -f config/certs/es01/es01.crt ]"]
interval: 1s
timeout: 5s
retries: 120
En haut du fichier docker-compose.yml, nous avons défini la version compose, suivie par les volumes et la configuration de réseau par défaut qui seront utilisés dans l'ensemble de nos différents conteneurs.
Nous voyons également que nous mettons en place un service intitulé "Configuration" avec des commandes bash pour spécifier nos nœuds de cluster. Cela nous permet d'appeler l'elasticsearch-certutil, en passant les noms de serveurs au format yml afin de créer le certificat CA et les certificats de nœud. Si vous souhaitiez avoir plus d'un nœud Elasticsearch dans votre suite, c'est ici que vous devez ajouter le nom du serveur pour autoriser la création du certificat.
Remarque : Dans une prochaine publication, nous adopterons la méthode recommandée d'utilisation d'un magasin de clés pour conserver les secrets ; mais pour le moment, cela nous permettra de rendre le cluster opérationnel.
Ce conteneur de configuration démarrera en premier, attendra que le conteneur ES01 arrive en ligne, puis utilisera nos variables d'environnement pour configurer les mots de passe que nous souhaitons dans notre cluster. Nous enregistrons également tous les certificats dans le volume "certs" pour que tous les autres conteneurs y aient accès.
Puisque le conteneur Configuration dépend du conteneur ES01, jetons rapidement un œil à la configuration suivante, afin de pouvoir les démarrer toutes les deux :
docker-compose.yml (conteneur ‘es01')
es01:
depends_on:
setup:
condition: service_healthy
image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
labels:
co.elastic.logs/module: elasticsearch
volumes:
- certs:/usr/share/elasticsearch/config/certs
- esdata01:/usr/share/elasticsearch/data
ports:
- ${ES_PORT}:9200
environment:
- node.name=es01
- cluster.name=${CLUSTER_NAME}
- discovery.type=single-node
- ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
- bootstrap.memory_lock=true
- xpack.security.enabled=true
- xpack.security.http.ssl.enabled=true
- xpack.security.http.ssl.key=certs/es01/es01.key
- xpack.security.http.ssl.certificate=certs/es01/es01.crt
- xpack.security.http.ssl.certificate_authorities=certs/ca/ca.crt
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.key=certs/es01/es01.key
- xpack.security.transport.ssl.certificate=certs/es01/es01.crt
- xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.license.self_generated.type=${LICENSE}
mem_limit: ${ES_MEM_LIMIT}
ulimits:
memlock:
soft: -1
hard: -1
healthcheck:
test:
[
"CMD-SHELL",
"curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'",
]
interval: 10s
timeout: 10s
retries: 120
Il s'agira du cluster unique d'Elasticsearch que nous utiliserons pour les tests.
Remarquez que nous utiliserons le certificat CA et les certificats de nœud ayant été générés.
Vous remarquerez également que nous stockons les données d'Elasticsearch dans un volume en dehors du conteneur en précisant - esdata01:/usr/share/elasticsearch/data Les deux raisons principales derrière cela sont la performance et la persistance des données. Si nous laissions le répertoire de données à l'intérieur du conteneur, nous verrions une dégradation importante de la performance de notre nœud Elasticsearch, et perdrions également des données à chaque fois que nous aurions besoin de changer la configuration du conteneur au sein de notre fichier docker-compose.
Avec les deux configurations en place, nous pouvons exécuter notre première commande `docker-compose up`.
Conseils concernant Docker Compose
Si vous démarrez avec Docker Compose ou si vous n'avez pas utilisé certaines commandes depuis quelque temps, examinons rapidement les commandes principales que vous aurez besoin de connaître ici.
Vous devrez exécuter toutes ces commandes dans un terminal tout en restant dans le même dossier que celui dans lequel se trouve votre fichier docker-compose.yml. Mon exemple de fichier :
Regardons ces commandes.
Maintenant, exécutons `docker-compose up`.
À ce stade, si la syntaxe est correcte, Docker commencera à télécharger toutes les images et à créer l'environnement répertorié dans le fichier docker-compose.yml. Cela peut prendre plusieurs minutes, en fonction de la rapidité de votre connexion Internet. Si vous souhaitez voir les images en dehors de Docker Desktop, vous pouvez toujours les trouver dans le hub officiel Elastic Docker.
Dépanner les erreurs de configuration de la mémoire virtuelle
Lorsqu'ils démarrent le nœud Elasticsearch pour la première fois, de nombreux utilisateurs se retrouvent bloqués par la configuration de la mémoire virtuelle et reçoivent un message d'erreur tel que :
{"@timestamp":"2023-04-14T13:16:22.148Z", "log.level":"ERROR", "message":"node validation exception\n[1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.\nbootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]", "ecs.version": "1.2.0","service.name":"ES_ECS","event.dataset":"elasticsearch.server","process.thread.name":"main","log.logger":"org.elasticsearch.bootstrap.Elasticsearch","elasticsearch.node.name":"es01","elasticsearch.cluster.name":"docker-cluster"}
Le point clé à retenir ici est que les domaines de mémoire virtuelle maximum vm.max_map_count [65530] sont trop bas, augmentez-les à au moins [262144].
En fin de compte, la commande sysctl -w vm.max_map_count=262144 doit être exécutée là où les conteneurs sont hébergés.
Sur un Mac, consultez ces instructions pour Docker pour Mac. Suivez ces instructions pour Docker Desktop. Utilisateurs de Linux, consultez ces instructions. Utilisateurs de Windows, si vous possédez Docker Desktop, vous pouvez essayer de suivre ces instructions. Cependant, si vous utilisez WSLv2 avec Docker Desktop, consultez ceci.
Une fois que vous avez terminé, vous pouvez redémarrer Docker Desktop et réessayer votre commande docker-compose up.
Souvenez-vous que le conteneur Configuration s'arrêtera délibérément après avoir terminé la génération des certificats et des mots de passe.
Jusqu'ici, tout va bien, mais procédons aux tests.
Nous pouvons utiliser une commande pour recopier le ca.crt du conteneur es01-1. Souvenez-vous que le nom de l'ensemble de conteneurs est basé sur le dossier à partir duquel le fichier docker-compose.yml s'exécute. Par exemple, si mon répertoire se nomme "elasticstack_docker", voici ce à quoi ressemblera ma commande, sur la base de la capture d'écran ci-dessus :
docker cp
elasticstack_docker-es01-1:/usr/share/elasticsearch/config/certs/ca/ca.crt /fr/tmp/.
Une fois le certificat téléchargé, exécutez une commande curl pour rechercher le nœud Elasticsearch :
curl --cacert /fr/tmp/ca.crt -u elastic:changeme https://localhost:9200
Nous avons réussi !
Vous remarquerez que nous accédons à Elasticsearch en utilisant localhost:9200. C'est grâce au port, qui a été précisé via la section ports de docker-compose.yml. Ce paramètre mappe les ports du conteneur sur les ports de l'hôte et permet au trafic de passer via votre machine et dans le conteneur Docker ayant précisé ce port.
Kibana
Pour la configuration Kibana, nous utiliserons le résultat du certificat que nous avons obtenu précédemment. Nous préciserons également que ce nœud ne commence pas avant d'avoir constaté que le nœud Elasticsearch ci-dessus fonctionne correctement.
docker-compose.yml (conteneur "kibana" container)
kibana:
depends_on:
es01:
condition: service_healthy
image: docker.elastic.co/kibana/kibana:${STACK_VERSION}
labels:
co.elastic.logs/module: kibana
volumes:
- certs:/usr/share/kibana/config/certs
- kibanadata:/usr/share/kibana/data
ports:
- ${KIBANA_PORT}:5601
environment:
- SERVERNAME=kibana
- ELASTICSEARCH_HOSTS=https://es01:9200
- ELASTICSEARCH_USERNAME=kibana_system
- ELASTICSEARCH_PASSWORD=${KIBANA_PASSWORD}
- ELASTICSEARCH_SSL_CERTIFICATEAUTHORITIES=config/certs/ca/ca.crt
- XPACK_SECURITY_ENCRYPTIONKEY=${ENCRYPTION_KEY}
- XPACK_ENCRYPTEDSAVEDOBJECTS_ENCRYPTIONKEY=${ENCRYPTION_KEY}
- XPACK_REPORTING_ENCRYPTIONKEY=${ENCRYPTION_KEY}
mem_limit: ${KB_MEM_LIMIT}
healthcheck:
test:
[
"CMD-SHELL",
"curl -s -I http://localhost:5601 | grep -q 'HTTP/1.1 302 Found'",
]
interval: 10s
timeout: 10s
retries: 120
Vous remarquerez dans notre section "environnement" que nous précisons ELASTICSEARCH_HOSTS=https://es01:9200 Nous pouvons ici préciser le nom du conteneur pour notre conteneur Elasticsearch ES01, car nous utilisons le réseau Docker par défaut. Tous les conteneurs qui utilisent le réseau "elastic" ayant été précisé au début de notre fichier docker-compose.yml pourront résoudre correctement les autres noms des conteneurs et communiquer les uns avec les autres.
Chargeons Kibana et voyons si nous pouvons y accéder.
Les conteneurs sont verts. Nous devrions maintenant pouvoir accéder à http://localhost:5601.
Une connexion rapide à l'aide du nom d'utilisateur et du mot de passe spécifiés devrait nous permettre d'arriver directement dans la toute nouvelle instance de Kibana. Parfait !
Metricbeat
Maintenant que Kibana et Elasticsearch sont opérationnels et communiquent, configurons Metricbeat pour nous aider à tout surveiller. Cela nécessitera aussi bien une configuration de notre fichier docker-compose que de notre fichier autonome metricbeat.yml.
Remarque : Pour Logstash, Filebeat et Metricbeat, les fichiers de configuration utilisent des montages liés. Des montages liés pour les fichiers garderont les mêmes autorisations et les mêmes propriétés au sein du conteneur qu'au sein du système hôte. Assurez-vous de définir les autorisations de sorte que les fichiers soient lisibles et, dans l'idéal, non inscriptibles par l'utilisateur du conteneur. Dans le cas contraire, vous recevrez une erreur dans le conteneur. Supprimer les autorisations d'écriture dans votre hôte devrait suffire.
docker-compose.yml (conteneur ‘metricbeat01')
metricbeat01:
depends_on:
es01:
condition: service_healthy
kibana:
condition: service_healthy
image: docker.elastic.co/beats/metricbeat:${STACK_VERSION}
user: root
volumes:
- certs:/usr/share/metricbeat/certs
- metricbeatdata01:/usr/share/metricbeat/data
- "./metricbeat.yml:/usr/share/metricbeat/metricbeat.yml:ro"
- "/var/run/docker.sock:/var/run/docker.sock:ro"
- "/sys/fs/cgroup:/hostfs/sys/fs/cgroup:ro"
- "/proc:/hostfs/proc:ro"
- "/:/hostfs:ro"
environment:
- ELASTIC_USER=elastic
- ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
- ELASTIC_HOSTS=https://es01:9200
- KIBANA_HOSTS=http://kibana:5601
- LOGSTASH_HOSTS=http://logstash01:9600
Ici, nous exposons les informations concernant les processus, le système de fichiers et le daemon Docker vers le conteneur Metricbeat en lecture seule. Cela permet à Metricbeat de collecter les données à envoyer à Elasticsearch.
metricbeat.yml
metricbeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: false
metricbeat.modules:
- module: elasticsearch
xpack.enabled: true
period: 10s
hosts: ${ELASTIC_HOSTS}
ssl.certificate_authorities: "certs/ca/ca.crt"
ssl.certificate: "certs/es01/es01.crt"
ssl.key: "certs/es01/es01.key"
username: ${ELASTIC_USER}
password: ${ELASTIC_PASSWORD}
ssl.enabled: true
- module: logstash
xpack.enabled: true
period: 10s
hosts: ${LOGSTASH_HOSTS}
- module: kibana
metricsets:
- stats
period: 10s
hosts: ${KIBANA_HOSTS}
username: ${ELASTIC_USER}
password: ${ELASTIC_PASSWORD}
xpack.enabled: true
- module: docker
metricsets:
- "container"
- "cpu"
- "diskio"
- "healthcheck"
- "info"
#- "image"
- "memory"
- "network"
hosts: ["unix:///var/run/docker.sock"]
period: 10s
enabled: true
processors:
- add_host_metadata: ~
- add_docker_metadata: ~
output.elasticsearch:
hosts: ${ELASTIC_HOSTS}
username: ${ELASTIC_USER}
password: ${ELASTIC_PASSWORD}
ssl:
certificate: "certs/es01/es01.crt"
certificate_authorities: "certs/ca/ca.crt"
key: "certs/es01/es01.key"
Notre Metricbeat dépend de l'intégrité des nœuds ES01 et Kibana avant de démarrer. Les configurations notables ici se trouvent dans le fichier metricbeat.yml. Nous avons activé quatre modules pour rassembler les métriques, y compris Elasticsearch, Kibana, Logstash et Docker. Cela signifie qu'une fois que nous avons vérifié que Metricbeat est opérationnel, nous pouvons passer à Kibana et accéder à "Monitoring de la Suite" pour voir comment les choses se présentent.
N'oubliez pas de configurer vos règles prêtes à l'emploi !
Metricbeat est également configuré pour monitorer l'hôte du conteneur via /var/run/docker.sock Vérifier Elastic Observability vous permet de voir les métriques qui arrivent depuis votre hôte.
Filebeat
Maintenant que le cluster est stable et monitoré grâce à Metricbeat, examinons Filebeat pour l'ingestion de logs. Ici, notre Filebeat sera utilisé de deux façons différentes :
docker-compose.yml (conteneur "filebeat01")
filebeat01:
depends_on:
es01:
condition: service_healthy
image: docker.elastic.co/beats/filebeat:${STACK_VERSION}
user: root
volumes:
- certs:/usr/share/filebeat/certs
- filebeatdata01:/usr/share/filebeat/data
- "./filebeat_ingest_data/:/usr/share/filebeat/ingest_data/"
- "./filebeat.yml:/usr/share/filebeat/filebeat.yml:ro"
- "/var/lib/docker/containers:/var/lib/docker/containers:ro"
- "/var/run/docker.sock:/var/run/docker.sock:ro"
environment:
- ELASTIC_USER=elastic
- ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
- ELASTIC_HOSTS=https://es01:9200
- KIBANA_HOSTS=http://kibana:5601
- LOGSTASH_HOSTS=http://logstash01:9600
filebeat.yml
filebeat.inputs:
- type: filestream
id: default-filestream
paths:
- ingest_data/*.log
filebeat.autodiscover:
providers:
- type: docker
hints.enabled: true
processors:
- add_docker_metadata: ~
setup.kibana:
host: ${KIBANA_HOSTS}
username: ${ELASTIC_USER}
password: ${ELASTIC_PASSWORD}
output.elasticsearch:
hosts: ${ELASTIC_HOSTS}
username: ${ELASTIC_USER}
password: ${ELASTIC_PASSWORD}
ssl.enabled: true
ssl.certificate_authorities: "certs/ca/ca.crt"
Commençons par définir un montage lié à mapper au dossier "filebeat_ingest_data" dans le conteneur. Si ce dossier n'existe pas dans votre hôte, il sera créé lorsque le conteneur sera lancé. Si vous souhaitez tester la visionneuse Logs Stream au sein d'Elastic Observability pour vos logs personnalisés, vous pouvez facilement déposer n'importe quel fichier disposant d'une extension .log dans /filebeat_ingest_data/, et les logs seront lus dans le flux de données Filebeat par défaut.
En parallèle, nous mappons également dans /var/lib/docker/containers et /var/run/docker.sock qui, en association avec la section filebeat.autodiscover et hints-based autodiscover, permet à Filebeat de collecter les logs pour tous les conteneurs. Ces logs se trouveront également dans la visionneuse Logs Stream susmentionnée.
Logstash
Le dernier conteneur que nous allons traiter n'est nul autre que Logstash.
docker-compose.yml (conteneur "logstash01")
logstash01:
depends_on:
es01:
condition: service_healthy
kibana:
condition: service_healthy
image: docker.elastic.co/logstash/logstash:${STACK_VERSION}
labels:
co.elastic.logs/module: logstash
user: root
volumes:
- certs:/usr/share/logstash/certs
- logstashdata01:/usr/share/logstash/data
- "./logstash_ingest_data/:/usr/share/logstash/ingest_data/"
- "./logstash.conf:/usr/share/logstash/pipeline/logstash.conf:ro"
environment:
- xpack.monitoring.enabled=false
- ELASTIC_USER=elastic
- ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
- ELASTIC_HOSTS=https://es01:9200
logstash.conf
input {
file {
#https://www.elastic.co/guide/en/logstash/current/plugins-inputs-file.html
#default is TAIL which assumes more data will come into the file.
#change to mode => "read" if the file is a compelte file. by default, the file will be removed once reading is complete -- backup your files if you need them.
mode => "tail"
path => "/usr/share/logstash/ingest_data/*"
}
}
filter {
}
output {
elasticsearch {
index => "logstash-%{+YYYY.MM.dd}"
hosts=> "${ELASTIC_HOSTS}"
user=> "${ELASTIC_USER}"
password=> "${ELASTIC_PASSWORD}"
cacert=> "certs/ca/ca.crt"
}
}
La configuration de Logstash est très similaire à celle de Filebeat. Encore une fois, nous utilisons un montage lié et nous mappons un dossier intitulé /logstash_ingest_data/ à partir de l'hôte dans le conteneur Logstash. Ici, vous pouvez tester certains des nombreux plug-ins d'entrée et plug-ins de filtre en modifiant le fichier logstash.yml. Déposez ensuite vos données dans le dossier /logstash_ingest_data/. Vous devrez peut-être redémarrer votre conteneur Logstash après avoir modifié le logstash.yml.
Notez que le nom de l'index de sortie Logstash est "logstash-%{+YYYY.MM.dd}". Pour consulter les données, vous devrez créer une Vue des données pour le modèle "logstash-*", comme indiqué ci-dessous.
Maintenant que Filebeat et Logstash sont tous deux opérationnels, si vous accédez de nouveau au monitoring de clusters, vous verrez que Logstash est monitoré, tout comme le sont certaines métriques et liens pour les Logs Elasticsearch.
Conclusion
La première partie de cette série a couvert l'intégralité d'un cluster actif en prenant le monitoring et l'ingestion comme base de notre suite. Cela fera office d'essai pour tester certaines des fonctionnalités de l'écosystème Elastic.
Envie d'en savoir plus ? Consultez la deuxième partie ! Nous traitons de l'optimisation de cette base, ainsi que de la configuration de fonctionnalités supplémentaires telles que le serveur APM, Elastic Agent, Elastic Integrations et Elastic Search. Nous déployons et testons également une application que nous pouvons équiper de certaines de ces pièces.
Tous les fichiers traités ici sont disponibles sur GitHub avec quelques exemples de données à ingérer pour Filebeat et Logstash.