Publicado:
Leitura 32 minutos
Por isso a equipe de TI precisa dispor de muitos dados que se traduzam em
informação de qualidade para tomada de decisões. Caso contrário eventos que venham
causar alguma pane ou comprometimento na infraestrutura não serão facilmente
percebidos ou localizados. Mais do que isso. O acompanhamento de alguns
indicadores especialmente escolhidos pode auxiliar bastante em uma ação
proativa dos profissionais de TI ajudando-os a descobrir problemas e evitá-los
antes mesmo de terem acontecido.
Situações críticas sempre exigiram monitoração muito próxima e intensa. O caso
de um paciente em uma UTI de hospital é uma boa analogia. Há sensores de muitos
tipos acompanhando várias funções vitais. Desde o batimento cardíaco, pressão
arterial, nível de oxigenação, taxa de açúcar no sangue, etc. Se os médicos
percebem uma queda momentânea da pressão e depois espontaneamente o paciente se
recupera, isso tem um significado. Se a pressão está lenta e continuamente
caindo isso tem outra interpretação e vai exigir sérias medidas. No ambiente de
TI acontecem as mesmas coisas.
De posse da ferramenta certa e principalmente feitas as escolhas dos pontos
críticos de monitoração problemas podem ser antecipados e administrados.
Curiosamente nem sempre uma pane catastrófica é a responsável pela interrupção
dos serviços importantes em uma empresa. Há situações muito simples e ao mesmo
tempo muito comuns, como por exemplo a escalada de consumo de recurso de poder
de processamento em um servidor crítico. É como se fosse constatado que a cada
dia seu automóvel tem que fazer mais força para vencer uma subida que existe no
caminho. É possível prever que um dia ele não terá força para vencer o aclive e
não vai subir, o servidor não vai ser capaz de processar o volume necessário de
informações. Este é o desafio. Ser capaz de enxergar isso a tempo e atuar
proativamente.
O grande valor da ferramenta PRTG para os negócios é exatamente este. Em
primeiro lugar ela pode apontar problemas reais que já aconteceram e que
necessitam de atenção urgente e imediata. E também acompanhar de perto o que
pode vir a ser fator de comprometimento em um momento futuro. Isso tudo garante
a continuidade da operação dos recursos de TI sem impactar os processos de
negócio. Minutos de interrupção pode custar muito caro para as empresas. E são
dezenas, centenas ou milhares (dependendo da complexidade do ambiente) os
pontos que requerem acompanhamento e fiscalização de possíveis falhas. Este é a
competência e o mérito do PRTG, olhar incansavelmente para todos os pontos
críticos e ajudar a evitar prejuízos para as empresas que podem advir da parada
de processos críticos para o negócio.
Testei o PRTG dois anos atrás e na ocasião escrevi o texto “PRTG
– monitorando totalmente sua rede e infraestrutura”, portanto o conceito e
características principais do produto não são novos para mim. Porém evoluções
interessantes aconteceram no produto e na sua forma de uso que justificam a
nova avaliação. E dessa vez foi bastante
ampliado o escopo do teste em relação a localidades e equipamentos.
Os sensores estão disponíveis com uma riqueza de alternativas impressionante.
Há sensores para diversos tipos variáveis que monitoram o hardware, ambientes
de software, rede, tráfego de dados, etc. A quantidade de itens que pode ser analisada
é grande a ponto de exigir alguns cuidados. O produto é licenciado pela
quantidade de sensores que podem ser usados. Se forem escolhidos muito mais
sensores do que aqueles que são realmente importantes será necessário contratar
uma versão mais cara. E se sensores demais forem definidos no ambiente de
monitoração o painel do PRTG fica muito carregado e difícil de identificar o
que realmente é mais importante para ser analisado. Trata-se da busca de um
equilíbrio entre a quantidade, a qualidade e a capacidade e avaliar as informações.
Toda a instalação do PRTG começa pela escolha de seu núcleo principal. Este é o
computador que realizará a permanente verificação de todos os elementos
monitorando constantemente cada um deles. Não é necessária a alocação de um
servidor dedicado para o sistema a não ser que o número de sensores utilizados
seja superior a certos limites. Um PC com 1 ou 2 GB de memória RAM com Windows
7 (ou mais novo), 32 ou 64 bits, ou Windows Server 2008 ou mais novo, são
suficientes para receber a instalação do PRTG.
A Paessler, desenvolvedora da solução informa que se o servidor usado para o
sistema for virtual, ele não deve gerenciar mais de 2000 sensores. E acima de
certos limites, instalações realmente grandes, nesta situação a recomendação é ter
o servidor dedicado para o sistema e para as sondas remotas (assunto que será
explorado mais tarde).
Iniciando a operação – adicionando
sensores
Na parte superior da tela de console na figura 05 aparece o resumo global de
tudo que está sendo monitorado. No instante que esta tela foi capturada havia
826 sensores “verdes” (OK), 9 alertas “vermelhos” (algum problema), 42 sensores
em “pausa” e 10 com informações não usuais (mas sem problema). Um sensor em
pausa é aquele que foi manualmente interrompido pelo administrador (por exemplo
um equipamento em manutenção) ou após certo número de alertas vermelhos ele
parou de gerar alertas novos. Esta situação será novamente explicada adiante no
texto quando eu falar dos “Tickets de Suporte”.
Outra informação importante pode ser vista na mesma figura 06. O PRTG já traz
sensores prontos (basta adicionar) para vários serviços de nuvem Google,
Dropbox, iCloud e sites muito usados como twitter, Facebook, Skype… Este
sensor de uma só vez mostra o nível de resposta de cada um destes serviços, bem
como o próprio usuário pode monitorar outros sites de seu interesse, veja que
foi criado um sensor para saber se o site da UOL está ou não acessível.
Bandwidth Sensor: Um dos tipos de
sensores, o qual não explorei no primeiro teste porque é uma boa novidade desta
versão, são os sensores de “banda” (bandwidth). Não foram todos os roteadores
que testei que consegui obter esta informação, mas felizmente no ambiente de
teste, o mais importante roteador de cada local, a saber um Cisco Linksys
RV042, modelo Dual Wan, consegui usar e explorar este importante recurso.
Uma dúvida que sempre permeia a cabeça dos administradores de rede é ter
ciência de que sua conexão com Internet está subutilizada ou eventualmente
sobrecarregada. Isso não é tarefa fácil porque em um local com 50, 80, 100 ou
mais pessoas, basta que duas ou três realizem operações de grande volume, como
assistir vídeos em 1080p ou downloads de arquivos realmente grandes que
resultará em algum nível de degradação na percepção no uso da Internet. Por
isso o volume global trafegado, a taxa de ocupação, a taxa de “uptime”, entre
outras, são informações vitais para poder avaliar e tomar decisões perante este
importante recurso.
Existe outra abordagem para aferir a qualidade de uma conexão externa. Podem
ser criados sensores do tipo HTTP que realizam acessos a URLs pré definidas. O
tempo de acesso e carga dos dados a cada uma dessas URLs é registrado e com
estes dados históricos também se deduz a qualidade da conexão. É uma medida
indireta e, portanto, sujeita a interpretações. Mas durante meu período de
teste estes tipos de medidas apresentados foram de grande valia. Há também a
possibilidade de monitorar o “live data”, ou seja, o tráfego em tempo real,
muito útil para identificar na mesma hora gargalos e sobrecarga de uso.
Mas ainda há outro jeito de ter acesso aos dados valiosos de monitoramento do
PRTG. Há versões de aplicativo que funcionam em TODAS as plataformas de
mobilidade existentes: iOS, Android, Blackberry 10 e Windows Phone (as duas
últimas em versão beta mas estão operacionais). Eu instalei em um Blackberry
Z30. Com sua tela grande a usabilidade para navegar entre diversos locais,
dispositivos, alertas, etc. é ótima a experiência. E partindo do nível máximo
onde ficam os locais, a cada toque na tela um novo nível de detalhamento vai
sendo mostrado: local, grupo, dispositivo, sensor e dados do sensor, etc.
No teste anterior eu já havia superado os limites físicos da rede na qual
fora instalado o PRTG. Uma das sedes da empresa era conectada à matriz por um
serviço de VPN. Nesta ocasião eu já usara o PRTG dessa forma. Remotamente a VPN
fazia com que as duas redes se comportassem como uma rede só. Assim bastou
adicionar os sensores necessários pelo próprio endereço IP dos dispositivos
remotos que consegui monitorar tudo que quis, fosse local ou fosse remoto.
Dessa vez a proposta deste teste era mais profunda. Estendi para 9 localidades
e destas inicialmente quatro delas estavam conectadas entre si por VPN. Repeti
o processo do teste anterior, mas fui mais minucioso e generoso com a
quantidade de sensores. Passei a monitorar remotamente informações mais
sensíveis.
Percebi que alguns sensores vez por outra perdiam a informação. Descobri que as
conexões VPN com os escritórios remotos apresentavam variações na latência. Uma
hora o PING era rápido, cerca de 20 ms e em outra hora bem mais lento, cerca de
300 ms. Conseguia usar o PRTG dessa forma, mas às vezes algum sensor ficava com
um ponto de interrogação “?” até que fosse feita nova coleta de dados pelo
sistema.
Contatei o suporte da PAESSLER e me foi apresentada uma solução brilhante,
muito melhor! É sobre o que detalho agora. Trata-se do “remote probe” ou “sonda
remota”. Funciona como se fosse uma “filial” do PRTG. Pode ser instalado em uma
máquina qualquer da rede remota, sem necessidade de um computador exclusivo.
Este se conecta ao PRTG central por meio da Internet (o padrão é usar a porta
23560 – que deve ser liberado no Firewall). A partir daí toda a adição de
grupos, dispositivos e sensores pode ser feita pelo PRTG “central”, mas de fato
quem “fiscaliza” os elementos da rede é a sonda remota.
O console central do PRTG acumula todas as informações, mas onde a sonda remota
está em operação a aquisição de dados é feita por ela. É o melhor dos mundos.
Manutenção, configuração e análise de dados centralizada e é feita a captura de
dados dos sensores localmente. Isso acaba de uma vez por todas com o eventual
problema de latência quando usado via VPN.
Na figura abaixo podem ser vistos os 8 grupos das localidades remotas, sendo
que o grupo HNKL está aberto e selecionado um sensor de uma impressora CANON
exibindo a quantidade total de páginas impressas. Em cada um destes 8 locais
designados pelos grupos IC, I1, I2, HKNL, ERW, SNG, CFRN e FX há uma sonda
remota instalada.
Repare que no momento que a figura 12 foi capturada o local FX estava
DISCONNECTED. Ou seja, naquele instante não havia conexão de Internet ativa.
Isso não é um grande problema porque a sonda remota tem um buffer de memória
que é capaz de armazenar as últimas 500.000 medições e dados de sensores. Isso
é suficiente para armazenar por 3 dias 100 sensores sendo avaliados a cada 1
minuto (tempo habitual das sondas remotas). Ou perto de uma hora se na
instalação houver 10.000 sensores. Na prática é tempo mais que suficiente para
restabelecer conexão ou ativar uma conexão de contingência. Ainda mais se na
localidade houver 10.000 sensores, isso indica que é uma localidade com grau de
complexidade que justifica ter Internet para contingência e assim rapidamente
voltar a monitorar os dados.
Foi introduzida em 2014 a funcionalidade do sistema de “Tickets de Suporte”
no PRTG. Claro que saber se está tudo bem, se há algum erro ou comportamento
anormal é bastante importante. Mas é natural que dentro de uma equipe que
gerencia a infraestrutura de rede e diversos dispositivos, organizar a solução
de problemas identificados e acompanhar seu ciclo de vida até que seja
encerrado é função essencial. Para isso foi criado o versátil sistema de
tickets de suporte.
O conceito é simples, pois sistemas que realizam este tipo de gerenciamento são
relativamente comuns e usados pelas áreas de TI das empresas. Porém a
integração com o PRTG tem benefícios sensíveis. Em sua configuração padrão o
PRTG cria ocorrências e associa a elas os tais tickets para funções de seu
próprio gerenciamento. Por exemplo, existência de nova versão do PRTG (que exige
atualização), término de uma operação de busca por sensores em um dispositivo
(que pode exigir uma escolha daqueles que são mais relevantes), etc.
Mas uma vez que existe um sensor apresentando um erro, isso foi sinalizado pelo
PRTG, o administrador viu onde está o problema, ele pode delegar a investigação
adicional e solução deste problema para um membro de sua equipe (o profissional
com expertise naquele tipo de dispositivo ou erro).
Isto foi particularmente útil para mim no processo de ajuste dos sensores de
muitos dispositivos. Ao usar o “auto Discovery” de sensores acabei adicionando
sensores que alarmavam com alta frequência, por exemplo, espaço em disco no
servidor. Era conhecida a situação e o storage da rede estava em vias de ser
ampliado. Assim pude abrir tickets de suporte para ajustar a sensibilidade de
sensores para outros limites (por exemplo alarmar com 10% e não 20%) e também em
outro caso semelhante foi aberto o ticket para que um dos membros da equipe
arquivasse algumas pastas antigas assim liberando espaço no disco e não mais
ocorresse alarme.
Alguns tipos de alerta, por exemplo, uma impressora sem comunicação, pode gerar
de forma automática um Ticket de Suporte para investigação e solução do
problema. Essa é uma boa medida porque feito o registro no sistema de tickets o
sensor entra em modo “pausa” e para de alarmar constantemente aquela
indisponibilidade, mas a tarefa de analisar e resolver já foi encaminhada para alguém.
Este comportamento é configurável, escolha do administrador da rede e do PRTG.
Erros que eu cometi (e que podem ser
evitados)
Por se tratar de uma implantação de certo vulto (quase 1000 sensores), bem diferente
de um teste de conceito que pode ser feito com mínimos sensores, eu tive
algumas dificuldades no processo. Preciso relatá-las para que futuros usuários
do PRTG não tenham as mesmas dúvidas e problemas que eu tive.
Atualização do PRTG
Quando eu já tinha instalado todas as sondas remotas e tudo estava funcionando,
faltava apenas adicionar alguns sensores ainda necessários eu percebi que havia
uma nova versão do PRTG. Isso é avisado logo na tela inicial do produto seja na
versão aplicativo Windows ou versão Web. Não tive dúvida e comandei a
atualização, aliás feita de forma muito simples. Concluído o processo o PRTG
foi reiniciado (não o servidor, apenas o serviço do PRTG). Em alguns minutos eu
percebi que todas as sondas remotas estavam desconectadas! Sem entender o
porquê logo pensei em voltar para a versão anterior. Mas de repente olhei de
novo o console e das 8 sondas remotas uma ou duas já estavam novamente conectadas.
Sem entender o que acontecia acionei o suporte da Paessler por e-mail e obtive
a resposta. Quando se atualiza o núcleo do PRTG as sondas remotas deve ter a
mesma atualização, a mesma versão. Isso não é problema porque o próprio PRTG
tem a inteligência de enviar automaticamente a nova versão das sondas para as
localidades remotas. Mas isso demora um pouco, principalmente se são várias
localidades. Por isso que algumas localidades começaram a funcionar e outras
não. Era uma questão de paciência. Após algum tempo das 8 localidades 6 já
funcionavam e em outras 2 havia no console uma mensagem dizendo “restart
required”, ou seja, que deveria ser reiniciado o processo da sonda (ou mais
simplesmente o computador com a sonda). Tive alguma dificuldade operacional
para contatar as pessoas destes escritórios para obter permissão para reiniciar
os computadores, mas em algum tempo estava tudo operacional novamente, as 8
localidades remotas com a sonda funcionando e tudo online no console do PRTG
central. Foi apenas um susto causado pelo meu desconhecimento desta dinâmica
das atualizações.
Troca de servidor do PRTG
Bem no começo do teste eu tinha escolhido uma das localidades para ser o
ponto central do PRTG e comecei toda a configuração neste servidor. Eu já tinha
inserido cerca de 500 sensores e 5 localidades remotas quando percebi que seria
mais útil ter o servidor do PRTG em outro local. Fiz a nova instalação e
comecei a criar todos os locais, dispositivos e sensores de novo. Eu já tinha
trabalhado por 10 dias (não em tempo integral) nessa configuração. De repente
eu percebi que já tinha passado um par de horas e que eu iria demorar bastante
para fazer, com todo cuidado e atenção, toda a configuração de novo no novo
servidor neste novo local.
Mais uma vez eu acionei o suporte da Paessler por e-mail. Imaginei que poderia
ter uma maneira melhor de fazer aquilo e de não perder todo o trabalho que já
tinha feito. Em algum tempo chegou a resposta. E foi melhor do que eu
imaginava. Recebi do suporte este
documento que explica passo a passo como realizar a migração e em diversas
situações. Se o PRTG estava em máquina de 32 bits e está sendo migrado para 64
bits (e vice versa), como resolver a ativação da licença no novo servidor,
quais arquivos e pastas transferir… Não é um processo muito complicado, mas
há vários passos a seguir. E deu certo! Eu comecei errando ao querer instalar e
configurar tudo de novo, mas com a devida orientação acelerei bastante a
reimplantação do PRTG e depois a implantação completa, que me permitiu seguir
com o teste, concluir e escrever esta avaliação.
Insistência com alguns dispositivos
O recurso de busca automática de sensores é ótimo! Muitas vezes cria dezenas de
sensores úteis para dispositivos. Normalmente nem todos são realmente críticos
(para o meu caso). Dessa forma este processo de criar todos os sensores
possíveis e depois escolher os que melhor se adaptam é um bom caminho. Mas com
alguns dispositivos era frustrante ver ele ficar procurando sensores por quase
10 minutos e depois criar apenas o sensor de PING (se há resposta na rede).
Descobri que alguns tipos de equipamentos como, por exemplo, roteadores e até
servidores Windows, registrar as credenciais de autenticação ajudam a superar
este problema. Mas ainda assim alguns equipamentos não expunham mais que um ou
dois sensores. Lendo a documentação do PRTG descobri que poderia tentar ativar
nas sondas e no servidor o protocolo SNMP
necessário para comunicação com algumas categorias de dispositivos.
Feito isso consegui avanço com alguns dispositivos, mas não todos. Eu estava
obcecado com a possibilidade de monitorar o nível de suprimento de algumas
impressoras, muito útil para prever sua substituição. Mas após travar uma longa
luta com estes equipamentos, descobri em documentos da Paessler e nas
discussões de usuários em fóruns de suporte que há equipamentos (principalmente
os mais antigos mas não só eles) que simplesmente não são “monitoring
friendly”, ou seja, não têm mesmo as informações de que eu precisava. E neste
caso não há mais nada a fazer. Eu perdi muito tempo com algumas impressoras
fazendo e refazendo a varredura de sensores das mais diversas formas. Fica
minha orientação, se usar a varredura simples, com a autenticação (credenciais
corretas), com SNMP ativado e mesmo assim não obtiver os sensores de que
precisa, a culpa não será do PRTG e sim do dispositivo.
Comentei pouco no texto, mas as novas categorias de sensores, como por exemplo
os de análise de banda e tráfego, sondas WiFi para verificar se o sistema de
rede sem fio está entregando o desempenho adequado, o subsistema de tickets de
suporte, as sondas remotas… Isso tudo deu um valor e um sabor bastante diferente
para este teste.
Na análise de valor de negócio feita na abertura deste texto eu destaquei a
importância deste tipo de ferramenta para as organizações. Em um cenário cada
dia mais amplo (e complexo) que é a infraestrutura de TI, muitas vezes
localizar a causa de um problema, uma lentidão ou mesmo uma interrupção do
serviço nem sempre é simples. E serviços de TI parados na empresa podem ter
custos que vão do alto ao intolerável. Adicionalmente poder fazer análises
preditivas dos indicadores (sensores) visando ter uma postura proativa tem
também grande valor.
A política de
comercialização do PRTG por parte de Paessler é muito clara e transparente,
detalhada no link citado. O custo é definido pela quantidade de sensores
possíveis de serem usados, começando por 100 sensores a US$ 440 indo até a
licença multinacional global ilimitada por US$ 47250, com várias outras opções
no meio do caminho. O usuário ao contratar o PRTG tem 12 meses de suporte e
atualização do produto. Depois pode renovar por mais 12, 24 ou 36 com descontos
progressivos. Porém se ele não renovar ainda pode permanecer usando o produto,
porém sem direito a suporte e atualização. São regras simples, diretas e
claras. Há outros bons produtos que se dispõem a fazer a mesma coisa que o PRTG
(alguns até mais), mas trabalham com regras complexas e nível de preço bastante
mais elevado.
Eu fiquei particularmente impressionado com a evolução do produto nestes dois
anos, pois já era uma boa solução. Devem ser destacados, as inovações, o
incremento de recursos, as facilidades e o ótimo suporte que tive em todas as
ocasiões que demandei por ajuda. Empresas que buscam uma solução para o
problema de monitoração de infraestrutura, como falei, há várias alternativas,
mas o PRTG sem dúvida merece lugar de destaque entre as possibilidades de
escolha. No meu cenário resolveu completamente a demanda, trouxe o resultado
esperado e superou minha expectativa no aspecto das sondas remotas.
Engenheiro e Administrador por formação, mas informatólogo por vocação. Antenado com fatos do dia a dia, amante de tecno- logia, corridas de rua e F1.
Login
