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.
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
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”.
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.
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.
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.
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.
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.
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).
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.
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.
