Primeros pasos con el Elastic Stack y Docker Compose: Parte 1

By

Eddie Mitchell

blog-thumb-charts-laptop.png

A medida que el Elastic Stack ha crecido con los años y los conjuntos de características han aumentado, también lo ha hecho la complejidad de dar los primeros pasos o intentar una prueba de concepto (POC) de forma local. Y si bien Elastic Cloud es la forma más rápida y sencilla de dar los primeros pasos con Elastic, la necesidad de desarrollar y realizar pruebas de forma local sigue siendo ampliamente significativa. Como desarrolladores, nos atraen las configuraciones rápidas y el desarrollo rápido que brindan resultados con poco esfuerzo. No hay nada que ofrezca configuración y POC rápidas como Docker; que es sobre lo que nos enfocaremos para dar los primeros pasos con un Elastic Stack completo creado para que lo disfrutes de forma local. 

En la primera de las dos partes de esta serie, veremos la configuración de los componentes de un Elastic Stack estándar que consta de Elasticsearch, Logstash, Kibana y Beats (ELK-B), a partir del cual podemos comenzar a desarrollar de inmediato.

En la parte dos, mejoraremos la configuración básica y agregaremos muchas de las distintas características que impulsan nuestro stack que evoluciona, como APM, Agent, Fleet, integraciones y Enterprise Search. También intentaremos instrumentarlas en nuestro nuevo entorno local para fines de desarrollo y POC.

Quienes ya hayan pasado por algo similar antes, son bienvenidos en TL;DR y pueden dirigirse al repositorio para tomar los archivos.

Como requisito previo, Docker Desktop o Docker Engine con Docker-Compose deberá instalarse y configurarse. Para este tutorial, usaremos Docker Desktop.

Nuestro foco para estos contenedores Docker serán principalmente Elasticsearch y Kibana. Sin embargo, usaremos Metricbeat para que nos brinde un poco de información sobre el cluster, además de Filebeat y Logstash para algunas cuestiones básicas de ingesta.

Estructura de archivos

Primero, comencemos por definir el esquema de nuestra estructura de archivos.

├── .env

├── docker-compose.yml

├── filebeat.yml

├── logstash.conf

└── metricbeat.yml

Lo mantendremos simple para empezar. Elasticsearch y Kibana podrán comenzar a partir del archivo docker-compose, mientras que Filebeat, Metricbeat y Logstash necesitarán configuración adicional de los archivos yml. 

Archivo de entorno

Luego, definiremos variables para pasar a docker-compose a través del archivo .env. Estos parámetros nos ayudarán a establecer puertos, límites de memoria, versiones de componentes, 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

Ten en cuenta que la palabra marcadora de posición "changeme" en todas las contraseñas y la clave de muestra se usan solo para fines de demostración. Se deben cambiar incluso para tu POC local. 

Como puedes ver aquí, especificamos los puertos 9200 y 5601 para Elasticsearch y Kibana, respectivamente. Aquí es también donde puedes cambiar el tipo de licencia de "básica" a "prueba" con el objetivo de probar características adicionales.

Usamos la variable de entorno "STACK_VERSION" aquí para pasarla a cada uno de los servicios (contenedores) en nuestro archivo docker-compose.yml. Al usar Docker, optar por codificar de forma rígida el número de versión en lugar de usar algo como la etiqueta :latest es una buena forma de mantener un control positivo del entorno. Para los componentes del Elastic Stack, no se brinda soporte para la etiqueta :latest, y necesitamos números de versión para recuperar las imágenes.

Nodo de configuración y Elasticsearch

Uno de los primeros inconvenientes que suele aparecer al inicio es la configuración de seguridad. A partir de la versión 8.0, la seguridad está habilitada de forma predeterminada. Por lo tengo, tendremos que asegurarnos de tener correctamente configurada la CA del certificado usando un nodo "setup" para establecer los certificados. Tener habilitada la seguridad es una práctica recomendada; no debería deshabilitarse, incluso en entornos de POC.

docker-compose.yml (contenedor "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 la parte superior de docker-compose.yml, establecemos la versión de Compose, luego los volúmenes y la configuración de redes predeterminada que se usará en todos nuestros distintos contenedores.

También vemos que estamos poniendo en marcha un contenedor con la etiqueta "setup" gracias a cierta magia de bash para especificar nuestros nodos del cluster. Esto nos permite llamar a elasticsearch-certutil y pasar los nombres de servidores en formato yml a fin de crear el certificado de CA y los certificados de nodo. Si querías tener más de un nodo de Elasticsearch en el stack, aquí es donde deberías agregar el nombre del servidor para permitir la creación del certificado.

Nota: En un próximo blog, adoptaremos el método recomendado de usar un keystore para mantener secretos, pero por ahora, esto nos permitirá poner en marcha el cluster.

Este contenedor setup se iniciará primero, esperará a que el contenedor ES01 se conecte y luego usará las variables de nuestro entorno para configurar las contraseñas que deseamos en nuestro cluster. También estamos guardando todos los certificados en el volumen "cert" para que todos los demás contenedores puedan tener acceso a ellos.

Como el contenedor setup depende del contenedor ES01, veamos rápidamente la próxima configuración para poder iniciar ambos:

docker-compose.yml (contenedor "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

Este será el cluster de un solo nodo de Elasticsearch que estamos usando para las pruebas.

Ten en cuenta que usaremos el certificado de CA y los certificados de nodo que se generaron. 

También verás que estamos almacenando los datos de Elasticsearch en un volumen fuera del contenedor especificando - esdata01:/usr/share/elasticsearch/data. Los dos motivos principales para hacer esto son el rendimiento y la persistencia de los datos. Si dejáramos el directorio de datos dentro del contenedor, veríamos una degradación significativa del rendimiento de nuestro nodo de Elasticsearch, además de datos sueltos cada vez que necesitáramos cambiar la configuración del contenedor dentro del archivo docker-compose.

Con ambas configuraciones listas, podemos ejecutar nuestro primer comando "docker-compose up".

Consejos sobre Docker Compose

Si eres nuevo en Docker Compose o ha pasado un tiempo desde que has tenido que recordar algunos de los comandos, revisemos brevemente los principales que necesitarás saber para esta aventura.

Deberás ejecutar todos estos comandos en una terminal mientras te encuentres en la misma carpeta en la que reside tu archivo docker-compose.yml. Mi carpeta de ejemplo:

Echemos un vistazo a esos comandos.

Ahora, ejecutemos "docker-compose up".

En este punto, si la sintaxis es correcta, Docker comenzará a descargar todas las imágenes y a crear el entorno incluido en el archivo docker-compose.yml. Esto puede demorar algunos minutos, según la velocidad de internet. Si deseas ver las imágenes fuera de Docker Desktop, puedes encontrarlas en el Elastic Docker Hub oficial.

Solución de problemas de errores de configuración de la memoria virtual

Al iniciar el nodo de Elasticsearch por primera vez, muchos usuarios se atascan en la configuración de la memoria virtual y reciben un mensaje de error como el siguiente:

{"@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"}

La conclusión clave aquí es max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144].

Por último, el comando sysctl -w vm.max_map_count=262144 debe ejecutarse donde se están hospedando los contenedores.

Si usas Mac, echa un vistazo a estas instrucciones de Docker para Mac. Sigue estas instrucciones para Docker Desktop. Los usuarios de Linux pueden consultar estas instrucciones. Los usuarios de Windows, si tienen Docker Desktop, pueden probar estas instrucciones. Sin embargo, si usas WSLv2 con Docker Desktop, echa un vistazo aquí.

Una vez que hayas finalizado, puedes reiniciar Docker Desktop y volver a intentar tu comando docker-compose up.

Recuerda, el contenedor setup se cerrará intencionalmente una vez que haya terminado de generar los certificados y las contraseñas.

Hasta ahora, todo bien, pero hagamos una prueba. 

Podemos usar un comando para copiar ca.crt del contenedor es01-1. Recuerda que el nombre del conjunto de contenedores está basado en la carpeta a partir de la cual se está ejecutando docker-compose.yml. Por ejemplo, mi directorio es "elasticstack_docker", por lo tanto, mi comando se vería similar al siguiente, basado en la captura de pantalla anterior:

docker cp

elasticstack_docker-es01-1:/usr/share/elasticsearch/config/certs/ca/ca.crt /es/tmp/.

Una vez descargado el certificado, ejecuta un comando curl para buscar en el nodo de Elasticsearch:

curl --cacert /es/tmp/ca.crt -u elastic:changeme https://localhost:9200

¡Felicitaciones!

Observa que estamos accediendo a Elasticsearch usando localhost:9200. Esto es gracias al puerto, que se especificó a través de la sección ports de docker-compose.yml. Esta configuración mapea los puertos del contenedor a los puertos en el host y permite la circulación de tráfico por tu máquina y hacia el contenedor Docker con ese puerto especificado.

Kibana

Para la configuración de Kibana, usaremos la salida del certificado anterior. También especificaremos que este nodo no se iniciará hasta que vea que el nodo de Elasticsearch anterior está funcionando correctamente.

docker-compose.yml (contenedor "kibana")

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

Observa que en nuestra sección "environment" estamos especificando ELASTICSEARCH_HOSTS=https://es01:9200. Aquí podemos especificar el nombre del contenedor para nuestro contenedor de Elasticsearch ES01 dado que estamos usando la red predeterminada de Docker. Todos los contenedores que están usando la red "elastic" especificada al inicio de nuestro archivo docker-compose.yml podrán resolver correctamente otros nombres de contenedores y comunicarse entre sí.

Carguemos Kibana y veamos si podemos acceder a él.

Los contenedores son verdes. Ahora deberíamos poder establecer la comunicación con http://localhost:5601.

Un inicio de sesión rápido con el nombre de usuario y la contraseña especificados nos debería llevar a una instancia nueva de Kibana. ¡Excelente!

Metricbeat

Ahora que Kibana y Elasticsearch están en marcha y se comunican, configuremos Metricbeat para que nos ayude a supervisar todo. Para ello, necesitaremos realizar la configuración en el archivo docker-compose y en un archivo independiente metricbeat.yml.

Nota: Para Logstash, Filebeat y Metricbeat, los archivos de configuración usan montajes de enlace. Los montajes de enlace para archivos mantendrán los mismos permisos y propiedad dentro del contenedor que poseen en el sistema host. Asegúrate de configurar los permisos de modo que el usuario del contenedor pueda leer los archivos e, idealmente, no escribir en ellos. De lo contrario, recibirás un error en el contenedor. Eliminar los permisos de escritura en el host puede ser suficiente.

docker-compose.yml (contenedor "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

Aquí, exponemos la información del host sobre los procesos, el sistema de archivos y el daemon de Docker. al contenedor de Metricbeat en un modo de solo lectura. Esto permite que Metricbeat recopile los datos para enviarlos a 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"

Nuestro Metricbeat depende de que los nodos de ES01 y Kibana estén en buen estado antes de comenzar. Las configuraciones destacadas aquí están en el archivo metricbeat.yml. Habilitamos cuatro módulos para reunir las métricas, entre ellos, Elasticsearch, Kibana, Logstash y Docker. Es decir, una vez que verificamos que Metricbeat está funcionando, podemos pasar a Kibana y navegar a "Stack Monitoring" (Monitoreo del stack) para saber cómo se ve todo.

No olvides configurar tus reglas listas para usar.

Metricbeat también está configurado para monitorear el host del contenedor a través de /var/run/docker.sock. Controlar Elastic Observability te permite ver las métricas que ingresan desde tu host.

Filebeat

Ahora que el cluster está estable y que lo monitorea Metricbeat, veamos Filebeat y la ingesta de logs. Aquí, nuestro Filebeat se usará de dos maneras diferentes:

docker-compose.yml (contenedor "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"

Primero, configuramos un montaje de enlace para mapear la carpeta "filebeat_ingest_data" al contenedor. Si esta carpeta no existe en tu host, se creará cuando se active el contenedor. Si deseas probar el visualizador de flujo de logs en Elastic Observability para tus logs personalizados, puedes colocar sin problema cualquier archivo con una extensión .log en /filebeat_ingest_data/ y los logs se leerán en el flujo de datos predeterminado de Filebeat.

Además de esto, también mapeamos en /var/lib/docker/containers y /var/run/docker.sock que, junto con la sección filebeat.autodiscover y hints-based autodiscover, permite a Filebeat ingresar los logs de todos los contenedores. Estos logs también se encontrarán en el visualizador de flujo de logs que mencionamos antes.

Logstash

El último contenedor al que debemos dar vida no es otro que el de Logstash.

docker-compose.yml (contenedor "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 configuración de Logstash es muy similar a la configuración de Filebeat. De nuevo, usamos un montaje de enlace y mapeamos una carpeta llamada /logstash_ingest_data/ desde el host hasta el contenedor Logstash. Aquí, puedes probar algunos de los tantos plugins de entrada y plugins de filtro modificando el archivo logstash.yml. Luego, vuelca los datos en la carpeta /logstash_ingest_data/. Es posible que debas reiniciar tu contenedor de Logstash luego de modificar el archivo logstash.yml.

Observa que el nombre del índice de salida de Logstash es "logstash-%{+YYYY.MM.dd}". Para ver los datos, deberás crear una vista de datos para el patrón "logstash-*", como se muestra a continuación.

Ahora, con Filebeat y Logstash en marcha, si navegas de regreso a Cluster Monitoring (Monitoreo de cluster), verás que se está monitoreando Logstash, al igual que algunas métricas y enlaces de Elasticsearch Logs.

Conclusión

En la primera parte de esta serie vimos un cluster completamente activo con monitoreo e ingesta como la base de nuestro stack. Esto funcionará como el área de pruebas local para probar algunas de las características del ecosistema de Elastic.

¿Estás listo para conocer más? Echa un vistazo a la parte dos. Profundizamos en la optimización de esta base, además de configurar características adicionales, como servidor APM, instancias de Elastic Agent, integraciones de Elastic y Elastic Search. También desplegamos y ponemos a prueba una aplicación que puedes instrumentar con algunas de estas piezas.

Todos los archivos sobre los que se habla aquí están disponibles en GitHub junto con algunos datos de muestra para ingestar en Filebeat y Logstash.

Mira la introducción al Elastic Stack

Recursos adicionales
  1. Cómo ejecutar Elasticsearch en Docker
  2. Cómo ejecutar Kibana en Docker
  3. Cómo ejecutar Metricbeat en Docker
  4. Cómo ejecutar Filebeat en Docker
  5. Cómo ejecutar Logstash en Docker

Regístrate para una prueba gratuita de Elastic Cloud

Activa un despliegue con todas las características en el Proveedor Cloud que selecciones. Como la empresa detrás de Elasticsearch, traemos nuestras características y soporte a tus clusters de Elastic en el cloud.

Comienza una prueba gratuita