Autor: Gao Yulong (Yuanbo)

Primero, comprendamos los antecedentes de Trace de enlace completo en el terminal móvil:

Desde la perspectiva del terminal móvil, un producto App se produce desde el concepto hasta la madurez y estabilidad final. El personal de I+D involucrado en el proceso de desarrollo del producto, el número de líneas de código en el proyecto, la escala de la arquitectura del proyecto, la frecuencia de los lanzamientos de productos y la reparación de los problemas comerciales en línea El tiempo, etc., sufrirá cambios relativamente grandes. Estos cambios nos han traído considerables dificultades y desafíos en la resolución de problemas, y los problemas comerciales a menudo son difíciles de reproducir y localizar. Por ejemplo, en la etapa inicial de un producto, la escala del proyecto suele ser relativamente pequeña, el proceso comercial es relativamente simple y los problemas en línea a menudo se pueden localizar rápidamente. Cuando la escala del proyecto es relativamente grande, el proceso comercial a menudo involucra más módulos.En este momento, algunos problemas en línea serán más difíciles de reproducir y localizar.

Este artículo es el intercambio del autor en la Conferencia de tecnología de terminales D2 de 2022, con la esperanza de brindarle algo de reflexión e inspiración.

¿Por qué es difícil reproducir y localizar problemas del lado del dispositivo?

¿Por qué los problemas comerciales en línea son difíciles de reproducir y solucionar? Según nuestro análisis, se debe principalmente a 4 motivos:

La recopilación de registros de terminales móviles y terminales de servidor no está unificada, y no existe una especificación estándar unificada para restringir la recopilación y el procesamiento de datos.
A menudo hay muchos módulos involucrados en el lado final, y los marcos de I + D también son diferentes. Los códigos están aislados entre sí, el equipo está fragmentado y el entorno de red es complejo, lo que dificultará la recopilación de datos en el lado final
Desde un punto de vista final, a menudo es difícil obtener datos entre diferentes marcos y sistemas al analizar problemas, y hay una falta de información contextual entre los datos, lo que dificulta el análisis de asociación de datos.
A menudo hay muchos dominios comerciales involucrados en los enlaces comerciales. Para reproducir y solucionar problemas desde la perspectiva del final, a menudo se requiere que los estudiantes en los dominios correspondientes participen en la resolución de problemas, y el costo de operación humana y mantenimiento es relativamente alto.

¿Cómo solucionar estos problemas? Nuestra idea es ir en cuatro pasos:

Establezca estándares uniformes y utilice protocolos estándar para regir la recopilación y el procesamiento de datos.
Unifique las capacidades de recopilación de datos para diferentes plataformas y marcos.
Análisis de contexto automático y procesamiento de datos generados por múltiples sistemas y módulos.
También hemos realizado algunas exploraciones en el análisis de experiencia automatizado basado en el aprendizaje automático.

Estándares de recopilación de datos unificados

¿Cómo unificar el estándar? En la actualidad, existen diversas soluciones en la industria, pero los problemas existentes también son evidentes:

Los protocolos/tipos de datos no son uniformes entre los diferentes esquemas;
También es difícil que sea compatible/interoperable entre diferentes soluciones.

Estándar aquí, elegimos OTel, OTel es la abreviatura de OpenTelemetry, hay dos razones principales:

OTel está dirigido por Cloud Native Computing Foundation (CNCF), que es una fusión de OpenTracing y OpenCensus, y actualmente es un protocolo casi estándar en el campo de la observabilidad;
OTel unifica diferentes lenguajes y modelos de datos y es compatible tanto con OpenTracing como con OpenCensus.También proporciona recopiladores independientes del proveedor para recibir, procesar y exportar datos observables.

En nuestra solución, las especificaciones de recopilación de datos de todos los terminales se basan en OTel, y el almacenamiento, el procesamiento y el análisis de datos se construyen en función de la capacidad de LogHub proporcionada por SLS.

Dificultades en la recopilación de datos de extremo a extremo

No es suficiente solo unificar el protocolo de datos, sino también resolver algunos problemas en la recopilación de datos en el lado final. En general, la adquisición de dispositivo a lado actualmente enfrenta tres dificultades principales:

La concatenación de datos es difícil
La garantía de cumplimiento es difícil
Difícil no perder datos

A menudo, hay muchos marcos y módulos involucrados en el proceso de investigación y desarrollo del lado final, y el negocio también es complejo. Hay múltiples llamadas asincrónicas a las API, como subprocesos y rutinas. Cómo resolver el problema de la conexión automática entre datos durante el proceso de recogida de datos? La fragmentación de los dispositivos móviles es grave, la distribución de las versiones del sistema está relativamente dispersa y hay muchos modelos.¿Cómo garantizar el rendimiento de recopilación constante de múltiples terminales? La incertidumbre de los escenarios de uso de la aplicación también es relativamente grande.¿Cómo garantizar que los datos recopilados no se pierdan?

Dificultades en la concatenación de datos del lado del dispositivo

Analicemos primero los principales problemas que enfrenta la concatenación automática de datos del lado del dispositivo.

Durante el proceso de recopilación de datos del lado final, no solo se recopilan datos de enlaces comerciales, sino que también se recopilan varios datos de monitoreo de rendimiento y estabilidad, y hay muchas fuentes de datos observables;
Si se utilizan otros marcos de I+D, como OkHttp, Fresco, etc., los datos clave del marco tripartito también se pueden recopilar para el análisis y el posicionamiento de las solicitudes de red, la carga de imágenes y otras cuestiones. Para los estudiantes de investigación y desarrollo empresarial, a menudo no prestamos demasiada atención a las capacidades técnicas de dichos marcos de tres partes.Cuando se trata de solucionar problemas de marco de este tipo, el proceso suele ser difícil;
Además, el lado del terminal se llama casi completamente de forma asíncrona, y hay muchas API llamadas de forma asíncrona, como subprocesos, rutinas, etc., y existen ciertos desafíos en la apertura de enlaces.

Aquí hay algunos problemas comunes:

¿Cómo recopilar los datos del marco tripartito? ¿Cómo concatenar?
¿Cómo conectar diferentes fuentes de datos observables?
¿Cómo concatenar automáticamente los datos distribuidos entre diferentes subprocesos y rutinas?

Solución de serialización automática de datos del lado final

Primero veamos el esquema de conexión en serie automática de datos del lado final.

En el estándar de protocolo OTel, la relación serial entre diferentes datos está restringida a través del protocolo de rastreo. OTel define los campos necesarios que debe contener cada pieza de datos en el enlace de datos de seguimiento, y debemos garantizar la consistencia de los datos en el mismo enlace. Por ejemplo, en el mismo vínculo de rastreo, el trace_id debe ser el mismo; en segundo lugar, si existe una relación padre-hijo entre los datos, el parent_id de los datos secundarios también debe ser el mismo que el span_id de los datos principales.

Sabemos que ya sea una plataforma Android o una plataforma iOS, un subproceso es la unidad más pequeña que puede programar el sistema operativo. En otras palabras, todo nuestro código eventualmente se ejecutará en el hilo. Cuando se ejecuta el código, si podemos asociar la información de contexto con el hilo actual, la información de contexto actual se puede obtener automáticamente cuando se ejecuta el código, de modo que se puede resolver el problema de la asociación automática de datos de rastreo en el mismo hilo.

En Android , la información de contexto de la pila de subprocesos actual se puede almacenar en función de la variable de subproceso ThreadLocal, que puede garantizar la asociación automática de los datos comerciales recopilados en el mismo subproceso. Si se usa en una rutina, habrá problemas con la solución basada en variables de subprocesos. Debido a que en la corrutina, el subproceso en ejecución real de la corrutina es incierto, y el cambio de subprocesos se puede realizar durante el ciclo de vida de la ejecución de la corrutina. Necesitamos usar el programador de corrutina y el Contexto de la corrutina para mantener la corrección del contexto actual. Cuando se reanuda la rutina, la información de contexto asociada surte efecto en el subproceso actual, y cuando se suspende la rutina, la información de contexto deja de ser válida en el subproceso actual.

En iOS, se basa principalmente en el mecanismo de seguimiento de actividad para mantener la validez de la información de contexto. A través del mecanismo de seguimiento de actividad, cuando se inicia un vínculo comercial, se crea automáticamente una actividad y asociamos información de contexto con la actividad. Dentro del alcance de la actividad actual, todos los datos generados se asociarán automáticamente con el contexto actual.

Con base en estas dos soluciones, al generar datos de Trace, el SDK asociará automáticamente la información de contexto con los datos actuales de acuerdo con el estándar del protocolo OTel. Los datos finales generados se asociarán lógicamente en forma de árbol, y el nodo raíz del árbol es el punto de inicio del vínculo de seguimiento. Este método no solo admite la asociación automática de datos dentro de corrutinas/subprocesos, sino que también admite el anidamiento de varios niveles.

Adquisición de datos y concatenación del marco tripartito

Para la recopilación de datos del marco tripartito, echemos un vistazo a las prácticas comunes en la industria.En la actualidad, hay dos tipos principales:

Si la biblioteca de tres partes admite la configuración de interceptores o proxies, generalmente se implementará agregando códigos integrados a los interceptores correspondientes;
Si la biblioteca de tres partes expone menos interfaces, generalmente agregará código incrustado a través de Hooks u otros métodos, o no es compatible con los puntos incrustados del marco correspondiente.

Hay dos problemas principales con este enfoque:

El punto oculto no está completo. Tome OkHttp como ejemplo. El SDK de terceros también puede depender de OkHttp. A través del método de interceptor, es posible que solo admita la recopilación de puntos ocultos del código comercial actual y la información de solicitud de red del No se puede recopilar el SDK de terceros, ya que generará información incompleta sobre puntos ocultos;
Puede ser necesario inmiscuirse en el código comercial. Para realizar el punto de incrustación del marco correspondiente, debe haber un tiempo de corte. Este tiempo de corte a menudo debe realizarse agregando elementos de configuración de código cuando el se inicializa el marco correspondiente.

¿Cómo resolver estos dos problemas?

La solución que usamos es implementar un complemento de Gradle e insertar el código de bytes en el complemento. Sabemos que durante el proceso de empaquetado de la aplicación de Android, hay un proceso que convierte los archivos .class en archivos .dex.Durante este proceso, los archivos de clase se pueden procesar a través de la API de transformación. Usamos ASM para realizar la instrumentación de archivos de clase. En el proceso de procesamiento de bytecode, primero es necesario encontrar un punto de inserción adecuado y luego inyectar las instrucciones adecuadas.

Aquí tomamos la instrumentación de bytes de OkHttp como ejemplo : el objetivo de la instrumentación es asociar la información de contexto del subproceso actual con la solicitud de OkHttp cuando OkHttpClient llama al método newCall. En el proceso de transformación, primero filtramos el archivo de clase de destino de acuerdo con el nombre de clase de OkHttpClient y luego filtramos el método que se insertará de acuerdo con el nombre de método newCall. A continuación, la información de contexto debe insertarse en el objeto de etiquetas de la solicitud al comienzo del método newCall. Después de nuestro análisis, es necesario insertar el código de destino cuando se inicia la llamada al método newCall. Para facilitar la implementación y la depuración, implementamos una herramienta auxiliar OkHttp en la biblioteca de extensiones, insertamos el código de bytes que llama a esta herramienta en la posición de destino y pasamos el objeto de solicitud.

El código de bytes insertado se asociará con la biblioteca de extensiones. De esta manera, se puede resolver el problema de la recopilación de datos del marco tripartito y la asociación automática del contexto.

En comparación con el método tradicional, utilizando el esquema de instrumentación de bytecode, el código comercial será menos intrusivo, y los puntos de incrustación pueden ser efectivos tanto para el código comercial como para el marco de tres partes, y también se puede completar la asociación automática del contexto. en combinación con la biblioteca de extensión.

Cómo garantizar el rendimiento

En el proceso de recopilación de datos observables, se generará una gran cantidad de datos y existen ciertos requisitos de rendimiento para la memoria, el uso de la CPU y la carga de E/S.

Implementamos la parte central basada en C para garantizar la consistencia del rendimiento de múltiples plataformas y optimizar el rendimiento desde tres aspectos :

En primer lugar, es optimizar el proceso de procesamiento del protocolo. En términos de protocolo de datos, se utiliza el protocolo Protocol Buffer. Comparado con JSON, Protocol Buffer no solo es más rápido, sino que también ahorra espacio en la memoria. En la serialización del protocolo, adoptamos la implementación del protocolo de encapsulación manual.Durante el proceso de serialización, evitamos la creación y copia de mucho espacio de memoria temporal y la llamada de funciones irrelevantes.

En segundo lugar, en términos de administración de memoria, establecemos directamente un límite de tamaño configurable en la memoria máxima utilizada por el SDK. El uso de la memoria se puede configurar a pedido de acuerdo con la situación comercial, para evitar el impacto del uso excesivo de memoria SDK en la estabilidad de la aplicación; en segundo lugar, también se introduce un mecanismo de administración de memoria dinámica para aumentar el uso del espacio de memoria según sea necesario, y no ocupará la aplicación todo el tiempo.Espacio de memoria, para evitar el desperdicio de espacio de memoria. También mejora el rendimiento del procesamiento de cadenas. En el procesamiento de caracteres, se introduce un mecanismo de cadena dinámica, que puede registrar la longitud de la propia cadena. Al obtener la longitud del carácter, la complejidad de la operación es baja y puede evitar el desbordamiento del búfer y reducir el costo de modificar el cadena Número de reasignaciones de memoria.

Finalmente, en términos de administración de caché de archivos, también limitamos el límite superior del tamaño del archivo para evitar desperdiciar el espacio de almacenamiento del dispositivo del mismo nivel. En el procesamiento de archivos de caché, hemos introducido el mecanismo de archivo de anillo para almacenar datos de caché en varios archivos y ensamblar varios archivos en forma de grupos de archivos de registro. Todo el grupo de archivos de registro se escribe desde el principio en forma de matriz circular, se escribe hasta el final y luego se vuelve al principio para volver a escribir. Escribir datos de esta manera puede reducir la búsqueda aleatoria al escribir archivos, y el mecanismo de archivo de anillo puede garantizar que un solo archivo de registro no sea demasiado grande, lo que reduce la carga de E/S del sistema tanto como sea posible. Además del mecanismo de Ring File, la lógica de guardado de puntos de interrupción y limpieza de caché también se agrega y ejecuta en conjunto para reducir las búsquedas aleatorias. El tamaño del archivo del punto de control también está limitado. Después de que se exceda el tamaño especificado, el archivo del punto de control se limpiará para evitar que el archivo del punto de control sea demasiado grande y afecte la eficiencia de lectura y escritura del archivo.

Después de las medidas de optimización anteriores, el rendimiento de los datos recopilados por SDK se ha multiplicado por 2, y el uso de memoria y CPU se ha reducido significativamente. Puede admitir la recopilación de hasta más de 400 datos por segundo.

¿Cómo asegurarse de que los registros no se pierdan?

No es suficiente que el rendimiento cumpla con los requisitos, también es necesario asegurarse de que los datos recopilados no se pierdan. Durante el uso de la aplicación, la aplicación a menudo puede fallar de manera anormal, el dispositivo móvil se reinicia de manera anormal, la calidad de la red es deficiente y el retraso y la fluctuación de la red son grandes. En escenarios tan anormales, ¿cómo garantizar que los datos recopilados no se pierdan?

Al recopilar datos, utilizamos el mecanismo de registro de escritura anticipada (WAL) y lo combinamos con el canal de aceleración de red construido por nosotros mismos para optimizar este problema.

El propósito de introducir el mecanismo de registro de escritura anticipada es garantizar que los datos escritos en el SDK no se pierdan por razones anormales antes de enviarse al servidor. El núcleo de este proceso es almacenar en caché los datos en el disco del dispositivo móvil antes de que los datos se envíen con éxito al servidor y luego eliminar los datos en caché en el disco después de que los datos se envíen con éxito. Si el envío de datos falla debido a una anomalía de la aplicación o al reinicio del dispositivo, porque los datos almacenados en caché todavía están allí, el SDK reanudará el progreso del envío de datos de acuerdo con la información del punto de interrupción registrada. Al mismo tiempo, el mecanismo de registro de escritura anticipada puede garantizar que la escritura y el envío de datos se ejecuten simultáneamente sin bloquearse entre sí;
Antes de que se envíen los datos, el algoritmo lz4 agregará y comprimirá varios datos, lo que puede reducir la cantidad de solicitudes de envío de datos y el consumo de tráfico de transmisión de red. Si la transmisión de datos falla, habrá una estrategia de reintento para garantizar que los datos se puedan enviar con éxito al menos una vez;
Al enviar datos, el SDK admite el acceso al nodo perimetral de aceleración más cercano y transmite datos a través del canal de aceleración de la red interna entre el nodo perimetral y SLS.

Después de estos tres métodos principales de optimización, el tamaño promedio de los paquetes de datos se reduce 2,1 veces, el QPS general aumenta un promedio de 13 veces, la tasa de éxito general de la transmisión de datos alcanza el 99,3 % y el retraso promedio de la red se reduce en un 50%.

Procesamiento de asociación de datos multisistema

Después de resolver los problemas de la conexión en serie y el rendimiento de la recopilación de datos del lado final, también es necesario abordar los problemas del almacenamiento de datos y el análisis de correlación entre múltiples sistemas.

En términos de almacenamiento de datos, almacenamos directamente datos relevantes de manera unificada en función de la capacidad SLS LogHub. Basado en SLS, puede transportar tráfico de nivel PB en promedio diariamente. Este rendimiento puede respaldar la recopilación completa de datos observables en terminales móviles.

Después de resolver el problema del almacenamiento unificado de datos, hay dos problemas principales que deben abordarse.

**La primera pregunta,** ¿Cómo lidiar con la asociación contextual entre datos observables de diferentes sistemas?

De acuerdo con las restricciones del protocolo OTel, podemos manejar la relación de mapeo entre el nodo raíz, el nodo principal y el nodo secundario en función de parent_id y span_id. Primero, al consultar el enlace de datos de seguimiento, todos los datos de seguimiento dentro de un cierto período de tiempo se extraerán del SLS. Luego, de acuerdo con las restricciones del protocolo OTel, se determina el tipo de nodo para cada dato. Debido a que los datos de varios sistemas pueden retrasarse, es posible que algunos datos no lleguen al consultar el enlace de datos de seguimiento. También necesitamos virtualizar el nodo principal que no existe temporalmente para garantizar la precisión del enlace de rastreo. A continuación, es necesario regularizar los nodos, agregar los nodos que pertenecen al mismo parent_id y luego clasificarlos de acuerdo con la hora de inicio de cada nodo y, finalmente, obtener una información de enlace de seguimiento. el sistema puede ser restaurado.

La segunda pregunta es que al realizar el análisis de seguimiento, a menudo necesitamos analizar más a fondo los datos de diferentes dimensiones desde la perspectiva del sistema. Por ejemplo, si desea analizar más a fondo los datos de seguimiento de diferentes dimensiones, como el ID del dispositivo, la versión de la aplicación y las llamadas de servicio, ¿qué debe hacer? Veamos cómo resolver este problema.

Generación de topología de datos multisistema

Cuando analizamos el problema desde la perspectiva general del sistema, la escala de los datos de rastreo requeridos suele ser relativamente grande, y puede haber decenas de millones de datos por minuto, y los requisitos de puntualidad de los datos también son relativamente altos. Los métodos tradicionales de procesamiento de flujo son propensos a cuellos de botella en el rendimiento en este escenario. La solución que adoptamos es convertir el problema de procesamiento de flujo en un problema de procesamiento por lotes y transformar la perspectiva de procesamiento de enlace tradicional en una perspectiva de procesamiento de sistema. Después de la transformación de perspectiva, desde la perspectiva del sistema, el núcleo más importante para resolver este problema es cómo determinar la relación entre dos nodos.

Echemos un vistazo al proceso específico. Para el procesamiento por lotes, utilizamos el marco MapReduce. En primer lugar, en la etapa de procesamiento de la fuente de datos, agregamos datos en función de la capacidad de análisis programado (ScheduledSQL) de SLS y recuperamos datos de la fuente de datos de Trace al minuto. En la etapa Map, agrupe primero los datos de acuerdo con traceID y luego agregue los datos de acuerdo con las dimensiones de spanID y parentID. Luego, calcule los datos estadísticos relevantes, como los datos estadísticos básicos, como la tasa de éxito, la tasa de fallas y el índice de retraso. En el uso comercial real, a menudo se recopilan algunos datos relacionados con atributos comerciales específicos, y esta parte de los datos a menudo varía mucho según el negocio. Para este tipo de datos, se admite la agrupación de resultados por otras dimensiones durante el proceso de agregación. En este punto se obtienen dos productos intermedios:

Los datos agregados que contienen relaciones de dos nodos, a este tipo de información del lado de los datos los llamamos
y datos sin procesar inigualables

Estos dos productos intermedios se volverán a agregar en la etapa Combine, y finalmente se obtendrán los datos de resultados que incluyen indicadores estadísticos básicos y otras dimensiones.

El producto final contendrá varias piezas principales de información:

La información secundaria puede reflejar la relación de llamada.
La información de dependencia puede reflejar las dependencias del servicio.
También hay información de indicadores y otra información de recursos, etc. Entre ellos, los datos relacionados con el atributo empresarial se verán reflejados en la información del recurso.

Con base en estos productos, podemos analizar múltiples dimensiones de recursos, servicios y otra información para calcular la distribución del problema y los vínculos de impacto de las dimensiones correspondientes.

Explorando la causa raíz de los problemas de automatización

A continuación, me gustaría presentarles algunas de nuestras exploraciones en la dirección de localizar la causa raíz de los problemas de automatización.

Sabemos que con la iteración de la versión de la aplicación, cada lanzamiento de la aplicación puede implicar cambios de código para varias empresas. Algunos de estos cambios se han probado por completo y otros no se han probado por completo, o los métodos de prueba convencionales no los han cubierto, lo que puede tener un cierto impacto potencial en los servicios en línea y hacer que algunos servicios no estén disponibles. Cuanto mayor sea la escala de la aplicación, más modelos comerciales, el volumen de datos comerciales correspondiente y mayor será la incertidumbre del enlace de solicitud. Después de que ocurre un problema, a menudo se requiere que varias personas participen en la investigación en todos los dominios, y el costo de operación y mantenimiento humano es relativamente alto.

¿Cómo solucionar y localizar problemas en el lado de la terminal y acelerar la eficiencia de I+D a través de medios técnicos? Hemos realizado una exploración basada en la tecnología de aprendizaje automático.

Nuestro método actual consiste en realizar primero el procesamiento de características en los datos de origen de la traza; luego, realizar un análisis de conglomerados en las características para encontrar la traza anormal; finalmente, en función del algoritmo gráfico, etc., analizar la traza anormal para encontrar el punto de inicio anormal.

Primero, la etapa de procesamiento de características en tiempo real lee los datos de origen de Trace, genera una característica para cada enlace de Trace al encontrar 5 nodos de abajo hacia arriba y codifica la característica. Luego, realice un análisis de agrupamiento jerárquico en las características codificadas a través del algoritmo HDBSCAN. En este momento, las anomalías similares se clasificarán en el mismo grupo y luego se encontrará un rastro anormal típico de cada grupo de rastros anormales. Finalmente, use el algoritmo gráfico para encontrar el punto de inicio de este Trazo anormal, a fin de determinar la posible causa raíz del Trazo anormal actual. De esta forma, se puede procesar cualquier fuente de datos que siga el protocolo estándar de OTel.

Caso: seguimiento de enlace multiterminal

Después de procesar los datos, veamos el efecto final.

Este es un escenario que simula Android, iOS, servidor y seguimiento de enlaces de extremo a extremo.

Usamos la aplicación iOS como remitente del comando y la aplicación Android como el extremo de respuesta del comando para simular la operación de encender el aire acondicionado del automóvil de forma remota. Podemos ver en la figura que después de que se activa la operación de "encender el aire acondicionado del automóvil" en el lado de iOS, ha pasado sucesivamente por los enlaces de "verificación de autoridad del usuario", "envío de instrucciones" y "solicitudes de red de llamadas". ". Después de que el terminal Android recibe la instrucción, ejecuta los pasos de "iniciar el acondicionador de aire de forma remota" y "comprobar el estado" en secuencia. En este gráfico de llamadas, podemos ver que los enlaces de Android, iOS, servidor y multiterminal están conectados en serie. Podemos analizar el enlace de la llamada desde cualquier perspectiva de Android, iOS y servidor. Se puede reflejar el consumo de tiempo de cada operación, el número de solicitudes correspondientes al servicio, la tasa de error y la dependencia del servicio.

Estructura general

A continuación, veamos la arquitectura de toda la solución:

La capa inferior es la fuente de datos, que sigue el protocolo OTel, y los SDK correspondientes a cada extremo se implementan de manera uniforme según la especificación del protocolo;
La capa de almacenamiento de datos se basa directamente en SLS LogHub y los datos recopilados por todos los sistemas se almacenan de manera unificada;
Más arriba está la capa de procesamiento de datos, que preprocesa los indicadores clave, los enlaces de rastreo, las dependencias, la topología y las características.

Finalmente, la aplicación de la capa superior proporciona capacidades de análisis de enlaces, consulta de topología, consulta de indicador, consulta de registro original y ubicación de causa raíz.

Planificación posterior

Finalmente, resuma nuestro plan de seguimiento:

En la capa de adquisición, continuaremos mejorando el soporte de complementos y anotaciones para reducir la intrusión del código comercial y mejorar la eficiencia del acceso.
Por el lado de los datos, se enriquecerán las fuentes de datos observables, y en el futuro se admitirá la recopilación de datos relacionados, como la calidad y el rendimiento de la red.
En el lado de la aplicación, se proporcionarán capacidades tales como monitoreo de acceso de usuarios y análisis de rendimiento.

Finalmente, abriremos nuestras capacidades técnicas básicas y las compartiremos con la comunidad.

SLS: Pensamientos y práctica de la construcción de Trace de enlace completo móvil basado en OTel