Implemente la observabilidad empresarial utilizando el complemento DeepFlow Wasm

1｜Introducción

DeepFlow utiliza eBPF para recopilar y analizar protocolos de aplicaciones, logrando un seguimiento distribuido y una recopilación de datos de indicadores sin intrusión. DeepFlow ya cuenta con soporte integrado para el análisis de más de diez protocolos de aplicaciones y aún se están agregando más. Sin embargo, descubrimos que la situación en el entorno empresarial real será más complicada: el desarrollo insistirá en devolver HTTP 200 y colocar la información de error en una estructura JSON personalizada. La parte de carga útil de una gran cantidad de RPC utiliza Protobuf, Thrift y otras serializaciones. métodos que dependen de Schema para decodificar y llamar. Se produjo un hilo cruzado en el flujo de procesamiento, lo que provocó que el enlace de seguimiento automático de eBPF se rompiera.

Para estos escenarios complejos, DeepFlow ha implementado un conjunto de mecanismos de complemento WebAssembly de intrusión cero, lo que permite a los desarrolladores personalizar las capacidades de análisis de protocolos de DeepFlow para sus propios entornos comerciales. Este artículo compartirá dos casos para presentar las capacidades del complemento Wasm en DeepFlow.

Al mismo tiempo, todos pueden registrarse para participar en el evento fuera de línea "Observability Meetup" celebrado por DeepFlow el 16 de septiembre.

02｜Caso: información de error de análisis en JSON

En este ejemplo, el mensaje de respuesta de la API HTTP monitoreada está en formato JSON. Cuando ocurre un error de API, el código de estado del protocolo HTTP aún puede ser 200. La información exacta del error se devuelve a través de campos como OPT_STATUS en JSON:

{
  "OPT_STATUS": "AUTH_HEADER_ERROR",   // 不等于 SUCCESS 时表示调用失败
  "DESCRIPTION": "请传递正确的验证头信息", // 详细错误信息
  ... // 其他返回字段
}

Después de consultar la documentación de la API, aprendimos que cuando el valor de OPT_STATUS no es igual a SUCCESS, significa que la llamada a la API falló. En el proceso de análisis normal de DeepFlow, cada campo del registro de llamadas HTTP se construirá de la siguiente manera:

• código_respuesta: asignado al código de estado en el encabezado de respuesta HTTP, como 200, 404, 500, etc.

• Response_status: cuando el código de estado es inferior a 400, se considera normal, 4XX se considera una excepción del cliente y 5XX se considera una excepción del servidor.

• respuesta_excepción: El valor asignado es la explicación en inglés correspondiente al código de estado de excepción HTTP, por ejemplo, cuando se asigna 404, a este campo se le asigna el valor No encontrado.

• respuesta_resultado: cuando el código de estado HTTP es anormal, el valor se asigna a toda la carga útil HTTP.

Después de instalar el complemento Wasm, podemos sobrescribir los siguientes campos en el registro de llamadas API fallidas según el análisis anterior para lograr el efecto de reflejar correctamente los errores comerciales:

• código_respuesta: cuando OPT_STATUS != SUCCESS en JSON y el código de estado HTTP es inferior a 400, este valor se sobrescribe a 500

• Response_status: reasigna el valor de acuerdo con el nuevo código de respuesta. Por ejemplo, cuando es 500, el valor se asigna como excepción del servidor.

• respuesta_excepción: sobrescrito al valor del campo DESCRIPCIÓN cuando OPT_STATUS! = ÉXITO en JSON

• respuesta_resultado: cuando el código de respuesta es mayor o igual a 400, el valor se asigna a toda la carga útil JSON.

Colocamos el código del complemento Wasm en este repositorio de GitHub . El comportamiento de la API anterior describe en realidad el servicio de estadísticas en DeepFlow Enterprise Edition. A continuación se demuestra el efecto de autoobservación en el servicio DeepFlow Enterprise Edition después de inyectar este complemento Wasm en DeepFlow Agent. Primero, activamos una llamada API para el servicio de estadísticas en la línea de comando:

# 请求
curl https://cloud.deepflow.yunshan.net/api/statistics/v1/stats/querier/DBDescription/ShowDatabases

# HTTP 响应头
HTTP/2 401
date: Tue, 22 Aug 2023 01:44:29 GMT
content-type: application/json
content-length: 152

# HTTP 响应体
{
  "DATA": false,
  "DESCRIPTION": "请传递正确的验证头信息",
  "ERR": null,
  "LEVEL": 0,
  "OPT_STATUS": "AUTH_HEADER_ERROR"
}

En la respuesta API anterior, el código de estado HTTP es 401 y OPT_STATUS=AUTH_HEADER_ERROR. Podemos ver correctamente los indicadores de excepción del cliente en la página de DeepFlow (en este ejemplo, el complemento se inyecta en el agente de flujo profundo del clúster cloud.deepflow K8s):

01-client_error_metrics

En la página de registro de llamadas de DeepFlow, puede ver los detalles del registro de llamadas anormales del cliente. Todo el cuerpo JSON se coloca en respuesta_resultado:

02-request_log

Al rastrear esta llamada, podemos ver que el motivo es la excepción 401 devuelta por fauths:

03-rastreo

La siguiente es la cadena de llamadas detallada. El primer paso es iniciar una solicitud DNS:

04-dns

El segundo paso llama al servicio backend para verificar la licencia:

05-licencia

El tercer paso inicia una solicitud DNS para la dirección del servicio fauths:

06-dns

El cuarto paso llama a la API de fauth/auth para verificar los permisos. En el proceso, debe acceder a Redis para obtener información del usuario:

07-fauth

08-redis

03｜Caso: extraiga el número de serie y utilícelo para el seguimiento distribuido

En el sistema comercial central de la industria financiera, el seguimiento distribuido generalmente se implementa entre servicios pasando un número de serie en RPC. En este ejemplo, escribimos un servicio de demostración que muestra un cliente y un servidor gRPC simples. Sabemos que el cuerpo del mensaje de gRPC se serializa usando Protobuf. Este ejemplo demostrará cómo usar el mecanismo del complemento Wasm de DeepFlow para analizar el mensaje de Protobuf en esta demostración, obtener el número de serie y finalmente implementar el seguimiento distribuido. El código del complemento Wasm se puede encontrar en este repositorio de GitHub .

El mensaje gRPC en este ejemplo se define de la siguiente manera:

service Game{
  rpc Game(OrderRequest) returns (OrderResponse);
}

message OrderRequest{
  string business_id = 1235;
}

message OrderResponse{
  string msg = 1235;
}

En el complemento Wasm, asignamos el valor del campo business_id en la carga útil de gRPC a trace_id para el seguimiento de la cadena de llamadas distribuidas. Al mismo tiempo, los campos originales como business_id y msg se almacenarán en la etiqueta nativa del registro de llamadas, correspondientes a atributo.business_id y atributo.msg respectivamente, que la empresa puede utilizar para ver información de transacciones más detallada.

Implementamos la demostración de gRPC en el clúster Sandbox K8s en el entorno cloud.deepflow. Después de instalar el complemento Wasm, filtre directamente l7_protocol = Custom en la página de DeepFlow para ver los indicadores y los datos del registro de llamadas de este protocolo privado:

08-métricas

09-registro de solicitudes

10 rastreo

04 ｜ Cómo utilizar Golang SDK para desarrollar complementos

Los complementos de Wasm se pueden desarrollar en varios idiomas. Actualmente, DeepFlow proporciona un SDK para Golang. Puede consultar la documentación para el desarrollo . Los pasos principales son los siguientes:

1. Cree un nuevo proyecto go y extraiga el SDK de Golang

go mod init ProjectName && go get github.com/deepflowio/deepflow-wasm-go-sdk

1. Implementar la lógica de análisis de protocolos en el complemento

package main

import (
        "github.com/deepflowio/deepflow-wasm-go-sdk/sdk"
)

func main(){
    sdk.Warn("plugin loaded")
    sdk.SetParser(SomeParser{})
}

type SomeParser struct {
}

func (p SomeParser) HookIn() []sdk.HookBitmap {
        return []sdk.HookBitmap{
                // 一般只需要 hook 协议解析
                sdk.HOOK_POINT_PAYLOAD_PARSE,
        }
}

func (p dnsParser) OnHttpReq(ctx *sdk.HttpReqCtx) sdk.HttpAction {
        return sdk.ActionNext()
}

func (p dnsParser) OnHttpResp(ctx *sdk.HttpRespCtx) sdk.HttpAction {
        return sdk.ActionNext()
}

func (p dnsParser) OnCheckPayload(ctx *sdk.ParseCtx) (uint8, string) {
    // 这里是协议判断的逻辑， 返回 0 表示失败
    // return 0, ""
    return 1, "some protocol"
}

func (p dnsParser) OnParsePayload(ctx *sdk.ParseCtx) sdk.ParseAction {
    // 这里是解析协议的逻辑
    if ctx.L4 != sdk.TCP|| ctx.L7 != 1{
                return sdk.ActionNext()
    }
    return sdk.ActionNext()
}

1. Compilado como complemento de Wasm

tinygo  build -o wasm.wasm  -target wasi  -panic=trap -scheduler=none -no-debug *.go 

05｜Cómo implementar complementos en DeepFlow

1. Cargue el complemento compilado en el servidor deepflow

deepflow-ctl plugin create  --type wasm --image wasm.wasm --name wasm-demo-1

1. Modifique la configuración del grupo de deepflow-agent y agregue los complementos que deben cargarse.

static_config:
  ebpf:
    # 对于 deepflow-agent 原生不支持的协议， eBPF 数据需要添加端口白名单才能上报
    kprobe-whitelist:
      port-list: 9999

  # 如果配置了 l7-protocol-enabled，别忘了放行 Custom 类型的协议
  l7-protocol-enabled:
  - Custom
  # other protocol

  wasm-plugins:
    - wasm-demo-1 // 对应 deepflow-ctl 上传插件的名称

Nota: Deepflow-agent se reiniciará automáticamente después de modificar esta configuración.

1. Compruebe si el complemento está cargado correctamente

kubectl -n deepflow logs -f deepflow-agent-xxxxx | grep -i plugin

11-cheque

Vemos que el registro de advertencia en la función principal del complemento se genera normalmente, lo que indica que el complemento se cargó correctamente.

06｜Resumen

El mecanismo de complemento DeepFlow Wasm proporciona un consumo de recursos programable, seguro y controlable en ejecución de sandbox, que es una parte importante de todo el mecanismo de DeepFlow Pipeline. Sus escenarios de uso incluyen:

• Mejore los protocolos admitidos de forma nativa : extraiga más información empresarial basada en las capacidades de análisis de los protocolos nativos.

• Admite el análisis de protocolos privados : especialmente la extracción de campos comerciales del contenido de carga útil que se basa en esquemas como Protobuf y Thrift.

• Seguimiento distribuido sin intrusión : se utiliza para implementar el seguimiento distribuido analizando el ID global de la transacción en la llamada.

• Desensibilización personalizada : borre información confidencial empresarial en MySQL, Redis y otros protocolos

En el futuro, también proporcionaremos una programabilidad más potente basada en complementos de Wasm. Por ejemplo:

• Filtrado personalizado : filtre los registros de llamadas según la URL, el punto final y otros campos

• Muestreo personalizado : decida si desea muestrear y descartar registros de llamadas analizando campos de seguimiento como TraceID.

07｜¿Qué es DeepFlow?

El proyecto de código abierto DeepFlow tiene como objetivo proporcionar una observabilidad profunda para aplicaciones complejas nativas de la nube. Basado en eBPF, DeepFlow implementa indicadores, seguimiento y recopilación de registros de código cero y pila completa, y realiza un etiquetado universal y un acceso eficiente a todos los datos de observación a través de tecnología de etiquetas inteligentes. Al utilizar DeepFlow, las aplicaciones nativas de la nube pueden tener automáticamente una observabilidad profunda, eliminando así la pesada carga de la instrumentación continua para los desarrolladores y brindando a los equipos de DevOps/SRE capacidades de monitoreo y diagnóstico desde el código hasta la infraestructura.

Dirección de GitHub: https://github.com/deepflowio/deepflow

Visite la demostración de DeepFlow para experimentar cero instrumentación, cobertura total y observabilidad totalmente relevante.

El autor del marco de código abierto NanUI pasó a vender acero y el proyecto fue suspendido. La primera lista gratuita en la App Store de Apple es el software pornográfico TypeScript. Acaba de hacerse popular, ¿por qué los grandes empiezan a abandonarlo? Lista de octubre de TIOBE: Java tiene la mayor caída, C# se acerca Java Rust 1.73.0 lanzado Un hombre fue alentado por su novia AI a asesinar a la Reina de Inglaterra y fue sentenciado a nueve años de prisión Qt 6.6 publicado oficialmente Reuters: RISC-V La tecnología se convierte en la clave de la guerra tecnológica entre China y Estados Unidos. Nuevo campo de batalla RISC-V: no controlado por ninguna empresa o país, Lenovo planea lanzar una PC con Android.

{{o.nombre}}

{{m.nombre}}