PRUEBA

Monitorizando más de cerca la infraestructura críticaMonitorizar para prevenir y detectar los problemas es esencial.

Flavio Xandó es especialista en servicios y tecnología de la información. Tiene formación en ingeniería y experiencia en la gestión y análisis de software. Co-laboró con el periódico O Estado de São Paulo durante diez años y con PCworld durante cuatro años. Actualmente es socio y director de consultoría y solu-ciones de software de FX Soluções em Informática.

Autor: Flavio XandóPublicado: Septiembre 2014

PRUEBA

PÁGINA 2 DE 17

Análisis de valor para el negocioHace un buen tiempo que los recursos de tecnología de la información se convirtieron críticos para las empresas. Hay ramas de actividades en las que TI es parte del nego-cio y no sólo como una herramienta de apoyo sino que tiene una función de carácter totalmente crucial. Y aún cuando TI es un área de soporte, de acuerdo a la forma como cualquier empresa trabaja hoy en día, los recursos tecnológicos son muy importantes. Ser capaz de resolver problemas de forma rápida y, más que eso, ser capaz de antici-parse en la prevención de situaciones críticas es de extrema relevancia.

Por eso el equipo de TI precisa disponer de muchos datos que se traduzcan en infor-mación de calidad para la toma de decisiones. De lo contrario, los eventos que pueden causar algún accidente o poner en peligro la infraestructura no serán fácilmente perci-bidos o localizados. Más que esto. El seguimiento de algunos indicadores especialmente elegidos puede ayudar mucho en una acción proactiva de los profesionales de TI, ayu-dándoles a descubrir los problemas y evitarlos antes de que sucedan.

ContenidoAnálisis de valor para el negocio ................................................................................

Prueba de PRTG - identificando el medio ambiente y la instalación inicial...................

Iniciando la operación – añadiendo sensores ..............................................................

Interfaces de administración Web, Aplicaciones y Smartphone ....................................

Uso distribuido – sondas remotas ...............................................................................

Rastreabilidad de los acontecimientos y errores – Sistema de Tickets ...........................

Errores que yo cometí (y que pueden ser evitados)......................................................

Actualización del PRTG .....................................................................................

Intercambio de servidor del PRTG .....................................................................

Insistencia con algunos dispositivos...................................................................

Conclusión ...............................................................................................................

2

3

5

9

11

13

15

15

15

16

16

PRUEBA

PÁGINA 3 DE 17

Las situaciones críticas siempre exigirán una monitorización muy estrecha e intensa. El caso de un paciente en una unidad de cuidados intensivos del hospital es una buena analogía. Hay sensores de muchos tipos acompañando varias funciones vitales del cu-erpo. Desde el latido del corazón, la presión arterial, el nivel de oxigenación, la tasa de azúcar en la sangre, etc. Si los médicos perciben una caída momentánea de la presión y después el paciente se recupera de forma espontánea, eso tiene un significado. Si la presión está baja y continuamente cayendo eso tiene otra interpretación y va a exigir medidas serias. En el ambiente de TI acontecen las mismas cosas.

Tener la herramienta adecuada y haber elegido los puntos críticos de monitorización permitirán que los problemas puedan ser anticipados y gestionados. Curiosamente no siempre una falla catastrófica es responsable de la interrupción de los servicios impor-tantes en una empresa. Hay situaciones muy simples y al mismo tiempo comunes, como por ejemplo la escalada de consumo de recursos de capacidad de procesamiento en un servidor crítico. Es como si cada día usted se da cuenta que su automóvil tiene que hacer más fuerza para vencer una subida que hay en el camino. Es posible predecir que un día el automóvil no tendrá la fuerza necesaria para superar la pendiente y no va a subir, de igual manera el servidor no será capaz de procesar el volumen necesario de información. Este es el desafío. Ser capaz de ver eso a tiempo y actuar proactivamente.

El gran valor de la herramienta del PRTG para los negocios es exactamente esto. En primer lugar ella puede señalar los problemas reales que ya han sucedido y que nece-sitan atención urgente e inmediata. Y también acompañar de cerca lo que podría llegar a ser un factor de compromiso en un momento futuro. Todo esto asegura la continuidad de la operación de los recursos de TI sin afectar los procesos de negocio. Minutos de interrupción puede costar muy caro para las empresas. Y hay docenas, cientos o miles (dependiendo de la complejidad del entorno) de puntos que requieren seguimiento y vigilancia de posibles fallos. Esta es la competencia y el mérito del PRTG, buscar incans-ablemente todos los puntos críticos y ayudar a prevenir daños para las empresas que puedan derivarse de la interrupción de procesos críticos para el negocio.

Prueba de PRTG – identificando el medio ambiente y la instalación inicial“PRTG – monitorizando totalmente su red e infraestructura*”, por lo tanto el concepto y las principales características del producto no son nuevas para mí. Pero sucedieron desarrollos interesantes en el producto y en su forma de utilización los que justifican la nueva evaluación. Y esta vez se amplió el alcance de la prueba en relación con lugares y equipos.

• 9 localidades remotas

• 18 servidores físicos

• 25 servidores virtuales

• 18 links de Internet

• 30 puntos de acceso WiFi

• 22 impresoras de red

• 9 routers duales de Internet

• 22 switches

• más de 500 usuarios en todas las localidades

Estos números no son enormes pero constituyen una prueba entre 4 a 5 veces mayor que la realizada hace dos años y sirven como un buen parámetro del entorno para poner a prueba la edición de PRTG de 2014.

PRUEBA

PÁGINA 4 DE 17

El primer concepto a ser explicado es el SENSOR. Es un elemento de observación, algo que debe ser analizado y monitorizado. Un dispositivo como, por ejemplo, una impresora puede estar asociada con uno o decenas de sensores. Todo dependerá de la necesidad de monitorización y la información que expone el dispositivo para la red. Una impresora se puede monitorizar por un sensor de presencia y respuesta (comando PING) en la red. Mas hay impresoras que permiten que muchas otras informaciones puedan ser moni-torizadas por más sensores: nivel de suministro, cantidad de páginas impresas, tiempo que está conectado, carga de CPU, uso de memoria… Cada una de esas informaciones es recogida por uno de estos sensores.

Los sensores están disponibles con una riqueza de alternativas impresionante. Hay sensores para diversos tipos de variables que monitorizan el hardware, ambientes de software, redes, tráfico de datos, etc. La cantidad de elementos que puede ser analizada es grande, a tal punto de exigir algunos cuidados. El producto es autorizado por el nú-mero de sensores que se pueden utilizar. Si fueran escogidos mucho más sensores que aquellos que son realmente importantes será necesario contratar una versión más cara. Y si demasiados sensores fueran definidos en el panel de monitorización del PRTG este queda muy cargado y será difícil identificar lo que realmente es más importante para ser analizado. Se trata de la búsqueda de un equilibrio entre la cantidad, la calidad y la capacidad y evaluar las informaciones.

Toda la instalación del PRTG comienza por la elección de su núcleo principal. Este es el ordenador que realizará la verificación permanente de todos los elementos monitori-zando constantemente cada uno de ellos. No es necesaria la asignación de un servidor dedicado para el sistema a menos que el número de sensores utilizados sea superior a ciertos límites. Una PC con 1 o 2 GB de memoria RAM con Windows 7 (o uno más actualizado), 32 o 64 bits, o Windows Server 2008 o más reciente, son suficientes para recibir la instalación del PRTG.

Paessler, desarrolladora de la solución, informa que si el servidor usado para el sistema es virtual, él no debe administrar más de 2000 sensores. Y por encima de ciertos límites, como instalaciones realmente grandes, la recomendación es tener el servidor dedicado para el sistema y para las sondas remotas (asunto que será explorado más tarde).

En esta prueba había posibilidad de elección entre muchos servidores. Fue escogido aquel que tenía la menor carga de trabajo. Se trata de un servidor DELL Power Edge T320, con 8 GB de RAM, procesador Xeon Y5-2407 que sirve como File Server y AD en una red local con apenas 35 usuarios. Consideré la posibilidad de crear una máquina vir-tual Hyper-V o VMware en otra localidad, pero la elección final fue perfecta ya que desde hace casi 50 días el sistema está en el aire y con CERO impacto en la utilización de este servidor para sus funciones del día a día.

FIGURA 01: Consola principal del PRTG

PRUEBA

PÁGINA 5 DE 17

FIGURA 02: Visualizando los primeros sensores

Enseguida el PRTG ofrece muchas maneras para que los puntos críticos puedan ser monitorizados automatizando la instalación de sensores.

• Adición manual de UN sensor para UN dispositivo (IP o nombre)• Adición manual de UN dispositivo y búsqueda automática de todos los sensores• Adición manual de un GRUPO (de IPs) y búsqueda automática de todos los sensores

Las búsquedas automáticas por sensores pueden ser hechas en base a tres niveles de detalle:

• Identificación automática standard (sólo sensores más comunes)• Identificación DETALLADA de sensores – todos los posibles• Identificación detallada basada en una “plantilla” (impresora, router, etc.)

El nivel de mayor automatización permite identificar un rango de IPs y dejar que el PRTG halle todos los dispositivos y sensores posibles. El caso más extremo es el de pedirlo para hacerlo en toda la red. Eso es una operación bastante tardada y va a resultar en un exceso de dispositivos y sensores. De este modo hasta las estaciones de trabajo de los usuarios serán detectadas. Esto no es práctico muchas veces.

Por otro lado un intervalo de direcciones IP puede ser definido. Esto es bueno porque habitualmente el administrador de la red define rangos específicos para los tipos de dispositivos como servidores, impresoras, routers, puntos de acceso, etc. Así el de-scubrimiento automático de informaciones queda mucho más objetivo y dirigido. En este proceso, aunque no existan rangos tan bien definidos, puede aún ser usada una “plantilla”, o sea, si “impresoras” son escogidas, sólo estos tipos de dispositivos y los sensores relacionados con impresoras serán asignados. Todo eso puede ser visto en la figura de abajo en la cual el rango de IP 192.168.1.xxx está siendo analizado entre las direcciones 192.168.1.100 y 192.168.1.110.

Iniciando la operación – añadiendo sensoresLuego de ser instalada la consola del PRTG, automáticamente son añadidos todos los sensores que él identifica como necesarios para el propio servidor en el cual reside. Eso es llamado en su terminología SONDA LOCAL O DISPOSITIVO DE SONDA. Eso hace mucho sentido ya que si el propio servidor en el que reside el PRTG está comprometido de alguna forma entonces la propia recolección de datos también puede estarlo. Por eso la nece-sidad de mirar primero para sí mismo antes de mirar para otros tantos puntos de la red.

PRUEBA

PÁGINA 6 DE 17

Debe quedar claro que añadir y organizar los sensores es una operación sensible y que requiere dedicación y planificación. Si el local que está siendo monitorizado es pequeño puede ser que presentar todos los dispositivos juntos sea suficiente. Pero si la cantidad de elementos monitorizados es mayor algún tipo de clasificación se hace necesaria. El PRTG permite que grupos y subgrupos sean creados. La forma más natural de hacerlo es crear grupos por tipo de dispositivos, pero no es la única forma. La figura 05 mostra-da abajo contiene una posible distribución por categoría.

Son muchas las posibilidades. En mi caso yo preferí añadir algunos dispositivos manu-almente (uno a uno), en la búsqueda de todos los sensores posibles o por rangos como en el ejemplo arriba. Invariablemente al final del proceso yo descubrí muchos sensores que no eran importantes para mí. Eso no es un gran problema media vez puedan ser escogidos los sensores no relevantes y sean borrados de una sola vez. Lo que yo llamo “sensores no relevantes” es algo subjetivo. Puede ser que yo no desee monitorizar, pero otro administrador de red juzgue importante aquel recurso (y viceversa).

FIGURA 04: Eliminando sensores no deseados

FIGURA 03: Añadiendo sensores

PRUEBA

PÁGINA 7 DE 17

FIGURA 06: Diversos sensores y sus respectivos status

Esta visión resumida es muy importante porque muestra cada dispositivo y cantidad de sensores en cada estado. En la pantalla de la consola del PRTG el concepto es siempre este. A cada nivel de consolidación él suma los sensores en cada estado. Así puede ser vista la situación de la empresa entera, de la categoría o del dispositivo en particu-lar. Existe una información importante que se extrae de esa pantalla: el access point 192.168.15.41 no estaba respondiendo. La investigación posterior me llevó a descubrir que fue accidentalmente desconectado (toma desconectada) y eso fue rápidamente resuelto. Parece un incidente trivial y sin importancia, pero no lo es. Justo este access point provee conexión para los usuarios de una sala de reuniones que incluye a invi-tados y clientes de la empresa. No sería descubierta esta situación hasta que esa sala fuera usada, ya con la limitación de conectividad y el problema sucediendo.

En la parte superior de la pantalla de la consola en la figura 05 aparece un resumen global de todo lo que está siendo monitorizado. En el instante que esta pantalla fue capturada había 826 sensores “verdes” (OK), 9 alertas “rojas” (algún problema), 42 sensores en “pausa” y 10 con informaciones no usuales (pero sin problema). Un sensor en pausa es aquel que fue manualmente interrumpido por el administrador (por ejemplo un equipo en mantenimiento) o después de cierto número de alertas rojas él paró de generar alertas nuevas. Esta situación será nuevamente explicada más adelante en el texto cuando yo hable de los “Tickets de Soporte”.

FIGURA 05: Asignación de los dispositivos en

grupos en el PRTG

PRUEBA

PÁGINA 8 DE 17

FIGURA 07: Monitorización de tráfico de uno de

los links de Internet

Arriba, la figura 06 muestra algunos dispositivos monitorizados de la empresa. Algunos de ellos sólo son sensores de respuesta (PING), RDP y HTTP. Otros son más comple-jos, donde aparecen inclusive máquinas virtuales Hyper-V activas, servicios de DNS, etc. Uno de ellos tiene un alerta rojo, pues aquel servicio se encuentra detenido. Hay también un alerta amarillo, señal de alerta (“warning”), pues el espacio en el disco está abajo del 20%. Curiosamente hay arriba un sensor con alerta del tipo “U” en naranja, o sea, “inusual” – no usual. Son parámetros que están (aún sin ser error) presentando valores distantes de los valores medios, sin ser propiamente un problema. Es importante saber que el PRTG mira y llama la atención hacia valores que no son muy esperados. Eso puede justificar una investigación adicional.

Otra información importante puede ser vista en la misma figura 06. El PRTG ya trae sensores listos (basta añadirlos) para varios servicios de nube Google, Dropbox, iCloud y webs muy usadas como twitter, Facebook, Skype... Este sensor de una sola vez muestra el nivel de respuesta de cada uno de estos servicios, así como el propio usuario puede monitorizar otras webs de su interés, note que fue creado un sensor para saber si la web de la UOL está o no accesible.

Estos sensores mostrados son sólo un mínimo ejemplo de lo que se puede obtener con el PRTG. Ellos fueron mostrados en pequeños grupos, pero el administrador de la red podrá exhibirlos todos de una sola vez y rápidamente saber lo que está verde (está OK) y lo que está rojo (incorrecto o problema). Pero ¿cómo el PRTG sabe diferenciar uno del otro? Es muy simple. Un sensor asignado por el PRTG, por ejemplo, espacio en disco en el servidor hereda un parámetro automático del sistema que determina: abajo del 10% es situación roja (problema) y abajo del 20% es sólo un alerta amarillo. El administrador puede alterar estos parámetros según su propio criterio y su propia comprensión cam-biando estos límites. Eso aplica para todos los tipos de sensores.

Sensor Bandwidth: Es uno de los tipos de sensores, el cual no exploré en la primera prueba porque es una gran novedad en esta versión: son los sensores de “banda” (bandwidth). No fueron todos los router que probé en los que conseguí obtener esta información; felizmente en el ambiente de prueba, en el más importante router de cada local, a saber un Cisco Linksys RV042, plantilla Dual Wan, conseguí usar y explorar este importante recurso.

Una duda que siempre permanece en la cabeza de los administradores de red es saber si la conexión con Internet está subutilizada o eventualmente sobrecargada. Eso no es tarea fácil porque en un local con 50, 80, 100 o más personas, basta que dos o tres realicen operaciones de gran volumen, como ver videos en 1080p o descargar archivos realmente grandes lo que resultará en algún nivel de degradación en la percepción en el uso de la Internet. Por eso el volumen global movilizado, la tasa de ocupación, la tasa de “uptime”, entre otras, son informaciones vitales para poder evaluar y tomar decisiones ante este importante recurso.

PRUEBA

PÁGINA 9 DE 17

La segunda forma es vía aplicación propia (Windows). En el sitio web del PRTG (Paess-ler) puede ser obtenido e instalado, así como a través de una de las opciones de menú de la interfaz Web. La aplicación es “más clásico”. Trae sistema de menús, ventanas redimensionables y minimizables del Windows, etc. Inclusive tiene una ventana que aparece automáticamente sobreponiéndose a las demás en el caso de haber alertas aún no tratadas. Yo hallé esta ventana apareciendo a toda hora un poco invasiva, pero ella tiene su importancia y es llamar la atención del responsable de monitorizar los eventos críticos y por eso fue diseñada de esta manera.

FIGURA 08: Interfaz WEB del PRTG

Arriba, en la figura 07, podemos ver que en los últimos 7 días (período del análisis) el router quedó operativo 100% del tiempo, el volumen total de tráfico (en Kbytes – cerca de 313 GB – entrada y salida). También vemos el gráfico que ilustra los períodos (días y horas de mayor utilización) e inmediatamente abajo vemos una tabla que detalla la infor-mación del gráfico, trazando hora a hora el análisis de tráfico de entrada, salida y tráfico total. Velocidades (en kbits/s). Muy preciso y muy completo.

Existe otro abordaje para referirse a la calidad de una conexión externa. Pueden ser creados sensores del tipo HTTP que realizan accesos a URLs pre-definidas. El tiempo de acceso y carga de los datos de cada una de esas URLs es registrado y con estos datos históricos también se deduce la calidad de la conexión. Es una medida indirecta y, por lo tanto, sujeta a interpretaciones. Pero durante mi período de prueba estos tipos de medidas presentados fueron de gran valía. Está también la posibilidad de monitorizar los “live data”, o sea, el tráfico en tiempo real, muy útil para identificar en la misma hora cuellos de botella y sobrecarga de uso.

Interfaces de administración Web, Aplicaciones y SmartphoneLa forma más simple y natural de usar el PRTG es por medio de su interfaz Web, ya sea en la red local o remotamente (una vez que la puerta 80 del servidor PRTG esté expue-sta para internet). Usando tecnología AJAX la aplicación Web es de uso óptimo. Probé en Chrome (36.0.19), Firefox (31.0) e Internet Explorer (11.09) con el mismo resultado, visualmente y recursos. Sólo en el IE fue un poco más lento el rediseño de las pantallas. Principalmente la adición de sensores, verificación de alarmas y visualización general del ambiente, son muy bien ejecutados por la interfaz Web.

PRUEBA

PÁGINA 10 DE 17

Curiosamente algunos de los cambios que acontecen como puede ser una nueva ubica-ción, un nuevo sensor hecho por otro operador del PRTG desde otra ubicación, tardan un poco más en aparecer (automáticamente) en la aplicación, pero en la versión Web basta hacer la actualización del navegador (F5) que fácilmente se ve todo lo que hay de nuevo. ¡Un consejo!

Pero aún hay otro camino para tener acceso a los datos valiosos de monitorización del PRTG. Hay versiones de aplicaciones que funcionan en TODAS las plataformas de movilidad existentes: iOS, Android, Blackberry 10 y Windows Phone (las dos últimas en versión beta pero están operativas). Yo instalé en un Blackberry Z30. Con su pantalla grande la facilidad para navegar entre diversas ubicaciones, dispositivos, alertas, etc. hace óptima la experiencia. Y partiendo del nivel máximo donde quedan las ubica-ciones, con cada toque en la pantalla un nuevo nivel de detalle va siendo mostrado: ubicación, grupo, dispositivo, sensor y datos del sensor, etc

FIGURA 09: Ventana de alertas de la aplicación

A lo largo de varias semanas usando el PRTG yo percibí que utilizaba más la interfaz vía navegador única y exclusivamente porque ella tiene todo que la aplicación posee, prácti-camente el mismo aspecto visual y carga ligeramente más rápido. Es perfecta para añadir sensores. Sin embargo si el objetivo es analizar gráficos y otras informaciones con más detalle la interfaz de la aplicación es más rica, presenta más información a la vez, trae los gráficos, tablas asociadas. Para eso la interfaz de la aplicación Windows es invencible.

FIGURA 10: Interfaz completa de la aplicación

para Windows del PRTG

PRUEBA

PÁGINA 11 DE 17

Quiero hacer un comentario más sobre las interfaces. Es algo que sólo percibí ahora al escribir el texto y que me preocupé en capturar en diversas pantallas. En cada una de sus versiones, Web, aplicación o móvil, el PRTG permite que sea escogido el idioma deseado. Yo no me acordé de configurar en portugués en todos los momentos porque yo me siento más a gusto en los servidores y dispositivos con los términos originales en inglés, pero debe ser destacado que todo podría estar en portugués u otro idioma que se escoja.

Uso distribuido – sondas remotasEn la prueba anterior yo ya había superado los límites físicos de la red en la cual fuera instalado el PRTG. Una de las sedes de la empresa era conectada a la matriz por un ser-vicio de VPN. En esta ocasión yo ya había usado el PRTG de esa forma. Remotamente la VPN hacía que las dos redes se comportaran como una sola red. Fue suficiente añadir los sensores necesarios por la propia dirección IP de los dispositivos remotos con los que conseguí monitorizar todo lo que quise, fuera local o fuera remoto.

Esta vez la propuesta de esta prueba era más profunda. La extendí para 9 localidades y de éstas inicialmente cuatro de ellas estaban conectadas entre sí por VPN. Repetí el proceso de la prueba anterior, pero fui más minucioso y generoso con la cantidad de sensores. Pasé a monitorear remotamente informaciones más sensibles.

Percibí que de vez en cuando algunos sensores perdían la información. Descubrí que las conexiones VPN con las oficinas remotas presentaban variaciones en latencia. En una hora el PING era rápido, cerca de 20 ms y en otra hora mucho más lento, cerca de 300 ms. Conseguí usar el PRTG de esa forma, pero a veces algún sensor quedaba con un signo de interrogación “?” hasta que fuera hecha una nueva recolección de datos por el sistema.

Contacté al soporte de la PAESSLER y me fue presentada una solución brillante, mucho mejor. Es sobre ello lo que detallo a continuación. Se trata del “remote probe” o “sonda re-mota”. Funciona como si fuera una “filial” del PRTG. Puede ser instalada en una máquina cualquiera de la red remota, sin necesidad de un ordenador exclusivo. Este se conecta al PRTG central por medio de la Internet (lo estándar es usar el puerto 23560 – que debe ser liberado en el Firewall). A partir de allí toda la adición de grupos, dispositivos y sensores puede ser hecha por el PRTG “central”, pero de hecho quien “fiscaliza” los elementos de la red es la sonda remota.

FIGURA 11: Interfaz de la versión para móvil en

un Blackberry Z30

PRUEBA

PÁGINA 12 DE 17

FIGURA 13: Consola principal del PRTG exhibiendo

todas las localidades remotas

La instalación de la sonda remota es muy simple. Por medio de la interfaz de gestión WEB, accesible a partir de cualquier lugar del PRTG, existe la dirección para download (descargar) y la pantalla de configuración de los permisos de acceso de la sonda remota. Después que se ha hecho la instalación del software y han sido validadas las llaves de seguridad inmediatamente aquel nuevo local aparece para administrarse en la consola central (WEB o Aplicación).

FIGURA 12: Instalación de sonda remota

La seguridad es plena. En el PRTG debe ser autorizado el IP que es usado en Internet por la sonda remota y aún así cada localidad tiene su propia contraseña (access key – que puede ser visto en la figura de arriba).

La consola central del PRTG acumula toda la información, pero donde la sonda remota está en operación la adquisición de datos es hecha por ella. Es lo mejor de los mundos. El mantenimiento, configuración y análisis de datos es centralizada y la captura de datos de los sensores es hecha localmente. Esto acaba de una vez por todas con el eventual problema de latencia cuando se usa vía VPN.

En la figura de abajo pueden ser vistos los 8 grupos de las localidades remotas, siendo que el grupo HNKL está abierto y se ha seleccionado un sensor de una impresora CANON mostrando la cantidad total de páginas impresas. En cada una de estas 8 ubicaciones designadas por los grupos IC, I1, I2, HKNL, ERW, SNG, CFRN y FX hay instalada una sonda remota.

PRUEBA

PÁGINA 13 DE 17

Rastreabilidad de los acontecimientos y errores – Sistema de TicketsFue introducida en 2014 la funcionalidad del sistema de “Tickets de Soporte” en el PRTG. Claro que es muy importante saber que todo está bien, o si hay algún error o comportamiento anormal. Pero es natural que dentro de un equipo que administra la infraestructura de red y diversos dispositivos sea una función esencial el organizar la solución de problemas ya identificados y acompañar su ciclo de vida hasta que sea concluido. Para eso fue creado el versátil sistema de tickets de soporte.

El concepto es simple pues sistemas que realizan este tipo de gestión son relativamente comunes y usados por las áreas de TI de las empresas. Sin embargo la integración con el PRTG tiene beneficios sensibles. En su configuración estándar el PRTG crea “even-tos” y asocia a ellos los tales tickets para funciones de su propia gestión. Por ejemplo, la existencia de nueva versión del PRTG (que exige actualización), el término de una operación de búsqueda por sensores en un dispositivo (que puede exigir una elección de aquellos que son más relevantes), etc.

Pero una vez que existe un sensor presentando un error, eso fue señalado por el PRTG, el administrador vio dónde está el problema, él puede delegar la investigación adicional y la solución de este problema a un miembro de su equipo (el profesional con experiencia en aquel tipo de dispositivo o error).

Note que en el momento en que la figura 12 fue capturada la ubicación FX estaba DIS-CONNECTED. O sea, en aquel instante no había conexión de Internet activa. Eso no es un gran problema porque la sonda remota tiene un búfer de memoria que es capaz de almacenar las últimas 500,000 mediciones y datos de sensores. Eso es suficiente para almacenar por 3 días 100 sensores siendo evaluados cada 1 minuto (tiempo habitual de las sondas remotas). O alrededor de una hora en la instalación puede haber 10,000 sensores. En la práctica es tiempo más que suficiente para restablecer una conexión o activar una conexión de contingencia. Aún más, si en la localidad hay 10,000 sensores, eso indica que es una localidad con un grado de complejidad que justifica tener Internet para cualquier contingencia y así volver a monitorear los datos rápidamente.

FIGURA 14: Instalación de sonda remota por inter-

faz WEB del PRTG

PRUEBA

PÁGINA 14 DE 17

FIGURA 16: Creación de un ticket de soporte delegando la

resolución a un miembro del equipo

Cuando el miembro del equipo entra en el PRTG con su usuario y contraseña o al revisar su email (la comunicación de apertura de ticket es enviada al profesional) él va a recibir la indicación de lo que debe hacer. En la pantalla del ticket que él recibe hay un link para el sensor exacto de aquel dispositivo de aquel local. Eso es muy importante una vez que él tiene acceso a los datos del sensor. Él puede saber desde cuándo el error comen-zó y tener la pista para resolver la situación. Él apunta en el sistema que el problema fue resuelto y su supervisor podrá concluir el llamado (o pedir una nueva verificación). Hay diversos recursos para consultas a los tickets, por grupo, por personas, por dispositivos, etc. Bastante versátil.

Esto fue particularmente útil para mí en el proceso de ajuste de los sensores de muchos dispositivos. Al usar el “auto Discovery” de sensores acabé añadiendo sensores que da-ban señal de alarma con mucha frecuencia, por ejemplo, espacio en disco en el servidor. Ya era conocida la situación y el almacenaje de la red estaba en vías de ser ampliado. Así pude abrir tickets de soporte para ajustar la sensibilidad de los sensores para otros límites (por ejemplo enviar señal de alarma con 10% y no 20%) y también en otro caso semejante fue abierto el ticket para que uno de los miembros del equipo archivase algunas carpetas antiguas liberando así espacio en el disco y no más ocurriese una alarma.

Algunos tipos de alarma, por ejemplo, una impresora sin comunicación, puede generar de forma automática un Ticket de Soporte para investigación y solución del problema. Esa es una buena medida porque hecho el registro en el sistema de tickets el sensor entra en modo “pausa” y deja de enviar la señal de alarma constantemente sobre aquella indispo-nibilidad, pero la tarea de analizar y resolver ya fue encaminada hacia alguien. Este com-portamiento es configurable, queda a elección del administrador de la red y del PRTG.

En la figura de arriba hay un ejemplo de eso. Un access point del local I1 está pre-sentando error de DNS. Esta situación precisa ser resuelta y por eso un ticket va a ser abierto para que el operario Maikson investigue y resuelva el problema.

FIGURA 15: Instalación de la sonda remota por la

interfaz WEB del PRTG

PRUEBA

PÁGINA 15 DE 17

Errores que yo cometí (y que pueden ser evitados)Por tratarse de una implantación de cierto tamaño (casi 1000 sensores), muy diferente de una prueba de concepto que puede ser hecho con mínimos sensores, yo tuve algu-nas dificultades en el proceso. Necesito relatarlas para que futuros usuarios del PRTG no tengan las mismas dudas y problemas que yo tuve.

Cuando ya tenía instaladas todas las sondas remotas y todo estaba funcionando y sólo faltaba añadir algunos sensores necesarios me dí cuenta que había una nueva versión del PRTG. Esto es informado inmediatamente en la pantalla inicial del producto ya sea en la versión de la aplicación Windows o versión Web. No tuve duda y comandé la actualización, de hecho fue realizada de forma muy simple. Concluido el proceso el PRTG fue reiniciado (no el servidor, sólo el servicio del PRTG). En algunos minutos yo observé que todas las sondas remotas ¡estaban desconectadas! Sin entender el porqué inmediatamente pensé en volver a la versión anterior. Pero de repente miré de nuevo la consola y de las 8 sondas remotas una o dos ya estaban nuevamente conectadas.

Sin entender lo que sucedía contacté al soporte de Paessler por email y obtuve la respue-sta. Cuando se actualiza el núcleo del PRTG las sondas remotas debe tener la misma actu-alización, la misma versión. Eso no es problema porque el propio PRTG tiene la inteligencia de enviar automáticamente la nueva versión de las sondas para las localidades remotas. Pero eso tarda un poco, principalmente si son varias localidades. Por eso fue que algunas localidades comenzaron a funcionar y otras no. Era una cuestión de paciencia. Después de algún tiempo, de las 8 localidades 6 ya funcionaban y en las otras 2 había en la consola un mensaje diciendo “restart required”, o sea, que debería ser reiniciado el proceso de la sonda (o simplemente el ordenador con la sonda). Tuve alguna dificultad operacional para contactar a las personas de estas oficinas y obtener su permiso para reiniciar los ordena-dores, pero algún tiempo después todo estaba operativo nuevamente, las 8 localidades remotas con la sonda funcionando y todo online en la consola central del PRTG.

Bueno, en el comienzo de la prueba yo había escogido una de las localidades para ser el punto céntrico del PRTG y comencé toda la configuración en este servidor. Ya había insertado cerca de 500 sensores y 5 localidades remotas cuando me dí cuenta que sería más útil tener el servidor del PRTG en otro sitio. Hice la nueva instalación y comencé a crear todos los locales, dispositivos y sensores de nuevo. Yo ya había trabajado por 10 días (no en tiempo total) en esa configuración. De repente me dí cuenta que ya había pasado un par de horas y que me tardaría mucho más para hacer, con todo cuidado y atención, toda la configuración de nuevo en el nuevo servidor en este nuevo local.

Una vez más yo contacté al soporte de la Paessler por email. Imaginé que podría tener una mejor manera de hacer aquello y de no perder todo el trabajo que ya había hecho. Algún tiempo después llegó la respuesta. Y fue mejor de lo que yo imaginaba. Recibí del soporte este documento* que explica paso a paso cómo realizar la migración y cómo hacerla en diversas situaciones. Si el PRTG estaba en una máquina de 32 bits y está siendo migrado para 64 bits (y viceversa), cómo resolver la activación de la licencia en el nuevo servidor, cuáles archivos y carpetas transferir... no es un proceso muy compli-cado, pero hay varios pasos a seguir. ¡Y todo salió bien! Yo comencé equivocándome al querer instalar y configurar todo de nuevo, pero con la debida orientación aceleré ba-stante la reimplantación del PRTG y después la implantación completa, que me permitió seguir con la prueba, y luego concluir y escribir esta evaluación.

INTERCAMBIO DE SERVIDOR DEL PRTG

ACTUALIZACIÓN DEL PRTG

* http://kb.paessler.com/en/topic/413-how-can-i-move-migrate-my-prtg-installation-to-another-computer

PRUEBA

PÁGINA 16 DE 17

FIGURA 17: Consola principal del PRTG

¡El recurso de búsqueda automática de sensores es óptimo! Muchas veces crea decenas de sensores útiles para dispositivos. Normalmente no todos son realmente críticos (para mi caso). De esa forma este proceso de crear todos los sensores posibles y después escoger los que mejor se adaptan es un buen camino. Pero con algunos dispositivos era frustrante verlo buscando sensores por casi 10 minutos y después crear sólo el sensor de PING (si hay respuesta en la red). Descubrí que en algunos tipos de equipos como, por ejemplo, routers y hasta servidores Windows, el registrar las credenciales de au-tenticidad ayudan a superar este problema. Pero aún así algunos equipos no exponían más que uno o dos sensores. Leyendo la documentación del PRTG descubrí que podría intentar activar en las sondas y en el servidor el protocolo SNMP* necesario para la comunicación con algunas categorías de dispositivos.

Hecho eso conseguí avanzar con algunos dispositivos, pero no todos. Yo estaba obse-sionado con la posibilidad de monitorear el nivel de suministro de algunas impresoras, muy útil para prever su sustitución. Pero después de mantener una larga lucha con estos equipos, descubrí en documentos de Paessler y en las discusiones de usuarios en los forums de soporte que hay sobre equipos (principalmente los más antiguos pero no sólo ellos) que simplemente no son “monitoring friendly”, o sea, no tienen aún la información que yo necesitaba. Y en este caso no hay nada más qué hacer. Yo perdí mucho tiempo con algunas impresoras haciendo y rehaciendo el escaneo de sensores de las más diversas formas. Mi consejo es, si después de usar el escaneo simple, con la autenticación (credenciales correctas), con SNMP activado y aún así no obtiene los sensores que necesita, la culpa no será del PRTG y sí del dispositivo.

INSISTENCIA CON ALGUNOS DISPOSITIVOS

ConclusiónA diferencia de la primera prueba que hice en 2012, esta vez el PRTG fue instalado en un ambiente más complejo. Tanto 2012 como ahora en 2014 la herramienta fue coloca-da en producción en ambiente real. Pero esta vez cruzó muchas fronteras, 8 localidades remotas, cerca de 1000 sensores. Si otra vez se prueba un producto ya conocido puede dar la impresión de estar haciendo lo mismo, eso no fue lo que sentí.

Lo comenté poco en el texto pero las nuevas categorías de sensores, como por ejemplo los de análisis de banda y tráfico, las sondas WiFi para verificar si el sistema de red sin cable está teniendo el desempeño adecuado, el subsistema de tickets de soporte, las sondas remotas... todo eso dio un valor y un sabor bastante diferente a esta prueba.

* http://es.wikipedia.org/wiki/Simple_Network_Management_Protocol

PRUEBA

PÁGINA 17 DE 17

En el análisis de valor del negocio realizado al inicio de este texto yo destaqué la im-portancia de este tipo de herramienta para las organizaciones. En un escenario cada día más amplio (y complejo) que es la infraestrutura de TI, muchas veces localizar la causa de un problema, una lentitud o una interrupción del servicio no es siempre simple. Y servicios de TI detenidos en la empresa pueden tener costos que van de alto a intolera-ble. Adicionalmente, poder hacer análisis predictivos de los indicadores (sensores) con el objetivo de tener una postura proactiva tiene también gran valor.

La política de comercialización del PRTG por parte de Paessler es muy clara y trans-parente, detallada en el link citado. El costo es definido por la cantidad de sensores posibles de ser usados, comenzando por 100 sensores a US$ 440 llegando hasta la licencia multinacional global ilimitada por US$ 47,250, con otras opciones en medio del camino. Al contratar el usuario el PRTG tiene 12 meses de soporte y actualización del producto. Después puede renovar por más de 12, 24 o 36 con descuentos progresivos. Sin embargo si no lo renova puede permanecer usando el producto pero sin derecho a soporte y actualización. Son reglas simples, directas y claras. Hay otros buenos pro-ductos que se disponen a hacer la misma cosa que el PRTG (algunos hasta más), pero trabajan con reglas complejas y a un nivel de precio bastante más elevado.

Yo quedé particularmente impresionado con la evolución del producto en estos dos años, pues de por sí ya era una buena solución. Deben ser destacadas las innovaciones, el incremento de recursos, las facilidades y el óptimo soporte que tuve en todas las oca-siones que solicité ayuda. Como dije, hay varias alternativas de empresas que buscan una solución para el problema de monitorización de infraestrutura, pero el PRTG sin duda merece un lugar destacado entre las posibilidades de elección. En mi escenario resolvió completamente la demanda, dio el resultado esperado y superó mi expectativa en el aspecto de las sondas remotas.

480368/ES/20141119