Un resumen de 10.000 palabras sobre la construcción de estabilidad de Serverless PaaS basado en Kubernetes

Autor: Xu Chengming (Jingxiao)

En la economía digital actual, la computación en la nube se ha integrado en la vida diaria de las personas como infraestructura. La estabilidad es un requisito básico para los productos en la nube y el resultado técnico para el personal de I+D. No se trata solo de los números de SLA de varios nueves prometidos en el documento. está estrechamente relacionado con los intereses vitales de los clientes e incluso con su riqueza y su vida, y la estabilidad está por encima de todo lo demás. Este artículo se centrará en la implementación real más que en la metodología y explicará la experiencia y el pensamiento en el proceso de construcción real de la estabilidad del lado comercial SAE de los productos en la nube.

SAE (Serverless Application Engine), como la primera plataforma PaaS sin servidor orientada a aplicaciones de la industria, está completamente administrada y no requiere operaciones, y realiza la sin servidor de aplicaciones web, aplicaciones de microservicios y tareas programadas. Una de sus principales ventajas es que los usuarios pueden implementar directamente sus aplicaciones/tareas en SAE con una carga mental baja y sin costo de modificación. Los usuarios solo necesitan centrarse en el desarrollo de la lógica empresarial central, mientras que SAE completa la gestión del ciclo de vida de la aplicación, la gestión de microservicios, el registro, la supervisión y otras funciones, ya sea el lanzamiento de paquetes de código, la integración de cadenas de llamadas de supervisión o el desarrollo. de marcos de programación distribuida La migración se puede utilizar sin cambiar ninguna lógica empresarial ni dependencias de versión. Al mismo tiempo, SAE está construyendo una nueva arquitectura basada en el alojamiento de la puerta de enlace de tráfico, utilizando elasticidad adaptativa, facturación inactiva y otras capacidades para reducir aún más los umbrales de uso y los costos para los usuarios.

El concepto de diseño de los productos SAE es presentar a los usuarios una experiencia simple y fácil de usar y una interfaz interactiva, proteger la complejidad del Kubernetes subyacente y reducir el costo de comprensión del usuario y el umbral de uso. Por lo tanto, la lógica interna del producto es relativamente una caja negra para los usuarios. Los usuarios no perciben la infraestructura subyacente, ni la lógica de ejecución y el proceso de interacción de los componentes. Al mismo tiempo, como producto de capa PaaS, para el personal de desarrollo y operación, es el uso unificado de Alibaba Cloud. Para unificar y simplificar la experiencia del usuario, la integración y el acoplamiento de SAE se basan en más de 10 productos o servicios en la nube. Estos atributos del producto prueban en gran medida cómo el personal de I+D de SAE debe comprender profundamente los requisitos para que puede presentar la experiencia de producto más simple, brindar a los usuarios cómo garantizar que las funciones del producto puedan satisfacer las expectativas de los usuarios en todos los niveles y cómo crear un entorno de nube estable, seguro, de alto rendimiento y de bajo costo a largo plazo para las aplicaciones de los usuarios.

Ideas para construir estabilidad

La construcción de estabilidad SAE dividirá todo el proceso de manejo de fallas en cuatro etapas: prevención de fallas, descubrimiento de fallas, ubicación de fallas, recuperación de fallas. Desde una perspectiva de plataforma, la prevención de fallas se centrará en la transformación de la región, UT, cobertura E2E y recuperación de fallas. gobernanza y actualizaciones en el propio SAE a través de simulacros y otros métodos para garantizar la alta confiabilidad y disponibilidad de los servicios back-end de SAE. Al mismo tiempo, se llevará a cabo la gestión de dependencias para productos relacionados, como agentes, espejos y dependencias de la capa IaaS para convergen en problemas relacionados con problemas ascendentes y descendentes. Causado por fallas en cascada, el descubrimiento de fallas se basa principalmente en el motor de diagnóstico y las sondas de disponibilidad del tiempo de ejecución para darse cuenta por primera vez de los problemas de la plataforma, el descubrimiento proactivo y el acceso oportuno a los problemas a través de la alarma unificada. centro. En el proceso de localización de problemas, continuaremos mejorando la construcción de la plataforma de operación y mantenimiento SAE, mejoraremos la eficiencia de operación y mantenimiento interno, mejoraremos las capacidades de delimitación de causas raíz, facilitaremos la identificación de límites y causas de problemas y haremos planes anticipados para riesgos potenciales y cambios de características para nuevas funciones, de modo que el sangrado se pueda detener rápidamente y la recuperación se pueda lograr rápidamente cuando ocurren problemas. Al mismo tiempo, ayudará a los usuarios a resolver sus propios problemas en un circuito cerrado a través de una serie de métodos basados en productos, como cuantificación de riesgos, diseño tolerante a fallas, verificación de calidad, observabilidad, centro de eventos y diagnóstico, logrando así la estabilidad de todo el enlace de Serverles.

Sistema de construcción de estabilidad

El sistema de estabilidad SAE se divide en cuatro partes de abajo hacia arriba, a saber, UT/E2E, inspección, diagnóstico del motor y sonda de disponibilidad. Primero, al mejorar la cobertura UT del código y expandir el caso E2E del proceso central, garantizamos la calidad del código, garantizamos la corrección de la lógica de ejecución del programa y evitamos problemas por adelantado. En segundo lugar, el proceso central de gestión de la vida útil de las aplicaciones se cubre mediante procedimientos de inspección periódica para garantizar la disponibilidad y el SLA del núcleo externo OpenApi. Al construir un motor de diagnóstico SAE, monitorea y consume varias fuentes de datos en tiempo real desde una perspectiva externa, genera alarmas de eventos a través de diagnóstico de patrones y procesos de delimitación de causa raíz, y descubre proactivamente problemas anormales antes de que lo hagan los usuarios. Sondeos de disponibilidad del tiempo de ejecución SAE para realizar una detección indiscriminada del tiempo de ejecución de la instancia en un entorno de usuario real para garantizar que el entorno operativo interno de la aplicación cumpla con las expectativas y utilizar el centro de alarmas unificado para completar el flujo de eventos para lograr un contacto eficiente con el problema y utilizar el -Detenga la plataforma de operación y mantenimiento para realizar operaciones de operación y mantenimiento en pantalla blanca, precipitando pasos comunes de operación y mantenimiento, mejorando la eficiencia de la ubicación del problema, cubriendo así todo tipo de problemas anormales de manera integral, multinivel y tridimensional. para garantizar la estabilidad de las aplicaciones SAE.

Motor de diagnóstico por infrarrojos.

La capa inferior de SAE es Kubernetes multiinquilino, que implementa todas las aplicaciones de los usuarios en el mismo clúster de Kubernetes a través de un mecanismo de aislamiento de seguridad, lo que facilita la gestión centralizada, favorece la mejora del nivel general del clúster y aumenta las primas comerciales y las sobreventas de recursos. pero las desventajas también son obvias, el radio de explosión de todo el grupo aumenta y las anomalías o inquietudes a pequeña escala en el grupo pueden causar anomalías en las aplicaciones de usuario de gran área. Al mismo tiempo, las funciones del producto evolucionan e iteran constantemente, y la escala de instancias de aplicaciones de usuario se expande constantemente, lo que hace que cada cambio subyacente y cada operación y operación de mantenimiento deban realizarse con precaución para evitar incompatibilidades y comportamientos anormales inesperados. Además, el propio Kubernetes tiene muchos componentes, muchas dependencias, muchas configuraciones y largos enlaces de interacción asincrónica entre componentes y servicios, lo que aumenta aún más la complejidad general. Al enfrentarse a un sistema distribuido tan complejo, es particularmente importante cómo detectar y localizar fallas de manera efectiva y oportuna.

SAE desarrolló las reglas activas de descubrimiento y diagnóstico de Infra combinando escenarios comerciales reales y experiencia de campo en el análisis y solución de problemas históricos, los resumió, extrajo el paradigma del escenario, lo convirtió en un DSL de diagnóstico universal y construyó un sistema basado en los cambios de estado de los recursos de Kubernetes. motor de descubrimiento activo. El personal de I+D puede configurar el DSL de diagnóstico en una pantalla blanca en la plataforma de operación y mantenimiento. El motor monitoreará los eventos de cambio de varios recursos de Kubernetes y cargará en caliente el DSL en tiempo real para activar el proceso de diagnóstico. El proceso de diagnóstico llevará a cabo una coincidencia de patrón común entre el estado del objeto correspondiente y las reglas de diagnóstico, analizará los recursos, los recursos en cascada, la puntualidad, la frecuencia y otros factores, verificará si cumplen con la definición de la regla y luego utilizará las características sobre esta base. El complemento de análisis implementa la delimitación de la causa raíz del problema y produce el evento de diagnóstico final. Este mecanismo puede respaldar el descubrimiento activo del estado anormal de cualquier recurso en Infra y generalmente es aplicable a escenarios que utilizan Kubernetes como base técnica.

Monitoreo de estado

El motor de descubrimiento activo SAE utiliza el estado de los recursos de Kubernetes como fuente de eventos para el diagnóstico. Cada cambio de estado desencadenará un diagnóstico de problema de proceso completo. Al mismo tiempo, se conservará y persistirá en SLS una instantánea del estado de ejecución del recurso para facilitar el historial. revisión del problema y cronograma. La clave para el monitoreo del estado es cómo garantizar que los eventos no se repitan y al mismo tiempo cumplir con los requisitos en tiempo real.

Como mecanismo central de Kubernetes, el modo de controlador utiliza un bucle de control para garantizar que el estado actual del clúster esté infinitamente cerca del estado objetivo deseado. Incluye dos partes: la percepción del estado actual (infromer) y el procesamiento de el Estado (controlador). Como medio para que el controlador interactúe con el apiserver, Infromer monitoreará los cambios de estado de los recursos de Kubernetes y activará devoluciones de llamadas de eventos. En el proceso, los objetos de recursos enumerados se almacenarán en caché en el caché local como un caché de consulta, lo que reducirá la presión sobre el apiserver. de operaciones de lectura posteriores. En comparación con métodos de consulta como el sondeo periódico, la fuente de eventos creada por el mecanismo de información puede manejar notificaciones de eventos con alto rendimiento, en tiempo real y confiabilidad.

En el escenario SAE, si el mecanismo de información nativo se usa directamente, dado que la cantidad de tipos de recursos en el clúster es grande y continuará creciendo con el crecimiento de la escala comercial, ocupará una gran cantidad de recursos de memoria y habrá existir un alto riesgo de desbordamiento de la memoria. Al mismo tiempo, cuando SAE descubre activamente que el motor se reinicia o se cambia el maestro, el proceso de lista se reactivará. Una gran cantidad de eventos en los recursos existentes ejercerán una gran presión sobre el motor y conducirán a diagnósticos repetidos de objetos de recursos. Y si un recurso se elimina durante el proceso de reinicio, su evento eliminado no se puede volver a obtener después del inicio, lo que provoca que el evento se pierda.

En respuesta a los puntos débiles anteriores, el motor de descubrimiento activo SAE ha realizado muchas modificaciones y mejoras al mecanismo de información nativo:

Ocupación de recursos de compresión: elimine el módulo de caché, almacene directamente el objeto temporalmente en la cola de trabajo cuando se activa la devolución de llamada del evento y elimínelo de la cola después de que se procese el evento. Al mismo tiempo, en la cola de trabajo nativa, si el controlador no puede procesar el mensaje, el evento se volverá a poner en cola a través del mecanismo de retroceso, lo que provocará que existan múltiples versiones del mismo objeto de recurso en la cola. El motor de descubrimiento activo solo presta atención al estado más reciente del recurso, la lógica de la cola de trabajo de modificación, al comparar la versión del recurso, solo retiene la última versión de los objetos, lo que simplifica aún más los objetos redundantes.
Mecanismo de marcador: el motor obtendrá la última versión del recurso del objeto procesado y el evento de marcador observado. Cuando la instancia sale, se almacenará persistentemente como información de progreso. Después de iniciar la nueva instancia, se leerá y almacenará en el lugar especificado. versión de recurso.La realización de la operación de lista garantiza que los eventos de sincronización redundantes no se consumirán debido al reinicio.
Gestión dinámica del finalizador: al agregar finalizadores a objetos de recursos como pods y trabajos, el finalizador solo se eliminará después de que el motor de descubrimiento activo haya completado el procesamiento, lo que garantiza la continuidad del evento en escenarios de alta concurrencia y reinicio de componentes.

Este mecanismo de monitoreo de estado ha cubierto el 100% de los recursos principales de Kubernetes en el clúster SAE, sin problemas como pérdida de eventos y estado desactualizado. En base a esto, se construye una vista de recursos de Kubernetes para mostrar el estado de sus objetos de recursos de Kubernetes asociados en cualquier momento. tiempo en la dimensión de la aplicación. Cambios de estado. El uso normal de memoria del componente es inferior a 100 MB.

Diagnóstico de esquema

Hay muchos objetos de recursos de Kubernetes y los problemas anormales son muy divergentes. Si los recursos humanos configuran políticas de alarma para cada caso anormal, será ineficiente y no podrá lograr una cobertura integral. Al resumir los problemas históricos, SAE abstrajo el siguiente paradigma de escenario:

¿El recurso A tiene campo x?
El recurso A está en el estado x
El recurso A está en estado x durante s min
El recurso A tiene el campo x y el campo y al mismo tiempo.
El recurso A tiene o no un campo x y está en el estado y al mismo tiempo
El recurso A tiene o no un campo x y está en el estado y durante s min al mismo tiempo.
El recurso A se refiere al recurso B, pero B no existe
El recurso A se refiere al recurso B. A está en el estado x, pero B está en el estado y.
El recurso A se refiere al recurso B. A está en el estado x, pero B está en el estado y durante s min.

Si se escapa del paradigma del escenario anterior hacia un DSL universal, el contenedor Sidecar estará en el estado No listo durante 300 segundos y se podrá configurar como (simplificado):

{
  "PodSidecarNotReady": {
    "duration": 300,
    "resource": "Pod",
    "filterField": [{
      "field": ["status", "phase"],
      "equalValue": ["Running"]
    }, {
      "field": ["metadata", "labels", "sae.component"],
      "equalValue": ["app"]
    }, {
      "field": ["metadata", "deletionTimestamp"],
      "nilValue": true
    }],
    "checkField": [{
      "field": ["status", "containerStatuses"],
      "equalValue": ["false"],
      "subIdentifierName": "name",
      "subIdentifierValue": ["sidecar"],
      "subField": ["ready"]
    }]

  }
}

El servicio que está en estado Eliminando durante 300 segundos se puede expresar como (simplificado):

{
  "ServiceDeleting": {
    "duration": 300,
    "resource": "Service",
    "filterField": [{
      "field": ["metadata", "labels", "sae-domain"],
      "equalValue": ["sae-domain"]
    }],
    "checkField": [{
      "field": ["metadata", "deletionTimestamp"],
      "notEqualValue": [""]
    }]
  }
}

El motor de diagnóstico procesará el objeto no estructurado de Kubernetes obtenido en el monitoreo de estado en tiempo real, coincidirá con las reglas DSL del recurso correspondiente y utilizará el árbol de sintaxis para analizar dinámicamente la información del campo para la coincidencia de patrones. Admite la obtención de cualquier campo, matriz de campos, y matriz de campos especificada en el objeto no estructurado. Los subcampos se utilizan para coincidencias exactas o coincidencias aproximadas. Si se alcanza la regla de diagnóstico después del análisis, se colocará en DelayQueue y se emitirá una alarma retrasada según la duración configurada. Cuando se genera la alarma, se completará el campo de estado y la información del evento de advertencia en el momento objetivo. para complementar el contexto diagnóstico.

Al mismo tiempo, si el objeto se monitorea posteriormente y se descubre que no cumplió con la regla de diagnóstico, se eliminará de DelayQueue, lo que indica que el problema se ha recuperado y no es necesario activar una alarma. Además del modo controlado por eventos, para algunos elementos de diagnóstico que deben ejecutarse periódicamente, como verificar que el Servicio corresponde al grupo de servidores virtuales backend SLB, si el oyente existe, si el Ingress corresponde a las reglas de enrutamiento ALB, si el orden es consistente, etc., la esencia es que en Kubernetes La información de estado expuesta por los recursos de objetos como Servicio e Ingreso es muy pequeña, y solo se puede juzgar accediendo continuamente a los productos en la nube, bases de datos y otros recursos externos correspondientes. Para tales escenarios, la última versión del objeto de recurso se mantendrá en DelayQueue y el objeto se retirará de la cola. Después de la verificación, se volverá a ingresar a la cola y se eliminará de DelayQueue solo cuando se elimine. Al mismo tiempo, se agrega un desplazamiento aleatorio al tiempo de retardo para dispersarlo, a fin de evitar activar el diagnóstico al mismo tiempo y causar limitación de acceso.

El motor de descubrimiento activo SAE puede realizar una lógica de procesamiento universal en recursos, admite cualquier configuración de reglas CRD e implementa una verificación completa de recursos/recursos en cascada, juicio de fugas/faltas de recursos, verificación de frecuencia de puntualidad y otras funciones. El personal de I+D puede ejecutar la plataforma de dimensiones que cambia la DSL en tiempo real y entra en vigor en las reglas de diagnóstico.

delimitación de la causa raíz

Para excepciones con estado directo en objetos de recursos o causas claras en los eventos correspondientes de Kubernetes, la coincidencia de patrones tiene un buen efecto de diagnóstico. Sin embargo, para problemas complejos con dependencias e interacciones de múltiples componentes, hay más falsos positivos. El personal de I+D necesita analizar más a fondo los problema en función de su apariencia, distinguir si el problema es causado por un error del usuario o una falla interna de la plataforma, y localizar la causa raíz del problema.

Con la ayuda de la capacidad de delimitación de la causa raíz del motor de diagnóstico Infra, la experiencia de los expertos puede precipitarse en un flujo de diagnóstico automatizado, que puede reducir eficazmente la aparición de falsas alarmas y converger en la percepción de anomalías por parte del usuario. El núcleo de la capacidad de delimitación de la causa raíz es dividir y profundizar la apariencia del problema en múltiples dimensiones y combinar los elementos característicos para un análisis estructurado y automatizado para encontrar la causa raíz del problema. Tomando como ejemplo la falla al extraer la imagen, el árbol de análisis del problema de delimitación de la causa raíz es (después de simplificarlo):

Cada nodo en la delimitación de la causa raíz es la lógica de negocios para un caso de diagnóstico específico y tiene atributos que cambian con frecuencia. Si se agregan al motor de descubrimiento activo, cualquier cambio requerirá un proceso de lanzamiento en línea, que requiere desarrollo, operación y mantenimiento. El costo es alto y no se puede lograr el aislamiento de recursos y el aislamiento de fallas, lo que aumenta la complejidad y los riesgos de seguridad de todo el motor. Por lo tanto, se adopta la arquitectura microkernel en el diseño del motor de descubrimiento activo, conservando la lógica central de los componentes, extrayendo elementos de diagnóstico como complementos de funciones livianos, realizando comunicación RPC con el motor de descubrimiento activo a través del modo adaptador y realizando la enrutamiento dinámico y enrutamiento dinámico del complemento a través del mecanismo de reflexión. El motor genera un gráfico acíclico dirigido al analizar el complemento DSL, organiza todo el proceso de llamada y delimita la causa raíz de los elementos de diagnóstico de destino. El complemento de funciones se implementa y ejecuta en Alibaba Cloud Function Compute, lo que provoca un retraso de inicio en frío de milisegundos. El complemento asigna recursos de ejecución de forma independiente y admite modificaciones en tiempo real y actualizaciones en caliente del código.

El uso de la transformación de complementos para lograr la delimitación de la causa raíz tiene los siguientes valores:

Desarrollo ágil: favorece la separación de preocupaciones y el desacoplamiento de proyectos, simplificando el proceso de codificación, depuración y mantenimiento, y mejorando la eficiencia del desarrollo y la implementación.
Escalabilidad dinámica: al modificar el DSL declarativo, los complementos se pueden insertar y eliminar dinámicamente en tiempo de ejecución en tiempo real, y el proceso de diagnóstico se puede personalizar y modificar de manera flexible.
Aislamiento de fallas: reduzca el radio de explosión y evite que todo el motor de descubrimiento activo sea anormal debido a una sola anomalía del complemento, de modo que el impacto se limite al complemento mismo.
Combinación y orquestación: con la ayuda de capacidades de complementos atómicos y un mecanismo de ejecución de máquina de estado unificado, la entrada y salida de los complementos se procesan y transfieren, lo que facilita la implementación de una lógica de diagnóstico más compleja.

Además de los complementos de funciones relacionados con la imagen de la figura, también hay complementos de funciones comunes, como picos de monitoreo, estado de ejecución de órdenes de lanzamiento, distribución anormal de instancias de aplicaciones, salida estándar de instancias e instantáneas del entorno de ejecución para ayudar. en la localización y solución de problemas.

Sondeo de disponibilidad en tiempo de ejecución

El descubrimiento activo basado en los cambios de estado de los recursos de Kubernetes puede cubrir la mayoría de los problemas de estabilidad, pero carece de una perspectiva interna y no puede reflejar completamente el estado del entorno de ejecución de la instancia. No puede detectar de manera oportuna y efectiva cambios en las dependencias de inicio del usuario y en los entornos de instancia de tiempo de ejecución. causados por diferencias no pueden definir efectivamente los límites de los problemas de tiempo de ejecución causados por el funcionamiento anormal de la aplicación misma.

Al crear sondas de disponibilidad en tiempo de ejecución SAE, la detección en tiempo real y la generación de informes de indicadores de disponibilidad se realizan dentro de las instancias de usuario, garantizando así el estado de salud de la implementación dimensional de la instancia y los estados de ejecución en el entorno real del usuario independientemente de las aplicaciones de lenguaje, y representando así la El estado de ejecución real de toda la instancia elimina el impacto de las anomalías de la aplicación del propio usuario, exponiendo así de manera efectiva problemas difíciles y ocultos, definiendo las causas fundamentales de la disponibilidad del tiempo de ejecución y mejorando la cobertura de estabilidad.

Como puede ver en la figura, la sonda de disponibilidad del tiempo de ejecución SAE se ejecuta como un complemento en la instancia del usuario y su arquitectura se divide en las siguientes partes:

Centro de configuración: se utiliza para configurar la versión en escala de grises de la sonda y si los elementos de detección dependientes son válidos, y admite la dimensión del usuario y la dimensión de la aplicación.
Proceso demonio: responsable de las funciones generales de gestión de procesos: actualización en caliente de la versión, carga en caliente de la configuración, verificación de estado, canal de comando, mantenimiento del proceso, transmisión transparente de señales y monitoreo del nivel de agua.
Proceso de trabajo: realiza tareas informáticas, es responsable de ejecutar una lógica de detección de dependencia específica y adjuntar metadatos para informar información de latidos a la unidad de almacenamiento persistente.
Unidad de almacenamiento persistente: almacena información de los latidos del corazón para facilitar el consumo y procesamiento posterior por parte del motor de diagnóstico, al tiempo que proporciona una visualización visual del mercado.
Motor de diagnóstico: consume datos de latidos de la sonda en la unidad de almacenamiento persistente, mejora las capacidades de delimitación de la causa raíz del diagnóstico, accede al centro de configuración para actualizar la información de configuración de la sonda y controla y opera los comportamientos de la sonda.

Detección de dependencia

SAE clasifica de manera integral las dependencias relacionadas con el estado de implementación y el estado de ejecución de la aplicación. Los factores que afectarán seriamente el funcionamiento de la instancia de la aplicación incluyen principalmente las siguientes categorías:

En términos del método de informe de latidos, dado que SAE adopta el modo de tarjeta de red única, la instancia solo está vinculada a la tarjeta de red ENI del usuario. La red de la plataforma no tiene la capacidad de acceder a instancias de usuarios remotos y el modelo de extracción no se puede utilizar para obtener información de latidos. Por el contrario, el modelo push admite naturalmente la expansión horizontal y no ocupar puertos de usuario evita posibles conflictos de puertos y riesgos de fuga de datos, por lo que la sonda utiliza el modelo push para informes activos en el lado final.

Para cada dependencia, la sonda de disponibilidad en tiempo de ejecución de SAE ejecutará una lógica de detección periódica, generará el código de estado del resultado e informará el latido a la unidad de almacenamiento persistente después del llenado de metadatos y la compresión de elementos asociados. El motor de descubrimiento activo SAE consume datos de latidos en tiempo real, obtiene el código de estado de los latidos para determinar el estado de ejecución de la instancia y activa alarmas anormales. Al mismo tiempo, los datos de los latidos se pueden resumir y visualizar para dibujar el ciclo de vida completo. trayectoria de la instancia y crear un panel de SLA de disponibilidad para referencia interna de SAE.

Gestión de operación y mantenimiento.

Dado que la prueba de disponibilidad del tiempo de ejecución de SAE se ejecuta en la instancia del usuario, la solidez de la prueba en sí es particularmente importante. Para lograr un control de versiones refinado y actualizaciones en caliente en tiempo real, y garantizar que la sonda pueda solucionar los problemas a tiempo y continuar con la iteración, la sonda SAE adopta el modo de operación de proceso demonio + proceso de trabajo. El proceso del demonio es responsable de la lógica general, como la extracción de configuración, el mantenimiento y actualización del proceso de trabajo, la captura de semáforos y la transmisión transparente, etc., para garantizar que el proceso de trabajo pueda salir normalmente y recuperarse automáticamente de las excepciones, mientras el proceso de trabajo es responsable de la programación de tareas y la ejecución de tareas específicas, lógica de verificación de dependencia y generación e informes de latidos. El motor de descubrimiento activo SAE identifica y controla el progreso de la actualización en escala de grises a través del número de versión en el latido. A través del desacoplamiento de proceso dual, la lógica volátil se mueve al proceso de trabajo y se utiliza el método de actualización automática distribuida. En comparación con el procesamiento de proceso único, la actualización de la versión se basa en la activación centralizada de la actualización in situ de CloneSet y la actualización de la imagen cada vez. asegurando que la actualización sea en tiempo real y no pase por el enlace de Kubernetes, lo que reduce la presión del proceso de actualización en el acceso al clúster y el impacto en el tráfico de contenedores comerciales de los usuarios.

El contenedor sidecar en la instancia SAE comparte especificaciones de recursos con el contenedor empresarial del usuario. Es necesario evitar el consumo excesivo de recursos de la sonda y la apropiación de recursos con el contenedor empresarial que afecte su funcionamiento normal. Análisis de rendimiento y optimización del código del tiempo de ejecución de SAE Se realizan sondas de disponibilidad y extrapola la lógica de cálculo al motor de descubrimiento activo SAE para su procesamiento para garantizar que la sonda sea lo suficientemente liviana. Después de comparar el consumo de recursos después de conectarse, la CPU de la sonda SAE casi no ocupa espacio y solo ocupa memoria. unos pocos MB. Al mismo tiempo, para evitar el uso excesivo de recursos en situaciones extremas, la sonda SAE también agrega capacidades de autocontrol de componentes, recopila periódicamente el consumo de recursos del proceso actual y lo compara con el umbral objetivo esperado configurado. es demasiado, se activará la lógica del disyuntor Retiro automático.

contenedor de herramientas

Dado que la sonda de disponibilidad del tiempo de ejecución de SAE se inicia antes del contenedor empresarial del usuario y reside en todas las instancias de usuario, se pueden preinstalar herramientas, comandos y scripts comunes como ossutils, wget, iproute, procps, arthas, etc. y la intranet de Alibaba Cloud. La fuente del software se puede configurar, para evitar la imposibilidad de instalar herramientas relacionadas y la imposibilidad de ejecutar comandos normalmente debido a la falla continua de los contenedores de usuario o el uso de imágenes reducidas como Alpine, mejorando así la eficiencia de operación y mantenimiento y la operación y Experiencia en mantenimiento durante el proceso de resolución de problemas. Al mismo tiempo, dado que los dos están ubicados en el mismo plano de la red, la sonda SAE se puede utilizar como trampolín para detectar problemas como la conectividad de la red, el retraso de la red y la existencia de recursos. Si la operación y el mantenimiento por lotes se realizan de manera centralizada mediante la ejecución de comandos a través de exec, dado que el proceso de llamada de exec debe pasar por el apiserver, los clústeres de múltiples inquilinos deben evaluar razonablemente la concurrencia de acceso y el tamaño del paquete de datos, y habrá cierta estabilidad. riesgos Al utilizar sondas como canal de comando, se puede aislar el tráfico de control y el tráfico de datos en el clúster SAE y respaldar la ejecución de informes de varios comandos y scripts de manera segura y confiable. Muchos complementos en el motor de descubrimiento activo de SAE se implementan utilizando la sonda de disponibilidad del tiempo de ejecución de SAE como canal de comando.

En el futuro, SAE también explorará la combinación de sondas de disponibilidad de tiempo de ejecución y tecnología ebpf para proporcionar métodos de depuración y resolución de problemas más profundos para llamadas al kernel, captura de paquetes de red, seguimiento del rendimiento, etc.

Centro de alarma unificado

Las fuentes de generación de alarmas de SAE están muy dispersas, incluidos eventos de diagnóstico del motor de diagnóstico, información de latidos de sondas de disponibilidad, eventos de Kubernetes, registros de componentes de tiempo de ejecución, datos de base de datos, monitoreo de la nube, monitoreo de Prometheus, etc., y cada uno El formato de datos de la fuente de alarma es inconsistente y las capacidades de alarma de las plataformas son diferentes, lo que hace imposible personalizar la configuración según las necesidades propias de la empresa.

Para garantizar que diversos problemas de estabilidad puedan llegar al personal de I+D de manera oportuna y eficaz, SAE ha creado un centro de alarmas unificado y ha formulado especificaciones de modelo de eventos unificados para convertir datos heterogéneos en eventos SAE mediante la integración y el consumo de varias fuentes de alarma. a través del filtrado de eventos en listas blancas y negras, deduplicación y compresión, enriquecimiento de metadatos, correlación de información contextual y, finalmente, informes de eventos completos a ARMS. Con la ayuda de la gestión de contactos de alarma, la distribución multicanal, la programación dinámica y otras capacidades de productización de ARMS, se realiza el proceso de alarma de un extremo a otro. Sobre esta base, mejoraremos el mecanismo de clasificación de alarmas y las capacidades de actualización de alarmas para manejar problemas urgentes y graves de manera oportuna y efectiva, mejoraremos la eficiencia del procesamiento de alarmas, construiremos un centro de eventos para exponer eventos internos a los usuarios para su suscripción y respaldaremos la salida. de indicadores básicos y de mercado visualizados y detalles de auditoría de alarmas históricas para lograr una gestión integral de todo el proceso de alarmas.

Clasificación de alarma

Con la mejora de las capacidades de descubrimiento activo y la mejora de la cobertura de diagnóstico, los diferentes tipos de alarmas son divergentes y se mezclan. Si el personal de I + D aún adopta un enfoque igual para verificar y solucionar problemas de alarmas, a menudo habrá alarmas que no se manejan a tiempo y alarmas que se pasan por alto Esta situación se da, y aunque el motor de diagnóstico ha detectado el problema, aún existen quejas de clientes por manejo inadecuado de las alarmas internas.

El procesamiento eficaz de alarmas no solo depende de la precisión de la alarma en sí, sino que también requiere reducir las falsas alarmas, las alarmas perdidas y la convergencia de alarmas no válidas. Al mismo tiempo, también se basa en el desvío de alarmas. Alarmas de diferentes tipos y diferentes Los impactos deben procesarse de diferentes maneras, de modo que se pueda utilizar la energía limitada. Hacer asignaciones más razonables para garantizar que los problemas puedan resolverse de manera efectiva.

Al combinar la estratificación del nivel de falla de Alibaba Cloud y las características comerciales propias de SAE, SAE divide internamente las alarmas en cuatro niveles:

SAE utiliza los indicadores principales SLA y SLO del producto como guía para clasificar todas las alarmas existentes y nuevas alarmas y configurar el nivel de alarma predeterminado. Al mismo tiempo, implementa un mecanismo de actualización de alarma. Cuando se emite una alarma, el sistema unificado El centro de alarmas manejará y resolverá la alarma. Se cuenta el número de aplicaciones, usuarios e incrementos de alarma afectados por todas las alarmas del mismo tipo dentro del intervalo de tiempo entre las dos, y si la alarma debe actualizarse se determina en función de la actualización. estrategia. La estrategia de actualización es la siguiente:

El centro de alarma unificado SAE utiliza el panel de alarmas ARMS para cuantificar los indicadores de respuesta de emergencia estándar de la industria MTTD, MTTA y MTTR para medir la calidad del procesamiento de alarmas. En la actualidad, a través del sistema de clasificación de alarmas detallado y el mecanismo de actualización de alarmas, los problemas de alarma se pueden desviar de manera eficiente y el personal de I + D puede resolver problemas de emergencia de una manera más específica, mejorando efectivamente la tasa de alcance y la eficiencia del procesamiento de las alarmas.

centro de eventos

Además de alertar al personal interno de I+D sobre problemas descubiertos activamente en la plataforma, el Centro de alarma unificado SAE también llevará a cabo una gestión, almacenamiento, análisis y visualización unificados de eventos en forma de un centro de eventos productizado, y diagnosticará problemas del lado del usuario y necesitan atención Las notificaciones se transmiten de forma transparente a los clientes, lo que les permite responder a las fallas de manera oportuna, realizar operaciones de operación y mantenimiento y evitar un mayor deterioro del problema.

El actual Centro de Eventos SAE divide los eventos en las siguientes categorías:

Los eventos de tiempo de ejecución son eventos generados durante la ejecución de la aplicación y requieren que los usuarios se suscriban activamente.

- Como falla en la verificación de estado, OOM de instancia, activador de escalado automático, estado de ejecución de tareas, reinicio de instancia, punto muerto del programa Java, tráfico desigual, aumento repentino de QPS/RT, microservicios elegantes en línea y fuera de línea, etc.

Los eventos de cambio son eventos generados cuando los usuarios realizan operaciones de cambio y mantenimiento, y requieren que los usuarios se suscriban activamente.

- Como el estado de operación de cambio de aplicación, el estado de inicio y detención de lotes, falla en la extracción de imágenes, IP de interruptor insuficiente, etc.

Los eventos del sistema, eventos definidos dentro del sistema SAE, no requieren que los usuarios se suscriban activamente. Están habilitados de forma predeterminada. Cuando ocurren eventos, se notificarán a la cuenta principal del usuario a través de Yunge.

- Si el nodo host es anormal, la instancia se migrará internamente.

Al mismo tiempo, SAE, como plataforma PaaS de alojamiento de aplicaciones, integra muchos productos de Alibaba Cloud y proporciona una vista de administración unificada para que la utilicen los usuarios. Sin embargo, la desventaja de este modelo es que los usuarios a menudo comentan problemas con otros productos en la nube, y SAE También es necesario identificar y definir ¿A qué producto en la nube debería pertenecer la excepción? Al mismo tiempo, el modelo de alojamiento débil de SAE a menudo hace que las operaciones del usuario y las operaciones de la plataforma entren en conflicto, se sobrescriban entre sí o fallen.

Ante tales problemas, además de revelar sus propios eventos de plataforma, el centro de eventos también cubrirá los productos en la nube relacionados con SAE y los divulgará en forma de eventos de productos en la nube. Específicamente, los problemas se dividirán en las siguientes cuatro categorías :

Indicadores anormales (según el monitoreo de la nube): pérdida de paquetes de monitoreo SLB, pérdida de paquetes con límite de velocidad entrante y saliente de EIP, ancho de banda lleno, etc.
La cuota está llena (según el centro de cuota): SLB retiene la cantidad de instancias, retiene la cantidad de monitores, la cantidad de servidores montados en el backend, la cantidad de EIP excede el límite, etc.
Conflictos de configuración: conflictos de configuración entre productos SLB y ALB, conflictos de configuración entre productos de enrutamiento de puerta de enlace.
Se eliminaron recursos: sistema de archivos NAS, fuente de montaje, directorio de montaje, depósito OSS, AK/SK, directorio de montaje, proyecto SLS, almacén de registros, etc.

En la consola, los usuarios pueden seleccionar los elementos de eventos a los que necesitan suscribirse según la aplicación, el espacio de nombres y las dimensiones geográficas, y configurar estrategias de notificación como ciclos de detección, umbrales de activación y métodos de contacto para completar el acceso en tiempo real a los problemas que les interesan. acerca de.

Operación y mantenimiento con un solo clic

Cuando ocurre una alarma, los pasos generales de procesamiento para el personal de I+D de SAE son: iniciar sesión en la plataforma de operación y mantenimiento, buscar la aplicación o instancia correspondiente a la alarma, analizar y determinar la causa de la excepción y realizar las operaciones de operación y mantenimiento correspondientes. . Hay muchos pasos previos a la operación en todo el proceso de resolución de problemas, lo que conduce a una disminución en la eficiencia de la resolución de problemas. Al mismo tiempo, es imposible que el personal de I + D permanezca junto a la computadora todo el tiempo, y la operación y La plataforma de mantenimiento no está adaptada específicamente al terminal móvil, si no está cerca durante los desplazamientos o los fines de semana, la computadora será muy incómoda para lidiar con las alarmas.

En referencia al concepto ChatOps, las acciones correspondientes se completan automáticamente en función de controladores de diálogo en herramientas de comunicación en tiempo real. SAE personaliza el estilo de la tarjeta DingTalk para mostrar el contenido de la alarma mientras enriquece el contexto de diagnóstico y combina operaciones comunes (eliminar instancias, desconectar instancias, reiniciar aplicaciones, detener el diagnóstico, detener temporalmente la alarma, etc.) se fija en la parte inferior de la tarjeta, lo que facilita al personal de I+D realizar operaciones y mantenimiento con un solo clic en DingTalk en sus teléfonos móviles en cualquier momento y en cualquier lugar, mejorando la eficiencia general de operación y mantenimiento. y experiencia de felicidad en I+D.

La operación y el mantenimiento posteriores con un solo clic evolucionarán hacia la operación y el mantenimiento automatizados, que realizarán operaciones de operación y mantenimiento deterministas cuando surjan alarmas como recursos que no se han limpiado durante mucho tiempo, discos llenos, acumulación de tareas, migración de instancias de nodos, etc. ., para lograr el aislamiento automático de fallas y la automatización de fallas.

Resumen de construcción de estabilidad

No existe una solución milagrosa en la construcción de la estabilización. Es una batalla prolongada y sin humo. También es una dirección que requiere inversiones a largo plazo y merece una inversión específica. Deberíamos respetar y convertirnos en personas que reparan tejados en días soleados, en lugar de los llamados héroes de la extinción de incendios. Deberíamos diseñar sistemas y arquitecturas desde una perspectiva más sistemática. Descubrir y resolver casos de esquinas ocultas es también el punto fuerte de los técnicos. SAE continuará optimizando, mejorando y profundizando todo el proceso de construcción de estabilidad para prevenir problemas y fallas por adelantado, descubrir, localizar con precisión y recuperarse rápidamente de manera proactiva. Tomando el valor del usuario como núcleo, siguiendo de cerca las demandas de los usuarios, continuamos creando una experiencia minimalista, de código abierto y una plataforma PaaS sin servidor tecnológicamente líder para los usuarios.