Monitorizando más de cerca la infraestructura crítica

Transcripción

1 Monitorizando más de cerca la infraestructura crítica Monitorizar 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. Colaboró 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 soluciones de software de FX Soluções em Informática. Autor: Flavio Xandó Publicado: Septiembre 2014

2 Contenido Análisis de valor para el negocio... 2 Prueba de PRTG - identificando el medio ambiente y la instalación inicial... 3 Iniciando la operación añadiendo sensores... 5 Interfaces de administración Web, Aplicaciones y Smartphone... 9 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 Análisis de valor para el negocio Hace 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 negocio 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 anticiparse 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 informació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 percibidos 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, ayudándoles a descubrir los problemas y evitarlos antes de que sucedan. PÁGINA 2 DE 17

3 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 cuerpo. 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 importantes 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 necesitan 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 incansablemente 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 PÁGINA 3 DE 17

4 FIGURA 01: Consola principal del PRTG 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 monitorizadas 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 monitorizando 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 Y que sirve como File Server y AD en una red local con apenas 35 usuarios. Consideré la posibilidad de crear una máquina virtual 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. PÁGINA 4 DE 17

5 Iniciando la operación añadiendo sensores Luego 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 necesidad de mirar primero para sí mismo antes de mirar para otros tantos puntos de la red. 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 descubrimiento 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 xxx está siendo analizado entre las direcciones y PÁGINA 5 DE 17

6 FIGURA 03: Añadiendo sensores Son muchas las posibilidades. En mi caso yo preferí añadir algunos dispositivos manualmente (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 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 mostrada abajo contiene una posible distribución por categoría. PÁGINA 6 DE 17

7 FIGURA 05: Asignación de los dispositivos en grupos en el PRTG 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 particular. Existe una información importante que se extrae de esa pantalla: el access point 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 invitados 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 06: Diversos sensores y sus respectivos status PÁGINA 7 DE 17

8 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 complejos, 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 cambiando 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. FIGURA 07: Monitorización de tráfico de uno de los links de Internet PÁGINA 8 DE 17

9 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 informació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 Smartphone La 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é expuesta para internet). Usando tecnología AJAX la aplicación Web es de uso óptimo. Probé en Chrome ( ), 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. FIGURA 08: Interfaz WEB del PRTG La segunda forma es vía aplicación propia (Windows). En el sitio web del PRTG (Paessler) 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. PÁGINA 9 DE 17

10 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ácticamente 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 Curiosamente algunos de los cambios que acontecen como puede ser una nueva ubicació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 ubicaciones, con cada toque en la pantalla un nuevo nivel de detalle va siendo mostrado: ubicación, grupo, dispositivo, sensor y datos del sensor, etc PÁGINA 10 DE 17

11 FIGURA 11: Interfaz de la versión para móvil en un Blackberry Z30 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 remotas En 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 servicio 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 remota. 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 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. PÁGINA 11 DE 17

12 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. 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). PÁGINA 12 DE 17

13 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 interfaz WEB del PRTG Rastreabilidad de los acontecimientos y errores Sistema de Tickets Fue 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 eventos 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). PÁGINA 13 DE 17

14 FIGURA 15: Instalación de la sonda remota por la interfaz WEB del PRTG En la figura de arriba hay un ejemplo de eso. Un access point del local I1 está presentando 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 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 (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 comenzó 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 daban 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 indisponibilidad, pero la tarea de analizar y resolver ya fue encaminada hacia alguien. Este comportamiento es configurable, queda a elección del administrador de la red y del PRTG. PÁGINA 14 DE 17

15 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 algunas dificultades en el proceso. Necesito relatarlas para que futuros usuarios del PRTG no tengan las mismas dudas y problemas que yo tuve. ACTUALIZACIÓN DEL PRTG 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 y obtuve la respuesta. Cuando se actualiza el núcleo del PRTG las sondas remotas debe tener la misma actualizació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 ordenadores, 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. INTERCAMBIO DE SERVIDOR 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 . 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 complicado, 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é bastante 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. * PÁGINA 15 DE 17

16 INSISTENCIA CON ALGUNOS DISPOSITIVOS 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 autenticidad 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 obsesionado 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. * FIGURA 17: Consola principal del PRTG Conclusión A 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 colocada 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. PÁGINA 16 DE 17

17 En el análisis de valor del negocio realizado al inicio de este texto yo destaqué la importancia 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 intolerable. 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 transparente, 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 productos 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 ocasiones 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 /ES/ PÁGINA 17 DE 17