Skip to main content
Login
Iniciar avaliação gratuitaFalar com vendas

Novo

Leia mais
Sobre nósParceirosSuporte|Login

Introdução ao Elastic Stack e ao Docker Compose: parte 1

Por

Eddie Mitchell

blog-thumb-charts-laptop.png

Conforme o Elastic Stack foi crescendo ao longo dos anos e os conjuntos de recursos aumentaram, aumentou também a complexidade para começar ou tentar uma prova de conceito (POC) localmente. Embora o Elastic Cloud ainda seja a maneira mais rápida e fácil de começar a trabalhar com a Elastic, a necessidade de desenvolvimento e testes locais ainda é alta. Como desenvolvedores, somos atraídos por configurações ágeis e desenvolvimento rápido com resultados de baixo esforço. Em termos de configuração rápida e POC, nada supera o Docker. É nisso que nos concentraremos para começar com um Elastic Stack completo para sua diversão local. 

Na primeira parte desta série de duas partes, veremos detalhes sobre a configuração dos componentes de um Elastic Stack padrão, composto por Elasticsearch, Logstash, Kibana e Beats (ELK-B), nos quais podemos começar a desenvolver imediatamente.

Na segunda parte, aprimoraremos nossa configuração de base e adicionaremos muitos dos diferentes recursos que melhoram nossa stack em evolução, como APM, Agent, Fleet, Integrations e Enterprise Search. Também veremos como instrumentar esses recursos no nosso novo ambiente local para fins de desenvolvimento e POC.

Quem já sabe como é pode ir direto ao repositório para pegar os arquivos.

Como pré-requisito, o Docker Desktop ou o Docker Engine com o Docker Compose precisará ser instalado e configurado. Neste tutorial, usaremos o Docker Desktop.

Nosso foco para esses containers do Docker será principalmente o Elasticsearch e o Kibana. No entanto, utilizaremos o Metricbeat para nos fornecer algumas informações sobre o cluster, bem como o Filebeat e o Logstash para obter alguns princípios básicos sobre ingestão.

Estrutura de arquivos

Primeiro, vamos começar definindo o esboço da nossa estrutura de arquivos.

├── .env

├── docker-compose.yml

├── filebeat.yml

├── logstash.conf

└── metricbeat.yml

Vamos mantê-la simples inicialmente. O Elasticsearch e o Kibana poderão iniciar a partir do arquivo docker-compose, enquanto o Filebeat, o Metricbeat e o Logstash precisarão de configuração adicional de arquivos yml. 

Arquivo de ambiente

A seguir, definiremos as variáveis a serem passadas para o docker-compose por meio do arquivo .env. Esses parâmetros nos ajudarão a estabelecer portas, limites de memória, versões 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

Observe que a palavra de espaço reservado “changeme” para todas as senhas e o exemplo de chave é usada apenas para fins de demonstração. Ela deve ser alterada até mesmo para atender às suas necessidades locais de POC. 

Como você pode ver aqui, especificamos as portas 9200 e 5601 para o Elasticsearch e o Kibana, respectivamente. É aqui também que você pode mudar o tipo de licença de “basic” (básica) para “trial” (avaliação) para testar recursos adicionais.

Utilizamos a variável de ambiente `STACK_VERSION' aqui para passá-la para cada um dos serviços (containers) em nosso arquivo docker-compose.yml. Ao usar o Docker, a opção de codificar o número da versão em vez de usar algo como a tag :latest é uma boa maneira de manter um controle positivo sobre o ambiente. Para componentes do Elastic Stack, a tag :latest não é aceita, e precisamos dos números das versões para extrair as imagens.

Nó “setup” e do Elasticsearch

Um dos primeiros problemas que costumamos encontrar ao começar é a configuração de segurança. A partir da versão 8.0, a segurança está habilitada por padrão. Portanto, precisaremos ter certeza de que temos o certificado CA configurado corretamente, utilizando um nó “setup” (de configuração) para estabelecer os certificados. Ter a segurança habilitada é uma prática recomendada e ela não deve ser desabilitada, mesmo em ambientes de POC.

docker-compose.yml (container “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

No topo do docker-compose.yml, definimos a versão do compose, seguida pelos volumes e pela configuração de rede padrão que serão usados em nossos diferentes containers.

Também vemos que estamos montando um container com o rótulo “setup” com um pouco da magia do Bash para especificar nossos nós de cluster. Isso nos permite chamar o elasticsearch-certutil, passando os nomes dos servidores no formato yml para criar o certificado CA e os certificados de nó. Se quiser ter mais de um nó do Elasticsearch na stack, é aqui que você adiciona o nome do servidor para permitir a criação do certificado.

Observação: em um post futuro, adotaremos o método recomendado de usar um keystore para manter os segredos, mas, por enquanto, isso nos permitirá colocar o cluster em funcionamento.

Esse container “setup” será iniciado primeiro, aguardará o container ES01 ficar online e usará nossas variáveis de ambiente para configurar as senhas que queremos em nosso cluster. Também estamos salvando todos os certificados no volume “certs” para que todos os outros containers possam ter acesso a eles.

Como o container “setup” depende do container ES01, vamos dar uma olhada rápida na próxima configuração para que possamos inicializar ambos:

docker-compose.yml (container “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

Esse será o cluster de nó único do Elasticsearch que estamos usando para testes.

Observe que usaremos o certificado CA e os certificados de nó que foram gerados. 

Você também notará que estamos armazenando os dados do Elasticsearch em um volume fora do container, especificando - esdata01:/usr/share/elasticsearch/data. Os dois principais motivos para isso são desempenho e persistência dos dados. Se deixássemos o diretório de dados dentro do container, veríamos uma degradação significativa no desempenho do nosso nó do Elasticsearch, bem como perderíamos dados sempre que precisássemos alterar a configuração do container dentro do nosso arquivo docker-compose.

Com as duas configurações definidas, podemos executar nosso primeiro comando `docker-compose up`.

Dicas do Docker Compose

Se você está começando agora a usar o Docker Compose ou já faz algum tempo que não o usa e precisa refrescar a memória relembrando alguns dos comandos, vamos ver rapidamente os principais que você vai querer conhecer para esta aventura.

Convém executar todos esses comandos em um terminal e na mesma pasta em que residir o arquivo docker-compose.yml. Minha pasta de exemplo:

Vamos dar uma olhada nesses comandos.

Agora, vamos executar `docker-compose up`.

Neste ponto, se a sintaxe estiver correta, o Docker começará a baixar todas as imagens e a criar o ambiente listado no arquivo docker-compose.yml. Isso pode demorar alguns minutos, dependendo da velocidade da sua conexão com a internet. Se quiser ver as imagens fora do Docker Desktop, você poderá encontrá-las no hub oficial do Docker no site da Elastic.

Solução de problemas de configurações incorretas de memória virtual

Ao iniciar o nó do Elasticsearch pela primeira vez, muitos usuários ficam sem saber o que fazer na configuração da memória virtual e recebem uma mensagem de erro como:

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

A principal conclusão aqui é max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144].

Em última análise, o comando sysctl -w vm.max_map_count=262144 precisa ser executado onde os containers estão hospedados.

No caso do Mac, verifique estas instruções para Docker para Mac. Siga estas instruções para o Docker Desktop. Usuários do Linux devem consultar estas instruções. Usuários do Windows poderão tentar estas instruções se tiverem o Docker Desktop. No entanto, se você estiver usando WSLv2 com o Docker Desktop, dê uma olhada aqui.

Depois de concluído, você pode reiniciar o Docker Desktop e tentar novamente o comando docker-compose up.

Lembre-se de que o container “setup” será encerrado propositalmente depois de concluir a geração dos certificados e das senhas.

Até aqui tudo bem, mas vamos testar. 

Podemos usar um comando para copiar o ca.crt do container es01-1. Lembre-se de que o nome do conjunto de containers é baseado na pasta na qual o docker-compose.yml está sendo executado. Por exemplo, meu diretório é “elasticstack_docker”, portanto, meu comando ficaria assim, com base na captura de tela acima:

docker cp

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

Depois que o certificado for baixado, execute um comando curl para consultar o nó do Elasticsearch:

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

Sucesso!

Observe que estamos acessando o Elasticsearch usando localhost:9200. Isso se deve à porta, que foi especificada na seção ports de docker-compose.yml. Essa configuração mapeia as portas no container para as portas no host e permite que o tráfego passe pela sua máquina e entre no container do Docker com essa porta especificada.

Kibana

Para a configuração do Kibana, utilizaremos a saída do certificado anterior. Também especificaremos que esse nó não seja iniciado até que o nó do Elasticsearch acima esteja instalado e funcionando corretamente.

docker-compose.yml (container “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

Observe em nossa seção `environment` que estamos especificando ELASTICSEARCH_HOSTS=https://es01:9200. Podemos especificar o nome do container aqui para nosso container do Elasticsearch ES01, já que estamos utilizando a rede padrão do Docker. Todos os containers que estiverem usando a rede “elastic” especificada no início do nosso arquivo docker-compose.yml poderão resolver adequadamente outros nomes de containers e se comunicar entre si.

Vamos carregar o Kibana e ver se conseguimos acessá-lo.

Os containers estão com status verde. Agora devemos conseguir acessar http://localhost:5601.

Um login rápido com o nome de usuário e a senha especificados nos levará diretamente a uma nova instância do Kibana. Excelente!

Metricbeat

Agora que o Kibana e o Elasticsearch estão funcionando e se comunicando, vamos configurar o Metricbeat para nos ajudar a ficar de olho em tudo. Isso exigirá uma configuração no nosso arquivo docker-compose e também em um arquivo metricbeat.yml independente.

Observação: para o Logstash, o Filebeat e o Metricbeat, os arquivos de configuração usam bind mounts. Os bind mounts para arquivos manterão as mesmas permissões e propriedade dentro do container que tiverem no sistema host. Certifique-se de definir as permissões de forma que os arquivos sejam legíveis e, idealmente, não possam ser gravados pelo usuário do container. Caso contrário, você receberá um erro no container. Remover as permissões de gravação no seu host pode ser suficiente.

docker-compose.yml (container “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

Aqui, expomos informações do host sobre processos, sistema de arquivos e o daemon do Docker ao container do Metricbeat em modo somente leitura. Isso permite que o Metricbeat colete os dados para enviar ao 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"

Nosso Metricbeat depende da integridade do nó ES01 e do nó do Kibana antes de iniciar. As configurações dignas de nota aqui estão no arquivo metricbeat.yml. Habilitamos quatro módulos para coleta de métricas, incluindo Elasticsearch, Kibana, Logstash e Docker. Isso significa que, depois de verificarmos que o Metricbeat está ativo, podemos entrar no Kibana e navegar até “Stack Monitoring” (Monitoramento da stack) para ver como estão as coisas.

Não se esqueça de configurar suas regras prontas para uso!

O Metricbeat também está configurado para monitorar o host do container por meio de /var/run/docker.sock. A verificação do Elastic Observability permite que você veja métricas provenientes do seu host.

Filebeat

Agora que o cluster está estável e está sendo monitorado com o Metricbeat, vamos dar uma olhada no Filebeat para ingestão de log. Aqui, nosso Filebeat será utilizado de duas maneiras diferentes:

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

Primeiro, definimos um bind mount para mapear a pasta “filebeat_ingest_data” para o container. Se essa pasta não existir no seu host, será criada quando o container for iniciado. Se quiser testar o visualizador Logs Stream no Elastic Observability para seus logs customizados, você poderá facilmente colocar qualquer arquivo com extensão .log em /filebeat_ingest_data/, e os logs serão lidos no fluxo de dados padrão do Filebeat.

Além disso, também mapeamos em /var/lib/docker/containers e /var/run/docker.sock que, combinados com a seção filebeat.autodiscover e com a descoberta automática baseada em dicas, permitem que o Filebeat extraia os logs de todos os containers. Esses logs também serão encontrados no visualizador Logs Stream mencionado acima.

Logstash

Nosso último container que será lançado é nada mais, nada menos que o do Logstash.

docker-compose.yml (container “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"
 }
}

A configuração do Logstash é muito semelhante à configuração do Filebeat. Novamente, estamos usando um bind mount e mapeando uma pasta chamada /logstash_ingest_data/ do host para o container do Logstash. Aqui você pode testar alguns dos muitos plugins de entrada e plugins de filtro modificando o arquivo logstash.yml. Em seguida, coloque seus dados na pasta /logstash_ingest_data/. Talvez seja necessário reiniciar o container do Logstash após modificar o arquivo logstash.yml.

Observe que o nome do índice de saída do Logstash é “logstash-%{+YYYY.MM.dd}”. Para ver os dados, você precisará criar uma visualização de dados para o padrão “logstash-*”, conforme mostrado abaixo.

Agora, com o Filebeat e o Logstash em funcionamento, se você navegar de volta para Cluster Monitoring (Monitoramento do cluster), verá o Logstash sendo monitorado, bem como algumas métricas e links para logs do Elasticsearch.

Conclusão

A primeira parte desta série abordou um cluster totalmente ativo com monitoramento e ingestão como base da nossa stack. Isso funcionará como seu playground local para testar alguns dos recursos do ecossistema Elastic.

Quer saber mais? Confira a segunda parte! Nela, veremos mais detalhes sobre a otimização dessa base, juntamente com a configuração de recursos adicionais como APM Server, Elastic Agents, Elastic Integrations e Elastic Search. Também implantamos e testamos uma aplicação que você pode instrumentar com algumas dessas peças.

Todos os arquivos apresentados aqui estão disponíveis no GitHub, junto com alguns dados de amostra para ingestão do Filebeat e do Logstash.

Assista à introdução ao Elastic Stack

Recursos adicionais (em inglês)
  1. Execução do Elasticsearch no Docker
  2. Execução do Kibana no Docker
  3. Execução do Metricbeat no Docker
  4. Execução do Filebeat no Docker
  5. Execução do Logstash no Docker

Sign up for Elastic Cloud free trial

Spin up a fully loaded deployment on the cloud provider you choose. As the company behind Elasticsearch, we bring our features and support to your Elastic clusters in the cloud.

Start free trial