Pré-requisitos DevOps

Você sabe o significado de pré-requisito e pra que ele serve?

Segundo o “pai dos burros”, vulgo dicionário, pré-requisito é uma condição prévia indispensável para se alcançar algo, seguir uma formação, fazer um curso, ocupar uma função etc. Ou seja, é uma disciplina cursada obrigatoriamente antes de outra, por envolver conhecimentos prévios necessários ao estudo de disciplinas posteriores (uma ou mais).

Quem me conhece sabe que eu sempre bato nessa tecla de ter conhecimentos básicos e sólidos justamente para você saber o que está fazendo. Em grupos de tecnologia vemos diariamente pessoas fazendo perguntas que soam a “imbecilidade” no ponto de vista de pessoas que tem os conhecimentos básicos na veia. Isso porque a pessoa que desdenha de tais questionamentos creem que o indivíduo que faz uma pergunta básica em um deveria ter a resposta se tivesse conhecimentos básicos sobre o assunto. Eu disse básico. Básico é diferente de aprofundado. Quando eu digo conhecimento básico, é ter o mínimo necessário para conseguir seguir a fluência necessária em um conhecimento mais avançado. E o que vemos atualmente são pessoas pulando etapas querendo aprender ferramentas sem ter os pré-requisitos necessários. Resumindo, vai ser uma BOSTA de DevOps.

Eu poderia ficar enchendo linguiça desse post colocando vários exemplos aqui. Mas, vou me abster e mostrar apenas um desses exemplos:

Em um grupo de Docker, um indivíduo envia uma mensagem perguntando se ele poderia ter duas ou mais aplicações em uma mesma porta. Um segundo indivíduo responde ao primeiro que pode, desde que ele não mapeie uma porta já usada por outro serviço no host. Claramente aqui nesse exemplo o primeiro indivíduo não tem conhecimento técnico básico do Modelo OSI, suas camadas, protocolos de rede etc. Sem contar que ele também não deve ter lido a própria documentação da ferramenta, que expõem detalhes de como um container Docker é isolado do sistema, podendo executar aplicações que usam a mesma porta, só que no container, e não no host que roda os containers. Sendo assim, ele pecou em não ter os pré-requisitos para usar uma ferramenta. Já quis pular etapas sem ter conhecimento prévio (mais uma vez o chato aqui falando de base sólida). Pecou novamente porque poderia ler a documentação e entender como funciona o isolamento de containers do sistema, entre eles o uso de redes.

Afinal, o que eu preciso aprender para me tornar um DevOps?

Você precisa aprender o básico de Linux. Não leia como básico aqui aprender a instalar e executar comandos básicos no terminal. Eu digo aprender o suficiente para você seguir as etapas seguintes, ou seja, fazer cursos de DevOps e as ferramentas utilizadas nesse mercado.

Com isso, aqui vai algumas dicas do que você deve fazer.

  • Aprenda a trabalhar no terminal
  • Aprenda sobre gerenciamento de pacotes
  • Aprenda editor VI/VIM
  • Estude sobre serviços
  • Estudo e aprenda o básico de redes no Linux (roteamento, DNS, firewall etc).
  • Antes de estudar sobre container, entenda sobre máquinas virtuais e quais as diferenças. Lembre-se de aprofundar em ferramentas como Vagrant (não fique no modo manual do VirtualBox).
  • Faça laboratórios usando várias VMs interconectadas em rede. Teste regras de firewall, roteamento etc. (quem disse que você sempre vai trabalhar com cloud?). Fazendo labs você vai ganhar confiança na configuração de um ambiente e de quebra vai aprender a solucionar de problemas de rede.
  • Estude o básico de como construir e implantar aplicações (Python, Node, Go etc.). No site bitnami.com você encontra várias stacks para fazer laboratórios em cloud, containers ou VMs. Isso vai ajudar você a ganha experiência pratica em vários cenários e ambientes. Você pode ver um exemplo básico aqui nesse post.
  • Estude Git e ferramentas de gerenciamento de controle de versão.
  • Estude o básico sobre banco de dados relacionais e NoSQL.
  • Aprenda sobre SSL e TLS. (pular isso aqui vai ser automutilação).
  • Aprenda YAML e JSON.
  • Estude o básico sobre o funcionamento de APIs e para que isso serve.

Eu preciso mesmo ter pré-requisitos?

No meu entendimento, qualquer pessoa pode iniciar uma carreira ou almejar um cargo sem pré-requisitos. Só que a história sempre mostra que mesmo que uma pessoa que não é da área de TI, que não fez faculdade etc. corre atrás de entender como funciona tal tecnologia. Essa pessoa corre atrás de suprimir o mínimo necessário para seguir adiante. Ela busca o conhecimento básico, os tais pré-requisitos que foi o que me fez escrever esse post. Esses profissionais geralmente se destacam da maioria.

Só que o mundo não tem 100% desse tipo de pessoas.

Temos também os profissionais que preferem pular etapas. Eles denigrem a sua própria imagem. Pular etapas me soa também como pegar atalhos. Mas, sabe aquele cara que pega um atalho na sorte e não sabe o que pode acontecer com a escolha que ele fez lá atrás? Isso acontece porque ele não estudou os caminhos, as dificuldades que pode encontrar nos atalhos. Pegar atalho errado é certeza de se dar mal. E se dar mal no mercado é sujar a sua imagem, que vai fazer você ficar estagnado.

Portanto, pense na sua carreira e só pegue atalhos que você saiba o que pode acontecer. Não se aventure em uma ferramenta se você não tem os pré-requisitos técnicos e muito menos não tem o conhecimento básico sobre a ferramenta. Nunca ache que isso vai ser desnecessário, perda de tempo. Muito pelo contrário, quem ganha mais com isso é você mesmo.

Lembre-se. Antes de se aventurar no mundo Cloud, DevOps e afins, não se esqueça de suprimir a parte fundamental que limita seu avanço.

Deixo aqui um roadmap muito legal que você pode seguir para auxiliar nos estudos. Entro em detalhes mais aprofundados nele em um post futuro.

Bons estudos.

Construindo e executando uma simples aplicação web em Docker.

Já começo avisando que neste artigo eu não vou ensinar a instalar o Docker. Na documentação oficial você encontra detalhes de como fazer isso.

Nosso principal objetivo é construir uma imagem docker de uma aplicação web Python. Como objetivo secundário, iremos realizar alguns troubleshooting para subir nossa aplicação e aumentar os skills necessários para resolver problemas básicos relacionados ao contexto do que aprenderemos nesse post.

O primeiro passo é agrupar os arquivos da nossa aplicação e suas dependências em um container. Para isso, vamos fazer o seguinte:

Temos aqui uma aplicação simples que irá exibir Hello World! assim que você acessar a aplicação pelo teu browser favorito.

from flask import Flask
app = Flask(__name__)


@app.route("/")
def hello():
    return "Hello World!\n"


if __name__ == "__main__":
    app.run(host='0.0.0.0')

Repare na primeira linha do código que importamos a biblioteca Flask, que é um framework muito popular usado entre os desenvolvedores Python.

Crie um diretório para ser a base do seu aplicativo. Sugiro web-python. Dentro desse diretório, cria outro diretório chamado app e salve o código acima como helloworld.py.

O que precisamos fazer para rodar nossa aplicação em um container?

Basicamente, precisamos fazer o build da imagem docker. Ou seja, iremos empacotar a aplicação em uma imagem de container.

Antes de construir nossa imagem, vamos parar para pensar como rodaríamos essa aplicação diretamente em nosso ambiente de desenvolvimento.

Você precisaria do ambiente Python instalado em seu sistema, que ficaria responsável por interpretar seu código. Você também precisa instalar o framework Flask.

  • Precisamos de uma versão específica do Python e também do Flask. A versão do Python para ter o suporte necessário para executar o código na versão que o mesmo foi desenvolvido e a versão da biblioteca do Flask para você amarrar a versão específica que foi testada durante o desenvolvimento. Mais tarde vou explicar o porque de usar essa abordagem.
  • Só para criar uma simples imagem de uma aplicação em container vai envolver o conhecimento básico de algumas tecnologias. Para não entrar muito em detalhes, vou exemplificar algumas: gerenciamento de pacotes, imagens de sistemas operacionais e execução de comandos.

Dica: sempre crie um ambiente Python para executar seus códigos. Nunca instale bibliotecas diretamente no sistema operacional.

Vamos ao que interessa

Para empacotar nossa imagem, vamos criar um arquivo Dockerfile com o seguinte conteúdo:

FROM ubuntu:20.04
RUN apt-get update -y && apt-get install -y python3-pip python3-dev
COPY requirements.txt /app/requirements.txt
WORKDIR /app
RUN pip3 install -r requirements.txt
COPY ./app/helloworld.py /app
ENTRYPOINT ["python3", "helloworld.py"]

Salve o arquivo Dockerfile na pasta principal. Se você seguiu minha sugestão, esse arquivo ficará na raiz do diretório web-python.

  • Na linha 1, informamos qual a distribuição linux iremos utilizar como imagem base para construção da imagem da aplicação.
  • Em seguida (linha 2), partimos para a execução de comandos para instalar o Python em nossa imagem.
  • Depois, copiamos o arquivo que armazena os pre-requisitos para rodar nossa aplicação (linha 3), informamos o diretório padrão de trabalho da nossa aplicação dentro do container (linha 4) e fazemos a instalação des pre-requisitos (linha 5).
  • Por fim, copiamos o código da nossa aplicação (linha 6) e informamos o que deverá ser executado quando o container for inicializado (linha 7).

Com o arquivo Dockerfile pronto, vamos criar o arquivo requirements.txt (que fizemos referência) e salvá-lo na pasta raíz web-python com o seguinte conteúdo:

Flask==1.1.2

Lembra que eu comentei de amarrar a versão da biblioteca do Flask. Isso é necessário para não correr o risco de quebrar a nossa aplicação caso for preciso criar uma nova versão da imagem docker. Se você apenas informar a biblioteca Flask, o gerenciamento de pacotes pip vai tentar instalar a última versão disponível do pacote. Digamos que ele tente instalar a versão 1.1.3 e esta teve uma modificação que quebra o seu código. Sua aplicação não irá funcionar como esperado e como foi testado no ambiente de desenvolvimento.

A estrutura da nossa aplicação ficará conforme a seguir:

$ tree
.
├── Dockerfile
├── app
│   └── helloworld.py
└── requirements.txt

1 directory, 3 files

Com a estrutura da nossa aplicação pronta, podemos usar o comando para construir nossa imagem:

docker build -t helloworld-server .

Para rodar nossa aplicação, executamos:

docker run -d helloworld-server

Um dos principais motivos que me fez escrever esse post foi para demonstrar que muitas pessoas que querem ingressar na área de DevOps querem pular etapas, mesmo sem saber que estão pulando (neste caso é porque estão sendo enganadas). E não digo isso apenas para os que estão começando na área, mas também para profissionais que já tem certa experiência e estão mais preocupados em adquirir conhecimentos em ferramentas e esquecem que devem ter conhecimentos sólidos de toda a parte que envolve determinadas tecnologias (digo conceitos se sistemas operacionais, redes etc.).

Vocês observaram que no início do post eu citei que para construir a imagem da nossa aplicação, precisamos ter conhecimento básico de alguns comandos de sistemas, instalação e gerenciamento de pacotes?

Pois bem. Se você chegou a executar o container com a imagem que construímos, deve ter reparado que a nossa aplicação não abriu no navegador. Eu fiz isso de propósito. O que faltou para a nossa aplicação funcionar?

Antes de eu dar essa resposta, por que não verificamos se a nossa aplicação está funcionando dentro do container? Para isso, vamos acessar o terminal do container executando o seguinte comando:

docker exec -it <id-do-container> bash

Para verificar o id do container, execute docker ps que você irá obter uma resposta parecida com a seguinte:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
faa60fb6a829 helloworld-server "python3 helloworld.…" 9 minutes ago Up 9 minutes sweet_hermann

Você também pode obter acesso ao terminal do container passando o nome ao invés do seu ID.

Já dentro do container, vamos instalar o curl, uma ferramenta para várias utilidades. Uma delas é testar acesso a sites direto do terminal.

apt-get install curl -y

Em seguida, vamos fazer o teste de acesso a nossa aplicação:

curl http://localhost

E receberemos a seguinte mensagem:

curl: (7) Failed to connect to localhost port 80: Connection refused

Ora, não conseguimos acesso a aplicação?

Será que nossa aplicação está rodando no container. Vamos verificar?

# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 1.2 105156 25272 ? Ss 21:19 0:00 python3 helloworld.py
root 168 0.0 0.1 4244 3520 pts/0 Ss 21:29 0:00 bash
root 178 7.0 0.1 5900 2904 pts/0 R+ 21:33 0:00 ps aux

Nossa aplicação está sendo executada. Se você tem conhecimento do framework Flask, sabe que uma aplicação por padrão roda em uma porta específica. Mas, se você não tem conhecimento e chegou até aqui nesse post, como saber em que porta a aplicação está rodando. Vamos instalar mais uma ferramenta para descobrirmos isso:

apt-get install net-tools -y

Instalamos o pacote net-tools. Mas, a ferramenta que iremos usar é a netstat que vem instalada com esse pacote.

Agora executamos o comando:

# netstat -ntal
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN
tcp 0 0 172.17.0.2:46426 91.189.88.152:80 TIME_WAIT

Observe que a primeira linha iniciada com tcp faz referência a 0.0.0.0 (que definimos como valor de host na última linha de código da nossa aplicação), seguida de :5000. Essa é a porta onde a aplicação está em execução. Agora, podemos fazer o teste certo:

curl http://localhost:5000
Hello World!

Tivemos o retorno esperado da nossa aplicação.

Sabendo que nossa aplicação está funcionando dentro do container, podemos matar o container

docker rm -f <id_do_container>

E agora executamos novamente o container passando o parâmetro de mapeamento de portas.

docker run -d -p 8080:5000 helloworld-server

Executando docker ps, podemos observar que o mapeamento de portas está configurado para nosso container:

docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e786dc13503e helloworld-server "python3 helloworld.…" 2 seconds ago Up 1 second 0.0.0.0:8080->5000/tcp exciting_hypatia

A porta 8080 será a porta que estará listada no host onde o docker está rodando. Ao ser requisitado acesso a porta 8080, automaticamente o acesso será encaminhado para a porta 5000 do container.

Agora podemos abrir o browser e acessar nossa aplicação passando a porta 8080.

Pronto. Nossa primeira aplicação em container rodando 100%.

Viram que para subir uma simples aplicação web, passamos por várias tecnologias, conceitos básicos, ferramentas etc.

Eu poderia muito bem resumir esse post apenas passando os comandos certos para você executar e no final ter a sua aplicação rodando lindamente, sem ter passado pelos erros que simulamos aqui.

O que eu quero postar no blog a partir desse artigo é para ajudar você a pensar em aprender a dominar uma tecnologia, aprender a ter conhecimentos sólidos e básicos de tudo que envolve para você resolver problemas. Infelizmente, nos últimos anos, muitos profissionais estão sendo “adestrados” por cursos e vídeos em redes sociais para serem fanáticos por ferramentas, meros mortais executores de comandos sem saber o que está fazendo. E acredite. Se você está se sentindo assim, o objetivo dessas pessoas está sendo atingido. Eles não querem que você pense para resolver problemas. Eles querem que você siga passos prontos e assim você sempre fica na dependência de uma nova dica de como fazer. Mas, nunca como você deve aprender.

A pergunta que eu faço é:

Você quer ser mais um desses “adestrados” e não se destacar no mercado de trabalho?

Se sua resposta for não, comece a seguir este blog, compartilhe com seus colegas. Eu vou continuar a minha missão aqui, que é passar conhecimento de verdade. E tenho outros amigos que desejam fazer o mesmo porque temos o mesmo intuito, mudar tudo que está sendo feito nesses últimos anos. E temos experiência para isso.

Em um post futuro vou demonstrar como podemos melhorar a construção da nossa imagem Docker e deixar ela mais otimizada. Por que para melhorar, sempre existe um jeito. Antes, teremos mais novidades.

Até a próxima.

É possível implantar cultura DevOps em empresas de pequeno porte?

Empresas pequenas raramente trabalham com uma estrutura funcional. Ou seja, elas não centralizam expertise, pois não possuem estruturas hierárquicas altas.

Empresas de pequeno porte não dividem os times de TI por especialidades (SysAdmin, DBA, Desenvolvedor etc.), mas preza pelo generalismo, o que acaba tornando os times independentes, entregando valor mais rápido para o cliente. Isso ajuda essas pequenas empresas a atingirem os resultados do DevOps em um período mais curto ao compararmos com empresas de médio e grande porte.

Conteúdo exclusivo para assinantes

Inscreva-se para obter acesso e continue sua leitura.

Subindo um cluster Kubernetes para estudos

Você está cansado de ficar brincando com o Minikube ou com o Kind?

Tá passando raiva com o Play with Kubernetes?

Quer subir um cluster K8S, mas seus créditos 0800 nos cloud providers se esgotaram?

Tá bom, tá bom!!! Isso não é propaganda das Organizações Tabajara.

Ok, vou tentar te ajudar.

Vamos usar três VM’s para subir nosso LAB K8S e brincar quando quiser.

Conteúdo exclusivo para assinantes

Inscreva-se para obter acesso e comece a ler agora mesmo.

Elimine tarefas penosas

Com tanta tecnologia envolvida atualmente e com as tarefas com prazos curtos para serem executadas, acaba que o SysAdmin, de maneira geral, não tem tempo para estudar novas tecnologias e se atualizar com o que o mercado está exigindo. O ideal de um SysAdmin que deseja ter sucesso em sua carreira, é que ele não perca tempo com tarefas operacionais, ou o que chamamos de tarefas penosas.

Antigamente, os SysAdmins se permitiam a ter o prazer de executar determinada tarefa que levava um tempo considerável de seu dia a dia de trabalho. E muitos até gostavam disso. Porém, o mundo evoluiu. Ficar fazendo trabalho repetitivo não vai fazer você evoluir. O ideal é você tornar aquela tarefa repetitiva (penosa) em uma tarefa automatizada, que faça o trabalho penoso para você. Portanto, tudo que for tarefa operacional e você puder automatizar, faça isso. Se for uma tarefa que você não tenha previsão de executar em um intervalo curto de tempo, analise se vale ou não automatizar o que lá na frente não será usado. Nesse caso, é  perder tempo fazendo algo desnecessário. Para esses casos, faça o básico, usando ferramentas mais práticas e que você já tem domínio sobre elas.

Se você estiver resolvendo um problema novo ou inventando uma nova solução, essa tarefa não é considerada tarefa penosa. Então, vale a pena você já pensar em automatizar uma tarefa que pode tornar-se penosa lá na frente. Neste caso, vale até estudar novas ferramentas para usar uma solução mais sólida e que você poderá ir adicionando novos recursos ao longo do tempo e, por que não, de seu uso.

O que não falta para um SysAdmin hoje em dia é eliminar tarefas penosas. Portanto, para eliminar essas tarefas, você precisará de algumas ferramentas:

  • Básicas, mas que ainda podem ser úteis:
    • Shell Script
    • Cron
    • AWK, grep (e suas variações), sed etc.
    • Expressões regulares (isso você sempre vai precisar)
  • Mais voltadas para o mundo DevOps

Por que você deve eliminar tarefas penosas?

  • Estagnação na carreira
    • O progresso de sua carreira se tornará mais lento se você ficar executando tarefas repetitivas a todo instante ao invés de utilizar esse tempo para estudar novas tecnologias e propor soluções para sua empresa.
  • Baixo moral
    • Tarefas penosas em grande volume resultam em tédio e insatisfação. Pode confiar, muitos SysAdmins se sentem assim. Não seja mais um para essa estatística.
  • Produtividade baixa
    • Se você perder seu tempo executando tarefas repetitivas, você estará deixando uma tarefa importante em atraso.

Esse texto foi escrito baseado na leitura do capítulo 5 do livro Site Reliability Engineering.

Zabbix x Software Livre

Não é mais segredo que muitas gigantes de tecnologia e de varejo usam ferramentas livres (AWS, UOL, Mercado Livre, Renner, Pão de Açúcar, etc).

Uma coisa é usar um Sistema Operacional e outra é usar uma plataforma como o Zabbix, que é mantido somente por uma empresa, apesar das dezenas de desenvolvedores, mas que ainda assim depende da comunidade para identificar BUGs e receber feedbacks.

Antes de mais nada, reflita por qual motivo você usa SL. Se a resposta for porque não há custo de licenciamento, pense que não é porque não existe licença que não haverá mão de obra para implantá-lo, onde em ferramentas pagas, na maioria das vezes, é tudo muito mais simples. Mas, se a resposta for porque você se identifica com o propósito do Torvalds, você não terá nenhuma dificuldade em usar o Zabbix.

Mas então do que esse post se trata? Simples, seja qual o for o seu motivo de usar o Zabbix, tenha sempre em mente que as melhores práticas do SL devem ser colocadas em prática para que você ou a empresa a qual você implantou o Zabbix possa usufruir da plataforma.

Algumas delas:

  • Use sempre as versão mais estáveis
  • Mantenha sempre o SO atualizado (Atualizado não é o mesmo que o mais novo, ok?)
  • Faça backups/snapshot das configurações que virão a ser alteradas SEMPRE
  • Ao identificar problemas, se possível, reporte ao desenvolvedor e/ou a comunidade para que outros não passem pelo que você passou

Atitudes como essa, fizeram do Linux o que ele é hoje e continuaremos a ter soluções para os nossos problemas tão boas quanto aos softwares pagos se mantivermos o mesmo sendo de coletividade.

Agora se você não se identificou com nada que eu escrevi acima e só precisa do Zabbix para substituir qualquer outra ferramenta, peça ajuda a um especialista pois além de você perder muito tempo, poderá não saber usar todos os recursos e executar os pré-requisitos que o Zabbix ou qualquer outra plataforma livre necessite.

Aproveitando, segue o links para o report de BUGs da Zabbix SIA.

https://support.zabbix.com/

Fim do suporte completo para o Zabbix 4.4

Para quem ainda utiliza o Zabbix 4.4, hoje (31/03/2020) vence o full support dessa versão.

Isso significa que essa versão receberá apenas correções de problemas críticos e de segurança por mais um mês. Então, se você ainda utiliza essa versão, comece já a planejar para atualizar o seu ambiente para a próxima versão LTS que em breve estará disponível, a aguardada versão 5.0.

A Zabbix SIA não garante nenhuma correção de código para versões mais antigas e versões não estáveis.

Fonte: https://www.zabbix.com/life_cycle_and_release_policy

Novo fôlego para o monitoramento MySQL via ODBC

Desde que o Zabbix incorporou o suporte nativo a monitoração de banco de dados (realizada via ODBC), vejo muita gente torcendo o nariz para o uso desse tipo de monitoração.

Antes mesmo da Zabbix SIA disponibilizar esse tipo de monitoração, muitos SysAdmins já usavam soluções como o falecido DBforBix, PyODBC e até mesmos scripts personalizados para efetuar monitoramento de bases de dados.

Fato é que o monitoramento ODBC nativo do Zabbix veio para facilitar a implementação para esse tipo de monitoramento. Porém, nem tudo são flores. Administrar as configurações de bases de dados nos arquivos odbc.ini e tnsnames.ora, por exemplo, não é tarefa fácil quando você monitora muitas instâncias de banco de dados. Para ajudar essa administração, desenvolvi o Zabbix2ODBC na empresa em que trabalho e o projeto virou open source. Este projeto está disponível desde 2019 no GitHub. Em uma postagem futura vou mostrar como usar a imagem Docker desse projeto.

Além da dificuldade em administrar os arquivos de configuração, ainda existe o problema principal do monitoramento ODBC, que é a performance. Raramente você vai notar perda de performance monitorando poucas bases de dados. Passando de 100 bases de dados com uma média de 50 itens coletados num intervalo médio de 3 minutos (usando um proxy com 4 CPUs e 8 GB de RAM), você já começa a sentir atraso na coleta dos dados. Isso acontece porque o monitoramento nativo de banco de dados do Zabbix utiliza uma conexão ao banco de dados para cada item configurado no host monitorado. Isso já causa um bloqueio temporário do poller do Zabbix Agent, pois o processo precisa aguardar a resposta do banco de dados com a métrica solicitada pelo processo de coleta para liberar o recurso, que pode partir do Proxy ou do Zabbix Server. Aqui uma observação: se você não usa Zabbix Proxy para esse tipo de coleta, corrija isso imediatamente. Além do uso de recursos de poller, existe outro problema ainda maior, que é o overhead no uso de CPU e load do sistema. Isso acontece pelo uso excessivo aos arquivos de configuração odbc.ini e tnsnames.ora (quando o Oracle é monitorado).

Para evitar o atraso na coleta de dados em grandes ambientes (que monitoram centenas ou milhares de instâncias de banco de dados) são necessários recursos computacionais (CPU e memória) para suprir a demanda pelo “faminto” monitoramento ODBC.

O que vem por aí? Teremos novidades?

No dia 30/01/2020, a Zabbix SIA disponibilizou um novo template para monitoramento do MySQL. Eu testei esse template e ele é compatível com a versão 4.4. A Zabbix SIA já está preparando o terreno para as novidades presentes na versão 5.0

Vale ressaltar que a versão 4.4 do Zabbix não é LTS e eu não recomendo o uso dessa versão em ambiente de produção. Se você está ansioso para testar esse template, que o faça em uma ambiente de testes/homologação.

Qual o ganho de uso com esse template?

O que eu observei nesse template, é que ele utiliza 5 itens ODBC nativo (sendo 2 em regras de discovery) e o restante são itens dependente usando recursos de pré-processamento de valores.

Isso significa que você terá um ganho elevado na performance, pois o seu sistema reduzirá drasticamente o uso de poller do Zabbix responsável por esse tipo de coleta, sem contar a redução do uso de CPU, que também contribuirá com a diminuição do load do sistema. Outro detalhe importante é que na versão 4.4 o gerenciamento de pré-processamento dos valores é suportado pelo Zabbix Proxy.

Como funciona a coleta com esse novo template?

Nesse novo template tem o item Zabbix_raw_items, que é responsável por fazer a coleta executando a query “show global status”. Com essa coleta, o Zabbix irá processar todos os itens dependentes, sem a necessidade de abrir uma conexão com o banco de dados para fazer a coleta desses itens. Isso já justifica o fôlego que esse tipo de monitoramento terá.

Se você usa monitoramento ODBC, a versão 5.0 do Zabbix já promete ganhos de performance em seu ambiente.

Para quem não estava satisfeito com a performance do monitoramento ODBC e pensava em desenvolver uma API ou escrever um exporter do Prometheus para entregar as métricas de banco de dados pra o Zabbix via HTTP Agent, sugiro analisar antes esse template. Com certeza você também ganhará um fôlego para esse monitoramento e evitará desenvolver algo sem necessidade.

O novo Template MySQL ODBC está disponível no repositório da Zabbix SIA.

No próximo post eu vou mostrar como subir o Zabbix em container Docker para testar esse novo template monitorando o próprio banco de dados do Zabbix.

Que versão do Zabbix devo usar em ambiente de produção?

No post anterior, eu mostrei como fazer a instalação do Zabbix 4.4 com SELinux habilidado.

Recebi muitas mensagens (por e-mail e Telegram) sobre esse assunto. Para minha surpresa, muitos leitores do blog questionaram por que eu demonstrei a instalação do Zabbix nessa versão. Digo que fiquei surpreso, justamente porque imaginei que surgiriam mais dúvidas a respeito do uso do SELinux, visto que é normal encontrar conteúdo sobre uso do Zabbix desabilitando o SELinux.

Eu demonstrei a instalação do Zabbix na versão 4.4, pois esta, no momento em que eu escrevi o post, era a versão estável lançada pela Zabbix SIA. Essa versão foi lançada em 7 de outubro de 2019 e atualmente está na release 4.4.1 (28/10/2019).

O motivo do questionamento de alguns leitores foi se deveriam usar essa versão em ambiente de produção, visto que a 4.4 não é uma versão LTS. Foi daí que eu escolhi o título desse post ;).

LTS significa Long Term Support. Ao pé da letra (Suporte de longo prazo).

Neste post vou mencionar não-LTS para a as versões Standard Release, que tem suporte em curto prazo.

Devo usar a versão 4.4 em ambiente de produção?

Depende se é uma nova instalação ou se é um upgrade de versão.

É a minha primeira instalação

Se você estiver na fase inicial de implantação, não vejo problemas de usar a versão 4.4, que é a versão estável. A única restrição nessa etapa é que você terá que planejar uma atualização para a versão 5.0 assim que a mesma for lançada.

– Por que preciso fazer isso? Porque a versão 4.4 não é LTS.

Uma versão não-LTS tem um suporte mais curto. Em um período de seis meses terminará o suporte completo. Isso significa que nesse período a Zabbix SIA se compromete a entregar todas as atualizações para essa versão. Finalizando esse período, essa versão terá mais um mês de suporte, apenas com atualizações de problemas críticos e de segurança. No fim desse período, essa versão será descontinuada e seu uso não é mais recomendado. Foi o que aconteceu recentemente com a versão 4.2

Figura 1: Versões do Zabbix atualmente suportadas.

Mantendo uma versão não-LTS em seu ambiente, você terá que realizar atualizações a cada seis meses. Isso pode ser um grande problema para infraestruturas de TI em grandes empresas.

Figura 2: Ciclo de vida da versão Standard

Já uso Zabbix em ambiente de produção em outra versão

Se você estiver usando uma versão LTS do Zabbix (atualmente a 4.0), não vejo porque correr para atualizar para uma versão não-LTS. Como mostrado na figura 1, uma versão LTS tem suporte mais longo: três anos para suporte total e mais dois anos para suporte limitado. O único revés que eu vejo nesse caso, é que precisa esperar (em média um ano e meio) para ter acesso aos novos recursos.

Figura 3: Ciclo de vida da versão LTS

Se estiver usando uma versão mais antiga, por exemplo, a 3.0 (que também é LTS), deve tomar cuidado com o fim do suporte, que pode acontecer justamente com o lançamento da versão 5.0. Não é regra, mas pode acontecer de não ter suporte para um upgrade direto da versão 3.0 para a versão 5.0. Portanto, se você ainda não atualizou para a 4.0, seria bom planejar essa atualização antes mesmo do lançamento da versão 5.0 e não ficar sem atualizações da versão 3.0. Caso contrário, seu ambiente estará vulnerável.

Dicas

  • Para saber mais detalhes sobre o ciclo de vida das versões do Zabbix, acesse https://www.zabbix.com/life_cycle_and_release_policy.
  • Vale conferir as notas de lançamento que a Zabbix SIA disponiliza, informando sobre novos recursos, melhorias e correção de bugs.
  • A previsão para lançamento do Zabbix 5.0 você também encontra na página de Roadmap do Zabbix. Nessa página você encontrará informações importantes sobre o que está no radar para ser desenvolvido. É um bom local para se preparar para um recurso importante que você quer usar e está em desenvolvimento.
  • Vale a pena ir testando as versões que estão em desenvolvimento e já tem alguns recursos disponíveis em versões RC, Alpha e Beta. Se você pensa em usar tais recursos para aplicar em produção, não correrá o risco de aplicar uma atualização sem ter conhecimento desses novos recursos.
  • Para encontrar as versões que estão atualmente em desenvolvimento, acesse https://www.zabbix.com/developers.

Espero que tenham gostado do assunto. Até o próximo post.

Instalação do Zabbix 4.4 no CentOS 8 com SELinux habilitado

Já tentou instalar o Zabbix e sempre dá problema na inicialização do serviço?
Para “resolver o problema” você desabilita o SELinux, certo? ERRADO.

Nesse post você vai aprender como instalar o Zabbix deixando o SELinux habilitado, ou seja, no modo Enforcing.

O modo Enforcing é o modo padrão do SELinux. Geralmente o SELinux é desabilitado pela trabalheira (??) que dá para configurar as políticas para que um determinado serviço funcione corretamente.

Para esse primeiro post, eu gravei um vídeo e disponibilizei no YouTube justamente para demonstrar como fazer com que o Zabbix Server funcione com o SELinux no modo Enforcing. Com as dicas presentes nesse vídeo, você poderá usar para configurar a política de outros serviços que por ventura não sobem quando o SELinux está em modo Enforcing.

Resolvi fazer esse vídeo porque encontramos vários sites e blogs mostrando como desabilitar o SELinux, como se isso fosse a solução do problema.

Aprender a usar o SELinux te dará mais conhecimento do que apenas desabilitar esse recurso. Fica a dica.

Deixo aqui alguns links sobre esse projeto:

Espero que tenham gostado do assunto. Até o próximo post.