[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.0″ _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.4″ _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″]6.803 d\u00f3lares por segundo. Parece lo que gana Jeff Bezos y no ir\u00edamos desencaminados, porque fueron las p\u00e9rdidas<\/A> de Amazon durante un corte de servicio de la CDN Fastly el 8 de junio de 2021. Poco m\u00e1s de 1 hora, 32 millones menos, porque cada segundo de downtime son ventas perdidas, trabajo interrumpido y clientes frustrados que se marchan para no volver. De ah\u00ed la importancia de implementar un uptime monitoring, o monitorizaci\u00f3n de disponibilidad, en nuestra infraestructura tecnol\u00f3gica. La monitorizaci\u00f3n de disponibilidad (uptime monitoring)<\/Strong> es el sistema de vigilancia que asegura que nuestros servicios digitales, desde webs hasta APIs, servidores o Sistemas de Control Industrial<\/a>, est\u00e9n siempre operativos. En t\u00e9rminos t\u00e9cnicos, es un conjunto de protocolos y herramientas que verifican, de forma automatizada y constante, la salud de los componentes de la infraestructura IT. En la pr\u00e1ctica, esto funciona mediante el establecimiento de chequeos programados que eval\u00faan:<\/p>\n Por ejemplo, si una empresa usa Kubernetes, el uptime monitoring no solo verifica que los nodos est\u00e9n activos, sino que pods cr\u00edticos, como un servicio de autenticaci\u00f3n, est\u00e9n ejecut\u00e1ndose correctamente.<\/p>\n El costo de una ca\u00edda de servicio va m\u00e1s all\u00e1 de las p\u00e9rdidas econ\u00f3micas directas. Por ejemplo:<\/p>\n Pero es que la interrupci\u00f3n de un servicio a\u00f1ade tambi\u00e9n un coste cr\u00edtico dif\u00edcil de cuantificar, el de la p\u00e9rdida de confianza del cliente<\/strong>. Seg\u00fan datos<\/a>, un 47% de los usuarios abandonan una web si tarda m\u00e1s de 2 segundos en cargar… Y el 80% no regresa tras una mala experiencia. Uno puede estar vivo, pero tambi\u00e9n agonizando. Por eso, la monitorizaci\u00f3n de disponibilidad no se limita a si un servidor responde. Debemos aplicar t\u00e9cnicas que, combinadas, detecten fallos en distintas capas de la infraestructura, empezando por la m\u00e1s b\u00e1sica.<\/p>\n Consiste en enviar paquetes ICMP a un dispositivo<\/strong> para verificar su conectividad b\u00e1sica. Esto identifica ca\u00eddas totales o cortes en la red, si ese ping no recibe respuesta. Con esta t\u00e9cnica no solo hacemos que el servicio web responda, sino que lo haga con el c\u00f3digo HTTP 200 OK y validez en los certificados SSL. Mientras sea as\u00ed, aseguramos que los usuarios finales pueden acceder y usar la p\u00e1gina web o API. Esta t\u00e9cnica supervisa la resoluci\u00f3n de DNS y tiempos de propagaci\u00f3n, evitando que nuestro dominio resulte inalcanzable por configuraci\u00f3n err\u00f3nea, ataques DNS poisoning, etc. Esta t\u00e9cnica verifica la accesibilidad y el rendimiento de puertos espec\u00edficos en una red. As\u00ed aseguramos que los servicios dependientes de protocolos TCP (HTTP, SMTP, FTP…) y UDP (streaming de v\u00eddeo, VoIP…) est\u00e9n operativos. Otra t\u00e9cnica en nuestro arsenal es la monitorizaci\u00f3n mediante el Simple Network Management Protocol (SNMP), que vigila la red, avisando de cualquier problema o comportamiento inusual. Esto se consigue recopilando datos de routers, switches, o dispositivos IoT mediante este protocolo. Aunque trabajemos con m\u00e1quinas, lo hacemos para personas<\/Strong>, y estas requerir\u00e1n de nosotros garant\u00edas de servicio, dado lo catastr\u00f3fico de cada segundo de downtime. La relaci\u00f3n entre los tres conceptos es clara: Hay un documental fascinante y multipremiado titulado Man on wire (2008). Este recrea la haza\u00f1a del equilibrista franc\u00e9s Philippe Petit, que en 1974 tendi\u00f3 ilegalmente un cable de funambulista entre las Torres Gemelas de Nueva York… y camin\u00f3 por \u00e9l de una a otra. Cada paso para avanzar era una gesta y un m\u00ednimo error o imprevisto significaba el final. El paseo fue ag\u00f3nico, 45 minutos para cruzar 8 veces los 400 metros que separaban las torres. No existen las m\u00e9tricas perfectas, solo las m\u00e1s adecuadas para una organizaci\u00f3n seg\u00fan su actividad, pero es cierto que algunas son fundamentales en el uptime monitoring y el cumplimiento de SLAs, como estas:<\/p>\n\n
\nHoy, todo es m\u00e1s veloz que nunca, pero sigue sin haber nada m\u00e1s r\u00e1pido que la impaciencia de los usuarios, y nada tan eterno como una hora sin documentos, chats o aplicaciones de trabajo, mientras ves marchar los euros por el desag\u00fce.
\nErrores siempre habr\u00e1, la diferencia es la mitigaci\u00f3n, que comienza por detectar instant\u00e1neamente cualquier anomal\u00eda. Por eso, he aqu\u00ed una gu\u00eda completa sobre uptime monitoring incluyendo: qu\u00e9 es, t\u00e9cnicas, herramientas, ejemplos, estrategias, criterios para elegir una buena soluci\u00f3n y mucho m\u00e1s.<\/p>\n\u00bfQu\u00e9 es la monitorizaci\u00f3n de disponibilidad y por qu\u00e9 es esencial?<\/h2>\n
\nEsto permite:<\/p>\n\n
\n
El impacto del downtime, mucho m\u00e1s que n\u00fameros<\/h3>\n
\n
\nEn este contexto, el uptime monitoring ya no es opcional, es lo m\u00ednimo para garantizar la continuidad<\/A> en lo posible.
\n\u00bfY c\u00f3mo empezamos?
\nLa clave es combinar t\u00e9cnicas b\u00e1sicas, como ping al servicio, junto a otras m\u00e1s avanzadas, como monitorizaci\u00f3n de redes<\/a> y experiencia de usuario y usuario web (UX y WUX<\/A>), para crear una red de seguridad multicapa.
\nVeamos las principales t\u00e9cnicas a nuestra disposici\u00f3n para construirla.<\/p>\nPrincipales t\u00e9cnicas de uptime monitoring<\/h2>\n
Ping Monitoring (ICMP), los cimientos de la monitorizaci\u00f3n<\/h3>\n
\nPero, \u00bfy si nuestro WordPress no puede conectarse a su base de datos por un error de configuraci\u00f3n? El ping nos dice que la p\u00e1gina est\u00e1 viva, pero no que est\u00e1 enferma. Por eso, debemos implementar otras t\u00e9cnicas.
\nDe lo contrario, monitorizar con ping puede convertirse en el meme del perro sentado ante una taza en medio de un incendio. El servidor dice \u00abEverything is fine\u00bb si preguntamos, pero todo a su alrededor est\u00e1 en llamas.<\/p>\nHTTP\/S Monitoring, el siguiente paso<\/h3>\n
\nEsto resuelve, por ejemplo, que nuestra tienda Woocommerce haya dado un error 500 en el Black Friday, porque la ley de Finagle siempre se cumple (\u00abTodo lo que pueda ir mal, ir\u00e1 mal en el peor momento\u00bb).
\nEn este caso, podr\u00edamos combinar tambi\u00e9n con monitorizaci\u00f3n sint\u00e9tica<\/a>, simulando transacciones reales, comprobando que funcionan bien y optimizando la experiencia de usuario.<\/p>\nDNS Monitoring, garantizando la resoluci\u00f3n del dominio<\/h3>\n
\nImaginemos que un banco se ha fusionado con otro y, en esas labores, es necesario actualizar DNS, pero hay un error de registros MX que provoca que los clientes no puedan acceder a su banca online.
\nHerramientas como monitorizaci\u00f3n DNS<\/a>, con alertas por cambios no autorizados o fallo en las resoluciones avisar\u00eda de lo ocurrido.<\/p>\nTCP\/UDP Monitoring, vigilando los puertos clave<\/h3>\n
\nPor ejemplo, un hospital accede a historiales m\u00e9dicos de manera segura mediante el puerto 443, pero el becario (siempre es el becario) ha reconfigurado el firewall y bloqueado el puerto sin darse cuenta. Una monitorizaci\u00f3n TCP\/UDP lo detectar\u00eda instant\u00e1neamente mediante una alerta y no despu\u00e9s, mediante los gritos de los m\u00e9dicos.
\nAqu\u00ed es donde vemos la importancia de soluciones que integren monitorizaci\u00f3n de infraestructura IT<\/A>.<\/p>\nSNMP Monitoring, el \u00abperro guardi\u00e1n\u00bb de la red<\/h3>\n
\n\u00bfLa impresora se ha conectado a Internet y est\u00e1 mandando gigas de datos a un servidor extra\u00f1o? Seguro que es \u00abtotalmente normal\u00bb (no, no lo es), pero una monitorizaci\u00f3n SNMP lo detectar\u00eda. Implementar esta t\u00e9cnica evita quebraderos de cabeza, as\u00ed que aqu\u00ed hay una gu\u00eda para configurar SNMP<\/a>.
\nUna buena estrategia de uptime monitoring debe combinar estas t\u00e9cnicas seg\u00fan las necesidades t\u00e9cnicas y operativas de nuestra organizaci\u00f3n. De este modo no caeremos en la situaci\u00f3n de que el ping diga \u00abtodo bien\u00bb, mientras la API de transacciones online est\u00e1 de huelga y ni nos enteramos.
\nEl objetivo final es asegurar el cumplimiento del nivel de servicio<\/strong> (Service Level Agreement o SLA), por lo que conviene profundizar un poco m\u00e1s en este t\u00e9rmino y otros relacionados.<\/p>\nSLA, SLO, SLI y su relaci\u00f3n con la monitorizaci\u00f3n de uptime<\/h2>\n
\nAqu\u00ed es donde entran todas estas siglas con las que debemos estar familiarizados:<\/p>\n\n
\nEl SLI mide el SLO y el SLO, interno y m\u00e1s estricto que el SLA, asegura el cumplimiento de este \u00faltimo.<\/p>\nC\u00f3mo impacta el uptime monitoring en los SLA<\/h3>\n
\nFascinante, en serio, pero lo importante es que, con los SLA, estamos en una situaci\u00f3n similar. Es muy complicado avanzar y raspar cent\u00e9simas de SLAs y SLOs para ascender en esos indicadores, pero es muy f\u00e1cil caer e incumplir en cuanto un downtime nos tire de la cuerda.
\nEl uptime monitoring es la red de funambulistas, que verifica cumplimientos y avisa enseguida para mitigar la ca\u00edda. Sin esa monitorizaci\u00f3n de disponibilidad:<\/p>\n\n
Ejemplos de m\u00e9tricas clave de uptime y SLA<\/h3>\n