Guía práctica de integración para equipos de redes y herramientas
La mayoría de los equipos de operaciones de red empresariales utilizan una docena de herramientas. La monitorización detecta anomalías, la gestión de servicios de TI (ITSM) administra la cola de incidencias, la gestión de direcciones IP (IPAM) almacena los datos de direcciones y la base de datos de configuración (CMDB) realiza un seguimiento de los elementos de configuración. Cada una cumple su función de forma independiente. Sin embargo, ninguna comparte información de contexto con las demás.
Se activa una alerta en Splunk. Se abre un ticket en ServiceNow. Un ingeniero consulta manualmente tres sistemas distintos para obtener el contexto necesario para comenzar la resolución de problemas. Para cuando se identifica la causa raíz, el incidente lleva abierto 40 minutos y se han producido dos escalamientos.
Esa brecha entre la detección y la resolución revela un problema de integración.
Esta guía describe tres pasos para completar el proceso: conectar las herramientas existentes para que las alertas se conviertan en activadores de automatización, unificar los datos de la red para que esos activadores se ejecuten con un contexto preciso y orquestar el ciclo completo de diagnóstico y resolución para que el mismo flujo de trabajo se ejecute de forma consistente en cada ocasión.
Si desea ir directamente a una integración específica, NetBrain Página de integraciones Cubre todo el ecosistema.
El primer punto donde falla la integración es en la capa de alertas. Las plataformas de monitorización y observabilidad están diseñadas para detectar problemas, no para actuar sobre ellos. El problema es que la mayoría de los equipos no tienen nada entre la detección y la respuesta, por lo que una alerta que debería iniciar una cadena de diagnóstico automatizada, en cambio, inicia un proceso de triaje manual.
Conectar tus herramientas de monitorización a tu plataforma de automatización convierte las alertas de notificaciones en activadores. A continuación, te mostramos cómo se ve esto en tres patrones de integración comunes.
Splunk: Cuando la anomalía es visible, pero la causa no lo es.
Splunk es muy bueno para la correlación. Cuando una serie de eventos coincide con un patrón definido, se activa. Lo que no puede hacer es mapear la ruta de red detrás de ese evento, verificar las configuraciones de los dispositivos relevantes según la intención, o indicar al ingeniero que responde si la causa raíz es una configuración incorrecta de BGP, una interfaz defectuosa o congestión en la red ascendente.
Esa falta de contexto es lo que convierte un diagnóstico de dos minutos en una escalada de 45 minutos.
Cuando Splunk está integrado con NetBrain Mediante un webhook, una alerta activada se convierte en un disparador para el marco de automatización activado (TAF). NetBrain mapea la ruta afectada y ejecuta el diagnóstico correspondiente. runbooky registra los hallazgos (estado del dispositivo, diferencias de configuración, análisis de ruta) en Splunk junto con la alerta original. El ingeniero que revisa el incidente obtiene una visión correlacionada de lo que sucedió y dónde, en lugar de un registro de eventos sin procesar que deba interpretar desde cero.
El impacto operativo: menos incidentes llegan al nivel 3, y los que llegan cuentan con un contexto de diagnóstico documentado en lugar de un alcance abierto. Splunk sigue haciendo lo que mejor sabe hacer. NetBrain Gestiona lo que Splunk no puede.
SolarWinds y Datadog: Métricas de dispositivos sin contexto de red.
SolarWinds marca un dispositivo como inaccesible. Datadog muestra una latencia elevada en la ruta de la aplicación. Ambas alertas son correctas. Ninguna indica si el problema se debe a un fallo de hardware, un cambio de enrutamiento, una desviación de la configuración o una dependencia ascendente fallida.
Sin una capa de automatización conectada, el ingeniero del NOC extrae manualmente los datos del dispositivo, comprueba las configuraciones en un sistema aparte, ejecuta un traceroute y comienza a construir una imagen que la cadena de herramientas ya debería haber ensamblado.
SolarWinds Datadog eventos integrados en NetBrain cambiar esa secuencia. La alerta activa una runbook Este proceso mapea la topología afectada, valida la configuración actual del dispositivo con respecto a la línea base de referencia y revela la causa raíz más probable antes de que un humano tenga que usar otra herramienta. El resultado es un análisis de incidencias rápido y consistente. Los mismos pasos de diagnóstico se ejecutan siempre, independientemente de quién esté de guardia.
Esa consistencia es importante para MTTR y es importante para la transferencia de conocimiento. Cuando el mismo runbook El proceso se ejecuta cada vez que se produce una infracción del umbral de SolarWinds, y el resultado del diagnóstico se convierte en un recurso de capacitación, no solo en una nota de cierre de incidencias.
ThousandEyes: El impacto en el usuario es visible, pero la capa de red no lo es.
El monitoreo sintético de ThousandEyes es eficaz para identificar cuándo se degrada la experiencia del usuario: una prueba fallida, una pérdida de paquetes elevada, una desviación de la ruta respecto a la configuración inicial. Sin embargo, no indica si la degradación se produce dentro de la red, en el borde de la red del proveedor de servicios de Internet o en la infraestructura del proveedor de la nube.
Esa ambigüedad tiene un coste real. Los equipos dedican tiempo a investigar la red empresarial cuando el problema reside en la red principal, o asumen que reside en la red principal cuando el problema es un cambio en el enrutamiento interno.
Cuando ThousandEyes está integrado con NetBrainUn fallo en una prueba sintética activa un diagnóstico de la capa de red sobre la ruta que sigue al recorrido del usuario afectado. NetBrain Mapea el segmento de red interna, valida el estado y la configuración del dispositivo y delimita el alcance para confirmar o descartar la causa raíz de un problema en la red empresarial. Los equipos responsables de cada dominio (red, nube y administración del ISP) obtienen una respuesta específica para su ámbito, en lugar de una ambigüedad compartida que retrasa la acción en los tres.
Conectar las herramientas de monitorización resuelve el problema de los disparadores, pero no el de la precisión.
Si runbook Consulta una CMDB con dos ventanas de cambios desactualizadas, verifica un registro IPAM que se actualizó manualmente por última vez y valida con un inventario que no refleja los cambios recientes en los racks; la automatización se ejecuta con datos obsoletos. Los flujos de trabajo automatizados que heredan conflictos de datos de sistemas desconectados no reducen el riesgo, sino que lo sistematizan.
NetBrain no reemplaza los sistemas que poseen sus datos autorizados. Infoblox posee DDI. Netbox posee el inventario. Su CMDB posee los registros de elementos de configuración. ¿Qué NetBrain Lo que hace es integrarse con todos ellos, de modo que cada flujo de trabajo activado se basa en un contexto preciso y sincronizado, en lugar de en lo que un ingeniero recuerde o pueda recuperar manualmente bajo presión.
Infoblox: Cuando los datos de IPAM no reflejan la realidad
Un ingeniero que soluciona un problema de conectividad consulta Infoblox y obtiene datos de subred y concesión DHCP del último ciclo de aprovisionamiento. La red activa ha sufrido una desviación. Se ha reasignado la dirección IP de un dispositivo. Se modificó un ámbito DHCP durante un cambio fuera del horario laboral. Ninguno de estos cambios se refleja en el registro consultado.
NetBrain Se integra con Infoblox NIOS. a través de API, extrayendo datos de DNS, DHCP y asignación de IP directamente a flujos de trabajo de descubrimiento y diagnóstico automatizados. Las vistas de una sola IP y los mapas de red se enriquecen con atributos Infoblox en tiempo real. Así que cuando un runbook Valida una asignación de IP o investiga una queja de conectividad; funciona a partir del estado DDI actual, no de una instantánea del último evento de aprovisionamiento.
Para los equipos que gestionan grandes entornos DHCP o arquitecturas DNS complejas, esto es fundamental durante la clasificación de incidentes. La pregunta "¿se trata de un conflicto de IP o de un problema de enrutamiento?" se responde mediante la automatización, no porque el técnico tenga que alternar entre dos pestañas del navegador.
Netbox: Cuando tu inventario no coincide con tu red
Netbox almacena metadatos estructurados de los dispositivos: posiciones en el rack, asignaciones de circuitos, convenciones de nomenclatura de interfaces, asignaciones de prefijos y atributos personalizados que los equipos han desarrollado con el tiempo. Estos datos son valiosos para la documentación, pero solo resultan útiles operativamente cuando se sincronizan con el comportamiento real de la red.
NetBrain Se integra con Netbox para mantener datos de topología y atributos de dispositivos precisos en flujos de trabajo automatizados. Compliance checkanálisis de impacto y gestión del cambio runbooks valida el estado actual con respecto a la arquitectura prevista almacenada en Netbox. La desviación de la configuración se muestra como una diferencia con respecto a la intención documentada, no solo como una diferencia bruta entre dos archivos de configuración.
Para ingenieros de automatización que construyen runbookEn el caso de dispositivos que abarcan distintos tipos de dispositivos y dominios de infraestructura, disponer del contexto de Netbox en el flujo de trabajo elimina una categoría de búsqueda manual que anteriormente requería cambiar el contexto fuera del entorno de automatización por completo.
CMDB: Cuando los registros de elementos de configuración siempre van con un cambio de retraso.
Los registros de la CMDB son, por diseño, fiables. Sin embargo, en la práctica, presentan retrasos. Los procesos de cambio requieren actualizaciones manuales, se acumulan excepciones y la brecha entre lo que indica la CMDB y lo que hace la red se amplía con el tiempo. Esta brecha se convierte en un problema cuando los flujos de trabajo automatizados dependen de los metadatos de la CMDB para tomar decisiones sobre el alcance, la propiedad o el enrutamiento de la aprobación de cambios.
NetBrain Recibe datos de CMDB para que cada flujo de trabajo activado refleje el estado correcto del dispositivo, el contexto de propiedad y la asignación de dependencias de servicio disponibles en el momento de la ejecución. Los resultados del análisis de causa raíz hacen referencia a registros de CI precisos. La documentación de cumplimiento refleja el estado verificado en lugar de la última actualización registrada.
La integración también admite patrones bidireccionales: como NetBrain Descubre y valida el estado de la red, y esos datos verificados pueden retroalimentar la CMDB para mejorar la precisión de los registros con el tiempo, reduciendo la desviación que hace que los datos de la CMDB no sean fiables en primer lugar.
Con las herramientas de monitorización configuradas como disparadores y las fuentes de datos sincronizadas para garantizar la precisión, el tercer paso consiste en asegurar que cada resultado de diagnóstico, cada acción de resolución y cada resultado de verificación lleguen al lugar correcto con un registro rastreable que lo respalde.
Aquí es donde las integraciones de ITSM cierran el círculo. No solo crean tickets, sino que también les añaden contexto. De esta forma, el registro de lo sucedido, por qué sucedió y qué se hizo queda completo sin necesidad de documentación manual.
ServiceNow: Cuando se abren tickets antes de ejecutar el diagnóstico
El flujo de trabajo estándar para la gestión de incidentes en la mayoría de las empresas es el siguiente: se genera una alerta, se abre un ticket, un técnico lo revisa y comienza la investigación. El diagnóstico se realiza después de crear el ticket, no antes de que se haya resuelto.
El Integración de ServiceNow con NetBrain invierte esa secuencia para los incidentes que califican. Cuando se crea un incidente de ServiceNow o se alcanza un umbral de alerta, NetBrainEl TAF de 's activa un diagnóstico runbook En relación con el ámbito afectado, se traza la ruta, se ejecuta la Evaluación Dorada y se valida el estado de la configuración según la intención. Toda la información resultante (rutas afectadas, hallazgos de configuración, acciones recomendadas) se registra en el ticket de ServiceNow antes de que el primer ingeniero lo abra.
El ingeniero que recibe ese ticket no parte de cero. Está revisando un diagnóstico estructurado que ya ha realizado los primeros 20 minutos de trabajo.
Para la gestión de cambios, el patrón funciona en ambas direcciones. Un cambio planificado en ServiceNow activa una verificación previa. runbook in NetBrain que valida el cambio propuesto contra network intent y el estado actual antes de que se abra la ventana de cambios. Después de la ejecución, una validación runbook Confirma el resultado y cierra el ciclo de verificación en el ticket.
Entre el 70 y el 80 por ciento de las interrupciones de red se deben a cambios de configuración. Una parte significativa de estas interrupciones se puede prevenir mediante la validación previa al cambio. La integración con ServiceNow permite que esta prevención se convierta en un flujo de trabajo repetible, en lugar de una simple lista de verificación manual.
Jira: Cuando la velocidad de emisión de tickets supera la capacidad de diagnóstico
Los equipos que utilizan Jira Service Management se enfrentan a la misma brecha de diagnóstico que los entornos de ServiceNow, a menudo con operaciones más reducidas. Los tickets de Jira se mueven por una cola sin contexto de red hasta que alguien los investiga manualmente. Y en entornos donde se repite el mismo tipo de incidente, esa investigación manual se ejecuta de forma idéntica cada vez sin generar nunca un artefacto reutilizable.
Cuando se crea un ticket en Jira Service Management Cloud, NetBrain Mapea automáticamente la red afectada y ejecuta el diagnóstico correspondiente. runbooky registra los resultados (análisis de ruta, estado del dispositivo, hallazgos de configuración) en el ticket antes de que el primer responsable lo abra. No se requiere activación manual. El ingeniero que revisa el incidente obtiene el contexto de red en tiempo real adjunto al registro, no un ticket en blanco para investigar desde cero.
También Integrado con Jira Data Center, la creación de un ticket que cumpla los requisitos o un cambio de estado envía un evento a NetBrainEste proceso inicia el flujo de trabajo de diagnóstico configurado y devuelve los resultados al ticket original a través del mismo canal API. Este patrón ofrece a los equipos locales e híbridos la misma capacidad de diagnóstico automatizado que las implementaciones en la nube, con el control adicional sobre la residencia de datos y la configuración de los activadores que requieren los entornos autogestionados.
Para los equipos que se enfrentan a incidentes repetidos, como el agotamiento de DHCP, la inestabilidad del árbol de expansión, las fluctuaciones recurrentes de BGP, el runbook El resultado se convierte en la base para una solución permanente en lugar de un cierre temporal.
Integraciones personalizadas: cuando su pila tiene aristas que no se ajustan a un patrón estándar.
No todos los entornos se ajustan a cinco integraciones con nombre. Las herramientas desarrolladas internamente, las plataformas especializadas y los sistemas heredados generan eventos relevantes para la operación que quedan excluidos de los flujos de trabajo de automatización porque no existe un conector predefinido para ellos.
NetBrainLa API REST y el marco de webhooks de admiten patrones de automatización ascendente, descendente y este-oeste. Los sistemas externos pueden activar NetBrain Los flujos de trabajo permiten consultar el estado de la red mediante programación o recibir resultados de diagnóstico sin necesidad de crear una integración personalizada desde cero en ninguno de los dos sistemas. Las plataformas AIOps, las herramientas de garantía de red y los sistemas de orquestación de seguridad pueden participar en la misma cadena de automatización a la que se conectan ServiceNow y Splunk.
La arquitectura se extiende a toda la pila tecnológica, no solo a las herramientas que aparecen en la lista de herramientas compatibles del proveedor.
Los tres pasos anteriores —conectar, unificar, orquestar— constituyen la base operativa que hace posible que todo sea posible.
La automatización eficaz de la red requiere más que runbookRequiere que su plataforma mantenga una visión continua y en tiempo real del estado de la red, no una instantánea del último ciclo de descubrimiento. Requiere que los flujos de trabajo automatizados razonen en un contexto de múltiples herramientas (datos de ruta, estado de configuración, registros de IPAM, metadatos de CMDB), en lugar de actuar sobre una única fuente de datos. Requiere que los disparadores se inicien a partir de eventos en vivo y umbrales de políticas, no solo de indicaciones humanas. Y requiere que cada acción ejecutada produzca un registro verificable, registrado y reversible.
Ninguna de estas capacidades se puede lograr con herramientas aisladas. Splunk por sí solo no puede analizar la topología. ServiceNow por sí solo no puede validar la intención de la configuración. Infoblox por sí solo no puede activar un diagnóstico. Cada sistema opera dentro de su propio ámbito. La capa de integración es la que transforma el ámbito individual en una acción coordinada.
Gartner proyecta que para 2030El 50 % de las organizaciones gestionarán sus operaciones de red con una automatización significativa y una mínima intervención humana en los flujos de trabajo rutinarios. Este cambio no se produce porque los equipos adquieran mejores herramientas de monitorización, sino porque integran las herramientas que ya poseen en una arquitectura capaz de actuar en función de la información que estas detectan. De forma consistente, a gran escala y con la documentación integrada.
Esta guía cubrió los patrones de integración más comunes en monitoreo, unificación de datos y orquestación de ITSM. NetBrain Página de integraciones Abarca todo el ecosistema, incluidos los patrones de activación específicos de cada herramienta, los marcos de API compatibles y los detalles de la arquitectura para cada plataforma.
Si su entorno utiliza Splunk, ServiceNow, Infoblox, Netbox, Datadog, ThousandEyes o una combinación de estos, encontrará los detalles de integración para cada uno. También encontrará orientación sobre configuraciones personalizadas de API REST y webhooks para las partes de su infraestructura que no se ajustan a un patrón predefinido.
La brecha operativa descrita en esta publicación se puede solucionar. Es probable que las herramientas para solucionarla ya estén disponibles en su entorno.
NetBrainEl gran anuncio de fue tan importante que acaparó toda la atención en Sphere. Pero esto era Cisco Live, así que hablemos también de lo que Cisco tenía que decir. En su discurso principal, Jeetu...
La automatización del cumplimiento de NERC CIP es el uso continuo de la automatización de la red para satisfacer los requisitos de las normas de protección de infraestructura crítica de NERC y la norma de FERC de 2023 sobre la monitorización de la seguridad de la red interna...
Una interrupción del servicio informático en 2024 le costó a una operadora estadounidense más de 500 millones de dólares. Dos años antes, un colapso operativo en otra operadora costó más de 750 millones de dólares. La Oficina de Responsabilidad Gubernamental de Estados Unidos...
Utilizamos cookies para personalizar el contenido y comprender su uso del sitio web con el fin de mejorar la experiencia del usuario. Al utilizar nuestro sitio web, acepta todas las cookies de acuerdo con nuestra política de privacidad.