[et_pb_section fb_built=\u00bb1″ admin_label=\u00bbSection\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb0px||0px||false|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_row column_structure=\u00bb1_4,3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb50px||||false|false\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb1_4″ disabled_on=\u00bbon|on|off\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb||||false|false\u00bb sticky_position=\u00bbtop\u00bb sticky_offset_top=\u00bb100px\u00bb sticky_limit_bottom=\u00bbsection\u00bb motion_trigger_start=\u00bbtop\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbindice\u00bb _builder_version=\u00bb4.27.5″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||0px||false|false\u00bb custom_padding=\u00bb||14px||false|false\u00bb link_option_url=\u00bb#1″ global_colors_info=\u00bb{}\u00bb]<\/p>\n
Secciones<\/strong><\/p>\n [\/et_pb_text][\/et_pb_column][et_pb_column type=\u00bb3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbseccion\u00bb module_id=\u00bb1″ module_class=\u00bbittopicscontent\u00bb _builder_version=\u00bb4.27.5″ _module_preset=\u00bbdefault\u00bb z_index=\u00bb0″ custom_margin=\u00bb0px||0px||true|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb hover_enabled=\u00bb0″ custom_css_main_element=\u00bbfont-family:%22Pandora-Light%22;\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb sticky_enabled=\u00bb0″]Una gu\u00eda clara y estructurada para entender qu\u00e9 es el monitoreo TI, c\u00f3mo funciona, qu\u00e9 m\u00e9tricas importan y c\u00f3mo elegir el software m\u00e1s adecuado.<\/strong><\/p>\n En Top Gun: Maverick, Tom Cruise se enfrenta a dos cazas superiores sin instrumentos, simplemente con instinto, destreza y vista. Y hasta la pel\u00edcula reconoce que, si no hubiera aparecido Hangman, Cruise hubiera volado en pedazos. Lo mismo ocurre si gestionamos nuestra infraestructura tecnol\u00f3gica sin esos instrumentos, sin herramientas de monitoreo TI. Porque en la vida real, el S\u00e9ptimo de Caballer\u00eda nunca llega y vivimos en una \u00e9poca donde la tolerancia al fallo es inexistente, y muy cara. Empecemos por los cimientos.<\/p>\n En los \u00faltimos a\u00f1os hemos pasado de tener el servidor en el cuarto de la escoba a gestionar entornos h\u00edbridos, donde la informaci\u00f3n cr\u00edtica fluye entre centros de datos on-premise, nubes AWS o contenedores ef\u00edmeros que nacen y mueren en segundos. Todo, porque cualquier cosa que quede en la sombra, por peque\u00f1a que sea, nos puede derribar el castillo de naipes. As\u00ed, se trata de entender profundamente la salud de:<\/p>\n Esta es la l\u00ednea que separa a los profesionales de los amateurs cuando se trata de monitorizar:<\/p>\n El objetivo es resolver problemas y que el tel\u00e9fono siga callado a las tres de la ma\u00f1ana.<\/p>\n La variedad de software de monitoreo TI es amplia y, a menudo, confusa. Para hacerlo f\u00e1cil sin sacrificar precisi\u00f3n, podemos clasificar las herramientas y estrategias seg\u00fan su enfoque principal. Es el que se centra en dispositivos de interconexi\u00f3n<\/strong> (routers, switches, firewalls) y el tr\u00e1fico que fluye por ellos. Del sistema circulatorio pasamos a los \u00f3rganos del sistema. El Application Performance Monitoring (APM) se eleva un nivel y ya no observa y controla a la m\u00e1quina, sino al c\u00f3digo que corre en ella<\/strong>. La nube es el ordenador de otro… que nos puede cobrar una factura astron\u00f3mica en cuanto nos descuidemos, o dejar de funcionar y depender de la destreza de equipos externos que no controlamos. Esta es la clave para los que mandan<\/Strong> sobre nosotros, jefes y clientes, porque traduce los bits a dinero y satisfacci\u00f3n<\/strong> (la cual deber\u00eda generar m\u00e1s dinero). Tener millones de datos es ruido, pero el monitoreo TI se basa en sacar la informaci\u00f3n clave<\/strong> de esos datos para tomar decisiones correctas. Estos signos vitales b\u00e1sicos nos dicen si nuestro Frankenstein vive, y si lo hace sano o con las costuras rotas. Aqu\u00ed entramos en la l\u00f3gica del negocio y si nuestro sistema act\u00faa correctamente, controlando aspectos como:<\/p>\n La experiencia lo es todo, porque es lo que percibe el humano al otro lado… y lo que disparar\u00e1 tickets de soporte<\/A> y quejas si no es adecuada, independientemente de lo que digan los datos t\u00e9cnicos. A la hora de evaluar herramientas de monitorizaci\u00f3n, todos caemos en las luces brillantes y los gr\u00e1ficos 3D. Es lo primero que se ve y no negar\u00e9 que, en el mundo real, las apariencias importan. De nada sirve detectar un fallo si no se avisa a nadie. \u00bfPara qu\u00e9 despertar a un t\u00e9cnico a las 4 de la ma\u00f1ana para reiniciar un servicio si el software puede hacerlo solo? Hoy tienes 100 servidores, ma\u00f1ana nos compra una filial de Google y tienes que encargarte de 10.000. La informaci\u00f3n debe ser digerida y presentada en un formato que se pueda consumir f\u00e1cilmente. En TI nos encantan los debates como este, en ocasiones, hasta la pedanter\u00eda. \u00bfSon el monitoreo y la observabilidad lo mismo? Obviamente no, aunque caminan cerca. \u00bfSe necesitan ambos? S\u00ed.<\/p>\n La clave de esa observabilidad es responder a: \u00ab\u00bfPor qu\u00e9 se est\u00e1 comportando as\u00ed el sistema?<\/strong>\u00bb. Aunque compremos la mejor herramienta del mercado, el monitoreo no es una cuesti\u00f3n de plug and play (\u00bftodav\u00eda se dice eso?). Instalar y olvidar es la manera m\u00e1s r\u00e1pida de tirar el dinero, porque el proceso de implementaci\u00f3n no solo debe ser gradual, sino que el monitoreo ha de evolucionar con nuestra infraestructura<\/strong>, o crearemos puntos ciegos con cambios y ampliaciones. Acabamos de instalar Pandora FMS y las posibilidades son tan amplias, que queremos \u00abmonitorizarlo todo\u00bb. La herramienta puede hacerlo sin problema, pero cometeremos un error de novato. Ya sabemos qu\u00e9 queremos mirar, as\u00ed que es hora de desplegar a nuestros \u00abojos\u00bb en el sistema. Esto puede hacerse de dos maneras principales.<\/p>\n Esa clase de tests, por ejemplo, tambi\u00e9n est\u00e1n disponibles en Pandora FMS para complementar una monitorizaci\u00f3n total, pero por s\u00ed solos se quedar\u00e1n cortos<\/Strong>. Aqu\u00ed es donde ocurre la magia (y donde fallan las herramientas mediocres). El sistema recibe millones de datos en bruto, pero un buen software de monitoreo TI no se limita a mostrarlos, los normaliza y busca patrones para generar conocimiento accionable<\/strong>. Tarde o temprano, algo ocurre y debemos responder, pero es cierto que, idealmente, el monitoreo moderno debe poder desplegar ciertas medidas autom\u00e1ticas<\/Strong> de mitigaci\u00f3n que quiten trabajo al equipo. Cada incidencia es una lecci\u00f3n<\/strong>. Por eso, en un mundo ideal y tras resolver un problema, el equipo debe realizar un an\u00e1lisis post-mortem apoyado en los datos del monitoreo.<\/p>\n Con eso, el monitoreo se afina bas\u00e1ndose en nuestra realidad cotidiana<\/strong>. As\u00ed, se ajustan los umbrales para reducir el ruido o se a\u00f1aden nuevos chequeos, para cubrir los puntos ciegos descubiertos durante el incidente.<\/p>\n Cada monitoreo es tan diferente como la necesidad que lo motiva, por eso, he aqu\u00ed unos ejemplos que muestran su diversidad.<\/p>\n La gesti\u00f3n TI est\u00e1 hecha de cafe\u00edna e historias de terror, estas deben servirnos como aquellos cuentos de peque\u00f1o, como advertencia y aprendizaje. La causa por la que un monitoreo TI se puede convertir en su propio enemigo, ofuscando lo que ocurre bajo el ruido de mil avisos triviales. Usar los valores por defecto es la receta del desastre. En muchas empresas, el equipo de redes tiene su herramienta, el de sistemas otra y el de desarrollo usa una tercera para las aplicaciones, porque se lo aconsej\u00f3 un tipo en Reddit. En TI estamos para asistir al negocio, y quienes lo gestionan no entienden de Modelo OSI o Agentes en el servidor. Si en el informe ponemos que el \u00abRouter X12 de la VLAN 4 ha ca\u00eddo\u00bb, el CEO te va a llamar al despacho. No quiero parecer melodram\u00e1tico, pero la decisi\u00f3n sobre qu\u00e9 herramienta de monitoreo TI utilizar es un poco como casarse. Si nos equivocamos y hay que cambiar, ser\u00e1 doloroso y arriesgado<\/Strong>. La tendencia actual es la convergencia y la pregunta debe ser: \u00ab\u00bfLa herramienta cubre todo mi stack tecnol\u00f3gico actual y futuro?<\/strong>\u00bb. No quiero sacar a pasear fantasmas, como las subidas de precio de VMware que hemos tratado aqu\u00ed<\/a> en detalle, pero quedarnos atrapados con un proveedor es una debilidad estrat\u00e9gica<\/strong>. Que no es solamente el de la licencia, sino el del tiempo y recursos que vamos a tener que dedicar<\/strong> si, por ejemplo, tenemos dos ingenieros empantanados solamente para que la aplicaci\u00f3n de monitoreo siga funcionando.<\/p>\n Real porque todas las herramientas dicen que escalan, hasta que pones a funcionar 50.000 agentes… Esto podr\u00eda entrar dentro de esos costes invisibles anteriores, pero merece apartado propio porque la mejor herramienta del mundo no sirve si nadie la usa<\/strong>, ya sea porque no sabe o porque no la soporta. No voy a insultar la inteligencia de nadie diciendo que soy imparcial. No lo soy, pero la realidad es que Pandora FMS es un referente multipremiado en monitorizaci\u00f3n… desde hace m\u00e1s de 20 a\u00f1os<\/strong>. Y por supuesto, Pandora FMS es la encarnaci\u00f3n de las mejores pr\u00e1cticas de monitoreo TI moderno, que no es reactivo, sino proactivo y predictivo. Recopilemos algunas de las principales dudas sobre el tema de monitorizaci\u00f3n.<\/p>\n No. As\u00ed de claro.\n
\nPorque incluso sin enemigos pegados a la cola, no disponer de un software de monitoreo TI es volar a ciegas<\/strong>, esperando no estrellarse contra una monta\u00f1a que ni siquiera sab\u00edas que estaba ah\u00ed.<\/p>\nPor qu\u00e9 el monitoreo TI es cr\u00edtico en infraestructuras modernas y entornos distribuidos<\/h2>\n
\nLos usuarios no esperan y si una aplicaci\u00f3n tarda tres segundos en cargar, se van. O si un servidor cr\u00edtico cae, las p\u00e9rdidas por minuto son de miles de euros<\/strong>.
\nEn este escenario, una herramienta de monitoreo no es un lujo ni un accesorio \u00abagradable de tener\u00bb, es el sistema nervioso central de cualquier organizaci\u00f3n<\/strong>.
\nEs la diferencia entre dormir tranquilo, sabiendo que tus sistemas velan ese sue\u00f1o, o despertarse a las tres con el tel\u00e9fono en llamas por incidencias evitables.
\nEsta gu\u00eda es el extintor y el ant\u00eddoto, en la que veremos:<\/p>\n\n
Qu\u00e9 es realmente el monitoreo TI<\/h2>\n
\nEl monitoreo TI<\/A> en este contexto es observar, medir y analizar<\/Strong> el comportamiento de nuestra tecnolog\u00eda, para asegurar que ayuda al negocio a cumplir sus objetivos.
\nSin embargo, he aqu\u00ed la trampa habitual.
\nMuchas organizaciones confunden tener visibilidad con tener control operativo<\/strong>.
\nInstalar una herramienta que diga que el disco duro est\u00e1 lleno, despu\u00e9s de que el servidor se cuelgue, no es controlar nuestra infraestructura, es hacerle una autopsia.
\nEl monitoreo moderno busca anticiparse<\/strong>, entender tendencias y correlacionar datos aparentemente inconexos para ofrecer respuestas antes incluso de que se produzca la pregunta de qu\u00e9 ocurre.
\nEsto es cr\u00edtico porque una infraestructura moderna es compleja y, como todo lo complicado, fr\u00e1gil.
\nUn fallo en un microservicio olvidado en un rinc\u00f3n puede desencadenar una cascada de errores que tumbe nuestro e-commerce. Sin ojos en cada eslab\u00f3n de esa cadena, el equipo TI se convierte en un pu\u00f1ado de bomberos apagando incendios, en lugar de arquitectos construyendo valor.
\nSiendo estrictos con definiciones t\u00e9cnicas, el monitoreo TI es el proceso continuo de recolecci\u00f3n, an\u00e1lisis y uso de informaci\u00f3n<\/strong> para controlar y optimizar el rendimiento, la disponibilidad y la seguridad de nuestros recursos tecnol\u00f3gicos.
\nPero bajando a tierra, el monitoreo es el acto de preguntar constantemente a tus sistemas: \u00ab\u00bfEst\u00e1s bien? \u00bfEst\u00e1s trabajando adecuadamente? \u00bfTe queda espacio para seguir haci\u00e9ndolo?\u00bb. Y esperar una respuesta honesta, claro, no el terror\u00edfico: \u00abNo s\u00e9, t\u00fa ver\u00e1s…\u00bb.<\/p>\nQu\u00e9 debemos monitorizar<\/h2>\n
\n
Monitoreo reactivo vs. proactivo<\/h3>\n
\n
Tipos de monitoreo TI<\/h2>\n
\nY s\u00ed, la tendencia l\u00f3gica es la integraci\u00f3n de esas piezas (es decir, herramientas \u00abtodo en uno\u00bb), pero es crucial entenderlas primero por separado.<\/p>\n1. Monitoreo de redes<\/h3>\n
\nLa misi\u00f3n es encontrar cuellos de botella, p\u00e9rdidas de paquetes o fallos en los enlaces.
\nEsta monitorizaci\u00f3n<\/a> es la base de la pir\u00e1mide que estamos construyendo, porque si la red falla, nada m\u00e1s importa<\/strong>.
\nPara ampliar, he aqu\u00ed m\u00e1s informaci\u00f3n sobre monitorizaci\u00f3n de redes<\/a>.<\/p>\n2. Monitoreo de servidores e infraestructura<\/h3>\n
\nYa sea el servidor que traquetea en el s\u00f3tano, una m\u00e1quina virtual en VMware o una instancia en la nube, nos importa el uso de CPU, de RAM, el espacio que queda en disco o la temperatura del hardware, por ejemplo.
\nEste ha sido durante mucho tiempo el h\u00e1bitat natural del administrador de sistemas y tienes m\u00e1s detalles en c\u00f3mo monitorizar servidores<\/a>.<\/p>\n3. Monitoreo de aplicaciones (APM)<\/h3>\n
\n\u00bfPor qu\u00e9 esa consulta a la base de datos tarda 5 segundos y no medio? \u00bfQu\u00e9 funci\u00f3n se est\u00e1 comiendo la memoria como chocolate?
\nLa respuesta a preguntas como esta ser\u00e1 vital para el trabajo de desarrolladores<\/strong> y equipos DevOps.<\/p>\n4. Monitoreo cloud e h\u00edbrido<\/h3>\n
\nPara evitar esos infartos, este tipo de monitoreo, normalmente integr\u00e1ndose con las APIs del proveedor, no solo mira el rendimiento, sino tambi\u00e9n el coste y el uso de recursos<\/Strong> ef\u00edmeros (orquestaci\u00f3n con Kubernetes, funciones serverless…).<\/p>\n5. Monitoreo de negocio y SLAs<\/h3>\n
\nA este nivel, una buena monitorizaci\u00f3n no le habla al CEO en t\u00e9rminos de latencia de servidores (cosa que ni le importa ni le ayuda), sino de facturaciones que aumentaron un 20%, o que no hemos alcanzado los SLAs (Service Level Agreements), de modo que toca compensar por contrato al cliente (y que amenace con marcharse).
\nAhora, una vez entendido lo general, hagamos zoom para ir a lo concreto, viendo qu\u00e9 se controla y gestiona de cada aspecto.<\/p>\nQu\u00e9 se monitoriza en un entorno TI<\/h2>\n
\nEso lo conseguimos mediante la recolecci\u00f3n de las m\u00e9tricas correctas.<\/p>\n1. M\u00e9tricas de infraestructura<\/h3>\n
\nEsas constantes vitales suelen ser, entre otras:<\/p>\n\n
2. M\u00e9tricas de aplicaciones<\/h3>\n
\n
3. M\u00e9tricas de servicio y experiencia<\/h3>\n
\nAs\u00ed, medimos cosas como:<\/p>\n\n
Qu\u00e9 debe ofrecer un software de monitoreo TI moderno<\/h2>\n
\nPero hemos de ir m\u00e1s all\u00e1 y los 5 pilares en los que debemos fijarnos<\/strong> como profesionales son:
\n1. La capacidad de recolecci\u00f3n de m\u00e9tricas y logs
\nLa herramienta debe ser capaz de hablar muchos idiomas: SNMP<\/a> para redes, agentes para servidores, WMI para Windows, SSH para Linux, APIs para la nube…
\nY no solo cuando se trata de n\u00fameros, tambi\u00e9n debe poder recopilar y dar sentido a los logs<\/a><\/strong>, que es donde a menudo se esconde la causa de los problemas. Este es el principal reto que nos encontramos en Pandora, por eso nos esforzamos desde el d\u00eda uno en crear Pandora FMS<\/A> para que no solamente fuera un repositorio centralizado de informaci\u00f3n, sino tambi\u00e9n un traductor universal de logs como en Star Trek<\/strong>, que permitiera convertir millones de datos en inteligencia y conocimiento.<\/p>\n2. Alertas y gesti\u00f3n de umbrales<\/h3>\n
\nSin embargo, esto tiene un reverso tenebroso. El ahogamiento en un mar de alertas <\/strong>es causa principal de p\u00e9rdida de cordura entre los t\u00e9cnicos.
\nEl sistema debe permitir umbrales inteligentes. No solo se trata de: \u00abAv\u00edsame si la CPU > 90%\u00bb, sino: \u00abAv\u00edsame si la CPU > 90% durante 5 minutos y es lunes por la ma\u00f1ana\u00bb, para saber si el sistema va a enlentecerse justo en el empuj\u00f3n de primera hora de la semana.
\nAs\u00ed, nuestra herramienta debe soportar personalizaci\u00f3n de alertas, escalado de las mismas y notificaci\u00f3n multicanal<\/strong> (email, Slack, WhatsApp, SMS…).<\/p>\n3. Automatizaci\u00f3n y acciones correctivas<\/h3>\n
\nLa capacidad de ejecutar scripts de autorrecuperaci\u00f3n ante eventos espec\u00edficos es lo que diferencia una herramienta de observaci\u00f3n pura de una herramienta de gesti\u00f3n.
\nEso s\u00ed, la automatizaci\u00f3n debe ser gradual, controlada y comenzar por los procesos menos cr\u00edticos<\/Strong>, hasta que comprobemos que no nos cambia el trabajo por disgustos.<\/p>\n4. Escalabilidad<\/h3>\n
\nEl software de monitoreo no puede ser el cuello de botella. Debe soportar arquitecturas distribuidas, alta disponibilidad y no degradarse<\/strong> cuando el volumen de datos, o activos a controlar, crece.<\/p>\n5. Dashboards y visualizaci\u00f3n<\/h3>\n
\nUn t\u00e9cnico necesita ver gr\u00e1ficas de I\/O de disco en tiempo real, pero el director de TI no. A ese nivel, precisa un sem\u00e1foro rojo o verde con el estado general del servicio.
\nLa flexibilidad creando vistas personalizadas y dashboards<\/a> para diferentes audiencias es innegociable hoy d\u00eda.<\/p>\nMonitoreo TI vs. Observabilidad<\/h2>\n
\n
\nEsto implica un paso m\u00e1s all\u00e1 de los s\u00edntomas (saber que el disco est\u00e1 lleno y falla) para analizar las causas (se est\u00e1 generando un log innecesario que ocupa gigas, por ejemplo).
\nSi nuestro sistema es monol\u00edtico o sencillo, una monitorizaci\u00f3n es el 90% de la batalla, pero ojal\u00e1 nuestras infraestructuras fueran as\u00ed. Con sistemas distribuidos, h\u00edbridos y multiproveedor, una buena plataforma de monitoreo debe integrar principios de observabilidad o estaremos bajando la fiebre cada d\u00eda sin curar la enfermedad.<\/p>\nC\u00f3mo funciona la monitorizaci\u00f3n TI en la pr\u00e1ctica<\/h2>\n
\nPor eso, la monitorizaci\u00f3n en la pr\u00e1ctica implica 5 fases que se retroalimentan<\/strong> y deben implementarse bajo el principio de mejora continua.
\nEstas son las fases.<\/p>\nFase 1: Planificaci\u00f3n y definici\u00f3n de lo cr\u00edtico para la organizaci\u00f3n<\/h3>\n
\nCuando todo es importante, nada es importante<\/Strong> y acabaremos ahogados en datos irrelevantes.
\nPor eso, todo empieza con una auditor\u00eda de activos y la pregunta:
\n\u00ab\u00bfQu\u00e9 procesos nos har\u00edan perder m\u00e1s dinero y reputaci\u00f3n si fallaran?\u00bb.
\nEl orden por importancia de dichos procesos nos marca las prioridades de monitoreo y los principales KPIs (Key Performance Indicators) a definir y vigilar.
\nSi es necesario y nuestra organizaci\u00f3n es amplia, dividiremos en etapas y aplicamos la fase 2 a lo m\u00e1s cr\u00edtico.<\/p>\nFase 2: Detecci\u00f3n y recolecci\u00f3n de datos<\/h3>\n
\n
\nIgualmente, esos datos deben estar centralizados para posibles auditor\u00edas, cumplimiento legislativo… Una herramienta profesional debe ser tambi\u00e9n repositorio seguro y unificado de dichos datos<\/strong>.<\/p>\nFase 3: Correlaci\u00f3n, procesamiento y an\u00e1lisis<\/h3>\n
\nPor ejemplo, el sistema detecta que la latencia de la base de datos ha subido (s\u00edntoma A) y, a la vez, el tr\u00e1fico en el firewall se ha disparado (s\u00edntoma B).
\nLa correlaci\u00f3n vincula estos eventos para sugerir que puede que un backup no programado est\u00e9 saturando la red, afectando a la base de datos. Sin esta fase, el administrador solo ver\u00eda luces rojas sin conexi\u00f3n aparente.<\/p>\nFase 4: Respuesta y automatizaci\u00f3n<\/h3>\n
\nDe lo contrario, tendremos a ingenieros bien pagados escribiendo en la terminal \u00absudo reboot\u00bb.
\nLa fase de respuesta tiene dos niveles:<\/p>\n\n
Fase 5: Revisi\u00f3n y mejora continua<\/h3>\n
\n
Casos de uso habituales del monitoreo TI<\/h2>\n
\n
Errores comunes y buenas pr\u00e1cticas en monitoreo TI<\/h2>\n
\nPor eso, he aqu\u00ed los errores m\u00e1s comunes que debemos grabarnos a fuego.<\/p>\n1. El exceso de alertas (Alert Fatigue)<\/h3>\n
\nBuena pr\u00e1ctica: <\/strong>Una alerta debe ser siempre accionable. Si el aviso no requiere que un humano intervenga, no debe ser una alerta, debe ser un registro en un informe semanal.
\nLa filosof\u00eda debe ser: si el monitoreo me despierta, es porque la casa est\u00e1 en llamas.<\/p>\n2. Umbrales est\u00e1ticos y mal definidos<\/h3>\n
\nSi un servidor de base de datos est\u00e1 dise\u00f1ado, por ejemplo, para consumir casi toda la memoria RAM disponible a fin de optimizar su cach\u00e9, alertar cuando llega al 80% es absurdo y genera ruido.
\nPor el contrario, un servidor de ficheros que llega al 90% de disco puede tener meses de vida \u00fatil por delante si crece muy despacio.
\nBuena pr\u00e1ctica: <\/strong> Trabajar con l\u00edneas base (baselines) y tendencias. Lo importante no es el valor absoluto, sino la desviaci\u00f3n de la normalidad. Un software moderno debe aprender qu\u00e9 es normal para cada sistema concreto.<\/p>\n3. Falta de correlaci\u00f3n y silos de herramientas<\/h3>\n
\nAs\u00ed, cuando la web va lenta, comienza el juego de la culpa.
\nRedes dice que el tr\u00e1fico es normal, Sistemas que la CPU est\u00e1 bien y Desarrollo que el c\u00f3digo no ha cambiado. Nadie ve la imagen completa.
\nBuena pr\u00e1ctica: <\/strong>Centralizar en una plataforma unificada. La herramienta debe ser capaz de ingerir datos de todas las fuentes y correlacionarlos para mostrar que la lentitud web coincid\u00eda con una actualizaci\u00f3n, por ejemplo.<\/p>\n4. Ausencia de contexto de negocio<\/h3>\n
\nTraducir eso a: \u00abLa oficina de ventas de Madrid no puede procesar pedidos debido a un fallo de comunicaciones por equipos obsoletos\u00bb ya es un problema de negocio entendible.
\nBuena pr\u00e1ctica: <\/strong>Traducir o mapear la infraestructura a servicios de negocio. As\u00ed, el monitoreo no debe vigilar solo servidores, tambi\u00e9n \u00abEl servicio de facturaci\u00f3n\u00bb o \u00abLa tienda online\u00bb, entendiendo qu\u00e9 elementos f\u00edsicos y l\u00f3gicos componen esos servicios.<\/p>\nC\u00f3mo evaluar un software de monitoreo TI<\/h2>\n
\nLa monitorizaci\u00f3n forma parte de los cimientos de la infraestructura y no quieres descubrir que construiste sobre arena cuando ya tienes dos plantas levantadas.
\nPor eso, m\u00e1s all\u00e1 del marketing, los proveedores deben estar dispuestos a una demo y nosotros llevar anotado todo lo que necesitamos<\/strong> en nuestro caso, para realizar un tercer grado hasta que resuelvan todas nuestras dudas.
\nDurante ese proceso, debemos considerar:<\/p>\n1. Prestaciones a presente y futuro<\/h4>\n
\nMuchas soluciones modernas son excelentes monitorizando Kubernetes, pero incapaces de hablar con sistemas antiguos. En Pandora FMS, por ejemplo, no importa si hablamos de Windows, BSD, AIX o venerables ancianos como HP-UX. Hay un agente para todo.<\/p>\n2. Flexibilidad y \u00abVendor Lock-in\u00bb<\/h4>\n
\nDel mismo modo, \u00bfla herramienta tiene flexibilidad? \u00bfUna API abierta y robusta? Porque sin eso, no se adaptar\u00e1 a nuestro negocio. Adem\u00e1s, \u00bftiene un c\u00f3digo abierto como Pandora FMS<\/a> o cerrado como una caja negra?<\/p>\n3. El verdadero Coste Total de Propiedad (TCO)<\/h4>\n
4. Escalabilidad real<\/h4>\n
\nLa cuesti\u00f3n no es solo que la base de datos aguante, sino que siga funcionando igual <\/strong>con 10 datos que con 10.000.<\/p>\n5. Curva de aprendizaje y usabilidad<\/h4>\n
\nPor eso, si la curva de aprendizaje es la de Vim o crear un dashboard requiere un m\u00e1ster, la monitorizaci\u00f3n se llenar\u00e1 de polvo y nuestros sistema de errores evitables.<\/p>\nPandora FMS como software de monitoreo TI<\/h2>\n
\nEso no se consigue por casualidad, sino solucionando frustraciones y solventando desaf\u00edos reales en las trincheras de nuestros clientes, con m\u00e1s de 50.000 instalaciones repartidas por m\u00e1s de 60 pa\u00edses<\/strong>.
\nEso se ha conseguido porque proporciona:<\/p>\n\n
\nComo siempre, hablar (escribir en este caso) es f\u00e1cil, pero demostrar es lo que cuenta y por eso te invitamos a comprobarlo sin compromiso<\/a>.
\nAs\u00ed, no ocurrir\u00e1 nada en ning\u00fan rinc\u00f3n de tu infraestructura sin que te enteres, incluso antes de que suceda, como en Minority Report.<\/p>\nPreguntas frecuentes sobre software de monitoreo TI<\/h2>\n
\u00bfEs suficiente el monitoreo tradicional en entornos cloud?<\/h4>\n
\nEn contextos donde instancias cloud aparecen y desaparecen y nuestra infraestructura est\u00e1 compuesta por hijos de mil padres y que son diferentes entre s\u00ed, necesitamos herramientas que se integren con APIs de proveedores y marchen al paso de v\u00e9rtigo que lleva la tecnolog\u00eda.<\/p>\n\u00bfCu\u00e1ndo necesita una empresa pasar de monitoreo a observabilidad?<\/h4>\n