DevOps na prática – entrega de software confiável e automatizada

Aproximadamente 55.225 palavras.

Página 39

Casa do Código Capítulo 2. Tudo começa em produç ão verificar que o banco de dados foi criado com sucesso, você pode executar o seguinte comando que lista todos os banco de dados existentes:

vagrant@db$ mysql -u root -p -e"SHOW DATABASES"

Enter password:

+——————–+ | Database | +——————–+ | information_schema | | loja_schema | | mysql | | performance_schema | | test | +——————–+ Assim como não é recomendável executar comandos no sistema opera- cional como usuárioroot, não é recomendável executar queries no MySQL como usuárioroot. Uma boa prática é criar usuários específicos para cada aplicaç ão, liberando apenas o acesso necessário para a aplicaç ão rodar. Além disso, a instalaç ão padrão do servidor MySQL inclui uma conta anônima para acesso ao banco de dados. Antes de criar a conta para a loja virtual, precisa- mos remover a conta anônima:

vagrant@db$ mysql -uroot -p -e "DELETE FROM mysql.user WHERE user=’’; > FLUSH PRIVILEGES"

Enter password:

Uma vez que a conta anônima foi removida, criaremos um usuário cha- madoloja, com uma senha “lojasecret”, com acesso exclusivo aoschema loja_schema:

vagrant@db$ mysql -uroot -p -e "GRANT ALL PRIVILEGES ON loja_schema.* > TO’loja’@ ’%’IDENTIFIED BY’lojasecret’;"

Enter password:

Para testar que o novo usuário foi criado corretamente, podemos executar umaquerysimples para verificar que tudo está OK (a senha deve ser “lojase-

Página 40

2.3. Configurando dependências nos servidores de produç ão Casa do Código cret” pois estamos executando o comando como usuáriolojaao invés de root):

vagrant@db$ mysql -u loja -p loja_schema -e "select database(), user()"

Enter password:

+————–+—————-+ | database() | user() | +————–+—————-+ | loja_schema | loja@localhost | +————–+—————-+ Neste ponto, o servidor de banco de dados já está configurado e rodando corretamente. Para deslogar da máquina virtualdb, você pode digitar o co- mandologoutou pressionarCtrl+D. O banco de dados ainda está vazio – nenhuma tabela ou dados foram criados – porém iremos cuidar disto na seção 2.4. Antes disso, precisamos terminar de configurar o resto da infraestrutura:

o servidor web.

Servidor web Iremos instalar o Tomcat e configurar uma fonte de dados para usar o banco de dados criado anteriormente. Para isto, precisamos logar no servidor rodando o comandovagrant ssh web, que abre uma sessão SSH com o servidorweb. Uma vez logado, a instalaç ão do Tomcat é feita através do pacotetomcat7. Também precisamos instalar o cliente para conectar com o banco de dados MySQL, disponível no pacotemysql-client:

vagrant@web$ sudo apt-get update Ign http://us.archive.ubuntu.com precise InRelease Ign http://us.archive.ubuntu.com precise-updates InRelease …

Reading package lists… Done vagrant@web$ sudo apt-get install tomcat7 mysql-client Reading package lists… Done Building dependency tree …

ldconfig deferred processing now taking place

Página 41

Casa do Código Capítulo 2. Tudo começa em produç ão Isto irá instalar o Tomcat 7, o cliente MySQL e todas as suas dependências, incluindo o Java 6. Para verificar que o Tomcat está rodando corretamente, você pode abrir seu navegador e digitar a URLhttp://192.168.33.12:8080/do servidor web –192.168.33.12foi o endereço IP configurado no Vagrant e8080é a porta onde o Tomcat roda por padrão. Se tudo estiver ok, você deve ver uma página com uma mensagem"It works!”.

A loja virtual precisa de uma conexão segura com o servidor para transfe- rir dados pessoais – como senhas ou números de cartão de crédito – de forma criptografada. Para isso, precisamos configurar um conector SSL para que o Tomcat consiga rodar tanto em HTTP quanto HTTPS. Conexões SSL usam um certificado assinado por uma autoridade confiável para identificar o ser- vidor e para criptografar os dados que trafegam entre o seu navegador e o ser- vidor. Usaremos a ferramentakeytool, que é parte da distribuiç ão padrão do Java, para gerar um certificado para o nosso servidor web. Durante este processo, você precisará fornecer diversas informações sobre o servidor além de uma senha para proteger okeystore, que no nosso caso será novamente “secret” para simplificar. O comando completo, juntamente com exemplos dos dados que precisam ser fornecidos, fica:

vagrant@web$cd/var/lib/tomcat7/conf vagrant@web$ sudo keytool -genkey -alias tomcat -keyalg RSA > -keystore .keystore Enter keystore password:

Re-enter new password:

What is your first and last name?

[Unknown]: Loja Virtual What is the name of your organizational unit?

[Unknown]: Devops na Prática What is the name of your organization?

[Unknown]: Casa do Código What is the name of your City or Locality?

[Unknown]: São Paulo What is the name of your State or Province?

[Unknown]: SP What is the two-letter country code for this unit?

[Unknown]: BR Is CN=Loja Virtual, OU=Devops na Prática, …, C=BR correct?

Página 42

2.3. Configurando dependências nos servidores de produç ão Casa do Código [no]: yes Enter key password for <tomcat> (RETURN if same as keystore password):

Explicando o comando passo a passo: a opção-genkeygera uma nova chave; a opção-alias tomcatdefine um apelido para o certificado; a op- ção-keyalg RSAespecifica o algoritmo usado para gerar a chave, nesse caso RSA; por fim, a opção-keystore .keystore define o arquivo que armazenará okeystore. Este formato de arquivo permite armazenar di- versas chaves/certificados no mesmokeystore, por isso é bom escolher um apelido para o certificado gerado para o Tomcat. Além disso, tanto o keystorequanto o certificado do Tomcat são protegidos por senha. Nesse caso, usamos “secret” para ambos.

Uma vez que o certificado foi criado e armazenado, precisamos configurar o servidor do Tomcat para habilitar o conector SSL. Isso é feito editando o arquivo/var/lib/tomcat7/conf/server.xml:

vagrant@web$ sudo nano /var/lib/tomcat7/conf/server.xml Dentro deste arquivo, a definiç ão do conector SSL para a porta 8443 já está predefinida, porém comentada. Você precisa descomentar a definiç ão deste conector e adicionar mais dois atributos que representam o arquivo do keystoree a senha de proteção. A parte relevante do arquivo XML que precisamos alterar é:

<?xml version=’1.0’ encoding=’utf-8’?> <Server"8005" shutdown="SHUTDOWN"> …

<Servicename="Catalina"> …

<!– Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation –> <Connectorport="8443"protocol="HTTP/1.1"

SSLEnabled="true"

Página 43

Casa do Código Capítulo 2. Tudo começa em produç ão maxThreads="150""https""true"

keystoreFile="conf/.keystore"

keystorePass="secret"

clientAuth="false""SSLv3"

…

</Service> </Server> A configuraç ão do servidor web está quase pronta aqui. A última al- teração que precisamos fazer é aumentar a quantidade de memória que o Tomcat pode usar. A loja virtual exige mais memória do que a instalaç ão padrão do Tomcat define, por isso precisamos alterar uma linha no arquivo /etc/default/tomcat7:

vagrant@web$ sudo nano /etc/default/tomcat7 A linha que define a opçãoJAVA_OPTSprecisa ser alterada para per- mitir que a máquina virtual do Java use até 512Mb de memória, ao invés da configuraç ão padrão de 128Mb. Após a alteraç ão, a opçãoJAVA_OPTSdeve ficar:

JAVA_OPTS="-Djava.awt.headless=true -Xmx512M -XX:+UseConcMarkSweepGC"

Por fim, para que todas as configurações sejam aplicadas, precisamos rei- niciar o servidor Tomcat:

vagrant@web$ sudo service tomcat7 restart Para verificar que tudo está funcionando, você pode voltar no navega- dor e tentar acessar a página padrão através do conector SSL, acessando a URLhttps://192.168.33.12:8443/. Dependendo de qual navegador você está uti- lizando, um aviso irá surgir para alertar que o certificado do servidor foi au- toassinado. Em um cenário real, você geralmente compra um certificado SSL assinado por uma autoridade confiável, mas nesse caso iremos prosseguir e aceitar o alerta pois sabemos que o certificado foi autoassinado intencional- mente. Se tudo der certo, você verá novamente a página"It works!”, dessa vez usando uma conexão segura em HTTPS.

Neste momento, ambos os servidores estão configurados e prontos para a última etapa: fazer obuildedeploypara colocar a loja virtual em produç ão!

Página 44

2.4. Build e deploy da aplicaç ão Casa do Código 2.4 Build e deploy da aplicação Até agora, a configuraç ão dos servidores de banco de dados e web foram re- lativamente genéricas. Instalamos os pacotes de software básicos para rodar o MySQL e o Tomcat, configuramos conectores para HTTP/HTTPS, criamos um usuário e um banco de dados vazio, que por enquanto não estão direta- mente associados à loja virtual a não ser pelo nome doschemae do usuário que escolhemos.

Chegou o momento de baixar e compilar o código, rodar os testes, empa- cotar a aplicaç ão e colocar a loja virtual no ar! Esse processo de compilaç ão, teste e empacotamento é conhecido comobuild. As etapas do processo de buildtambém podem incluir gerenciamento de dependências, rodar ferra- mentas de análise estática do código, cobertura de código, geraç ão de docu- mentaç ão, dentre outros. A principal função do processo debuildé gerar um ou mais artefatos, com versões específicas, que se tornam potenciais candida- tos, ourelease candidates, para o deployem produç ão.

Geralmente recomenda-se rodar o processo debuildem um ambiente pa- recido com o ambiente de produç ão para evitar incompatibilidades de sistema operacional ou versões de bibliotecas. Poderíamos até configurar o Vagrant para criar uma nova máquina virtual para utilizarmos como servidor debuild.

Porém, para facilitar a discussão neste capítulo, faremos obuildno servidor web, que é onde odeployvai acontecer. Isso economizará diversos passos agora, porém vamos revisitar este processo no capítulo6.

Para realizar obuild, é preciso instalar mais algumas ferramentas: o Git(http://git-scm.com/) para controle de versão, o Maven(http://maven.

apache.org/) para executar o buildem si e oJDK(Java Development Kit) para conseguirmos compilar o código Java:

vagrant@web$ sudo apt-get install git maven2 openjdk-6-jdk Reading package lists… Done Building dependency tree …

ldconfig deferred processing now taking place Uma vez que essas ferramentas foram instaladas, precisamos baixar o có- digo que está hospedado no Github através do comandogit clone, e exe- cutar obuildrodando o comandomvn install:

Página 45

Casa do Código Capítulo 2. Tudo começa em produç ão vagrant@web$ vagrant@web$ git clone https://github.com/dtsato/ loja-virtual-devops.git Cloning into ’loja-virtual-devops’…

remote: Counting objects: 11358, done.

remote: Compressing objects: 100% (3543/3543), done.

remote: Total 11358 (delta 6053), reused 11358 (delta 6053) Receiving objects: 100% (11358/11358), 55.47 MiB | 1.14 MiB/s, done.

Resolving deltas: 100% (6053/6053), done.

vagrant@web$ vagrant@web$ MAVEN_OPTS=-Xmx256m vagrant@web$ mvn install [INFO] Scanning for projects…

[INFO] Reactor build order:

[INFO] loja-virtual-devops [INFO] core [INFO] admin [INFO] site [INFO] combined [INFO] —————————————————- [INFO] Building loja-virtual-devops [INFO] task-segment: [install] [INFO] —————————————————- …

A primeira execuç ão do Maven vai demorar de 20 a 25 minutos pois di- versas coisas acontecem:

•Sub-projetos: o projeto está organizado em 4 módulos: corepossui as configurações principais, extensões e customizações da loja virtual; siteé a aplicaç ão web da loja virtual;adminé uma aplicaç ão web restrita para administraç ão e gerenciamento da loja virtual; por fim, combinedé um módulo que agrega as duas aplicações web e o core em um único artefato. Cada módulo atua como um subprojeto que o Maven precisa realizar obuildseparadamente.

•Resolução de dependências: o Maven irá resolver todas as dependên- cias do projeto e baixar as bibliotecas e frameworks necessários para

Página 46

2.4. Build e deploy da aplicaç ão Casa do Código compilar e rodar cada módulo da loja virtual.

•Compilaç ão: o código Java e GWT precisa ser compilado para execu- ção. Isso toma um bom tempo na primeira vez. O compilador Java é inteligente o suficiente para recompilar apenas o necessário embuilds subsequentes.

•Testes automatizados: em módulos que definem testes automatizados, o Maven irá executá-los e gerar relatórios de quais testes passaram e quais falharam.

•Empacotamento de artefatos: por fim, o módulo coreserá empaco- tado como um arquivo.jarenquanto os módulos web (site, admin ecombined) serão empacotados como um arquivo .war. Ambos os arquivosjarewarsão equivalentes a arquivoszipque você baixa regularmente da internet, no entanto a estrutura interna dos pacotes é bem definida e padronizada pelo Java: ojarcontém classes compi- ladas e serve como biblioteca enquanto owarcontém classes, biblio- tecas, arquivos estáticos e de configuraç ão necessários para rodar uma aplicaç ão web em umcontainerJava como o Tomcat.

Ao final da execuç ão do processo debuild, se tudo correr bem, você deve ver um relatório do Maven parecido com:

…

[INFO] —————————————————- [INFO] Reactor Summary:

[INFO] —————————————————- [INFO] loja-virtual-devops …………… SUCCESS [1:35.191s] [INFO] core ………………………… SUCCESS [6:51.591s] [INFO] admin ……………………….. SUCCESS [6:54.377s] [INFO] site ………………………… SUCCESS [4:44.313s] [INFO] combined …………………….. SUCCESS [25.425s] [INFO] —————————————————- [INFO] —————————————————- [INFO] BUILD SUCCESSFUL [INFO] —————————————————- [INFO] Total time: 20 minutes 31 seconds

Página 47

Casa do Código Capítulo 2. Tudo começa em produç ão [INFO] Finished at: Sat Mar 15 02:34:24 UTC 2014 [INFO] Final Memory: 179M/452M [INFO] —————————————————- Isso significa que obuildrodou com sucesso e o artefato que nos interessa paradeployé o arquivodevopsnapratica.war do módulocombined, que se encontra no diretóriocombined/target.

Antes de fazer odeploydo arquivowar, a última configuraç ão necessária no Tomcat é a definiç ão das fontes de dado, ouDataSource, que a aplicaç ão irá acessar para conectar com o banco de dados. Se tais definições estivessem dentro do artefato em si, nós precisaríamos realizar um novobuildtoda vez que os parâmetros de conexão com o banco de dados mudassem ou caso qui- séssemos rodar a mesma aplicaç ão em ambientes diferentes. Em vez disso, a aplicaç ão depende de recursos abstratos através da especificaç ão JNDI (Java Naming and Directory Interface). Estes recursos precisam ser configurados e expostos pelocontainer, possibilitando a alteraç ão sem necessidade de um novobuild.

A loja virtual precisa de três fontes de dados no JNDI chamadas jdbc/web, jdbc/secureejdbc/storage. No nosso caso, usare- mos o mesmo banco de dados para os três recursos, definidos no arquivo context.xml:

vagrant@web$ sudo nano /var/lib/tomcat7/conf/context.xml As configurações relevantes são os três elementos <Resource>e a dife- rença entre eles é apenas o atributoname:

<?xml version=’1.0’ encoding=’utf-8’?> <Context> <WatchedResource>WEB-INF/web.xml</WatchedResource> <Resource"jdbc/web" auth="Container"

type="javax.sql.DataSource" maxActive="100" maxIdle="30"

maxWait="10000" username="loja" password="lojasecret"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://192.168.33.10:3306/loja_schema"/>

Página 48

2.4. Build e deploy da aplicaç ão Casa do Código <Resource auth="Container"

type="javax.sql.DataSource" maxActive="100" maxIdle="30"

maxWait="10000" username="loja" password="lojasecret"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://192.168.33.10:3306/loja_schema"/> <Resourcename="jdbc/storage"auth="Container"

type="javax.sql.DataSource" maxActive="100" maxIdle="30"

maxWait="10000" username="loja" password="lojasecret"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://192.168.33.10:3306/loja_schema"/> </Context> Para fazer odeployda loja virtual em si, simplesmente precisamos copiar o artefatowarpara o lugar certo e o Tomcat fará o necessário para colocar a loja virtual no ar:

vagrant@web$cd~/loja-virtual-devops vagrant@web$ sudo cp combined/target/devopsnapratica.war > /var/lib/tomcat7/webapps Assim como obuilddemorou um pouco, o processo dedeploytambém vai levar alguns minutos na primeira vez, pois a aplicaç ão irá criar as tabelas e popular os dados usando o Hibernate. Você pode acompanhar o processo dedeployolhando para os logs do Tomcat. O comandotail -fé útil nesse caso pois ele mostra em tempo real tudo que está acontecendo no log:

vagrant@web$ tail -f /var/lib/tomcat7/logs/catalina.out Mar 15, 2014 2:08:51 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-8080"] Mar 15, 2014 2:08:51 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-8443"] Mar 15, 2014 2:08:51 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 408 ms …

Odeploytermina assim que você perceber que as atividades no log para- ram. Para terminar o comandotailvocê pode usarCtrl+C. Agora é só

Página 49

Casa do Código Capítulo 2. Tudo começa em produç ão testar que tudo está funcionando: abra uma nova janela no navegador e digite a URLhttp://192.168.33.12:8080/devopsnapratica/. Parabéns, a loja virtual está em produç ão!

Figura 2.3: Página de administraç ão da loja virtual Você também pode acessar a página de administraç ão que se encontra na URLhttp://192.168.33.12:8080/devopsnapratica/admin/(a barra no final da URL é importante). Entrando com o usuário “admin” e senha “admin” você podenavegar pelas páginas de administraç ão e gerenciar o catálogo de produtos, categorias, o conteúdo das páginas da loja virtual, gerenciar pedidos, assimcomo usuários e permissões.

Agora que estamos em produç ão e conquistamos a última milha, pode- mos focar nos princípios e práticas de DevOps necessários para operar nossaaplicaç ão em produç ão, ao mesmo tempo permitindo que novas mudanças sejam introduzidas de forma confiável.

Página 50

Página 51

Capítulo3 Monitoramento Agora que a loja virtual está em produç ão, conquistamos a parte mais im- portante do ciclo de vida de qualquersoftware. No entanto, este foi apenas o primeiro passo! Daqui para frente, precisamos vestir o chapéu do time de operações e nos responsabilizar pela estabilidade do sistema em produç ão:

precisamos garantir que a loja virtual continue funcionando sem problemas.

Como saber se o sistema está funcionando normalmente ou se está fora do ar? Você pode acessar a loja virtual manualmente e verificar se está tudo ok, porém isso leva tempo e depende de você lembrar de fazê-lo. Você tam- bém pode esperar por reclamações de seus usuários, mas essa também não é uma boa opção. Sistemas de monitoramento existem para resolver esse pro- blema. Você define quais verificações são necessárias para saber se o sistema está funcionando e o sistema de monitoramento envia notificações assim que alguma verificaç ão falhar.

Um bom sistema de monitoramento irá alertá-lo quando algo estiver er-

Página 52

3.1. Instalando o servidor de monitoramento Casa do Código rado, permitindo que você investigue e arrume o que estiver causando proble- mas o mais rápido possível. Desta forma, você não precisa depender de seus usuários avisarem quando algo está fora do ar, possibilitando uma abordagem mais proativa para resoluç ão de problemas.

Neste capítulo iremos instalar um sistema de monitoramento e configurá- lo com várias verificações para garantir que a loja virtual esteja funcionando em produç ão. Utilizaremos uma das ferramentas de monitoraç ão mais utili- zadas por equipes de operações: o Nagios(http://www.nagios.org/) . Apesar de ser uma ferramenta antiga e possuir uma interface gráfica não muito ami- gável, ele ainda é uma das opções mais populares por ter uma implementaç ão robusta e um ecossistema enorme de plugins escritos e mantidos pela comu- nidade. Ao final do capítulo, nosso ambiente de produç ão incluirá um novo servidor, conforme mostra a figura3.1.

Figura 3.1: Ambiente de produç ão da loja virtual 3.1 Instalando o servidor de monitoramento Em um sistema de monitoramento, os servidores geralmente atuam em doispapéis principais:supervisorousupervisionado. O supervisoré responsável por coletar informações sobre o resto da infraestrutura, avaliar se ela está sau- dável e enviar alertas caso encontre algum problema. Ossupervisionadossão os servidores que fazem o trabalho real que você está interessado em moni- torar. Na nossa loja virtual, o servidor web e o servidor de banco de dados

Página 53

Casa do Código Capítulo 3. Monitoramento serão supervisionados por um novo servidor que iremos instalar e configurar para atuar como supervisor.

Rodar o supervisor externamente aos servidores supervisionados é uma boa prática. Se o supervisor estiver rodando na mesma máquina e algum problema acontecer, ambos ficarão indisponíveis e você não conseguirá ser alertado do problema. Por esse motivo, iremos declarar uma nova máquina virtual no arquivoVagrantfile, com o apelido monitore endereço IP 192.168.33.14:

Vagrant.configure("2") do|config| config.vm.box ="precise32"

config.vm.define :dbdo|db_config| db_config.vm.network :private_network, :ip=>"192.168.33.10"

end config.vm.define :webdo|web_config| web_config.vm.network :private_network, :ip=>"192.168.33.12"

end config.vm.define :monitordo|monitor_config| monitor_config.vm.network :private_network, :ip=>"192.168.33.14"

end end Após salvar o arquivo, basta executarvagrant upno mesmo diretó- rio para subir o novo servidor. Se tudo der certo, a saída do comando será parecida com:

$ vagrant up Bringing machine ’db’ up with ’virtualbox’ provider…

Bringing machine ’web’ up with ’virtualbox’ provider…

Bringing machine ’monitor’ up with ’virtualbox’ provider…

==> db: Checking if box ’hashicorp/precise32’ is up to date…

==> db: VirtualBox VM is already running.

Página 54

3.1. Instalando o servidor de monitoramento Casa do Código ==> web: Checking if box ’hashicorp/precise32’ is up to date…

==> web: VirtualBox VM is already running.

==> monitor: Importing base box ’hashicorp/precise32’…

==> monitor: Matching MAC address for NAT networking…

==> monitor: Checking if box ’hashicorp/precise32’ is up to date…

==> monitor: Setting the name of the VM:

blank_monitor_1394851889588_2267 ==> monitor: Fixed port collision for 22 => 2222.

Now on port 2201.

==> monitor: Clearing any previously set network interfaces…

==> monitor: Preparing network interfaces based on configuration…

monitor: Adapter 1: nat monitor: Adapter 2: hostonly ==> monitor: Forwarding ports…

monitor: 22 => 2201 (adapter 1) ==> monitor: Running ’pre-boot’ VM customizations…

==> monitor: Booting VM…

==> monitor: Waiting for machine to boot. This may take a few minutes…

monitor: SSH address: 127.0.0.1:2201 monitor: SSH username: vagrant monitor: SSH auth method: private key monitor: Error: Connection timout. Retrying…

==> monitor: Machine booted and ready!

==> monitor: Configuring and enabling network interfaces…

==> monitor: Mounting shared folders…

monitor: /vagrant => /private/tmp/blank Para completar a instalaç ão básica, precisamos logar no servidor usando o comandovagrant ssh monitor. Uma vez logado, a instalaç ão do Na- gios é feita através do pacotenagios3. Porém, antes de instalar o Nagios, precisamos configurar o sistema para usar a última versão. Para isto, precisa- mos executar os seguintes comandos:

vagrant@monitor$ > >

Página 55

Casa do Código Capítulo 3. Monitoramento Package: nagios* Pin: release n=raring Pin-Priority: 990 vagrant@monitor$ > | sudo tee /etc/apt/sources.list.d/raring.list deb http://archive.ubuntu.com/ubuntu raring main vagrant@monitor$ sudo apt-get update Ign http://archive.ubuntu.com raring InRelease Ign http://security.ubuntu.com precise-security InRelease …

Isso adiciona uma nova entrada na lista de pacotes com oreleasemais novo do Ubuntu – chamado “raring” – e configura as preferências do insta- lador de pacotes para dar prioridade ao novoreleasenos pacotes do Nagios.

O comandoapt-get updatefaz com que o instalador de pacotes atua- lize seucachepara saber das novas versões disponíveis. Uma vez feito isso, podemos instalar o nagios através do comando:

vagrant@monitor$ sudo apt-get install nagios3 Reading package lists… Done Building dependency tree …

O Nagios possui uma dependência com o Postfix, um programa UNIX responsável por envio de e-mails. Por esse motivo, durante a instalaç ão irá aparecer uma tela rosa pedindo configurações para o Postfix. Esco- lhaInternet Sitepara seguir o processo de instalaç ão e na próxima tela, onde ele pede o nome do sistema para envio de e-mails, digite “moni- tor.lojavirtualdevops.com.br”.

A próxima tela de configuraç ão é do Nagios, e você precisa escolher uma senha para o usuário administrador “nagiosadmin” conseguir acessar a in- terface web. Usaremos a senha “secret”. Após estas configurações, o pro- cesso de instalaç ão deve terminar e você pode testar se a instalaç ão funcio- nou abrindo o seu navegador web e visitando o endereçohttp://nagiosadmin:

secret@192.168.33.14/nagios3. Caso você tenha escolhido outro usuário ou se- nha, modifique a URL com os dados de acesso corretos. Se tudo der certo, você verá a interface web de administraç ão do Nagios. Clicando no linkSer- vices, você verá uma tela parecida com a figura3.2.

Página 56

3.1. Instalando o servidor de monitoramento Casa do Código Figura 3.2: Interface de administraç ão do Nagios Como você pode perceber, algumas verificações padrão – ou serviços, na terminologia do Nagios – já estão pré-configuradas. Por enquanto, o servi- dor está apenas se automonitorando, atuando tanto como supervisor quanto supervisionado. Nesta tela, cada servidor monitorado – ouhost– possui um conjunto de serviços. O servidor do Nagios está representado pelo nome lo- calhoste cada linha na tabela representa uma verificaç ão independente. O status verde “OK” significa que a verificaç ão passou, enquanto o status “PEN- DING” significa que a verificaç ão ainda não rodou. As verificações padrão são:

•Carga atual: a carga de um sistema UNIX mede o quão ocupada a CPU está. Para ser mais exato, a carga é uma média móvel do tamanho da fila de processos esperando para executar. Quando a CPU começa a se sobrecarregar, os processos precisam esperar mais tempo para ro- dar, aumentando a fila e fazendo o sistema rodar mais devagar. Esta verificaç ão envia um alerta quando a carga atual ultrapassa um certo limite.

•Usuários atuais: verifica quantos usuários estão logados no sistema.

Página 57

Casa do Código Capítulo 3. Monitoramento Essa é uma maneira simplificada de detectar intrusão no servidor e en- viar alertas quando o número de usuários logados vai além do esperado.

•Espaço de disco: quando um servidor fica sem espaço em disco, di- versos problemas começam a aparecer. Um dos motivos mais comuns para isso é a geraç ão de logs em sistemas de produç ão. Para evitar este problema é importante monitorar quanto espaço livre ainda resta. Esta verificaç ão envia alertas quando o espaço livre atinge um certo limite.

•HTTP: verifica que o servidor está aceitando conexões HTTP. Neste caso, o Nagios instalou um servidor web para que possamos acessar a interface de administraç ão da figura3.2. Por padrão, esta verificaç ão enviará alertas caso não consiga abrir uma conexão HTTP na porta 80.

•SSH: verifica que o servidor está aceitando conexões SSH na porta 22 e envia alertas quando encontra algum problema.

•Número total de processos: outra forma de avaliar se o servidor está sobrecarregado é através do número total de processos. Se muitos pro- cessos estiverem executando ao mesmo tempo, o sistema operacional vai gastar mais tempo gerenciando qual pode rodar na CPU, não so- brando tempo suficiente para que nenhum deles rode efetivamente.

Esta verificaç ão envia alertas quando o número total de processos ul- trapassa um certo limite.

A primeira vista, pode parecer que são muitas verificações para monito- rar um único servidor. No entanto, seguindo o mesmo princípio de escre- ver poucas asserções por teste quando desenvolvemos código usando TDD, verificações mais granulares ajudam a identificar o ponto de falha mais ra- pidamente quando algum problema acontece. Em vez de receber um alerta genérico dizendo que o servidor está com problemas, você vai ter informa- ções específicas para identificar a causa do problema mais rapidamente.

Nas próximas seções discutiremos um pouco mais sobre os conceitos e as configurações do Nagios e aprenderemos como supervisionar outros servi- dores, como adicionar mais verificações e como receber alertas quando algo dá errado.

Página 58

3.2. Monitorando outros servidores Casa do Código 3.2 Monitorando outros servidores Com o Nagios instalado e efetuando verificações, precisamos configurá-lo para monitorar nossos outros servidores de produç ão. Para isto precisamos declarar onde estão os outros servidores e quais verificações executar. Cria- remos um novo arquivo para definir todas as configurações pertinentes à loja virtual:

vagrant@monitor$ sudo nano /etc/nagios3/conf.d/loja_virtual.cfg Neste arquivo iremos declarar os servidores da loja virtual, definindo no- voshostscom os respectivos endereços IP:

define host { use generic-host host_name 192.168.33.10 hostgroups ssh-servers, debian-servers } define host { use generic-host host_name 192.168.33.12 hostgroups ssh-servers, debian-servers } Sempre que alteramos um arquivo de configuraç ão, precisamos recarregá-los para que o Nagios detecte as mudanças. Para isto, usamos o comandoreload:

vagrant@monitor$ sudo service nagios3 reload No Nagios, umhostrepresenta um dispositivo a ser monitorado, como por exemplo um servidor, um roteador ou uma impressora. Podemos tam- bém agruparhostssemelhantes emhost groupse definir configurações para diversos servidores de uma vez, evitando duplicaç ão. O mesmohostpode ser membro de mais de umhost group.

No arquivo de configuraç ão/etc/nagios3/conf.d/loja_virtual.cfg, definimos que os nossos servidores são membros de dois grupos:

Página 59

Casa do Código Capítulo 3. Monitoramento ssh-serversedebian-servers. O grupo ssh-serverscria uma verificaç ão para o serviço SSH. O grupo debian-serversnão define nenhuma verificaç ão extra, mas adiciona informações como o logotipo da Debian que aparece no ícone do servidor na interface web do Nagios.

Para verificar que as configurações foram aplicadas com sucesso, você pode recarregar a página de administraç ão e esperar até que as novas veri- ficações SSH estejam OK, conforme mostra a figura3.3.

Figura 3.3: Monitorando serviço SSH em mais servidores Para facilitar a configuraç ão, iremos adicionar nossos servidores a dois novoshost groups: um grupo chamado web-serverspara os servidores web e um grupo chamadodb-serverspara os servidores de banco de dados.

Faremos isso editando o mesmo arquivo de configuraç ão:

vagrant@monitor$ sudo nano /etc/nagios3/conf.d/loja_virtual.cfg Será preciso adicionar os novoshost groupse modificar a configuraç ão doshostsexistentes para adicioná-los aos grupos corretos:

define hostgroup { hostgroup_name db-servers alias Database Servers

Página 60

3.3. Explorando os comandos de verificaç ão do Nagios Casa do Código } define hostgroup { hostgroup_name web-servers alias Web Servers } define host { use generic-host host_name 192.168.33.10 hostgroups ssh-servers, debian-servers, db-servers } define host { use generic-host host_name 192.168.33.12 hostgroups ssh-servers, debian-servers, web-servers } Após recarregar o arquivo de configuraç ão – usando o mesmo comando sudo service nagios3 reload – você pode verificar que os novos gru- pos existem clicando no linkHost Groupsna tela de administraç ão do Nagios.

Executar diversas verificações e enviar alertas quando algo está errado são as funcionalidades mais importantes de um sistema de monitoramento como o Nagios. Na próxima seção, vamos conhecer os diversos tipos de checagens que estão disponíveis para verificar que a loja virtual está funcionando corre- tamente.

3.3 Explorando os comandos de verificação do Nagios Cada serviço do Nagios está associado a um comando que é executado em cada verificaç ão. O comando nada mais é do que um script que pode ser exe- cutado diretamente da linha de comando. Diversos comandos já vêm instala- dos com o Nagios por padrão, porém você pode criar seus próprios scripts ou instalar plugins da comunidade para estender sua biblioteca de verificações.

Página 61

Casa do Código Capítulo 3. Monitoramento Vamos explorar alguns dos comandos pré-instalados, que estão disponí- veis no diretório/usr/lib/nagios/plugins. Por exemplo, o comando check_ssh, que é executado na verificaç ão do serviço SSH:

vagrant@monitor$ vagrant@monitor$ ./check_ssh 192.168.33.12 SSH OK – OpenSSH_5.9p1 Debian-5ubuntu1 (protocol 2.0) vagrant@monitor$ 0 vagrant@monitor$ ./check_ssh 192.168.33.11 No route to host vagrant@monitor$ 2 Perceba que ao rodar o comandocheck_sshpassando o endereço IP do servidor web, ele imprime uma mensagem com um resumo de uma linha do que aconteceu. Essa mensagem geralmente é da forma<VERIFICAÇÃO> <STATUS> – <MENSAGEM COM DETALHES>, porém o que define o re- sultado da verificaç ão não é o formato da mensagem, mas sim, o código de saída do processo – ouexit code, representado pela variável$?no bash:

•0 – OK: indica que a verificaç ão passou com sucesso. Representado pelo status verde na interface web.

•1 – WARNING: indica que a verificaç ão passou o primeiro limite de alerta. Representado pelo status amarelo na interface web.

•2 – CRITICAL: indica que a verificaç ão falhou e algo está errado. Re- presentado pelo status vermelho na interface web.

•3 – UNKNOWN: indica que a verificaç ão não conseguiu decidir se o serviço está bem ou não. Representado pelo status laranja na interface web.

Outra verificaç ão que podemos fazer é que conseguimos acessar o servi- dor web por HTTP:

vagrant@monitor$ ./check_http -H 192.168.33.12 Connection refused

Página 62

3.3. Explorando os comandos de verificaç ão do Nagios Casa do Código HTTP CRITICAL – Unable to open TCP socket vagrant@monitor$ 2 vagrant@monitor$ ./check_http -H 192.168.33.12 -p 8080 HTTP OK: HTTP/1.1 200 OK – 2134 bytes in 0.007 second response time …

vagrant@monitor$ 0 Perceba que precisamos passar a opção-Hpara indicar qualhostdeve ser verificado. Além disso, como não especificamos a porta a ser verificada, o comandocheck_httpusa a porta 80 por padrão. Ao passarmos a opção -pcom o valor 8080 – a porta onde o servidor Tomcat está escutando – a verificaç ão passa com sucesso.

Um último comando para explorarmos é a verificaç ão de quanto espaço em disco ainda está disponível:

vagrant@monitor$ ./check_disk -H 192.168.33.12 -w 10% -c 5% /usr/lib/nagios/plugins/check_disk: invalid option — ’H’ Unknown argument Usage:

check_disk -w limit -c limit [-W limit] [-K limit] …

vagrant@monitor$ ./check_disk -w 10% -c 5% DISK OK – free space: / 74473 MB (97% inode=99%); …

Perceba que, ao contrário do comandocheck_http, o comando check_disknão aceita a opção-He consegue apenas verificar quanto es- paço em disco está disponível no servidor local. Isso acontece pois o serviço HTTP é um serviço de rede acessível remotamente. Por outro lado, o co- mandocheck_diskprecisa de informações locais do servidor para deci- dir quanto espaço de disco está disponível e não pode ser executado remota- mente.

O Nagios possui três opções quando você precisa realizar uma verificaç ão remota de um serviço que não está disponível na rede:

•Checagem por SSH: através do comando check_by_ssh, o Nagios consegue abrir uma conexão SSH com o servidor remoto e executar o

Página 63

Casa do Código Capítulo 3. Monitoramento comando lá. Esta é uma opção simples pois não exige a instalaç ão de nenhum agente no servidor supervisionado. No entanto, conforme o número de verificações remotas aumenta, isso pode aumentar a carga no servidor supervisor, pois ele precisará criar e destruir diversas co- nexões SSH.

•Checagem ativa com NRPE: o Nagios Remote Plugin Executor, ou NRPE, é um plugin que permite a execuç ão de verificações que de- pendem de recursos locais no servidor supervisionado. Um processo agente do NRPE roda no servidor supervisionado e fica esperando pe- didos de verificaç ão do supervisor. Quando o Nagios precisa executar uma verificaç ão, ele pede para o agente NRPE rodá-la e coleta os resul- tados quando a verificaç ão termina. Este tipo de verificaç ão é ativa pois quem inicia o pedido de execuç ão do comando é o servidor supervisor.

•Checagem passiva com NSCA: o Nagios Service Check Acceptor, ou NSCA, é um plugin que permite a execuç ão de verificações remotas de forma passiva no servidor supervisionado. Um processo cliente do NSCA roda no servidor supervisionado e executa as verificações peri- odicamente, enviando os resultados para um servidor NSCA que roda no supervisor. Este tipo de verificaç ão é passiva pois quem inicia a exe- cução do comando é o próprio servidor supervisionado.

A figura3.4mostra as diferentes formas de realizar verificações com o Nagios. Verificações de serviços de rede, como check_httprodam direto do servidor supervisor. Verificações que precisam rodar no servidor super- visionado, podem ser chamadas ativamente comcheck_by_sshou através do plugin NRPE. Por fim, verificações passivas podem rodar de forma inde- pendente no servidor supervisionado e os resultados enviados para o Nagios através do plugin NSCA.

Página 64

3.4. Adicionando verificações mais específicas Casa do Código Figura 3.4: Verificações remotas com Nagios Agora que já conhecemos os diferentes tipos de verificações do Nagios e sabemos como executar seus diferentes comandos, vamos tornar o monito- ramento da infraestrutura da loja virtual mais robusto.

3.4 Adicionando verificações mais específicas Além das verificações padrão, você pode declarar seus próprios serviços e associá-los a um únicohostou a um grupo dehosts. Na infraestrutura da loja virtual, o servidor de banco de dados está rodando o MySQL como um serviço de rede. Podemos verificar que o serviço está disponível adicionando uma verificaç ão associada ao grupodb-serversno final do arquivo de con- figuraç ão/etc/nagios3/conf.d/loja_virtual.cfg:

define hostgroup …

define host …

define service { service_description MySQL use generic-service hostgroup_name db-servers check_command check_tcp!3306 } Após recarregar o Nagios e esperar pela próxima execuç ão da verificaç ão, um novo serviço “MySQL” aparecerá com o status OK. Esta verificaç ão usa o comandocheck_tcpque tenta abrir uma conexão TCP na porta especifi- cada – nesse caso a porta onde o MySQL roda é 3306. A sintaxe do Nagios para passar argumentos para um comando é separá-los com um ponto de exclamaç ão (!).

Página 65

Casa do Código Capítulo 3. Monitoramento Esta verificaç ão garante que existe algum processo aceitando conexões TCP na porta 3306, porém não garante que tal processo seja o MySQL.

Para verificar que o banco de dados realmente está lá, é preciso usar um outro comandocheck_mysql, já instalado no diretório de plugins /usr/lib/nagios/plugins. Executando diretamente da linha de co- mando, podemos ver quais argumentos ele aceita:

vagrant@monitor$ /usr/lib/nagios/plugins/check_mysql –help …

Usage:

check_mysql [-d database] [-H host] [-P port] [-s socket] [-u user] [-p password] [-S] …

Vamos então adicionar uma nova verificaç ão no arquivo de configuraç ão da loja virtual:

define hostgroup …

define host …

define service …

define service { service_description MySQL-lojavirtual use generic-service hostgroup_name db-servers check_command check_mysql_database!loja!lojasecret !loja_schema } Você deve ter percebido que o comando executado na linha de co- mando se chamacheck_mysql, porém o comando que usamos para de- clarar o serviço se chama check_mysql_database. Isso acontece pois os comandos precisam ser declarados dentro do Nagios antes de serem usados por um serviço. Nesse caso, o plugin já definiu os comandos do Nagios e podemos ver suas declarações olhando o conteúdo do arquivo /etc/nagios-plugins/config/mysql.cfg:

vagrant@monitor$ cat /etc/nagios-plugins/config/mysql.cfg define command{

Página 66

3.4. Adicionando verificações mais específicas Casa do Código command_name check_mysql command_line /usr/lib/nagios/plugins/check_mysql -H ’$HOSTADDRESS$’ } …

define command{ command_name check_mysql_database command_line /usr/lib/nagios/plugins/check_mysql -d ’$ARG3$’ -H …

} …

O último comando permite passar argumentos para o nome de usuário, senha e qual banco de dados queremos verificar. Podemos ver também a or- dem em que os argumentos devem ser passados quando declaramos nosso serviço: o Nagios substitui os tokens$ARG1$, $ARG2$, $ARG3$pelos va- lores separados pelo ponto de exclamaç ão na respectiva ordem.

Agora que temos nosso banco de dados monitorado, é hora de adicio- nar algumas verificações para os servidores web. Seguindo o mesmo raciocí- nio de antes, os serviços de rede expostos pelo servidor web são as conexões HTTP e HTTPS do Tomcat. O comando que podemos usar para realizar tais verificações é o check_http, também instalado no diretório de plu- gins/usr/lib/nagios/plugins. Executando diretamente da linha de comando, podemos ver quais argumentos ele aceita:

vagrant@monitor$ /usr/lib/nagios/plugins/check_http –help …

Usage:

Página 67

Casa do Código Capítulo 3. Monitoramento [-M <age>] [-A string] [-k string] [-S <version>] [–sni] [-C <warn_age>[,<crit_age>]] [-T <content-type>] [-j method] NOTE: One or both of -H and -I must be specified …

Nesse caso, apesar do plugin já declarar alguns comandos do Nagios no arquivo/etc/nagios-plugins/config/http.cfg, nenhum deles aceita o argumento-ppara passar a porta. Como o tomcat não está ro- dando na porta HTTP padrão (80), antes de associarmos um novo serviço ao grupo de servidoresweb-serversprecisamos declarar nossos próprios co- mandos. Faremos isso no arquivo de configuraç ão da loja virtual (lembrando que a barra invertida indica apenas que o comando deve ser definido todo na mesma linha):

define hostgroup …

define host …

define service …

define command { command_name check_tomcat_http command_line /usr/lib/nagios/plugins/check_http -H ’$HOSTADDRESS$’ -p ’$ARG1$’ -u ’$ARG2$’ -e ’HTTP/1.1 200 OK’ } define service { service_description Tomcat use generic-service hostgroup_name web-servers check_command check_tomcat_http!8080!’/devopsnapratica/’ } O argumento-Hrepresenta o endereço dohostmonitorado, o primeiro argumento representa a porta da verificaç ão HTTP e o segundo argumento é a URI. Nosso comando também passa a opção-epara garantir que a resposta do servidor é um status de sucesso:HTTP/1.1 200 OK.

Por fim, vamos adicionar uma última verificaç ão para garantir que a co- nexão SSL também funciona na porta 8443 do Tomcat:

Página 68

3.4. Adicionando verificações mais específicas Casa do Código define hostgroup …

define host …

define service …

define command …

define service …

define command { command_name check_tomcat_https command_line /usr/lib/nagios/plugins/check_http -H ’$HOSTADDRESS$’ –ssl=3 -p ’$ARG1$’ -u ’$ARG2$’ -e ’HTTP/1.1 200 OK’ } define service { service_description Tomcat SSL use generic-service hostgroup_name web-servers check_command check_tomcat_https!8443!’/devopsnapratica/ admin/’ } Após recarregar a configuraç ão do Nagios e esperar pela execuç ão das novas verificações, a tela de serviços na interface de administraç ão deve estar parecida com a figura3.5.

Página 69

Casa do Código Capítulo 3. Monitoramento Figura 3.5: Todas as verificações da loja virtual O arquivo de configuraç ão/etc/nagios3/conf.d/loja_virtual.cfg completo, ao final desta seção ficará assim:

define hostgroup { hostgroup_name db-servers alias Database Servers } define hostgroup { hostgroup_name web-servers alias Web Servers } define host { use generic-host host_name 192.168.33.10 hostgroups ssh-servers, debian-servers, db-servers } define host { use generic-host host_name 192.168.33.12

Página 70

3.4. Adicionando verificações mais específicas Casa do Código hostgroups ssh-servers, debian-servers, web-servers } define service { service_description MySQL use generic-service hostgroup_name db-servers check_command check_tcp!3306 } define service { service_description MySQL-lojavirtual use generic-service hostgroup_name db-servers check_command check_mysql_database!loja!lojasecret !loja_schema } define command { command_name check_tomcat_http command_line /usr/lib/nagios/plugins/check_http -H ’$HOSTADDRESS$’ -p ’$ARG1$’ -u ’$ARG2$’ -e ’HTTP/1.1 200 OK’ } define service { service_description Tomcat use generic-service hostgroup_name web-servers check_command check_tomcat_http!8080!’/devopsnapratica/’ } define command { command_name check_tomcat_https command_line /usr/lib/nagios/plugins/check_http -H ’$HOSTADDRESS$’ –ssl=3 -p ’$ARG1$’ -u ’$ARG2$’ -e ’HTTP/1.1 200 OK’ } define service {

Página 71

Casa do Código Capítulo 3. Monitoramento service_description Tomcat SSL use generic-service hostgroup_name web-servers check_command check_tomcat_https!8443!’/devopsnapratica/ admin/’ } Agora que temos verificações mais detalhadas sobre o funcionamento da loja virtual, a última coisa que precisamos configurar para ter um sistema de monitoramento robusto é o recebimento de alertas.

3.5 Recebendo alertas Ter verificações detalhadas do seu sistema é apenas o primeiro passo para construir um sistema de monitoramento robusto. Não adianta nada seu sis- tema de monitoramento detectar um problema se você não puder ser avisado.

Por isso, é importante configurarmos alertas para receber informações sobre problemas o quanto antes possível.

Existem vários plugins do Nagios para enviar alertas de diversas manei- ras: e-mail, pager, mensagem SMS, sistemas de chat como MSN, ICQ, Yahoo, ou qualquer coisa que você puder fazer da linha de comando. Você pode inclusive definir seu próprio comando para escolher como o Nagios enviará alertas. Por padrão, o Nagios já vem configurado com dois comandos para enviar alertas por e-mail: um deles notifica que ohostestá com problemas e o outro notifica que algum serviço está com problemas. Podemos ver a defi- nição desses comandos no arquivo/etc/nagios3/commands.cfg:

vagrant@monitor$ cat /etc/nagios3/commands.cfg …

define command { command_name notify-host-by-email command_line /usr/bin/printf "%b" … | /usr/bin/mail -s …

} define command { command_name notify-service-by-email command_line /usr/bin/printf "%b" … | /usr/bin/mail -s …

Página 72

3.5. Recebendo alertas Casa do Código } …

Além desses comandos, existem mais dois objetos do Nagios que po- dem ser configurados para decidir quem recebe os alertas e quando:con- tatoseperíodos de tempo– outime periods. Períodos de tempo de- finem quando alertas podem ser enviados e estão definidos no arquivo /etc/nagios3/conf.d/timeperiods_nagios2.cfg. Olhando o con- teúdo do arquivo podemos ver as diferentes opções, inclusive o famoso pe- ríodo de suporte 24×7 – 24 horas por dia, 7 dias por semana:

vagrant@monitor$ cat /etc/nagios3/conf.d/timeperiods_nagios2.cfg …

define timeperiod { timeperiod_name 24×7 alias 24 Hours A Day, 7 Days A Week sunday 00:00-24:00 monday 00:00-24:00 tuesday 00:00-24:00 wednesday 00:00-24:00 thursday 00:00-24:00 friday 00:00-24:00 saturday 00:00-24:00 } …

Contatos são as pessoas que recebem alertas. No nosso caso, usare- mos o único contato definido no Nagios para o usuárioroot, no arquivo /etc/nagios3/conf.d/contacts_nagios2.cfg:

vagrant@monitor$ cat /etc/nagios3/conf.d/contacts_nagios2.cfg …

define contact { contact_name root alias Root service_notification_period 24×7 host_notification_period 24×7 service_notification_options w,u,c,r host_notification_options d,r

Página 73

Casa do Código Capítulo 3. Monitoramento service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email email root@localhost } …

Na definiç ão do contato você escolhe o período em que o contato estará em alerta, seu endereço de e-mail, os comandos executados para enviar aler- tas e as opções de notificaç ão. Neste caso, seremos notificados quando ohost estiver indisponível (dparadown) ou recuperado (rpararecovery) e quando serviços entrarem em status de alerta (wparawarning), desconhecido (u paraunkown), crítico (cparacritical) ou recuperado (rpararecovery). O Nagios também suporta configurações para grupos de contatos quando você quer alertar um time inteiro ao invés de uma única pessoa. No entanto, não precisaremos usar esta funcionalidade neste capítulo.

Para garantir que nossa infraestrutura consiga enviar alertas de verdade, precisamos escolher qual serviço de mensagens será usado pelo Nagios. Ape- sar de ninguém gostar de ser acordado de madrugada, times de operações precisam dar suporte 24×7 para seus sistemas e portanto preferem ser notifi- cados por pager ou SMS. No entanto, é difícil encontrar algum serviço grátis para envio de SMS, especialmente para operadoras brasileiras. Algumas op- ções de serviços online pagos com cobertura SMS internacional são oTwilio (http://www.twilio.com/) e o Nexmo(http://www.nexmo.com/) .

Outro serviço online pago bastante usado é o PagerDuty(http://www.

pagerduty.com/) por permitir gerenciar grupos, contatos, agenda de quem estáon-calle formas de envio de alertas num único lugar, independente do Nagios. O PagerDuty suporta envio de SMS, e-mail, ou até notificações para iPhone ou Android. Antes de começar a pagar pelo plano mensal, é possível criar uma conta de teste válida por 30 dias e o PagerDuty possui uma página bem detalhada explicando como integrá-lo com o Nagios.

No nosso caso, para evitar uma dependência em um sistema externo pago, vamos usar a configuraç ão padrão do Nagios de envio de alertas por e-mail.

A única configuraç ão necessária é criar um contato no Nagios para receber os alertas da loja virtual. Faremos isso editando o arquivo de configuraç ão de contatos/etc/nagios3/conf.d/contacts_nagios2.cfg, trocando o

Página 74

3.5. Recebendo alertas Casa do Código endereço de e-mailroot@localhostpelo seu endereço de e-mail de ver- dade:

…

define contact { contact_name root …

email <seu_email>@gmail.com } …

Para que esta configuraç ão tenha efeito, precisamos recarregar o serviço do Nagios pela última vez:

vagrant@monitor$ sudo service nagios3 reload * Reloading nagios3 monitoring daemon configuration files nagios3 …done.

A partir de agora, qualquer alerta será enviado diretamente para o seu e- mail. Para testar que o envio de alertas está funcionando corretamente, você pode parar o serviço SSH e esperar a execuç ão das próximas verificações do Nagios:

vagrant@monitor$ sudo service ssh stop ssh stop/waiting O Nagios irá tentar executar a verificaç ão quatro vezes antes de declarar o serviço indisponível. Assim que o serviço aparecer com status vermelho na tela de administraç ão do Nagios e o número de tentativas alcançar “4/4”, você deverá receber um alerta por e-mail. Para que tudo volte ao normal, reinicie o serviço SSH:

vagrant@monitor$ sudo service ssh start ssh start/running, process 3424 Assim que o Nagios detectar que o serviço voltou ao normal, você rece- berá um e-mail avisando que o serviço está recuperado.

Página 75

Casa do Código Capítulo 3. Monitoramento 3.6 Um problema atinge produção,e agora?

Agora que temos um sistema de monitoramento configurado para executar verificações e enviar alertas sobre eventuais problemas na infraestrutura da loja virtual, podemos simular um cenário de falha de um dos servidores. Essa também é uma boa maneira de testar se o sistema de monitoramento está funcionando corretamente.

Vamos imaginar que nosso servidor de banco de dados tenha sofrido um problema de hardware e parou de funcionar. Para isto, basta sair da máquina virtual de monitoramento executando o comandologoutou simplesmente digitandoCTRL-De pedir para o Vagrant destruir a máquina virtual do banco de dados:

vagrant@monitor$ Connection to 127.0.0.1 closed.

$ vagrant destroy db db: Are you sure you want to destroy the ’db’ VM? [y/N] y ==> db: Forcing shutdown of VM…

==> db: Destroying VM and associated drives…

Dentro de alguns minutos, o sistema de monitoramento irá detectar que o servidor está indisponível e enviará um alerta. A partir deste momento, usuá- rios não conseguem mais acessar a loja virtual para efetuar compras. Sendo o engenheiro responsável pela operaç ão em produç ão, você recebe a notificaç ão e responde prontamente para confirmar a falha e agora você precisa restituir o serviço.

Olhando o console do Nagios, você verá algo parecido com a figura3.6.

Ohostdo banco de dados e todos os seus serviços estão vermelhos, porém a verificaç ão do serviço HTTP no servidor web também falha, indicando que o problema do banco de dados está afetando a loja virtual.

DevOps na prática – entrega de software confiável e automatizada