Análise de valor para o negócio
Já faz um bom tempo que os recursos de tecnologia de informação se tornaram
críticos para as empresas. Há ramos de atividades que a TI é parte do negócio e
não apenas uma ferramenta de apoio e sim uma função de caráter totalmente
crucial. E mesmo quando TI é uma área de apoio, da forma como qualquer empresa
trabalha hoje em dia, os recursos de tecnologia são muito importantes. Ser
capaz de resolver problemas rapidamente e, mais do que isso, ser capaz de se
antecipar na prevenção de situações críticas é de extrema relevância.
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.
Testando o PRTG –
identificando o ambiente e instalação inicial
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.
- 9 localidades remotas
- 18 servidores físicos
- 25 servidores virtuais
- 18 links de Internet
- 30 pontos de acesso WiFi
- 22 impressoras de rede
- 9 roteadores Duais de Internet
- 22 switches
- mais de 500 usuários em todas as localidades
Estes números se não são imensos configuram um teste entre 4
a 5 vezes maior do que aquele feito há dois anos e serve como um bom parâmetro
de ambiente para colocar a prova o PRTG na sua edição de 2014.
figura 01 – console principal do PRTG
(clique para ampliar)
O primeiro conceito a ser explicado é o do SENSOR.
Trata-se de um elemento de observação, algo a ser analisado e monitorado. Um
dispositivo como, por exemplo, uma impressora pode ter associado apenas um ou
dezenas de sensores. Tudo dependerá da necessidade de monitoração e das
informações que aquele dispositivo expõe para a rede. Uma impressora poder ser
apenas monitorada pelo sensor de presença e resposta na rede (um comando PING).
Mas há impressoras que permitem que muitas outras informações possam ser
monitoradas por mais sensores: nível do suprimento, quantidade de páginas
impressas, tempo que está ligada, carga de CPU, uso de memória... Cada
informação dessas é coletada por um destes sensores.
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).
Neste teste havia possibilidade de escolha entre muitos
servidores. Foi escolhido aquele que tinha menor carga de trabalho. Trata-se de
um servidor DELL Power Edge T320, com 8 GB de RAM, processador Xeon E5-2407 que
serve como File Server e AD em uma rede local com apenas 35 usuários.
Considerei a possibilidade de criar uma máquina virtual Hyper-V ou VMware em
outra localidade, mas a escolha final foi perfeita uma vez que há quase 50 dias
o sistema está no ar e com impacto ZERO na utilização deste servidor para suas
funções do dia a dia.
Iniciando a operação – adicionando
sensores
Logo após ser instalado o console do PRTG, automaticamente
já são adicionados todos os sensores que ele identifica como necessários para o
próprio servidor no qual reside. Isso é em sua terminologia chamado de LOCAL
PROBE ou DISPOSITIVO DE SONDA. Isso faz muito sentido uma vez que se o próprio
servidor que reside o PRTG estiver comprometido de alguma forma a própria
coleta de dados pode também estar. Por isso a necessidade de olhar para si
mesmo antes de olhar para tantos outros pontos da rede.
figura 02 – visualizando os primeiros sensores
Em seguida o PRTG oferece muitas maneiras para que os pontos
críticos possam ser monitorados e automatizando a instalação de sensores.
- Adição manual de UM sensor para UM dispositivo (IP ou nome)
- Adição manual de UM dispositivo e busca automática de todos os sensores
- Adição manual de um GRUPO (de IPs) e busca automática de todos os sensores
As buscas automáticas por sensores podem ser feitas baseadas em três níveis de detalhes:
- Identificação automática padrão (apenas sensores mais comuns)
- Identificação DETALHADA de sensores – todos possíveis
- Identificação detalhada baseada em um “template” (impressora, roteador, etc.)
O nível de maior automação permite identificar uma faixa de IPs e deixar para o PRTG achar todos os dispositivos e sensores possíveis. O caso mais extremo é pedir para fazer na rede inteira. Isso é uma operação razoavelmente demorada e vai resultar em um excesso de dispositivos e sensores. Dessa forma até estações de trabalho de usuários serão detectadas. Isso não é muitas vezes prático.
Por outro lado um intervalo de endereços IP pode ser definido. Isso é bom porque habitualmente o administrador da rede define faixas específicas para os tipo de dispositivos como servidores, impressoras, roteadores, access points, etc. Assim a descoberta automática de informações fica bem mais objetiva e dirigida. Neste processo, mesmo que não existam faixas tão bem definidas, pode ainda ser usado um “template”, ou seja, se “impressoras” são escolhidas, apenas estes tipos de dispositivos e sensores relacionados com impressoras serão atribuídos. Isso tudo pode ser visto na figura abaixo na qual a faixa de IP 192.168.1.xxx está sendo analisada entre os endereços 192.168.1.100 e 192.168.1.110.
figura 03 – adicionando sensores (clique para ampliar)
São muitas possibilidades. No meu caso eu preferi adicionar
alguns dispositivos manualmente (um a um), mas com a busca de todos os sensores
possíveis ou por faixas no exemplo acima. Invariavelmente no final do processo
eu descobria muitos sensores que não eram importantes para mim. Isso não é um
grande problema uma vez que podem ser escolhidos os sensores não relevantes e
serem apagados de uma só vez. O que eu chamo de “sensores não relevantes” é
algo subjetivo. Pode ser que eu não deseje monitorar, mas outro administrador
de rede julgue importante aquele recurso (e vice-versa).
figura 04 – eliminando sensores não desejados
Deve ficar claro que adicionar e organizar os sensores é uma operação sensível
e que requer dedicação e planejamento. Se o local sendo monitorado é pequeno
pode ser que apresentar todos os dispositivos juntos seja suficiente. Mas se a
quantidade de elementos monitorados for maior algum tipo de classificação se
faz necessária. O PRTG permite que grupos e subgrupos sejam criados. A forma
mais natural é criar grupos por tipo de dispositivos, mas não é a única forma.
A figura 05 mostrada abaixo contém uma possível distribuição por categoria.
figura 05 – alocação dos dispositivos em grupos no PRTG
Esta visão resumida é bem importante porque mostra cada
dispositivo e quantidade de sensores em cada estado. Na tela de console do PRTG
o conceito é sempre este. A cada nível de consolidação ele soma os sensores em
cada estado. Assim pode ser vista a situação da empresa inteira, da categoria
ou do dispositivo em particular. Existe uma informação importante que se extrai
dessa tela: o access point 192.168.15.41 não estava respondendo. Investigação
posterior me levou a descobrir que fora acidentalmente desligado (tomada
desconectada) e isso foi prontamente resolvido. Parece um incidente trivial e
sem importância, mas não é. Justo este access point provê conexão para os
usuários de uma sala de reuniões inclusive convidados e clientes da empresa!
Não seria descoberto até que a tal sala fosse usada, já com a limitação de
conectividade e o problema acontecendo.
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”.
figura 06 – diversos sensores e seus respectivos status (clique para ampliar)
A figura 06 acima mostra alguns dispositivos monitorados da empresa. Alguns
deles apenas há sensores de resposta (PING) , RDP e HTTP. Outros são mais
complexos onde aparecem inclusive máquinas virtuais Hyper-V ativas, serviços de
DNS, etc. Um deles tem um alerta vermelho, pois aquele
serviço se encontra parado. Há também um alerta amarelo, sinal de alerta
(“warning”), pois o espaço em disco está abaixo de 20%. Curiosamente há acima
um sensor com alerta do tipo “U” em laranja, ou seja, “unusual” – não usual. São parâmetros que
estão (mesmo sem ser erro) apresentando valores distantes dos valores médios, sem
ser propriamente um problema. É importante saber que o PRTG olha e chama a
atenção para valores que não são muito esperados. Isso pode valer uma
investigação adicional.
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.
Estes sensores mostrados são apenas um mínimo exemplo do que
se pode obter com o PRTG. Eles foram mostrados em pequenos grupos, mas o
administrador da rede poderá exibi-los todos de uma só vez e rapidamente saber
o que está verde (está
OK) e o que está vermelho (errado ou
problema). Mas como o PRTG sabe diferenciar um do outro? É muito simples. Um
sensor alocado pelo PRTG, por exemplo, espaço em disco no servidor herda um
parâmetro automático do sistema que determina: abaixo de 10% é situação vermelha (problema) e abaixo de 20% é apenas um
alerta amarelo. Mas o
administrador pode alterar estes parâmetros segundo o seu próprio conceito e
seu próprio entendimento mudando estes limites. Isso vale para todos os tipos
de sensores.
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.
figura 07 – monitoração de tráfego de um dos links de Internet (clique para
ampliar)
Na figura 07 acima podemos ver que nos último 7 dias
(período da análise) o roteador ficou operacional 100% do tempo, o volume total
de tráfego (em Kbytes – cerca de 313 GB – entrada e saída). Também vemos o
gráfico que ilustra os períodos (dias e horas de maior utilização) e logo
abaixo uma tabela que detalha a informação do gráfico, trazendo hora a hora a
análise de tráfego de entrada, saída, tráfego total. Velocidade (em kbits/s).
Muito preciso e muito completo.
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.
Interfaces de gerenciamento Web, Aplicativo e smartphone
A forma mais simples e natural de usar o PRTG é por meio de sua interface Web,
seja na rede local ou remotamente (uma vez que a porta 80 do servidor PRTG
esteja exposta para a Internet). Usando tecnologia AJAX a aplicação Web é de
ótima usabilidade. Testei em Chrome (36.0.19), Firefox (31.0) e Internet
Explorer (11.09) com o mesmo resultado, mesmo visual e recursos. Apenas no IE
foi um pouco mais lento o redesenho das telas. Principalmente adição de
sensores, verificação de alarmes e visualização geral do ambiente, são muito
bem executados pela interface Web.
figura 08 – interface WEB do PRTG
(clique para ampliar)
A segunda forma é via aplicativo próprio (Windows). A partir
do site do PRTG (Paessler) ele pode ser obtido e instalado, bem como por uma
das opções de menu da interface Web. O aplicativo é mais “clássico”. Traz sistema
de menus, janelas redimensionáveis e minimizáveis do Windows, etc. Tem
inclusive uma janela que aparece automaticamente se sobrepondo às demais no
caso de haver alertas ainda não tratados. Eu achei esta janela aparecendo toda
hora um pouco invasiva, mas ela tem a sua importância, chamar a atenção do responsável pelo monitoramento
aos eventos críticos e por isso foi desenhada deste jeito.
figura 09 – janela de alertas do aplicativo
(clique para ampliar)
Ao longo das várias semanas usando o PRTG eu percebi que utilizava
mais a interface via browser apenas e tão somente porque ela tem tudo que o
aplicativo tem, praticamente o mesmo visual e carrega ligeiramente mais rápido.
É perfeita para adicionar sensores. Porém se o objetivo é analisar gráficos e
outras informações com mais detalhes a interface do aplicativo é mais rica,
apresenta mais informações ao mesmo tempo, traz os gráficos, tabelas
associadas. Para isso a interface do aplicativo Windows é imbatível.
figura 10 – interface completa do aplicativo para Windows do PRTG (clique para
ampliar)
Curiosamente algumas das mudanças que acontecem, um novo
local, um novo sensor feito por outro operador do PRTG a partir de outro local,
demoram um pouco a mais para aparecer (automaticamente) no aplicativo, mas na
versão Web basta fazer o refresh do navegador (F5) que facilmente se vê tudo
que há de novo. Uma dica!
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.
figura 11 – interface da versão mobile em um Blackberry Z30 (clique para
ampliar)
Quero fazer um comentário a mais sobre as interfaces. Algo
que só percebi agora ao escrever o texto e que me preocupei em capturar
diversas telas. Em cada uma de suas versões, Web, aplicativo ou móvel, o PRTG
permite que seja escolhido o idioma desejado. Eu não me lembrei de configurar o
português em todos os momentos porque eu me sinto mais à vontade nos servidores
e dispositivos com os termos originais em inglês, mas deve ser destacado que
tudo poderia estar em português ou outro idioma escolhido.
Uso distribuído – sondas remotas
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.
figura 12 – instalação da sonda remota
A segurança é plena. No PRTG deve ser autorizado o IP que é
usado na Internet pela sonda remota e ainda cada localidade tem a sua própria
senha (access key – que pode ser visto na figura acima).
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.
figura 13 – console principal do PRTG
exibindo todas as localidades remotas (clique para ampliar)
A instalação da sonda remota é muito simples. Por meio da
interface de gerenciamento WEB, acessível a partir de qualquer lugar do PRTG
existe o endereço para download e a tela de configuração das permissões de
acesso da sonda remota. Feita a instalação do software e validadas as chaves de
segurança imediatamente aquele novo local aparece para gerenciamento no console
central (WEB ou Aplicativo).
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.
figura
14 – instalação da sonda remota pela interface WEB do PRTG (clique para
ampliar)
Rastreabilidade das
ocorrências e erros – Sistema de Tickets
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).
figura
15 – instalação da sonda remota pela interface WEB do PRTG (clique para
ampliar)
Na figura acima há um exemplo
disso. Um access point do local I1 está apresentando erro de DNS. Esta situação
precisa ser resolvida e por isso um ticket vai ser aberto para que o
funcionário Maikson investigue e resolva o problema.
figura
16 – criação de um ticket de suporte delegando a resolução para membro da
equipe (clique para ampliar)
Quando o membro da equipe entrar no PRTG com seu usuário e
senha ou ao checar seu e-mail (a comunicação de abertura de ticket é enviada
para o profissional) ele vai receber a indicação do que ele deve fazer. Na tela
do ticket que ele obtém há um link para o exato sensor daquele dispositivo
daquele local. Isso é muito importante uma vez que ele tem acesso aos dados do
sensor. Ele pode saber desde quando o erro começou e ter a pista para resolver
a situação. Ele aponta no sistema que o problema foi resolvido e o seu
supervisor poderá encerrar o chamado (ou pedir nova verificação). Há recursos
diversos para consultas aos tickets, por grupo, por pessoas, por dispositivos,
etc. Bastante versátil.
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.
figura 17 – console principal do PRTG (clique para ampliar)
Conclusão
Diferente do primeiro teste que fiz em 2012, dessa vez o PRTG foi instalado
em um ambiente mais complexo. Tanto 2012 como agora em 2014 a ferramenta foi
colocada em produção em ambiente real. Mas dessa vez cruzou muitas fronteiras,
8 localidades remotas, perto de 1000 sensores. Se ao testar de novo um produto
já conhecido pode dar a impressão de estar fazendo a mesma coisa, não foi o que
senti.
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.