Una descripción general rápida de los aspectos más destacados en un minuto
La escala comercial y los grupos de usuarios de Bilibili continúan expandiéndose, y sus requisitos de estabilidad y disponibilidad del servicio también están aumentando. Esto requiere que el sistema de monitoreo y alarma de la estación B sea capaz de detectar y localizar problemas de manera oportuna y precisa para resolverlos lo antes posible y mantener la experiencia del usuario.
Este artículo es un registro detallado de una importante iteración y optimización del sistema de monitoreo de alarmas de la estación B. El artículo detalla las ideas de diseño y las iteraciones de optimización de la plataforma de alarma en la Estación B, así como los problemas encontrados y las soluciones durante el proceso de implementación. Especialmente para mejorar la precisión del posicionamiento de la alarma y la eficiencia del posicionamiento, el artículo proporciona nuevas soluciones de diseño y métodos prácticos.
Sobre el Autor
Ingeniero senior de desarrollo de Bilibili——Wang Chengtian
Miembro del equipo de expertos de la comunidad de estabilidad TakinTalks e ingeniero de desarrollo senior en Bilibili. Se unió a Bilibili en 2020 y ha sido responsable de la plataforma de eventos, el seguimiento de enlaces, AIOps y la evolución de la tecnología de dirección de la plataforma de alarmas y la iteración de la plataforma. Se completó la implementación de una plataforma de alarmas de nueva generación, se logró la detección de extremo a extremo de anomalías dentro del percentil 99 en un minuto y se logró un gran avance en la gestión de alarmas per cápita de más de 1000 por persona por semana a más de 70 por persona.
Recordatorio: este artículo tiene aproximadamente 6000 palabras y su lectura debería tomar 8 minutos.
Responda "Comunicación" en el fondo de TakinTalks Stability Community para ingresar al grupo de comunicación de lectores, responda "1130" para obtener material didáctico;
fondo
En el negocio diversificado de Bilibili, la plataforma de alarma juega un papel vital. Ya sea reproducción de video, envío de bombardeos, comentarios de usuarios, administración de salas de transmisión en vivo o revisión de contenido en segundo plano, estadísticas de datos, etc., todos son inseparables del funcionamiento estable del sistema. La plataforma de alarma puede monitorear el estado operativo de estos sistemas comerciales en tiempo real. Una vez que ocurre una anomalía, se emitirá una alarma a tiempo, lo que permitirá al personal de operación y mantenimiento localizar rápidamente el problema y manejarlo de manera oportuna.
Sin embargo, mantener el funcionamiento estable de estos negocios no es tarea fácil. Desde la perspectiva de las tres etapas antes, durante y después de que ocurra la alarma, es decir, el extremo de producción, el extremo de transmisión y el extremo del consumidor, el diseño de la plataforma de alarma de la estación B enfrenta desafíos y complejidad considerables.
Teniendo en cuenta estas necesidades y complejidad del negocio, nos embarcamos en una actualización integral de la plataforma de alarmas de nueva generación de la estación B. Como resultado, logramos una reducción del 90 % en las alarmas por persona y un avance del 87,9 % de precisión en el análisis de la causa raíz. . En este artículo, describiré el concepto de diseño de la plataforma de alarmas de nueva generación y me centraré en compartir las estrategias de implementación de la plataforma en la reducción del ruido de las alarmas y el análisis inteligente de las alarmas.
1. ¿Qué diseños clave se han realizado para la plataforma de alarma?
1.1 Demandas comerciales principales
Durante el proceso de diseño e iteración de la plataforma de alarmas, continuamos recibiendo varios requisitos comerciales. En términos generales, el núcleo de estos requisitos se centra en "tomar la calidad como centro, descubrir y manejar excepciones de manera oportuna y garantizar la estabilidad del negocio". En concreto, los escenarios de demanda se pueden dividir en escenarios de riesgo y escenarios de fallo. En escenarios de riesgo, los problemas potenciales deben detectarse con anticipación y abordarse de manera efectiva; mientras que en escenarios de falla, los problemas en línea deben descubrirse rápidamente y responderse de manera oportuna para lograr una recuperación rápida.
En el proceso de satisfacer estas necesidades comerciales, hemos refinado tres demandas y objetivos principales:
Validez: esperamos que todas las alarmas recibidas sean válidas, es decir, cada vez que se recibe una alarma, de hecho hay una excepción y esta alarma es significativa para el destinatario actual.
Oportunidad: Para las excepciones de alta prioridad, esperamos llegar a ellas lo antes posible y ser percibidos por los usuarios para que puedan tomar medidas oportunas para manejarlas.
Cobertura y seguimiento: Esperamos lograr una cobertura y seguimiento integral de las alertas. Desde la perspectiva del usuario, esperan que todos los escenarios comerciales o de aplicaciones de los que son responsables puedan estar cubiertos por alarmas y, al mismo tiempo, también esperan comprender la cobertura de alarmas en diferentes escenarios. Cuando ocurre una excepción en una regla, los usuarios necesitan una forma conveniente de manejar y realizar un seguimiento rápido para resolver el problema.
1.2 Diseño detallado de la plataforma de alarma.
1.2.1 Modelo de circuito cerrado
En el diseño detallado de la plataforma de alarma, construimos un modelo de circuito cerrado basado en los objetivos y requisitos comerciales antes mencionados. Este modelo está diseñado para asegurar la participación activa de todas las partes relevantes para impulsar la mejora continua de los objetivos. En particular, la definición y la gestión de alarmas son dos vínculos clave en el modelo, porque determinan la eficacia de la reducción y recuperación del ruido de las alarmas.
A continuación, se presentará en detalle el diseño de las funciones laterales de canal, detección y definición de alarma de la estación B. La atención se centra en el manejo de alarmas, el análisis de la causa raíz y el contenido práctico sobre la gestión de alarmas.
1.2.2 Acceso a alarmas
En el proceso de acceso a alarmas se distinguen principalmente tres escenarios, cuyo diseño puede cubrir la mayoría de las necesidades empresariales de acceso a alarmas.
1) Escenarios orientados a plataformas
Proporcionamos capacidades de interfaz abierta para reglas de alarma y plantillas para escenarios de alarma cubiertos por la plataforma, y admitimos la integración de reglas de múltiples inquilinos. Se pueden configurar diferentes inquilinos según plantillas predefinidas y la definición y cobertura de alarmas se puede completar rápidamente al solicitar servicios o registrar recursos. Todo el proceso es de bajo costo y muy conveniente.
2) Para escenarios personalizados
Abrimos directamente la definición de reglas de alarma para el negocio, incluyendo la configuración de condiciones de activación, expresiones y estrategias de notificación de las reglas.
3) Para eventos de terceros
Tenemos capacidades abiertas de integración de eventos. Los usuarios pueden completar el acceso registrando eventos y enviarlos a la plataforma de alarma a través de la activación activa. La plataforma de alarma completa el procesamiento de circuito cerrado posterior.
1.2.3 Cálculo de alarma
Diseñamos un motor de cálculo de alarmas distribuidas para implementar la programación multinivel. Con base en las reglas que son completamente efectivas en línea, se realiza una programación global para programar escenarios de alarma y zonas de disponibilidad para diferentes zonas de disponibilidad y clústeres informáticos. En el mismo clúster informático, realice la programación local y programe tareas en diferentes nodos informáticos para lograr el equilibrio de carga. El nodo informático detectará periódicamente los datos para determinar si se activa la alarma y los entregará al canal de alarma después de activarse.
1.2.4 Canal de alarma
Se dedica principalmente a la reducción, representación y distribución de ruido para lograr una entrega precisa y un acceso rápido. Para eventos de alarma generados en el lado del motor, los mensajes de alarma se generarán en el canal y luego pasarán por el módulo de reducción de ruido para completar la interceptación de la ventana de notificación, la interceptación de la frecuencia de notificación, la interceptación de alarma, la interceptación silenciosa, la interceptación de supresión, la agregación de alarmas, etc. en secuencia. A continuación, a través del módulo de distribución y representación de alarmas, se completa el destinatario de la representación, el canal de notificación de la representación y la plantilla de notificación de la representación y, finalmente, se llega al usuario y se actualiza el estado de entrega de la alarma.
2. ¿Cuáles son las experiencias prácticas de gestión de alarmas?
A continuación explicaré principalmente cómo la estación B implementa estrategias de gestión de alarmas, reduce el ruido de las alarmas y mejora la eficacia de las alarmas en el proceso práctico de gestión de alarmas.
2.1 Antecedentes de la gestión de alarmas
En el último período, el problema de la inundación de notificaciones de alarma en la Estación B se ha convertido en un problema durante muchos años y en un importante problema para el equipo técnico y la plataforma. Por un lado, con la aparición de problemas de estabilidad y el acceso a nuevas plataformas, las reglas y configuraciones de alarmas siguen aumentando; por otro lado, faltan mecanismos eficaces de gestión de alarmas y análisis operativo. Esto ha dado lugar a un número cada vez mayor de alarmas y muchos usuarios no toman la iniciativa de gestionar las alarmas, sino que optan por configurar No molestar. Por último, los riesgos y anomalías reales suelen quedar ocultos tras numerosas alarmas y no pueden percibirse inmediatamente.
Para resumirlo en una frase: "Demasiadas alarmas equivalen a ninguna alarma".
2.2 Análisis de problemas
Creemos que esto se debe principalmente a las siguientes cuatro razones:
Definiciones de alarma irrazonables: muchas reglas carecen de un mantenimiento efectivo. Después de que se activan una gran cantidad de reglas, no significa que haya ocurrido una excepción y la empresa no la manejará. Además, la granularidad de algunas alarmas es demasiado fina, lo que provoca que se genere una gran cantidad de alarmas después de que se activa la misma excepción, lo que amplifica el impacto de toda la notificación.
Ampliación del número de personas notificadas: debido a cambios en la estructura organizacional histórica o problemas temporales de resolución de problemas, los permisos de posicionamiento se acoplan, lo que resulta en una falta de gobernanza a largo plazo en el árbol de servicios, lo que resulta en una amplificación sustancial del número de alarmas. notificaciones, que a menudo se envían a personal no relacionado.
Falta de herramientas de análisis y gestión: aunque todo el mundo sabe que hay demasiadas alarmas y que es necesario gestionarlas, no tienen ni idea ni capacidades de plataforma adecuadas que les ayuden a analizar las principales partes concentradas de las alarmas para llevar a cabo una gestión específica.
Falta de mecanismos operativos efectivos: No hay suficiente motivación para gestionar las alarmas, y también faltan mecanismos efectivos y limitaciones normativas. En la historia, después de cierta gobernancia de corto plazo, la alarma repuntó y el efecto de gobernancia dejó de existir.
2.3 Tres etapas de gestión de alarmas
Después de analizar los motivos de la proliferación de alarmas, iniciamos la gestión de alarmas, este proceso se divide principalmente en tres etapas.
Fase uno: establecimiento de objetivos
Después de muchas rondas de reuniones y debates, determinamos el indicador del número de alertas y redujimos el número original de alertas de más de 1000 por semana a 80 por semana. Este objetivo parecía casi imposible en las etapas iniciales. Sin embargo, creemos que estas 80 alarmas son un rango razonable al que el personal empresarial puede responder y manejar una por una. Por lo tanto, insistimos en implementar este objetivo y hacer todo lo posible para lograrlo.
Fase 2: Análisis de datos
Integramos datos de alarmas en el almacén de datos, proporcionando una vista de análisis multidimensional y brindando soporte de datos para la gestión de alarmas. El factor de impacto se determina mediante una fórmula de cálculo, que se basa en el número de notificaciones de alarma, es decir: número de notificaciones de alarma = número de alarmasEl número de personas que activan la notificación cada vez Coeficiente de reducción de ruido. Esta fórmula nos ayuda a aclarar la dirección y el enfoque de la gobernanza.
La tercera etapa: acciones de gobernanza
En esta etapa comenzamos a ejecutar una serie de acciones de gobernanza.
En primer lugar, se optimizaron los elementos de alarma, se evaluó la racionalidad de los elementos de alarma predeterminados con SRE y los colegas de la plataforma, y se cerraron los elementos de alarma no válidos. Para algunos elementos de alarma irrazonables, evaluamos y optimizamos condiciones como sus expresiones y umbrales predeterminados para reducir el ruido de las alarmas y mejorar la efectividad de las alarmas.
En segundo lugar, para solucionar el problema de aumentar el número de notificaciones, se ha optimizado la configuración de los destinatarios de las alarmas. Hemos estado profundamente involucrados y promovidos el desarrollo del árbol de servicios y la calibración del rol de la persona a cargo, y lanzamos capacidades como en servicio y actualización para limitar el alcance de las notificaciones de alarma y reducir efectivamente el ruido amplificado por el número. de personas notificadas.
Finalmente, la estrategia de reducción del ruido de alarma del canal se enriquece, admitiendo capacidades de interceptación ajustadas de grupos de reglas y capacidades de agregación y resumen de alarmas multidimensionales, reduciendo así el ruido de alarma de manera más eficiente.
2.4 Resumen de experiencia en el proceso de gestión de alarmas
Después de realizar una serie de acciones de gobernanza de alarmas, resumimos y pensamos en el proceso de gobernanza. Comparta principalmente los siguientes tres aspectos:
1) La recuperación de excepciones es el resultado final
A lo largo de todo el proceso de gobernanza, las alarmas de ruido no válidas se procesan principalmente de forma intensiva, pero no se deben ignorar las alarmas reales y válidas. En la gobernanza, siempre nos adherimos al principio de que no se puede sacrificar la recuperación de excepciones. Por lo tanto, centramos nuestra atención en reglas irrazonables como la activación continua, la activación repetida y la amplificación anormal, así como en las reglas de nivel superior, y llevamos a cabo una gobernanza especial sobre estas cuestiones.
2) El avance operativo es esencial
De hecho, el proceso de gobernanza es un proceso de avance operativo. En este proceso se crearon decenas de grupos y se desarrollaron innumerables documentos de gobernanza, promoción y seguimiento para asegurar la implementación de todo el trabajo intensivo y obligatorio de gestión de alarmas. Al mismo tiempo, también trabajamos estrechamente con varias plataformas de escenarios y SRE para promover conjuntamente la gestión de alarmas.
3) Las capas y la gradación se centran en la dirección.
Aprendimos de las ideas del profesor Mao Jian, haciendo hincapié en las capas y calificaciones, y centrándonos en puntos clave, especialmente en las alarmas centrales que garantizan la disponibilidad del negocio. Para las alarmas de tipo evento, se recomienda registrarlas y consultarlas para evitar ahogar otras notificaciones de alarma importantes. Para algunas alarmas dependientes que no son adecuadas para la notificación directa al lado comercial, se recomienda presentarlas mediante correlación, lo que puede reducir efectivamente el ruido de las alarmas.
2.5 Efecto de gestión de alarmas
En los últimos seis meses, los datos de alarmas han mejorado significativamente gracias a la gestión de alarmas basada en push:
La mediana del número de alarmas disminuyó de 1.000 veces por semana a 74 veces por semana, una reducción del 7,4% del número original;
El número total de notificaciones de alarma se ha reducido de más de 300.000 antes del tratamiento a más de 22.000, lo que se reduce al 7% del número original;
El número de notificaciones de alarma per cápita disminuyó de 1600+ a 140, lo que se redujo al 8,8% del número original;
2.6 Establecer un mecanismo de gobernanza a largo plazo
Para garantizar que los resultados logrados por la gestión de alarmas sean sostenibles y estables, hemos creado un mecanismo de gobernanza a largo plazo, que incluye específicamente los siguientes tres aspectos:
1) Herramientas convenientes de análisis de gobernanza
Contiene un panel de análisis de gestión de alarmas, que está integrado en la plataforma de alarmas. Este mercado respalda el análisis de la distribución y las tendencias de las alarmas desde múltiples perspectivas, como la empresarial, la individual y la empresa, y a través de múltiples dimensiones. Además, también utilizamos algunas herramientas de gobernanza para proporcionar las capacidades necesarias para una gobernanza rápida.
2) Suscripción al informe de datos
Llegamos a un consenso con cada plataforma componente de SRE, establecimos objetivos comunes y generamos suscripciones para varios informes de datos. Continuar dando seguimiento a estos reportes para evitar que las alarmas empeoren y continuar gestionando las alarmas.
3) control de acceso
Para nuevas reglas de acceso y escenarios de plataforma, se ha agregado cierta verificación manual del acceso a los datos de alarma, así como verificación y monitoreo de ruido en el lado de la plataforma. Para algunas reglas irrazonables, recomendaremos que la parte de acceso correspondiente las optimice para mantener los resultados de la gestión de alarmas.
3. ¿Cómo se diseña y aplica el análisis de la causa raíz de las alarmas?
Combinando las tecnologías de vanguardia ampliamente utilizadas en la industria actual, como la detección de anomalías, la reducción inteligente de ruido, las estrategias de fusión inteligentes y el análisis de causa raíz, me centraré en compartir la práctica y la experiencia práctica de la estación B en el análisis de causa raíz.
3.1 Antecedentes del análisis de causa raíz
A medida que el sistema SLO se vuelve cada vez más perfecto, más empresas se conectan al sistema SLO. Esto nos permite tener definiciones claras de excepciones y objetos desencadenantes, lo que nos permite realizar análisis de causa raíz con mayor precisión.
Además, la Estación B se ha fijado el objetivo “1-5-10”. En la actualidad, al optimizar la recopilación y los canales de cálculo de alarmas, se ha logrado el descubrimiento de problemas de extremo a extremo del percentil 99 en un minuto. Sin embargo, todavía existen algunos obstáculos para el posicionamiento de 5 minutos. El proceso de posicionamiento depende demasiado de la experiencia manual y existe un cierto grado de incertidumbre. La experiencia de los expertos artificiales varía de persona a persona y se ve afectada por la escena, lo que resulta en una eficiencia de posicionamiento inconsistente. Además, debido a la construcción e interacción de las capacidades de la plataforma, así como a los retrasos en la respuesta en algunas situaciones extremas, como fallas temprano en la mañana o viajes de negocios, la eficiencia del posicionamiento se verá afectada.
Finalmente, la acumulación de necesidades de los usuarios también está aumentando. Con el crecimiento de los negocios y la infraestructura, la gente presta cada vez más atención a la eficiencia del posicionamiento de alarmas y ha acumulado mucha experiencia en la localización de alarmas. Por lo tanto, la necesidad de un análisis de la causa raíz es cada vez más urgente y, al mismo tiempo, las condiciones para implementar el análisis de la causa raíz están madurando gradualmente.
3.2 Análisis y diseño de causa raíz
3.2.1 Diseño de análisis de causa raíz Versión 1.0
Primero, adoptamos un diseño basado en alarmas SLO para diseñar las capacidades de posicionamiento de los indicadores dorados bajo la arquitectura de microservicio. Este es el diseño de análisis de causa raíz de la versión 1.0. Todo el plan de diseño consta principalmente de tres etapas.
En la primera etapa, monitoreamos los activadores de alarmas de SLO, correlacionamos el alcance del error y los datos, y luego analizamos los indicadores de registro en función de estos datos para detectar las dimensiones anormales. Por ejemplo, los errores pueden concentrarse en una determinada instancia de un clúster específico o en una determinada interfaz de una determinada solicitud ascendente.
En la segunda etapa, correlacionamos las llamadas a enlaces en el lado de la aplicación en función de estas dimensiones de error y encontramos los enlaces anormales durante el período anormal. A través del análisis de agregación, se pueden distinguir escenarios de error y que consumen mucho tiempo, y se pueden localizar nodos anormales bajo enlaces anormales mediante análisis de ruta crítica, poda y profundización.
En la etapa final, los nodos anormales ubicados se asignan al gráfico de conocimiento y se relacionan con bases de datos, cachés, colas de mensajes, contenedores, máquinas, conmutadores, gabinetes, salas de computadoras y otra información relevantes a través del gráfico de datos. Luego, combinado con información como excepciones, alarmas, cambios, etc., se hacen recomendaciones de puntuación a través del modelo de análisis de correlación y finalmente se recomienda la posible clasificación de causa raíz principal.
Aunque la precisión del diseño de análisis de causa raíz de esta versión 1.0 es aceptable en algunos escenarios, todavía tiene algunos cuellos de botella.
3.2.2 Diseño de análisis de causa raíz Versión 2.0
Al diseñar la versión 2.0 del análisis de causa raíz, realizamos una encuesta exhaustiva y obtuvimos una comprensión profunda del proceso de localización de problemas por parte de SRE senior y colegas comerciales de la industria.
En resumen, este proceso es principalmente: después de que se activa la alarma, se relaciona con el evento anormal específico según la experiencia de los expertos; luego, basándose en estas experiencias, analiza las posibles razones de la anormalidad y descubre los indicadores relevantes. y registros de estos motivos. Espere los datos de observación; finalmente, al observar estos datos, determine la causa raíz de la anomalía.
En el proceso de diseño de la versión 2.0, nos esforzamos por universalizar este proceso y construir un gráfico de conocimiento de anomalías para precipitar la experiencia de los expertos. Al mismo tiempo, también abre las funciones de integración del análisis de causa raíz y catálogo de conocimientos, proporcionando capacidades generales de análisis de causa raíz.
La implementación del análisis de causa raíz gira principalmente en torno a la definición de conocimiento. El conocimiento aquí se basa principalmente en la definición de nodos anormales. Cada excepción se definirá en un nodo de entidad específico, como una instancia de clúster de una aplicación o una base de datos. Cada excepción estará asociada con nodos de datos específicos, como registros, indicadores, alarmas, etc. A través de estos datos, podemos detectar y juzgar la ocurrencia de excepciones. Al mismo tiempo, también existen relaciones conductivas entre anormalidades. ¿Qué anormalidades pueden causar una anormalidad? ¿Cuáles son los vínculos conductivos y las correlaciones entre estas anormalidades? Esta es toda la estructura del conocimiento que definimos en ingeniería del conocimiento.
Este método de análisis de causa raíz basado en el gráfico de conocimiento resuelve bien los problemas encontrados en la versión 1.0. Esto nos permite obtener una comprensión más profunda de los motivos de las excepciones y localizar con mayor precisión la causa raíz del problema. Al acumular sistemáticamente la experiencia de los expertos, no sólo mejora la eficiencia de la localización de problemas, sino que también permite heredar y acumular conocimientos.
3.2.3 Compatibilidad con el algoritmo AIOps
El desarrollo de capacidades para el análisis de la causa raíz es inseparable del soporte de los algoritmos AIOps. En la actualidad, hemos creado un sistema de algoritmos integral y hemos diseñado múltiples escenarios, como indicadores, registros, eventos y enlaces. Al mismo tiempo, también admite capacidades de algoritmo para múltiples escenarios, como predicción de series temporales, detección de anomalías, clasificación de indicadores, agrupación de registros, desglose multidimensional, agrupación de eventos y análisis de enlaces basados en diferentes tipos de datos.
3.2.4 Actualización del modelo de análisis de correlación
En el proceso de análisis de correlación, construimos el gráfico de anomalías mediante la construcción de características, la carga del modelo, la predicción y la puntuación basadas en el razonamiento del modelo, y finalmente recomendamos la causa raíz y la ruta de transmisión de la anomalía. El diseño de funciones incluye: funciones dependientes del tiempo, funciones de relación/distancia de gráficos, funciones causales, funciones de similitud de rutas y funciones de categoría de eventos.
En términos de construcción del modelo, en la etapa inicial, se basó principalmente en el método de arranque en frío y predefinió algunos coeficientes de propagación entre anomalías. A medida que aumentan los datos de anotación de la muestra, comienza el entrenamiento del modelo y se realizan razonamientos y recomendaciones basadas en el modelo. Además, también admitimos el modelo GBDT para mejorar aún más las capacidades de análisis de correlación.
3.3 Dificultades y puntos clave
En el proceso de análisis de la causa raíz, enfrentamos algunas dificultades y puntos clave. La principal dificultad radica en cómo evaluar eficazmente las causas fundamentales de las recomendaciones y cómo obtener datos de evaluación y precisión del usuario. Esto es fundamental para evaluar diferentes versiones, así como la precisión y eficacia del análisis de causa raíz, y para ayudar a que el modelo se repita. Para resolver este problema, llevamos a cabo las siguientes cuatro partes de trabajo:
A lo largo del proceso, la atención se centró en reunir y aprovechar la experiencia de los expertos. Tendremos una comunicación profunda con diferentes estudiantes de negocios y SRE, clasificaremos conocimientos anormales relevantes y experiencia experta, y completaremos la definición de esta parte del conocimiento.
En cuanto a los componentes, continuaremos mejorando las capacidades de definición y construcción de esta parte del conocimiento con estudiantes relevantes. Para algunos escenarios especiales, también proporcionaremos soluciones de integración basadas en la experiencia de expertos externos y brindaremos capacidades de integración e interfaces para el análisis de causa raíz, de modo que las causas raíz externas también se puedan completar a través de capacidades de análisis para lograr la recomendación, visualización y evaluación. de alarmas manuales.
3.4 Análisis de casos
3.4.1 Un aumento repentino del tráfico ascendente provoca una limitación del servicio y una reducción de la disponibilidad.
En este caso, puede asociar excepciones de SLO a servicios específicos basados en alarmas y profundizar para obtener interfaces de excepción y errores específicos. Al mismo tiempo, mediante un análisis de correlación anormal, se puede detectar un aumento repentino en el tráfico ascendente y es posible identificar qué entrada tiene un aumento repentino de tráfico. Con esta información, la parte empresarial puede realizar algunas configuraciones limitantes actuales en los servicios ascendentes y repararlas.
3.4.2 Los cambios posteriores provocan anomalías en el servicio que afectan la disponibilidad de la interfaz de la puerta de enlace
Puede asociarse a enlaces específicos a través del análisis de causa raíz y asociarse a anomalías y cambios específicos posteriores. En última instancia, se puede recomendar que los cambios en el servicio de IA sean la causa principal de afectar la interfaz de la puerta de enlace. Los estudiantes de negocios pueden encontrar rápidamente el cambiador correspondiente y luego realizar operaciones de limitación de pérdidas, como resolución de problemas y reversión.
3.4.3 La excepción de solicitud de Redis descendente afecta la interfaz de servicio
Se puede vincular a servicios específicos mediante análisis internos y excepciones, y se puede construir la ruta de transmisión anormal. Al mismo tiempo, se pueden recomendar registros y tiempos de solicitud anormales específicos. Además, el lado comercial también puede realizar un posicionamiento más profundo con sus compañeros de clase sobre componentes relacionados.
3.5 Evaluación de efectos
Se implementó el análisis de causa raíz y se obtuvieron algunos resultados——
Número de análisis de causa raíz: 20652/día
Precisión: 87,9%
Tasa de recuperación: 77,5%
El análisis toma el percentil 95: 10s
Tiempo promedio de análisis: dentro de 4 segundos (esto significa que después de que se emite una alarma, solo se necesitan un promedio de 4 segundos para recomendar la causa raíz, y el personal comercial puede ver directamente la causa raíz anormal correspondiente al abrir la tarjeta de alarma).
4. Resumen y perspectivas
Al diseñar una plataforma de alarma, es necesario considerar una variedad de necesidades comerciales y diferentes escenarios de aplicación. Comprenda la esencia de estos requisitos y luego cree las capacidades de la plataforma y los modelos funcionales clave basados en esta esencia, y diseñe una lógica de circuito cerrado para diseñar una plataforma de alarma que se acerque más a las necesidades comerciales. En segundo lugar, el proceso de gestión de alarmas es fundamental. Independientemente de la cantidad de alarmas, solo a través de un mecanismo completo de gestión de alarmas se puede cerrar todo el sistema para optimizar la definición de reglas, mejorar continuamente la efectividad de las alarmas y maximizar el valor de las alarmas. Finalmente, la combinación de alarma e inteligencia artificial es la tendencia de desarrollo futura. A través de una integración profunda de algunas capacidades, se puede mejorar la precisión de la detección de fallas, se puede reducir el tiempo de posicionamiento y recuperación de la pérdida de parada y se puede garantizar la gestión de calidad y la estabilidad del sistema. (Finaliza el texto completo)
Preguntas y respuestas:
1. ¿Esta gestión de alarmas se basa principalmente en la detección manual y la reducción de reglas?
2. ¿Puede darnos un ejemplo de correlación de alarmas y reducción de ruido en el ámbito empresarial? ¿Está relacionado en el lado de monitoreo o en el lado de alarma? ¿Se pueden asociar las alarmas empresariales a las alarmas básicas?
3. ¿Existe algún escenario de análisis automático posterior a la alarma?
4. ¿Cómo gestionar el estado de envío y el efecto del seguimiento de las notificaciones de alarma? ¿Cómo lidiar con fallas o excepciones de notificación?
5. En términos de fusión de alarmas, ¿cómo no ahogar las alarmas de alta calidad? Al mismo tiempo, ¿garantizar la inspección de calidad de las alarmas de baja calidad?
6. ¿Cómo optimizar la eficiencia y precisión del análisis de causa raíz para respaldar el análisis en tiempo real y el procesamiento por lotes? ¿Cómo gestionar y almacenar grandes cantidades de datos e información de registro durante el análisis de la causa raíz? ¿Qué mejores prácticas y experiencias puedes compartir?
Para obtener las respuestas a las preguntas anteriores, haga clic en "Lea el texto completo" para ver la respuesta completa.
Declaración: Este artículo fue escrito originalmente por la cuenta pública "TakinTalks Stability Community" y expertos de la comunidad. Si necesita reimprimir, responda "Reimprimir" en segundo plano para obtener autorización.
Tang Xiaoou, fundador de SenseTime, falleció a la edad de 55 años En 2023, PHP se estancó Wi-Fi 7 estará completamente disponible a principios de 2024 debutará, 5 veces más rápido que Wi-Fi 6 El sistema Hongmeng está a punto de independizarse y muchas universidades han establecido “clases de Hongmeng” Zhihui La nueva empresa de Jun se refinancia, la cantidad supera los 600 millones de yuanes y la valoración previa al dinero es de 3.500 millones de yuanes La versión para PC de Quark Browser comienza las pruebas internas Asistente de código AI es popular y las clasificaciones de lenguajes de programación son todas No hay nada que puedas hacer El módem 5G y la tecnología de radiofrecuencia del Mate 60 Pro están muy por delante MariaDB divide SkySQL y se establece como empresa independiente Xiaomi responde a la declaración de plagio de Yu Chengdong sobre el “pivote de quilla” de Huawei¡Este artículo es publicado por la plataforma de publicaciones de blogs OpenWrite!