Integrando o Ubuntu Landscape com o Opsview Enterprise

Recentemente, temos analisado o conjunto de ferramentas do Ubuntu descrito no discurso de abertura do Openstack deste ano por Mark Shuttleworth – de particular interesse foi o Ubuntu Landscape; sua ferramenta de gerenciamento de sistemas e servidores que permite a aplicação de patches e gerenciamento de milhares de servidores Ubuntu a partir de um único console.

A beleza do Landscape é que, se você tem 1000 servidores Ubuntu, pode atualizar o software e aplicar patches em tempo real a partir de uma única visão, você pode até clicar em cada servidor para obter os inventários de hardware e software, ver os relatórios sobre quais processos estão usando a CPU, etc., tudo a partir de uma única ferramenta.

Um item interessante do ponto de vista do Opsview é que ele contém uma aba de “monitoramento” por dispositivo. Esta aba é rudimentar, pois mostra apenas o básico do monitoramento (uso de recursos, throughput de rede, etc) como abaixo:

Isso está presumivelmente sendo coletado / sondado via o cliente Landscape rodando no servidor Ubuntu e usando as saídas usuais de “carga” etc que estão sendo analisadas e modificadas. Este detalhe é bastante básico, no entanto, é improvável que muitas pessoas usem isso como sua única ferramenta de monitoramento em vez do Opsview – é mais um complemento útil que permite verificar a saúde de ‘X’ enquanto você está no painel do Landscape.

No entanto, isso nos fez pensar – e se pudéssemos ainda usar o Opsview como nossa principal ferramenta de monitoramento, que permite que os clientes façam login para visualizar seus sistemas via um painel, relatórios por e-mail, enviar alertas por SMS, etc., mas integrar esses dados do Opsview no painel do Landscape – assim, é possível clicar em “Server100” no Opsview e “Server100” no Landscape e ver os mesmos gráficos. Isso poderia nos permitir ver a saúde do servidor, não importa qual ferramenta estamos usando.

Para fazer isso no Landscape, na verdade, é bastante simples (uma vez que você se acostuma com as nuances do sistema). Primeiro, a partir do nosso console principal, devemos navegar até “Gráficos personalizados” como abaixo:

Em seguida, devemos clicar em “Adicionar gráfico personalizado”, o que traz uma página como abaixo (economizamos tempo populando o campo já):

Como pode ser difícil de ler na imagem, o “código” está colado abaixo:

#!/bin/bash 
cd /usr/local/nagios/bin 
./opsview_rest --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview' | grep value | sed -e 's/value => //g' | sed -e 's/,//g' | sed 's/ //g'

Isso basicamente usa o comando opsview_rest para se conectar ao sistema de monitoramento Opsview e obter a métrica “max_used_connections” do host “opsview” e, em seguida, faz algumas modificações para nos dar um valor gráfico, ou seja, “28”, em vez de “value=>28;21;s…” que o Ubuntu não gosta :)

O que isso nos permite fazer é ter nosso sistema de monitoramento Opsview adicionado como um host do Landscape e nos permitir monitorar a saúde do sistema de monitoramento via Landscape, junto com a saúde de qualquer outro host sendo monitorado pelo sistema Opsview – e qualquer verificação de serviço em execução contra ele. Podemos obter essas informações executando o comando:

opsview_rest --username=admin --password=initial --pretty GET /rest/status/performancemetric/?hostname=opsview

Onde “?hostname” é o host que estamos tentando visualizar os dados de desempenho. Uma vez que isso esteja configurado e salvo conforme a captura de tela anterior, precisamos definir nosso “executar como usuário:” (seja root ou um usuário diferente) e “Título do eixo Y” (segundos, conexões de db, temperatura, etc). Uma vez feito isso, clicamos em “Salvar” e isso será aplicado a todos os hosts (se você tiver marcado a caixa).

Então, após um dia ou mais, podemos ir ao host e visualizar a aba “monitoramento” e ver nossos gráficos personalizados:

…e é assim que podemos integrar o Opsview com o Ubuntu Landscape.

O Desafio

O desafio seguinte enfrentado foi que o dispositivo gerenciado pelo Landscape executa o comando:

./opsview_rest --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview'

..que usa “opsview_rest” via bash e roda localmente. O que seria ideal é executar isso de qualquer lugar (ou seja, o servidor que estamos gerenciando no Landscape), mas ainda rodar contra nosso sistema Opsview. O último é fácil; podemos adicionar um prefixo como abaixo:

./opsview_rest *--url-prefix=monitoringtool.company.com* --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview'

…mas isso ainda depende do comando “opsview_rest”, que obviamente precisa estar disponível na máquina local, já que os gráficos personalizados executam o script localmente no sistema gerenciado pelo Ubuntu Landscape. E também isso expõe o nome de usuário e a senha ao servidor host, ou seja, seu servidor web agora tem detalhes de login para o Opsview. No entanto, podemos restringir esse último problema permitindo que esse papel tenha acesso muito específico apenas para leitura, e apenas leitura de alguns itens específicos.

O que precisamos é da capacidade de ter o host que está sendo monitorado pelo Opsview e gerenciado pelo Ubuntu Landscape, para ter a capacidade de consultar o Opsview via a API REST sobre sua própria saúde - para que possa fornecer essas informações de volta ao Landscape para gráficos. No entanto, não podemos distribuir opsview_rest devido a problemas com Perl, dependências, etc., então o que podemos fazer?

O único item que parece funcionar ou satisfazer nossos critérios é usar check_nrpe da “maneira não tradicional”. O que quero dizer com isso, é que tradicionalmente o NRPE é um programa do lado do cliente que é consultado pelo Opsview para informações – ou seja, “Quão ocupado está sua CPU? Quão cheios estão seus discos?”. Esses valores são então passados de volta ao Opsview, e armazenados para relatórios, painéis e afins e usados para alertas.

O que encontramos neste exemplo, é que poderíamos instalar o Cliente NRPE (Agente Opsview) no host monitorado/gerenciado e usar isso para consultar o NRPE rodando no mestre do Opsview.

Nesse mestre do Opsview, especificaríamos nossos comandos NRPE em “/usr/local/nagios/etc/nrpe_local/overrides.cfg” (este arquivo não existe, você precisa criá-lo) e adicionar as linhas como abaixo:

############################################################################
# Arquivo de configuração NRPE adicional para Opsview
############################################################################
check_command[get_rest]=/usr/local/nagios/bin/landscape_monitor.pl $ARG1$ $ARG2$

Onde “get_rest” é o comando que chamaremos remotamente, e qualquer coisa “a leste do igual” é o comando real que está sendo executado localmente.

Você pode ver acima, que estamos executando algo chamado “landscape_monitor.pl” – um script Perl que escrevemos para pegar o argumento do host (ou seja, $ARG1$ poderia ser “server00156” ou “networkswitch-X624” no Opsview (o ‘hostname’)). Isso significa que, em vez de ter que criar um check_command para cada um, ou seja:

check_command[get_rest]=/usr/local/nagios/bin/landscape_monitor.pl server1 
check_command[get_rest2]=/usr/local/nagios/bin/landscape_monitor.pl server2 
check_command[get_rest3]=/usr/local/nagios/bin/landscape_monitor.pl server3

Podemos apenas usar $ARG1$ e fazer nosso script Perl esperar por isso. Em seguida, temos o script real (isso usa JSON e IPC, então precisamos dos seguintes pacotes instalados no sistema Opsview: libipc-run-perl libjson-any-perl)

#!/usr/bin/perl Shell
use strict;
use warnings;
use IPC::Run qw(run);
use JSON; 
my $hostname = $ARGV[0] || ''; 
my $perf_metric = $ARGV[1] || '';
my @cmd = qw(/usr/local/nagios/bin/opsview_rest --username admin --password initial --data-format json GET);
push @cmd, '/rest/status/performancemetric?order=metricname&order=hostname&metricname='. $perf_metric .'&hostname='. $hostname; 
run \\@cmd, \\undef, \\my $out;
my $data = decode_json($out);
print $data->{list}->[0]->{value};

Como podemos ver acima, pegamos uma variável (o hostname) e a adicionamos ao comando opsview_rest que estamos construindo. Também pegamos a métrica de desempenho e, após executar o comando construído, imprimimos a saída do comando no formato JSON – “23” em nosso exemplo. Isso nos economiza ter que grep / sed para obter o valor real que o Landscape pode usar.

Então, uma vez que você tenha adicionado seu script “landscape_monitor.pl” a /usr/local/nagios/bin/, e chmod / chown’d ele – você pode prosseguir e criar o arquivo overrides.cfg e adicionar a linha como acima.

Finalmente, inicie o NRPE no dispositivo monitorado/gerenciado – e estamos prontos para descansar como abaixo.

Cenário

Etapa 1: Temos o ambiente de monitoramento padrão; Opsview monitora “Servidor A” e solicita informações como estatísticas de DB, estatísticas do apache, etc., e exibe essas informações em painéis para os usuários via GUI, envia alertas por e-mail/mensagem de texto, etc., quando problemas surgem.

Etapa 2: Agora que o Opsview está coletando milhares de métricas e estatísticas de nossos servidores, podemos usar a API REST para consultar essas estatísticas do servidor monitorado, ou seja, “Servidor A”, usando o script perl acima. Para fazer isso, simplesmente executamos os comandos como abaixo:

./check_nrpe -H opsview-master-server -c get_rest -a serverA Max_used_connections

ubuntu@serverA:/usr/local/nagios/libexec$ ./check_nrpe -H opsview-master-server -c get_rest -a serverA Max_used_connections  
23  
ubuntu@serverA:/usr/local/nagios/libexec$

Ao usar check_nrpe no ServerA e passar nosso hostname, ou seja, “ServerA”, podemos ver o valor max_db_connections que o Opsview tem para nós.

Etapa 3: Porque agora temos a capacidade do dispositivo monitorado, de conhecer suas próprias métricas – as possibilidades do que podemos fazer são infinitas. Em nosso exemplo, simplesmente queremos usar o Landscape para graficar nossas métricas coletadas pelo Opsview para que possamos ter acesso aos gráficos “de relance” em nosso sistema Landscape, além de poder mergulhar no Opsview para ver relatórios / painéis e os itens mais específicos de monitoramento. No entanto, nada nos impede de usar essa tecnologia para integrar o Opsview com outras ferramentas de graficação, etc.

Para integrar isso com o Landscape, é muito simples. Precisamos apenas criar outro “Gráfico Personalizado” como descrevemos anteriormente no documento, e na caixa de texto adicionar:

#!/bin/bash
cd /usr/local/nagios/bin
./check_nrpe –H opsviewserver –c get_rest -a servername max_used_connections

Finalmente, aplicamos esse gráfico ao único host que queremos – e voilà, agora estamos monitorando as “máx conexões de DB” do servidor, via Landscape. Podemos então construir sobre isso, mudar a métrica, etc., então, em essência, você pode ver todas as métricas coletadas pelo Opsview, de dentro do Ubuntu Landscape, RH Satellite, etc.

Uma última olhada

Então, em teoria, agora temos o seguinte cenário:

100 servidores Ubuntu sendo gerenciados e atualizados etc pelo Ubuntu Landscape.
100 servidores Ubuntu sendo monitorados e alertados etc pelo Opsview Enterprise.

Teríamos os hosts adicionados tanto ao Landscape quanto ao Opsview, e usaríamos o Opsview para o nível mais granular de monitoramento, alertas, relatórios, painéis, NetFlow, etc., e então puxar as métricas particularmente interessantes ‘de relance’ para a página do Landscape desses hosts.

Host no Opsview

O host é adicionado no Opsview como acima – podemos ver todas as métricas, grafar sobre elas, controlar quando são monitoradas, mudar métricas com base no período de tempo, etc.

Host no Landscape

Também temos o host no Landscape – a partir desta visão podemos ver o ativo (hardware, etc), atualizar pacotes, ver relatórios sobre a saúde do sistema, etc. Também podemos clicar em “Monitoramento”, e ver nossas informações coletadas pelo Opsview ‘de relance’, de dentro do Landscape, como abaixo:

(embora, um servidor Apache muito subutilizado! ^_^ ).

Experimente o Opsview Enterprise ›

Experimente o Ubuntu Landscape ›