DEV Community: Thaynara Mendes

Como evitar a perda de mensagens no Logstash com Dead letter queue (DLQ)

Thaynara Mendes — Wed, 05 Jul 2023 10:55:50 +0000

O Logstash é um pipeline de processamento de dados do lado do servidor de código aberto que ingere dados de várias fontes, transforma-os simultaneamente e os envia para seu "stash" favorito, o mais comum é o Elasticsearch.

A coleta de dados é realizada por meio de plugins de entrada configuráveis. Depois que um plugin de entrada coleta dados, ele pode ser processado por plugins de filtro que modificam e anotam os dados do evento. Por fim, o Logstash roteia eventos para plugins de saída que podem encaminhar os eventos para uma variedade de ferramentas, incluindo Elasticsearch.

Qaundo o Logstash encontra um evento que não pode processar (erro de mapeamento ou algum outro problema) a pipeline do Logstash trava ou descarta o evento malsucedido. Para proteger contra perda de dados nessa situação, podemos configurar o Logstash para gravar eventos malsucedidos em uma fila de mensagens em vez de descartá-los. Esta fila é chamada de Dead letter queue (DLQ)

Neste artigo, quero mostrar um exemplo prático de como configurar essa fila!

Laboratório

Crie o diretório:

sudo mkdir -p /opt/dlq
sudo chown -R logstash:logstash /opt/dlq

Edite o arquivo logstash.yml

dead_letter_queue.enable: true
path.dead_letter_queue: /opt/dlq

Crie um arquivo json com o seguinte conteúdo:

sudo vim /opt/dlq/teste-dql.json

{"age":39,"full_name":"Shelley Bangs","gender":"Female"}
{"age":32,"full_name":"Sally Penylton","gender":"Female"}
{"age":39,"full_name":"Janot Maxfield","gender":"Female"}
{"age":28,"full_name":"Isaak Taynton","gender":"Male"}
{"age":36,"full_name":"Pavel Braund","gender":"Male"}
{"age":43,"full_name":"Eleanore Seaton","gender":"Female"}
{"age":46,"full_name":"Ely Fullilove","gender":"Male"}
{"age":23,"full_name":"Deeann Moon","gender":"Female"}
{"age":27,"full_name":"Niels Milam","gender":"Male"}
{"age":23,"full_name":"Lorne Cuxson","gender":"Female"}
{"age":false,"full_name":"Robbyn Narrie","gender":"Female"}
{"age":true,"full_name":"Clyde Marney","gender":"Male"}
{"age":false,"full_name":"Frankie Semble","gender":"Male"}
{"age":true,"full_name":"Aggy Reditt","gender":"Female"}
{"age":true,"full_name":"Fionna Dozdill","gender":"Female"}
{"age":true,"full_name":"Erroll Hallut","gender":"Male"}
{"age":true,"full_name":"Gayle Terrell","gender":"Female"}
{"age":true,"full_name":"Lucita Garthside","gender":"Female"}
{"age":true,"full_name":"Renaud Djurkovic","gender":"Male"}
{"age":false,"full_name":"Joellen Strick","gender":"Female"}

Esse documento json é o que vamos utilizar para simular a perda de dados, é possível observar que as mensagens finais contém o campo age com dado do tipo booleano e não inteiro.

Crie a pipeline:

sudo vim /etc/logstash/conf.d/exemplo-dlq.conf

input {
  file {
    codec => "json"
    start_position => "beginning"
    path => "/opt/dlq/teste-dql.json"

  }
}
output {
  elasticsearch {
    hosts => [ "https://node-master:9200", "https://node-data:9200" ]
    index => "dlq-exemplo-dados"
    user => "sysadmin"
    password => "4linux"
    cacert => "/etc/logstash/certs/elasticsearch-ca.pem"
  }

  stdout {
    codec => "rubydebug"
  }
}

Execute o logstash:

sudo -u logstash /usr/share/logstash/bin/logstash --path.settings /etc/logstash/ -f /etc/logstash/conf.d/exemplo-dlq.conf

A pipeline será executada, o logstash vai retornar o erro que ocorreu ao tentar anexas as ultimas mensagens mas a pipeline não será encerrada. Ao verificar a quantidade de documentos no elasticsearch, pode-se observar que algumas não foram enviadas:

GET /_cat/indices/dlq*?v

Resultado:

health status index             uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   dlq-exemplo-dados 7i3c7U1yRCaGt4_QESE36g   1   1         10            0     31.7kb         19.7kb

Na pasta /opt/dlq, é possível observar que o logstash criou uma pasta com o nome da pipeline:

root@monitoring:/opt/dlq# ls
main  teste-dql.json
root@monitoring:/opt/dlq# ls -lha main/
total 28K
drwxrwxr-x 2 logstash logstash 4.0K Dec  3 11:15 .
drwxr-xr-x 3 logstash logstash 4.0K Dec  3 11:15 ..
-rw-rw-r-- 1 logstash logstash  14K Dec  3 11:15 1.log
-rw-rw-r-- 1 logstash logstash    1 Dec  3 11:15 2.log.tmp
-rw-rw-r-- 1 logstash logstash    0 Dec  3 11:15 .lock

Para recuperar esses dados, vamos criar uma pipeline e utilizar o módulo dead_letter_queue:

sudo vim /etc/logstash/conf.d/dlq.conf

input {
  dead_letter_queue {
    path => "/opt/dlq/"
  }
}
output {
  elasticsearch {
    hosts => [ "https://node-master:9200", "https://node-data:9200" ]
    index => "dlq-dados-perdidos"
    user => "sysadmin"
    password => "4linux"
    cacert => "/etc/logstash/certs/elasticsearch-ca.pem"
  }

  stdout {
    codec => "rubydebug"
  }
}

Execute a pipeline:

sudo -u logstash /usr/share/logstash/bin/logstash --path.settings /etc/logstash/ -f /etc/logstash/conf.d/dlq.conf

Agora temos 2 indices com 10 documentos:

health status index              uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   dlq-dados-perdidos D4rLwdaZTSWXF-ne79DaOw   1   1         10            0       18kb          8.9kb
green  open   dlq-exemplo-dados  uJTSqP5RSHypoxCdZLYHLw   1   1         10            0       18kb            9kb

Neste exemplo eu enviei os dados para outro índice porquê neste caso, não conseguimos converter booleano para inteiro. Mas dependendo do seu tipo de erro, é possível tratá-lo utilizando os plugins de filtro do logstash e enviar para o mesmo índice.

Conhecendo a ferramenta Opensearch

Thaynara Mendes — Mon, 06 Jun 2022 14:55:19 +0000

Heeey!

Podemos nos referir ao Opensearch como um fork do Elasticsearch e Kibana 7.10. Basicamente, o Opensearch é uma ferramente de monitoração de aplicação e análise de logs totalmente opensource (mas neste post vamos explorar um pouco mais sobre demais recursos que a ferramenta oferece).

Antes de tudo, vamos entender um pouco mais sobre o que a própria AWS nos conta sobre a ferramenta:

O que é Opensearch?

O OpenSearch é um conjunto distribuído de pesquisa e análise de código aberto usado para uma ampla variedade de casos de uso, como monitoramento de aplicações em tempo real, análise de logs e pesquisa de sites. O OpenSearch fornece um sistema altamente escalável para fornecer acesso rápido e resposta a grandes volumes de dados com uma ferramenta de visualização integrada, o OpenSearch Dashboards, que facilita a exploração de dados pelos usuários.
Assim como o Elasticsearch, o Opensearch oferece um mecanismo de pesquisa de texto completo distribuído baseado no Apache Lucene com uma interface de API RESTful e suporte para documentos JSON.

Qual a ideia por trás da criação?

Em 2021 a Elastic mudou a licença de software permissiva ALv2 para a Elastic License v2 (ELv2) and SSPL, essas licenças não seguem firmemente a ideia do Open Source e não oferecem as mesmas liberdades para os usuários. Logo, o opensearch virou um fork do Elasticsearch e Kibana na versão 7.10. Com o objetivo de oferecer uma ferramenta totalmente opensource para a comunidade.

Principais recursos do Opensearch que não fazem parte da licença free do Elasticsearch

Recurso	Benefício
Segurança avançada	Oferece recursos de criptografia, autenticação, autorização e auditoria. Eles incluem integrações com Active Directory, LDAP, SAML, Kerberos, tokens da Web JSON
Geração de relatórios	Agende, exporte e compartilhe relatórios de painéis, pesquisas salvas, alertas e visualizações.
Detecção de anomalias	Aproveite a detecção de anomalias de Machine Learning com base no algoritmo Random Cut Forest (RCF) para detectar anomalias automaticamente à medida que seus dados são ingeridos. Combine com Alertas para monitorar dados quase em tempo real e enviar notificações de alertas automaticamente.
Analisador de performance e framework RCA	Consulte várias métricas e agregações de performance do cluster. Use o PerfTop, a interface de linha de comando (CLI) para exibir e analisar essas métricas rapidamente. Use a framework de análise de causas-raiz (RCA) para investigar problemas de performance e confiabilidade em clusters.
Trace Analytics	Ingere e visualize dados OpenTelemetry para aplicações distribuídas. Visualize o fluxo de eventos entre essas aplicações para identificar problemas de performance.
Geração de alertas	Monitore dados automaticamente e envie notificações de alertas automaticamente para as partes interessadas. Crie condições de alerta altamente específicas usando a linguagem de consulta completa e os recursos de script do OpenSearch.

Vamos a prática!

Vamos subir o Opensearch e o Opensearch dashboards na versão de teste, esta versão, o Opensearch já provisiona todas as configurações de segurança (certificados).

Garanta que você tenha odocker-compose instalado.

Garanta que a variável vm.max_map_count esteja setada com o valor de 262144:

sysctl -w vm.max_map_count=262144

Essa configuração do sysctl não é permanente

Crie o arquivo docker-compose.yml:

version: '3'
services:
  opensearch-node1:
    image: opensearchproject/opensearch:latest
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node1
      - discovery.seed_hosts=opensearch-node1,opensearch-node2
      - cluster.initial_master_nodes=opensearch-node1,opensearch-node2
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g" 
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536 
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data
    ports:
      - 9200:9200
      - 9600:9600
    networks:
      - opensearch-net
  opensearch-node2:
    image: opensearchproject/opensearch:latest
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node2
      - discovery.seed_hosts=opensearch-node1,opensearch-node2
      - cluster.initial_master_nodes=opensearch-node1,opensearch-node2
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g"
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
    networks:
      - opensearch-net
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:latest
    container_name: opensearch-dashboards
    ports:
      - 5601:5601
    expose:
      - "5601"
    environment:
      OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]'
    networks:
      - opensearch-net

volumes:
  opensearch-data1:
  opensearch-data2:

networks:
  opensearch-net:

Assim que salvar o arquivo, suba todos os serviços:

docker-compose up -d

Temos que ter 3 containers rodando, dois opensearch e um opensearch Dashboards

CONTAINER ID   IMAGE                                            COMMAND                  CREATED         STATUS              PORTS                                                                                                      NAMES
7e1de85c3f8c   opensearchproject/opensearch-dashboards:latest   "./opensearch-dashbo…"   2 minutes ago   Up About a minute   0.0.0.0:5601->5601/tcp, :::5601->5601/tcp                                                                  opensearch-dashboards
40b047a9123e   opensearchproject/opensearch:latest              "./opensearch-docker…"   2 minutes ago   Up About a minute   9200/tcp, 9300/tcp, 9600/tcp, 9650/tcp                                                                     opensearch-node2
c72ebd7f6e3b   opensearchproject/opensearch:latest              "./opensearch-docker…"   2 minutes ago   Up About a minute   0.0.0.0:9200->9200/tcp, :::9200->9200/tcp, 9300/tcp, 0.0.0.0:9600->9600/tcp, :::9600->9600/tcp, 9650/tcp   opensearch-node1

Agora basta acessar o Opensearch Dashboard na porta 5601:

Você consegue acessar com user admin, senha admin.

Inserindo dados para visualização

Para visualizar dados eu importei alguns dados.

No Menu lateral, na área de Management, selecione o Dev Tools.

Através do Dev Tools, é possível realizar requisições direto no nós de Opensearch.

Os nossos documentos não tem nenhum campo do tipo datetime (ele é necessário para uma melhor visualização e análise), então primeiro vamos criar uma pipeline que irá criar o campo "indexed_at" em todo arquivo que for adicionado:

PUT /_ingest/pipeline/timestamp
{
  "description": "Adicionando o campo indexed_at nos documentos",
  "processors": [
    {
      "set": {
        "field": "indexed_at",
        "value": "{{_ingest.timestamp}}"
      }
    }
  ]
}

Vamos criar o índice e definir essa pipeline como default:

PUT /movies
{
  "settings": {
    "index.default_pipeline": "timestamp"
  }
}

Vamos adicionar um bulk request para alguns documentos:

PUT /movies/_bulk/
{ "index":{} }
{ "title" : " Predestination", "year":2014 , "genre":["Action", "Drama", "Sci-Fi"] }
{ "index":{} }
{ "title" : "Star Wars: Episode VII - The Force Awakens", "year":2015 , "genre":["Action", "Adventure", "Fantasy", "Sci-Fi"] }
{ "index":{} }
{ "title" : "Interstellar", "year":2014 , "genre":["Sci-Fi", "Adventure", "Drama"] }
{ "index":{} }
{ "title" : "Venom", "year":2018 , "genre":["Action", " Adventure", "Sci-Fi"] }
{ "index":{} }
{ "title" : "A Quiet Place Part II", "year":2020 , "genre":["Horror", "Sci-Fi", "Drama"] }
{ "index":{} }
{ "title" : "Donnie Darko", "year":2001 , "genre":["Drama", "Sci-Fi", "Mistery"] }
{ "index":{} }
{ "title" : "Black Widow", "year":2021 , "genre":["Action", " Adventure", "Sci-Fi"] }
{ "index":{} }
{ "title" : "Nobody", "year":2021 , "genre":["Action", "Drama", "Crime"] }
{ "index":{} }
{ "title" : "The Dark Knight", "year":2008 , "genre":["Action", "Drama", "Crime"] }
{ "index":{} }
{ "title" : "Inception", "year":2010 , "genre":["Action", " Adventure", "Sci-Fi"] }
{ "index":{} }
{ "title" : " The Matrix", "year":1999 , "genre":["Action",  "Sci-Fi"] }
{ "index":{} }
{ "title" : "Avatar", "year":2009 , "genre":["Action", " Adventure", "Fantasy"] }
{ "index":{} }
{ "title" : "Ex Machina", "year":2014 , "genre":["Action", " Adventure", "Sci-Fi"] }
{ "index":{} }
{ "title" : " The Hobbit: An Unexpected Journey", "year":2012 , "genre":[" Adventure", "Fantasy"] }
{ "index":{} }
{ "title" : "Wonder Woman", "year":2017 , "genre":["Action", " Adventure", "Fantasy"] }

Clique em um ícone de play para enviar a requisição:

Configurando Index Pattern

Ao retornar no Discover aparecerá uma página para criar o Index Pattern, clique em Create index pattern:

Index pattern name: movies*

Time field: indexed_at

Clique em Create Index pattern

Aparecerá todos os campos existentes neste index, podemos alterar o modo de visualização. Por exemplo:

Acesse o campo year e clique no ícone de editar:

Format: Number
Numeral.js format pattern: 0

Clique em Save field

Após retornar para o Discover, já conseguimos visualizar os documentos que adicionamos:

Um recurso que faz falta no Opensearch Dashboard é o Lens. Não foi possível inseri-lo porque esta feature do Kibana não é Open Source.

Espero que tenham gostado da ferramenta!
Até mais o/

Provisionando VMs com Vagrant + YAML + Shell Script

Thaynara Mendes — Thu, 19 Nov 2020 14:42:47 +0000

Heey!

Vagrant é uma ferramenta poderosa para provisonar VMs (Virtual Machine), recentemente comecei a utilizá-la para subir alugns labs e decidi fazer um post de como provisionar e configurar várias máquinas de forma rápida ( e organizada) com o YAML.

Antes de tudo, vamos utilizar o Virtual Box como provider, então precisamos dele instalado.

Uma vez que o vagrant está instalado e rodamos o vagrant init percebemos que ele cria o Vagrantfile.

$ vagrant init

A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

É nesse arquivo que a mágica realmente acontece.

Comandos básicos e a nossa primeira VM

Ao abrir o Vagrantfile ele estará desta forma:

# vim Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.

  # Every Vagrant development environment requires a box. You can search for
  # boxes at https://vagrantcloud.com/search.
  config.vm.box = "base"

  # Disable automatic box update checking. If you disable this, then
  # boxes will only be checked for updates when the user runs
  # `vagrant box outdated`. This is not recommended.
  # config.vm.box_check_update = false

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  # NOTE: This will enable public access to the opened port
  # config.vm.network "forwarded_port", guest: 80, host: 8080

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine and only allow access
  # via 127.0.0.1 to disable public access
  # config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1"

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # config.vm.network "private_network", ip: "192.168.33.10"

  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # config.vm.network "public_network"

  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"

  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  # Example for VirtualBox:
  #
  # config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
  #   vb.gui = true
  #
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  # end
  #
  # View the documentation for the provider you are using for more
  # information on available options.

  # Enable provisioning with a shell script. Additional provisioners such as
  # Ansible, Chef, Docker, Puppet and Salt are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   apt-get update
  #   apt-get install -y apache2
  # SHELL
end

Caso seja sua primeira vez mexendo com o vagrant, você consegue subir um CentOs7 alterando a configuração do box:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
   config.vm.box = "centos/7"
end

Uma vez com o Vagrantfile configurado, você já consegue verificar o status da vm:

$ vagrant status

Current machine states:

default                   not created (virtualbox)

The environment has not yet been created. Run `vagrant up` to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.

Como não definimos nada além do box, ele criou uma maquina com configurações padrões e o nome "default" para iniciá-la basta rodar:

$ vagrant up default

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos/7'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'centos/7' version '2004.01' is up to date...
==> default: Setting the name of the VM: devto_default_1605719030819_60986
==> default: Fixed port collision for 22 => 2222. Now on port 2202.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2202 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2202
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: 
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

Uma vez que ela está rodando, você já consegue acessá-la:

$ vagrant ssh default

Last login: Wed Nov 18 17:13:10 2020 from 10.0.2.2
[vagrant@localhost ~]$ cat /etc/centos-release
CentOS Linux release 7.8.2003 (Core)
[vagrant@localhost ~]$

Tudo pronto! Com apenas esses passos nós criamos e subimos um VM com CentOS7. O vagrant possui vários tipos de boxes e você pode verificar através do site https://app.vagrantup.com/boxes/search :D

Agora vamos para o que interessa e utilizar o YAML o/

Primeiro vamos destruir a máquina que subimos:

$ vagrant destroy default

    default: Are you sure you want to destroy the 'default' VM? [y/N] y
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...

ENV.YAML

Primeiro vamos criar um arquivo YAML onde iremos inserir as informações das nossas máquinas:

Vou montar pequeno lab com a stack ELG

# env.yaml

---
- name: graylog-lab
  box: centos/7
  hostname: graylog.lab
  ipaddress: 192.168.1.101
  memory: 2048
  provision: script/lab.sh

- name: elastic-lab
  box: centos/7
  hostname: elastic.lab
  ipaddress: 192.168.1.102
  memory: 2048
  provision: script/lab.sh

- name: logstash-lab
  box: centos/7
  hostname: logstash.lab
  ipadress: 192.168.1.103
  memory: 1024
  provision: script/lab.sh

Basicamente vamos subir 3 máquinas CentOS7 (<3) onde definimos o name, box, hostname, ipaddress, memory e provision.

Entendendo o campo Provision

O vagrant disponibiliza provisionadores que permite que você instale pacotes e configure serviços no processo de criação das máquinas (vagrant up). Ou seja, você consegue criar as máquinas com uma pré-configuração. Entre os principais provisionadores temos: Shell, Ansible, Docker, Chef.

Esse recurso é muito bom para automatizar alguns processos, o provisionamento só vai acontecer automaticamente no processo de criação das máquinas mas você consegue forçar para que ele seja executado novamente.

Vou utilizar Shell Script para instalar pacotes que irei precisar em todos os servidores e configurar o arquivo /etc/hosts com os DNS do nosso lab.

Ficou desta forma:

$ vim script/lab.sh

#!/bin/bash

echo "HEEEEY o/"
echo "Instalando pacotes..."
yum update -y && yum install -y vim java-1.8.0-openjdk-headless.x86_64
echo "Configurando alguns DNS..."
file="/etc/hosts"
( 
 echo "192.168.1.101    graylog.lab"
 echo "192.168.1.102    elastic.lab"
 echo "192.168.1.103    logstash.lab"
) >> $file

Bom, criamos o env.yaml e nosso script de provisionamento, agora só falta utilizá-los no nosso Vagrantfile.

Vagrantfile

Agora vamos caregar o arquivo env.yaml e configurar nossas máquinas de acordo com as variáveis que inserimos nele:

# vim Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

require 'yaml'

env = YAML.load_file('env.yaml')

Vagrant.configure("2") do |config|

  env.each do |env|
    config.vm.define env['name'] do |host|
      host.vm.box = env['box']
      host.vm.hostname = env['hostname']
      host.vm.network 'public_network', ip: env['ipaddress']
      host.vm.provider 'virtualbox' do |vb|
        vb.name = env['name']
        vb.memory = env['memory']
      end

      host.vm.provision "shell", path: env['provision']
    end
  end
end

Com o Vagrantfile configurado, vamos verificar se está tudo ok:

$ vagrant status

Current machine states:

graylog-lab               not created (virtualbox)
elastic-lab               not created (virtualbox)
logstash-lab              not created (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.

Você pode subir uma de cada vez vagrant up graylog ou apenas rodar vagrant up ele vai provisionar todas respectivamente.

Assim que o vagrant termina as configurações das máquinas,ele executa nosso script. Após terminar todo o processo temos 3 máquinas CentOS7 com o vim e java pré-instalados.

$ vagrant ssh graylog-lab

[vagrant@graylog ~]$ cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)
[vagrant@graylog ~]$ java -version
openjdk version "1.8.0_272"
OpenJDK Runtime Environment (build 1.8.0_272-b10)
OpenJDK 64-Bit Server VM (build 25.272-b10, mixed mode)
[vagrant@graylog ~]$ vim -version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2020 16:13:17)
Garbage after option argument: "-version"
More info with: "vim -h"
[vagrant@graylog ~]$

Curti bastante essa configuração do Vagrantfile, desta forma, caso for criar outro tipo de lab, apenas é preciso alterar o env.yaml e configurar o script de provisionamento :)

É isso, abs o/

Guia de como configurar o ELK Stack Multi Node

Thaynara Mendes — Fri, 13 Nov 2020 17:18:48 +0000

O ELK Stack é a junção de três softwares, Elasticsearch, Logstash e Kibana. O Logstash vai ser responsável por filtrar logs, inclusive tem a capacidade de coletar vários tipos arquivo, em seguida ele manda esses logs para o Elasticsearch, que por sua vez irá indexar e armazenar os logs. O Kibana possui uma interface gráfica que permite criar dashboards com gráficos e consultas específicas com os logs do Elasticsearch. Neste post nós vamos configurar essa Stack com a arquitetura Multi Node, que é usada normalmente para lidar com grande volume de dados.

Nossa arquitetura terá 3 servidores com Elasticsearch, 2 servidores com o Logstash e 1 servidor com o Kibana.

A distro que irei usar nesses servers é o Debian 9. Vamos lá ;)

Elasticsearch

Instalação

Um pré-requisito é o Java, então vamos começar por ele :)

apt update && apt install default-jdk

Agora vamos baixar e instalar a signing key:

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -

Salvar no repositório:

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-7.x.list

Agora basta instalar o apt-transport-https e o Elasticsearch:

apt install apt-transport-https && apt update && apt install elasticsearch

Agora que instalamos o Elasticsearch, vamos para a configuração da arquitetura Multi Node.

Configuração

# vim /etc/elasticsearch/elasticsearch.yml
…………………………………………
cluster.name: elk-cluster
node.name: elastic1.elk
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["elastic1.elk", "elastic2.elk", "elastic3.elk"]
cluster.initial_master_nodes: ["elastic1.elk", "elastic2.elk", "elastic3.elk"]

obs: Configurei os hostnames dos servidores no /etc/hosts

Uma vez configurado, agora basta iniciar o serviço:

# systemctl daemon-reload
# systemctl enable elasticsearch
# systemctl start elasticsearch

Você consegue verificar se está tudo ok batendo na api:

# curl 'http://elastic2.elk:9200'
{
  "name" : "elastic2.elk",
  "cluster_name" : "elk-cluster",
  "cluster_uuid" : "krxVRWInQtCzIhHdw1Mqkg",
  "version" : {
    "number" : "7.9.2",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "d34da0ea4a966c4e49417f2da2f244e3e97b4e6e",
    "build_date" : "2020-09-23T00:45:33.626720Z",
    "build_snapshot" : false,
    "lucene_version" : "8.6.2",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Para verificar o status do cluster basta fazer a request:

# curl 'http://elastic1.elk:9200/_cluster/health?pretty'                                                   
{
  "cluster_name" : "elk-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 0,
  "active_shards" : 0,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

Logstash

Instalação

O processo de instalação vai ser basicamente da mesma forma que o elasticsearch:

# apt update && apt install default-jdk
# wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -
# echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-7.x.list
# apt install apt-transport-https && apt update && apt install logstash

Configuração

Primeiro vamos copiar um arquivo de configuração padrão:

# cd /etc/logstash/ && cp logstash-sample.conf conf.d/logstash.conf

Agora vamos alterá-lo para inserir o tipo de log que ele irá coletar e inserir os endereços do elasticsearch:

# vim conf.d/logstash.conf

input {
  beats {
    port => 5044
  }
}

output {
  elasticsearch {
    hosts => ["http://elastic1.elk:9200", "http://elastic2.elk:9200", "http://elastic3.elk:9200"]
    index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
    #user => "elastic"
    #password => "changeme"
  }
}

Agora vamos editar o arquivo de configuração para ativar o monitoramento do cluster no Kibana:

# vim /etc/logstash/logstash.yml
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.hosts: ["http://elastic1.elk:9200", "http://elastic2.elk:9200", "http://elastic3.elk:9200"]

Após editar os arquivos de configuração, vamos iniciar o Logstash:

# systemctl daemon-reload
# systemctl enable logstash
# systemctl start logstash

Você consegue verificar os status do logstash através dos logs em /var/log/logstash-stdout.log.

Kibana

Instalação

Novamente o processo de instalação vai ser da mesma forma que o elasticsearch:

# apt update && apt install default-jdk
# wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -
# echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-7.x.list
# apt install apt-transport-https && apt update && apt install kibana

Configuração

Agora vamos editar o arquivo de configuração:

# vim /etc/kibana/kibana.yml

server.host: "kibana.elk"
server.name: "kibana.elk"
elasticsearch.hosts: ["http://elastic1.elk:9200", "http://elastic2.elk:9200", "http://elastic3.elk:9200"]

Após configurar, vamos iniciar o Kibana:

# systemctl daemon-reload
# systemctl enable Kibana
# systemctl start Kibana

Após alguns segundos a interface estará disponível http://kibana.elk:5601:

No Kibana, nós conseguimos verificar o status do nosso cluster, basta acessar o menu hamburguer que fica localizado no canto superior esquerdo. Na seção "Management" clique em "Stack Monitoring". Na primeira vez que acessar a página ele irá aparecer a opção de realizar o monitoramento com o "MetricBeat" e a opção "or, set up with self monitoring". Vamos clicar nesta segunda. Após alguns segundos irá aparecer esta página:

Enviando logs com Filebeat

Para mostrar um pouco do que podemos fazer no Kibana, temos que configurar o envio de algum log. Como este é um lab de teste, irei enviar o log do próprio Kibana para monitorarmos.

Para isso vamos utilizar o Filebeat, para instalar basta rodar os seguintes comandos:

# curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.9.2-amd64.deb
# dpkg -i filebeat-7.9.2-amd64.deb

Uma vez instalado, vamos configurá-lo. No arquivo de configuração do filebeat, vc vai inserir o diretórios dos logs que seram enviados e o endereço do logstash (descomente o bloco de output do elasticsearch):

# vim /etc/filebeat/filebeat.yml
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/kibana/kibana.stdout
#output.elasticsearch:
  #  hosts: ["localhost:9200"]

output.logstash:
    hosts: ["logstash1.elk:5044", "logstash2.elk:5044"]
    loadbalance: true

Agora que configuramos o Filebeat, vamos configurá-lo no Kibana.

Acesse o menu, vá em "Management" e clique em "Stack Management". No lado esquerdo irá aparecer algumas opções, vamos clicar em "Index Management":

Já conseguimos ver que o index do filebeat está disponível. Agora vamos criar um padrão de index. No canto esquerdo, clique em "Index Patterns", após isso clique em "Create index pattern". Vamos inserir um nome para o nosso index:

No passo dois selecione a opção "@timestamp" e clique em "Create index pattern".

Agora que criamos, retorne a página de "Discover" e verá as mensagens de log do próprio Kibana:

Stopei o Elasticsearch para que o Kibana reportasse mensagens de erro, com essas mensagens podemos fazer alguns gráficos.

Criando Gráficos e Dashboards

No menu lateral do Kibana temos a opção Dashboad. Vamos criar uma nova para salvarmos consultas dos logs do Kibana.

Clique em "New Dashboard". Após isso clique em "Create new". Escolha a opção "Metric" e selecione o index filebeat.

Vamos adicionar a query message : "Unable to revive connection" e pegar quantas vezes o Kibana tentou reconectar com o Elasticsearch na última hora:

Clique em "Save", insira um nome para o seu card e clique em "Save and return".

Voltamos para a nossa página de Dashboard, vamos salvá-la e inserir um nome (inseri o nome "Cluster State"):

Agora vamos adicionar 2 gráficos. Na página de Dashboard, clique em "Edit" e logo depois "Create new".

Adicionei um pie chart para mostrar a porcentagem de disponibilidade dos nodes do Elastic, ficou desta forma:

O último gráfico que irei colocar é um area chart com o status das mensagens por faixa de tempo:

Na página de Dashboard, tem o botão "Edit"(canto superior esquerdo), essa opção permite que você edite as consultas salvas e também permite redimensionar e arrastar cada widget que nós criamos nesse guia. A minha dashboard, após fazer os três gráficos, ficou desta forma:

Este guia apenas coloquei o log do Kibana mas você consegue acrescentar novos tipos de logs, criar novas dashboards e deixar sua ELK stack ainda mais produtiva. Espero que tenha gostado! Até mais :)

Guia de como criar um cluster com o centralizador de logs Graylog 3.3

Thaynara Mendes — Thu, 08 Oct 2020 12:56:35 +0000

Heeey!

Fiz um lab utilizando a arquitetura do Graylog de alta disponibilidade e resolvi criar um guia com os passos que fiz nessa jornada.

Na documentação do graylog essa configuração se chama "Multi-node Setup". Utilizaremos 3 servidores com Graylog e MongoDB, 3 servidores com Elasticsearch e 1 com HAProxy.

Para ter uma ideia. Nossa arquitetura vai ficar desta forma:

OBS:Os servidores foram criados com a distro CentOS 7. Logo, se fizer em outra distro vai ter que rever os processo de instalação. Vamos lá ;)

Elasticsearch

O Elasticsearch é o mecanismo de busca e análise de dados que o Graylog utiliza para indexar os logs recebidos.

Instalação

O Graylog apenas suporta até a versão 6.x do Elasticsearch.

eu que sempre instalo a última versão das coisas descobri isso após ter finalizado o cluster </3

Um pré-requisito para todos servidores é o java. Então vamos começar por ele.

yum update && yum -y install java-1.8.0-openjdk-headless.x86_64

Para a instalação do Elasticsearch, vamos importar a Elastic GPG key.

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

E adicionar o arquivo elasticsearch.repo no /etc/yum.repos.d/.

$ vim elasticsearch.repo
[elasticsearch-6.x]
name=Elasticsearch repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/oss-6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Após isso basta instalar

yum install elasticsearch-oss

Configuração

Como os meus servidores eu coloquei o mínimo de RAM (1G) precisei mudar algumas opções do Java, limitando o uso de memória dele. Caso tiver mais que 1G não precisa fazer essa etapa.
Altere as linhas:

$ vim /etc/elasticsearch/jvm.options
-Xms512m
-Xmx512m

Edite o arquivo de configuração:

$ vim /etc/elasticsearch/elasticsearch.yml
cluster.name: graylog
node.name: ${HOSTNAME}
network.host: 0.0.0.0
http.port: 9200
discovery.zen.ping.unicast.hosts: ["elastic1.lab", "elastic2.lab", "elastic3.lab"]

OBS: Para ficar melhor a identificação dos servers, configurei o DNS no /etc/hosts

Após configurar basta subir o serviço:

systemctl daemon-reload
systemctl enable elasticsearch.service
systemctl restart elasticsearch.service

Você consegue checar o status do Elasticsearch através do curl:

$ curl http://elastic1.lab:9200 
{
  "name" : "elastic1",
  "cluster_name" : "graylog",
  "cluster_uuid" : "qMtqk9hUTcm9gT8a6wF7-w",
  "version" : {
    "number" : "6.8.12",
    "build_flavor" : "oss",
    "build_type" : "rpm",
    "build_hash" : "7a15d2a",
    "build_date" : "2020-08-12T07:27:20.804867Z",
    "build_snapshot" : false,
    "lucene_version" : "7.7.3",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

No meu caso não foi de primeira, por um bloqueio do SELinux. Então caso não conseguir verifique se o SELinux ou o firewall está bloqueando a conexão.

Você pode apenas desabilitar o firewall ou deixá-lo ativo e liberar a conexão do elasticsearch.

Para desabilitar basta rodar o comando:

$ systemctl disable firewalld

Após replicar esses processos nos outros dois servidores, o nosso cluster do Elasticsearch estará pronto!

MongoDB

OBS: Agora vamos configurar 3 servidores com mongo e Graylog, então recomendo no mínimo 2G

O MongoDB é um serviço de banco de dados NoSQL que o Graylog utiliza para armazenar os dados de configuração.

Instalação

Crie um arquivo mongodb-org-4.4.repo no /etc/yum.repos.d/

$ vim mongodb-org-4.4.repo
[mongodb-org-4.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc

Após isso basta instalar
yum update && yum install -y mongodb-org

Configuração

Crie os diretórios:

mkdir -p /var/lib/mongo
mkdir -p /var/log/mongodb
mkdir -p /data/db

Configure as permissões do usuário mongod:

chown -R mongod:mongod /var/lib/mongo
chown -R mongod:mongod /var/log/mongodb

Na documentação do mongo, tem uma seção para configurar a política do SELinux para que permita os acessos. Caso sua distro não use SELinux, pode pular essa etapa.

$ yum install checkpolicy policycoreutils-python

cat > mongodb_cgroup_memory.te <<EOF
module mongodb_cgroup_memory 1.0;

require {
    type cgroup_t;
    type mongod_t;
    class dir search;
    class file { getattr open read };
}

#============= mongod_t ==============
allow mongod_t cgroup_t:dir search;
allow mongod_t cgroup_t:file { getattr open read };
EOF

$ checkmodule -M -m -o mongodb_cgroup_memory.mod mongodb_cgroup_memory.te
$ semodule_package -o mongodb_cgroup_memory.pp -m mongodb_cgroup_memory.mod
$ semodule -i mongodb_cgroup_memory.pp

Após configurar basta subir o serviço:

$ systemctl daemon-reload
$ systemctl enable mongod
$ systemctl start mongod

Você consegue testar a conexão rodando:

mongo

OBS:Caso mostrar alguma falha, verifique o firewall.

Para a configuração das réplicas do mongo basta executar (antes é preciso parar a instancia do mongod que está rodando):

mongod  --replSet "rs0" --bind_ip localhost,mongodb1.lab --fork --logpath /var/log/mongodb/mongod

Sobre o esta linha de comando:

mude mongodb1.lab para o endereço do server
--fork é para que o processo seja executado em segundo plano
--replSet para inserir o nome da configuração de replicação.

Após fazer esses procedimentos nos 3 servers. Em apenas um, conecte ao mongo shell:

$ mongo

e inicialize a configuração da replica:

rs.initiate( {
   _id : "rs0",
   members: [
      { _id: 0, host: "mongodb1.devops.lab:27017" },
      { _id: 1, host: "mongodb2.devops.lab:27017" },
      { _id: 2, host: "mongodb3.devops.lab:27017" }
   ]
})

você consegue verificar a configuração rodando:

rs.status()

a saída deve estar mais ou menos desta forma:

rs0:PRIMARY> rs.status()
{
        "set" : "rs0",
        "date" : ISODate("2020-10-07T04:23:25.190Z"),
        "myState" : 1,
        "term" : NumberLong(12),
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "heartbeatIntervalMillis" : NumberLong(2000),
        "majorityVoteCount" : 2,
        "writeMajorityCount" : 2,
        "votingMembersCount" : 3,
        "writableVotingMembersCount" : 3,
        "optimes" : {
                "lastCommittedOpTime" : {
                        "ts" : Timestamp(1602044601, 9),
                        "t" : NumberLong(12)
                },
                "lastCommittedWallTime" : ISODate("2020-10-07T04:23:21.627Z"),
                "readConcernMajorityOpTime" : {
                        "ts" : Timestamp(1602044601, 9),
                        "t" : NumberLong(12)
                },
                "readConcernMajorityWallTime" : ISODate("2020-10-07T04:23:21.627Z"),
                "appliedOpTime" : {
                        "ts" : Timestamp(1602044604, 11),
                        "t" : NumberLong(12)
                },
                "durableOpTime" : {
                        "ts" : Timestamp(1602044602, 11),
                        "t" : NumberLong(12)
                },
                "lastAppliedWallTime" : ISODate("2020-10-07T04:23:24.975Z"),
                "lastDurableWallTime" : ISODate("2020-10-07T04:23:22.958Z")
        },
        "lastStableRecoveryTimestamp" : Timestamp(1602044492, 7),
        "electionCandidateMetrics" : {
                "lastElectionReason" : "electionTimeout",
                "lastElectionDate" : ISODate("2020-10-07T04:19:54.787Z"),
                "electionTerm" : NumberLong(12),
                "lastCommittedOpTimeAtElection" : {
                        "ts" : Timestamp(0, 0),
                        "t" : NumberLong(-1)
                },
                "lastSeenOpTimeAtElection" : {
                        "ts" : Timestamp(1601673721, 7),
                        "t" : NumberLong(11)
                },
                "numVotesNeeded" : 2,
                "priorityAtElection" : 1,
                "electionTimeoutMillis" : NumberLong(10000),
                "numCatchUpOps" : NumberLong(0),
                "newTermStartDate" : ISODate("2020-10-07T04:19:55.550Z"),
                "wMajorityWriteAvailabilityDate" : ISODate("2020-10-07T04:19:56.455Z")
        },
        "members" : [
                {
                        "_id" : 0,
                        "name" : "mongodb1.devops.lab:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 424,
                        "optime" : {
                                "ts" : Timestamp(1602044604, 11),
                                "t" : NumberLong(12)
                        },
                        "optimeDate" : ISODate("2020-10-07T04:23:24Z"),
                        "syncSourceHost" : "",
                        "syncSourceId" : -1,
                        "infoMessage" : "",
                        "electionTime" : Timestamp(1602044395, 1),
                        "electionDate" : ISODate("2020-10-07T04:19:55Z"),
                        "configVersion" : 1,
                        "configTerm" : 12,
                        "self" : true,
                        "lastHeartbeatMessage" : ""
                },
                {
                        "_id" : 1,
                        "name" : "mongodb2.devops.lab:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 219,
                        "optime" : {
                                "ts" : Timestamp(1602044604, 6),
                                "t" : NumberLong(12)
                        },
                        "optimeDurable" : {
                                "ts" : Timestamp(1602044601, 9),
                                "t" : NumberLong(12)
                        },
                        "optimeDate" : ISODate("2020-10-07T04:23:24Z"),
                        "optimeDurableDate" : ISODate("2020-10-07T04:23:21Z"),
                        "lastHeartbeat" : ISODate("2020-10-07T04:23:24.801Z"),
                        "lastHeartbeatRecv" : ISODate("2020-10-07T04:23:25.012Z"),
                        "pingMs" : NumberLong(0),
                        "lastHeartbeatMessage" : "",
                        "syncSourceHost" : "mongodb1.devops.lab:27017",
                        "syncSourceId" : 0,
                        "infoMessage" : "",
                        "configVersion" : 1,
                        "configTerm" : 12
                },
                {
                        "_id" : 2,
                        "name" : "mongodb3.devops.lab:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 212,
                        "optime" : {
                                "ts" : Timestamp(1602044604, 6),
                                "t" : NumberLong(12)
                        },
                        "optimeDurable" : {
                                "ts" : Timestamp(1602044601, 5),
                                "t" : NumberLong(12)
                        },
                        "optimeDate" : ISODate("2020-10-07T04:23:24Z"),
                        "optimeDurableDate" : ISODate("2020-10-07T04:23:21Z"),
                        "lastHeartbeat" : ISODate("2020-10-07T04:23:24.801Z"),
                        "lastHeartbeatRecv" : ISODate("2020-10-07T04:23:25.031Z"),
                        "pingMs" : NumberLong(1),
                        "lastHeartbeatMessage" : "",
                        "syncSourceHost" : "mongodb1.devops.lab:27017",
                        "syncSourceId" : 0,
                        "infoMessage" : "",
                        "configVersion" : 1,
                        "configTerm" : 12
                }
        ],
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1602044604, 11),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1602044604, 11)
}

Crie um banco de dados e um usuário para o Graylog:

use graylog;
db.createUser( { user: "mongo_admin", pwd: "graylog", roles: [ { role: "root", db: "admin" } ] } )

Certo, com o Elasticsearch e o MongoDB configurados, vamos para o Graylog!

Graylog

Instalação

$ rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-3.3-repository_latest.rpm
$ yum update && yum -y install java-1.8.0-openjdk-headless.x86_64 graylog-server

Configuração

Você também consegue alterar o uso de memória do Java, o arquivo de configuração dessas opções que fica em /etc/sysconfig/graylog-server.

Antes de editar o arquivo de configuração, você irá precisar gerar duas senhas.

Para gerar a password_secret basta rodar o comando:

pwgen -N 1 -s 96

obs: caso não tenha o pwgen instalado basta seguir esses passos:

$ yum install epel-release
$ yum install pwgen

Para gerar a root_password_sha2, rode esse comando:

echo -n "Enter Password: " && head -1 </dev/stdin | tr -d '\n' | sha256sum | cut -d" " -f1

Após isso, edite o arquivo de configuração:

$ vim /etc/graylog/server/server.conf
is_master = true
password_secret = [gerada anteriormente]
root_password_sha2 = [gerada anteriormente]
root_timezone = America/Sao_Paulo
http_bind_address = graylog1.lab:9000
http_publish_uri = http://graylog.1.lab:9000/
elasticsearch_hosts = http://elastic1.lab:9200,http://elastic2.lab:9200,http://elastic3.lab:9200
elasticsearch_shards = 3
mongodb_uri = mongodb://mongo_admin:graylog@mongodb1.lab:27017,mongodb2.lab:27017,mongodb3.lab:27017/graylog?replicaSet=rs0

obs:

apenas deixe is_master = true em um dos servidores
modifique web.graylog1 para o endereço do server
modifique a linha elasticsearch_hosts com os endereços dos servidores do elasticsearch
modifique a linha mongodb_uricom os endereços dos servidores do mongo

Agora basta subir o server do graylog:

$ systemctl daemon-reload
$ systemctl enable graylog-server
$ systemctl start graylog-server

Após alguns minutos você irá conseguir acessar o endereço do graylog http://graylog1.lab:9000/. O login é admin e a senha é a que você inseriu no campo root_password_sha2.

HAProxy

o HAProxy vai servir como um balanceador de carga para o nosso cluster. Isso quer dizer que ao configurar o envio de logs, nós iremos mandar para o endereço do servidor que está o HAProxy e ele que vai ser o responsável por enviar para os servidores do graylog.

Instalação

yum update && yum install haproxy

Configuração

Edite o arquivo de configuração e insira os blocos:

$ vim /etc/haproxy/haproxy.cfg

listen stats
   bind :32700
   stats enable
   stats uri /
   stats hide-version
   stats auth devops:devopslab

listen syslog_1514
   bind *:1514
   mode tcp
   option tcplog
   timeout client 120s
   timeout server 120s
   default-server inter 2s downinter 5s rise 3 fall 2 maxconn 64 maxqueue 128 weight 100
   server graylog1 graylog1.lab:1514 check
   server graylog2 graylog2.lab:1514 check
   server graylog3 graylog3.lab:1514 check

O primeiro bloco é para a página de estatísticas que o HAProxy exibe, ao acessá-la você conseguirá ver o balanceamento de dados entres os servidores do graylog. Basta acessar o endereço do server na porta 32700:

O segundo bloco é a configuração da porta onde o HAProxy irá "ouvir" e depois realizar o balanceamento entre os servers. O "check" é para que ele verifique se o server está up antes de enviar.

Enviando log para o Graylog

Você consegue enviar praticamente qualquer log de sistema para o servidor do graylog. Neste guia eu vou demonstrar apenas como configurar o envio utilizando o rsyslog.

Para outros tipos de log, você pode utilizar o Graylog Sidecar, é um serviço que roda em segundo plano coletando logs que deseja enviar para a API do Graylog.

O primeiro passo para isso é configurar o Input na API do graylog, ele é o responsável por criar uma porta específica para os variados tipos de log.

Acesse a API do Graylog (no meu caso http://graylog1.lab:9000/) e siga os passos:

Vá em System
Depois em Inputs
Selecione SysLog TCP
Selecione Launch new Input

Ao seguir esses passos irá abrir uma janela para que preencha os detalhes do Input então vamos preencher os campos:

Marque a opção Global
Title: “Log Syslog”
Bind address: 0.0.0.0
Port:1514
Clique em Salvar.

Ao clicar em salvar, verá que o status do input passará de NOT RUNNING para RUNNING.

Agora que você já configurou o input, basta configurar o rsyslog da máquina que irá enviar os logs:

$ vim /etc/rsyslog.d/graylog.conf
*.* @@web.graylog.lab:1514;RSYSLOG_SyslogProtocol23Format

obs:Troque web.graylog.lab para o endereço do servidor do HAProxy

Reinicie o serviço

systemctl restart rsyslog

Após todos esses passos, ao acessar a API do Graylog, na aba Search você conseguirá visualizar, fazer consultas e criar dashboards personalizadas :)

última observação: Quando lidamos com cluster é muito importante que todos os servidores estejam com o mesmo horário, a divergência pode gerar erros no graylog.

Vlw pessoal! \o/