Anuncios

sábado, 19 de junho de 2021

Monitoração com Zabbix - Adição de host Linux


Olá pessoal, tudo bem? 

Espero que estejam todos bem e se cuidando!

Dando continuidade no assunto sobre Zabbix, hoje vamos ver como registrar os seus hosts Linux no Zabbix e assim passar a monitorá-los. Neste momento, pelo menos monitoração básica, ok?

Nosso host que iremos adicionar para monitorar no Zabbix:

IP: 192.168.100.112
SO: Debian 10.7
Hostname: debian-app-mon

Para instalar o Zabbix agent, execute o comando abaixo:
# apt-get install zabbix-agent

Terminando a instalação, devemos ter os arquivos dentro do diretório /etc/zabbix.


Iremos editar o arquivo zabbix_agentd.conf, localizando a linha Server e inserindo o IP do nosso Zabbix server:

Server=192.168.100.113

Feito isso,  vamos fazer o start do serviço e aproveitar para habilitar o serviço durante o boot.
# systemctl start zabbix-agent
# apt-get enable zabbix-agent
O serviço do agent estando OK, devemos ter uma saída parecida com a imagem abaixo:


Agora vamos a console de gerencia do Zabbix para fazer o cadastro do host na monitoração.

http://192.168.100.113/zabbix

No Menu do canto esquerdo, iremos clicar em Configuration:


Em seguida, vamos clicar em Hosts:


Vamos clicar agora em Creat host:


Na tela seguinte, iremos preencher as infos básicas do server que iremos adicionar e selecionar o tipo de registro/comunicação com este host:


Mediante então ao nosso lab, este é o exemplo de como ficaria o preenchimento. Ah, e muito importante é selecionar em Groups, os grupos de monitores que são correspondentes ao equipamento que está sendo adicionado. Como nosso server é Linux, devemos escolher "Linux servers". Ou seja, podemos criar grupos customizados de acordo com nossas aplicações, unidades de negócio, etc ... Você configura de acordo com o que faça sentido para sua organização ou seu cliente.
Em interfaces é onde vamos colocar o IP do host agent e a porta de comunicação. Caso você opte por monitorar via SNMP, IPMI, etc, é meste campo que você deve escolher.


Por fim, devemos clicar em Add assim que terminarmos de preencher tudo.

Automaticamente, você será redirecionado para tela anterior dos hosts que estão adicionados e nessa tela você já deve ver o que acabamos de adicionar.


Uma outra coisa que precisamos fazer é fornecer qual é o tipo de template que este host à ser monitorado faz parte.
Para isso vamos clicar no nome do host, Templates e selecionar os templates adequados:



Agora até que tudo seja coletado e a estrutura seja criada leva um tempo, que é o tempo de descoberta do agent, do que tem no server, do que tem pelo template que adicionamos lá para que ele possa construir toda estrutura para a view do Zabbix.


Passado um tempo, começamos a ter as visões de performance do host, parte de disco, network, etc:



Pelo menos o básico de monitoração para este host Linux já temos =)

Abs e até a próxima!
:wq!

sábado, 24 de abril de 2021

Monitoração com Zabbix - Instalação no Debian

Fala pessoal, tudo bem?
Espero que estejam todos bem!

Hoje vamos falar de monitoração, mais precisamente de monitoração com a ferramenta Zabbix.

Mas o que é o Zabbix?    
    - É uma ferramenta de monitoração de código aberto utilizada para monitoração de recursos de infraestrutura como Redes, Computação, Serviços e experiência de usuário.

Além disso é possível criar regras de relacionamento para análise de causa raiz para problemas que ocorram.

Sem contar a possibilidade de monitorar recursos por agente, sem agente, SNMP, IPMI e JMX. É realmente uma grande quantidade de opções.

Bem, vamos lá, para parte prática!

Nosso cenário será o seguinte:

  • Virtualização com VirtualBox;
  • Uma máquina virtual com Debian para ser nosso Zabbix Server
    • 1 vCPU
    • 2 GB Memory
    • 12 GB de Disco
    • Rede como Bridge Adapter
  • Uma máquina virtual com Debian para ser nosso cliente de monitoração
  • Uma máquina virtual com CentOS 7 para ser nosso cliente de monitoraçao
OBS.: Na parte dos clientes de monitoração, tanto faz o size da máquina que será criada, OK? O importante é estarem também como Bridge Adapter ou na mesma configuração de rede da máquina Zabbix Server para não termos problemas de comunicação.

1 - Instalando o Zabbix Server

O download pode ser feito pelo site ofical do Projeto Zabbix.

Os passos que devemos executar no server são:

a. Instalação do repositório
# wget https://repo.zabbix.com/zabbix/5.2/debian/pool/main/z/zabbix-release/zabbix-release_5.2-1+debian10_all.deb
# dpkg -i zabbix-release_5.2-1+debian10_all.deb
# apt-get update

b. Instalação do Zabbix Server, agent e frontend
# apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-agent

2 - Instalação e configuração do MariaDB/MySQL
# apt-get install mariadb-common mariadb-server mariadb-client

a. Iniciando o serviço do MariaDB e criando o serviço para start automático
# systemctl start mariadb ; systemctl enable mariadb

b. Reset da senha de root do banco. Para isso precisamos subir o banco em modo de segurança
# mysql_secure_installation
Enter current password for root (enter for none): Pressione Enter
Set root password? [Y/n]: Y
New password: <Enter root DB password>
Re-enter new password: <Repeat root DB password>
Remove anonymous users? [Y/n]: Y
Disallow root login remotely? [Y/n]: Y
Remove test database and access to it? [Y/n]:  Y
Reload privilege tables now? [Y/n]:  Y

c. Vamos agora criar o database e dar permissão para permitir conexão com a mesma, além disso vamos já aproveitar e fazer o import do schema e data e habilitar o strict mode. Lembrando que o import do schema pode levar alguns minutos
- Criando o database -
# mysql -uroot -p'Senha-do-Banco-de-Dados' -e "create database zabbix character set utf8 collate utf8_bin;"

- Permitindo conexão -
# mysql -uroot -p'Senha-do-Banco-de-Dados' -e "grant all privileges on zabbix.* to zabbix@localhost identified by 'Senha-do-usuario-zabbix';"

- Importando o schema e data-
# mysql -uroot -p'Senha-do-Banco-de-Dados' zabbix -e "set global innodb_strict_mode='OFF';"
# zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p'Senha-do-usuario-zabbix' zabbix

- Habilitando o strict mode -
# mysql -uroot -p'Senha-do-Banco-de-Dados' zabbix -e "set global innodb_strict_mode='ON';"

d. Agora precisamos inserir a senha do usuário zabbix utilizado para conexão com o banco de dados no arquivo de configuração /etc/zabbix/zabbix_server.conf
Utilize um editor de texto de sua preferência e insira na respectiva linha a seguinte entrada (normalmente o arquivo já tem essa linha, é só descomentar e inserir a senha)

DBPassword=Senha-do-usuario-zabbix
Salve o arquivo e pode sair do editor de texto.

Uma ponto importante é se você utiliza firewall local. Caso a resposta seja sim, você deve liberar as respectivas portas:
  • 10050/tcp
  • 10051/tcp
  • 80/tcp

Até mesmo no ambiente produção (fora este lab que estamos fazendo) é bom já deixar anotado para solicitar ou fazer as liberações no firewall.

3 - Agora vamos fazer o start e enable do serviço Zabbix Server e Agent Processes

# systemctl restart zabbix-server zabbix-agent ; systemctl enable zabbix-server zabbix-agent

4 - Configuração do Zabbix frontend (interface gráfica)

a. Vamos editar o arquivo /etc/zabbix/apache.conf e novamente, para isso escolha um editor de texto de sua preferência.
Ao abrir o arquivo, descomente a linha php_value date.timezone Europe/Amsterdam e troque o timezone para o qual você utiliza (normalmente, no nosso caso é America/Sao_Paulo).
php_value date.timezone America/Sao_Paulo

b. Restart e habilitar o serviço do Apache
# systemctl restart apache2 ; systemctl enable apache2

Agora para concluir essa primeira parte, vamos acessar a interface web do Zabbix para finalizar a configuração incial.

Para isso, acesse http://ip-do-zabbix-server/zabbix e siga os passo-a-passo das seguintes telas:





Terá um passo também, o qual não tirei print, onde será possível definir o tema do Zabbix =)

Ao finalizar a configuração, você será redirecionado para tela de login (usuário Admin e senha default zabbix).

E pronto, você deve ter acesso a uma console semelhante à essa:


Prontinho!
Primeira parte finalizada com sucesso se você conseguiu chegar até aqui =)

Na parte II iremos adicionar alguns hosts para iniciarmos nossa monitoração básica.

Espero que tenham gostado e que seja útil para o dia-a-dia de vocês.

Até a próxima...
:wq!

domingo, 21 de março de 2021

Jenkins - Pipeline para subir uma aplicação Java

Fala pessoal, beleza?

Espero que estejam todos bem!

Conforme meu post sobre Jenkins e pipeline para deploy de uma aplicação, vamos para segunda parte.

A primeira parte foi apenas para instalação e a segunda agora é para criação e uso de um pipeline.

Vamos definir pipeline como uma sequência de instruções que serão executadas até finalizar e prover uma entrega.

Nosso cenário será o seguinte:

  • Um servidor com o Jenkins instalado e configurado (feito no posto anterior)
  • Um servidor com linux instalado onde iremos subir um pacote de uma aplicação java que ao final do deploy nos dará uma ferramenta de monitoração
  • Chave SSH entre o servidor do Jenkins e o servidor onde a aplicação será instalada
  • Pipeline com as instruções para cada passo que iremos definir no processo de deploy (cópia de arquivos, descompactação, ajuste de parâmetros, criação de serviços, start

Uma observação importante: Eu não sou um expert e nem estou falando que este modelo de pipeline que estou propondo é o melhor e que não podemos fazer de outra forma. Essa foi uma forma que achei para ajudar em uma necessidade do meu dia-a-dia, OK? Cada um deve avaliar a melhor forma de usar a estrutura de funcionalidade e adaptar para o seu uso.

Agora vamos a criação do pipeline na console do Jenkins. 

Para isso clicar em New Job - Insira um nome - Clique em pipeline - OK


Agora irá abrir uma nova tela de configuração onde podemos colocar um comentário para documentarmos melhor o pipeline, algumas opções via checkbox para não termos deploys concorrentes, usar po Git, etc.

No nosso caso, não iremos marcar nenhuma opção. Vamos direto no campo pipeline e inserir a estrutura abaixo:

pipeline {
    agent none
    environment {
            IP = "xx.xx.xx.xx"
    }
    stages {
        stage ('Copia o pacote da aplicacao para o servidor') {
            agent any
           
            steps {
                sh '''#!/bin/bash
                scp /home/jenkins/repoapp/mon-java.tar.gz root@$IP:/opt
                '''
            }
        }
        stage ('SSH + desccompacta pacote do aplicacao') {
            agent any
            steps {
               sh '''#!/bin/bash
               ssh -o StrictHostKeyChecking=no root@$IP << EOF
               tar xzvf /opt/mon-java.tar.gz -C /opt
               exit
               EOF
               '''
            }
           
        }
        stage ('Adiciona usuario banco Postgres e muda permissao do data e tmp'){
            agent any
            steps {
                sh '''#!/bin/bash
                ssh -o StrictHostKeyChecking=no root@$IP << EOF
                useradd -m -d /opt/ManageEngine/OpManager/pgsql/ postgres
                chown -R postgres:postgres /opt/ManageEngine/OpManager/pgsql/tmp/
                chown -R postgres:postgres /opt/ManageEngine/OpManager/pgsql/data/
                exit
                EOF
                '''
            }
        }
        stage ('Cria o serviço e incia a aplicacao'){
            agent any
            steps {
                sh '''#!/bin/bash
                ssh -o StrictHostKeyChecking=no root@$IP << EOF
                cd /opt/ManageEngine/OpManager/bin/
                ./linkAsService.sh
                systemctl daemon-reload
                systemctl start OpManager.service
                exit 0
                EOF
                '''
            }
        }
        stage ('Alguns tunings na aplicacao'){
            agent any
            steps {
                sh '''#!/bin/bash
                ssh -o StrictHostKeyChecking=no root@$IP << EOF
                sed -i 's/wrapper.java.initmemory=512/wrapper.java.initmemory=600/g' /opt/ManageEngine/OpManager/conf/wrapper.conf
                sed -i 's/wrapper.java.maxmemory=1024/wrapper.java.maxmemory=1500/g' /opt/ManageEngine/OpManager/conf/wrapper.conf
                sed -i 's/24MB/1024MB/g' /opt/ManageEngine/OpManager/pgsql/data/postgres_ext.conf
                sleep 4m
                exit
                EOF
                '''
            }
        }
 }
}

Vejam que temos uma variável neste pipeline: IP = "xx.xx.xx.xx"
Trabalhar com variáveis torna o nosso pipeline mais preciso, pois em qualquer ponto necessário iremos declarar apenas a variável e seu conteúdo pode sofrer alterações que será replicado para todos. =)
Vale o mesmo conceito adotado em programação...

O IP da nossa máquina de aplicação neste exemplo é: 192.168.100.109, então devemos colocar este IP na variável.

Agora vamos no servidor do Jenkins, na shell do user Jenkins copiar nossa chave SSH para o servidor de aplicação:


Com isso, ao tentar acessar SSH o servidor destino através do shell do usuário Jenkins, não será solicitado senha (por que no meu exemplo foi configurado dessa forma). Se você colocar senha em sua chave, será necessário criar um mecanimos para essa senha seja digitada automaticamente no pipeline. 

** Importante **

A questão de ter que fazer o passo da chave SSH pode ser resolvido se no seu processo de deploy ou criação do ambiente (máquina virtual, instância, físico não importa) se você já adicionar a chave SSH do usuário Jenkins =)

Bem, agora na console do Jenkins vamos  clicar no pipeline que criamos e na opção Build Now, para o processo começar.

O legal é que para cada passo que criamos dentro do pipeline, ele irá gerar uma saída com a identificação, e caso necessário um log da execução.



Ao término, dando tudo certo, o pipeline ficar tudo "azul" indicando que todos os passos concluíram com sucesso.
Caso algum item apresente erro, teremos uma indicação na cor vermelha e com um breve log do possível erro para tratarmos.


Legal também é que temos o tempo que cada step demorou em sua execução completa.

Agora validando no servidor de aplicação, devemos ter nossa ferramenta de monitoração instalada, configurada com os tunings que fizemos, os serviços criados, etc. Sendo que no nosso caso basta apenas acessar a URL e autenticar para ver se ela encontra-se disponível para uso.





A ideia deste pipeline é para uma execução bem simples, mas que automatiza uma tarefa que poderia demorar fazendo tudo de forma manual, nos dando maior possibilidade de erros humanos, cada um fazendo um deploy de um jeito diferente, etc.

Lembre-se que existe uma infinidade de possibilidades de configuração e cenários para uso. Com issa ideia "base" espero que vocês possam adequar so seu modelo de uso e assim tornar tarefas corriqueiras automatizadas da melhor forma possível.

Por hoje é isso!
Abs e até a próxima.
:wq!

sexta-feira, 22 de janeiro de 2021

Ubuntu - Problema para traduzir OIDs de uma MIB (SNMP)

 E aí pessoal, tudo bem?

Um dica rápida para quem usa Ubuntu Server ou até mesmo para quem está estudando as possibilidades de utilizá-lo depois do anúncio do fim do CentOS.

Bem, pra quem trabalha com monitoração é comum ter que configurar o serviço SNMP no servidor para que ele possa envitar traps ou até mesmo para que a monitoração faça consultas e assim gerar a coleta do consumo de recursos e/ou disponibilidade.

Bem, vou tentar explicar brevemente algumas coisas antes de continuar:

SNMP

  • Simple Network Management Protocol - resumindo, é o protocolo mais utilizado para podermos saber o que está acontecendo dentro de um equipamento que tenham suporte a este serviço (exemplo: servidores, equipamentos de rede, alguns storages, etc).
  • MIB - As mibs descrevem de forma hierarquica como a gestão dos dados devem acontecer, contendo identificadores (OID) para cada objeto.
  • OID - Uma estrututra hierarquica onde com a separação da árvora em alguns pontos temos as identificações do fabricante, modelo do equipamento, versão, recursos que podem ser "coletados".  Ao pé da letra, é a identificação do objeto dentro da árvore da MIB.

Exemplo da estrutura de uma MIB:


 Imagem do site Support Huaewi - Switch CloudEngine 8800, 7800, 6800, and 5800 V200R003C00.

Acontece que fazendo uma "varredura" em um equipamento por toda estrutura do SNMP que ele responde, pode não ser muito amigável a saída de cada OID. Isso mesmo! Podemos ter saída apenas no formato número e para saber o que é cada item, ter que pegar o número, consultar na internet ou documentação da MIB para verificar qual componente/monitor ele se refere.

Existe algumas opções de comando que fazem a tradução destes OIDs para nomes mais amigáveis e assim podermos ter uma noção melhor do monitor ao qual o OID se refere.

No Ubuntu Server, encontrei um problema onde essa tradução não estava funcionando e por isso resolvi fazer este post para compartilhar.

 Para os testes vamos utilizar o comando:

# snmpwalk -t -2 -v2c -c servers IP-DO-DEVICE .1.3.6.1.2.1.25.2.3.1.2

Como podemos ver na imagem acima, não temos a menor ideia do que é cada OID ou cada monitor por assim dizer, quando fazemos uma consulta específica por um bloco da estrutura da MIB.

No Ubuntu Server para resolver isso, precisamos comentar a linha "mibs :" no arquivo /etc/snmp/snmp.conf

Após comentar a linha e salvar o arquivo, devemos fazer o restart do serviço do SNMP

# systemctl restart snmpd.service

E ao fazer o mesmo teste novamente, a saída deve ser semelhate à abaixo:

Apenas como comparativo, quando utilizava CentOS isso não era necessário, pois a configuração que vinha "padrão" na instalação funcionava dessa forma.

Mas é isso ...

Nem tudo é igual no mundo Linux quando falamos de uma distribuição para outra, alguns ajustes requerem mais interação nossa, etc...

Espero que isso ajude.

Até a próxima.

Abs

:wq!