1｜Введение

DeepFlow использует eBPF для сбора и анализа протоколов приложений, обеспечивая распределенное отслеживание с нулевым вмешательством и сбор индикаторных данных. DeepFlow уже имеет встроенную поддержку анализа более десяти протоколов приложений, и новые продолжают добавляться. Однако мы обнаружили, что ситуация в реальной бизнес-среде будет сложнее: разработчики будут настаивать на возврате HTTP 200 и помещении информации об ошибках в специальную структуру JSON. Часть полезной нагрузки большого количества RPC использует сериализацию Protobuf, Thrift и другие. методы, использующие схему для декодирования, вызов. В потоке обработки возник перекрестный поток, что привело к разрыву ссылки eBPF AutoTracing.

Для этих сложных сценариев DeepFlow реализовал набор механизмов подключаемых модулей WebAssembly с нулевым вмешательством, позволяющих разработчикам настраивать возможности анализа протоколов DeepFlow для своих собственных бизнес-сред. В этой статье будут описаны два случая представления возможностей подключаемого модуля Wasm в DeepFlow.

В то же время каждый может зарегистрироваться для участия в офлайн-мероприятии «Observability Meetup», которое DeepFlow проведет 16 сентября!

02｜Случай — информация об ошибке синтаксического анализа в JSON

В этом примере ответное сообщение отслеживаемого HTTP API имеет формат JSON. При возникновении ошибки API код состояния протокола HTTP по-прежнему может быть 200. Точная информация об ошибке возвращается через такие поля, как OPT_STATUS в JSON:

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

Изучив документацию по API, мы узнали, что если значение OPT_STATUS не равно SUCCESS, это означает, что вызов API не удался. В обычном процессе анализа DeepFlow каждое поле журнала вызовов HTTP будет построено следующим образом:

код_ответа: присваивается коду состояния в заголовке ответа HTTP, например 200, 404, 500 и т. д.
статус_ответа: когда код состояния меньше 400, он считается нормальным, 4XX считается исключением клиента, а 5XX считается исключением сервера.
response_Exception: присвоенное значение представляет собой объяснение на английском языке, соответствующее коду состояния исключения HTTP. Например, если присвоено значение 404, этому полю присваивается значение «Не найдено».
response_result: Если код состояния HTTP является ненормальным, значение присваивается всей полезной нагрузке HTTP.

После установки плагина Wasm мы можем перезаписать следующие поля в журнале неудачных вызовов API на основе приведенного выше анализа, чтобы добиться эффекта правильного отражения бизнес-ошибок:

код_ответа: если OPT_STATUS != SUCCESS в JSON и код состояния HTTP меньше 400, это значение перезаписывается на 500.
статус_ответа: переназначьте значение в соответствии с новым кодом_ответа. Например, если 500, значение назначается как исключение сервера.
response_Exception: перезаписывается значением поля DESCRIPTION, когда OPT_STATUS != SUCCESS в JSON.
response_result: когда response_code больше или равно 400, значение присваивается всей полезной нагрузке JSON.

Код плагина Wasm мы поместили в этот репозиторий GitHub . Вышеупомянутое поведение API фактически описывает службу статистики в DeepFlow Enterprise Edition.Ниже демонстрирует эффект самонаблюдения в службе DeepFlow Enterprise Edition после внедрения этого подключаемого модуля Wasm в DeepFlow Agent. Сначала мы запускаем вызов API для службы статистики в командной строке:

# 请求
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"
}

В приведенном выше ответе API код состояния HTTP — 401 и OPT_STATUS=AUTH_HEADER_ERROR. Мы можем правильно видеть индикаторы исключений клиента на странице DeepFlow (в этом примере плагин внедряется в deepflow-агент кластера Cloud.deepflow K8s):

01-client_error_metrics

На странице журнала вызовов DeepFlow вы можете увидеть подробную информацию о журнале ненормальных вызовов клиента.Все тело JSON помещается в ответ_результат:

02-request_log

Отслеживая этот вызов, мы видим, что причиной является исключение 401, возвращаемое fauths:

03-трассировка

Ниже приведена подробная цепочка вызовов. Первый шаг — инициировать DNS-запрос:

04-днс

Второй шаг вызывает серверную службу для проверки лицензии:

05-лицензия

Третий шаг инициирует DNS-запрос адреса службы fauths:

06-днс

Четвертый шаг вызывает API fauth's/auth для проверки разрешений. При этом вам необходимо получить доступ к Redis для получения информации о пользователе:

07-фаут

08-редис

03｜Дело — извлечь серийный номер и использовать его для распределенного отслеживания.

В базовой торговой системе финансовой отрасли распределенная трассировка обычно реализуется между службами путем передачи серийного номера в RPC. В этом примере мы написали демонстрационный сервис, демонстрирующий простой клиент и сервер gRPC. Мы знаем, что тело сообщения gRPC сериализуется с использованием Protobuf. В этом примере будет показано, как использовать механизм подключаемого модуля DeepFlow Wasm для анализа сообщения Protobuf в этой демонстрации, получения серийного номера и, наконец, реализации распределенной трассировки. Код плагина Wasm можно найти в этом репозитории GitHub .

Сообщение gRPC в этом примере определяется следующим образом:

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

message OrderRequest{
  string business_id = 1235;
}

message OrderResponse{
  string msg = 1235;
}

В подключаемом модуле Wasm мы присваиваем значение поля business_id в полезных данных gRPC значению Trace_id для отслеживания распределенной цепочки вызовов. В то же время исходные поля, такие как business_id и msg, будут храниться в теге Native журнала вызовов, соответствующем атрибуту.business_id и атрибут.msg соответственно, который может использоваться предприятием для просмотра более подробной информации о транзакциях.

Мы развернули gRPC Demo в кластере Sandbox K8s в среде cloud.deepflow.После установки плагина Wasm напрямую отфильтруйте l7_protocol=Custom на странице DeepFlow, чтобы увидеть индикаторы и данные журнала вызовов этого частного протокола:

08-метрики

09-журнал запросов

10-отслеживание

04｜Как использовать Golang SDK для разработки плагинов

Плагины Wasm можно разрабатывать на нескольких языках. В настоящее время DeepFlow предоставляет SDK для Golang. Для разработки можно обратиться к документации . Основные шаги заключаются в следующем:

Создайте новый проект Go и загрузите Golang SDK.

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

Реализовать логику анализа протокола в плагине

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()
}

Скомпилировано как плагин Wasm.

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

05｜Как развертывать плагины в DeepFlow

Загрузите скомпилированный плагин на deepflow-сервер.

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

Измените конфигурацию группы deepflow-agent и добавьте плагины, которые необходимо загрузить.

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 上传插件的名称

Примечание. Агент Deepflow автоматически перезапустится после изменения этой конфигурации.

Проверьте, правильно ли загружен плагин

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

11-проверка

Видим, что журнал предупреждений в основной функции плагина выводится нормально, что свидетельствует об успешной загрузке плагина.

06｜Резюме

Механизм подключаемого модуля DeepFlow Wasm обеспечивает программируемую, безопасную и управляемую рабочую песочницу с потреблением ресурсов, которая является важной частью всего механизма DeepFlow Pipeline. Сценарии его использования включают в себя:

Улучшение встроенных протоколов : извлечение большего количества бизнес-информации на основе возможностей анализа собственных протоколов.
Поддерживает анализ частных протоколов : особенно извлечение бизнес-полей из содержимого полезной нагрузки, основанного на схемах, таких как Protobuf и Thrift.
Распределенная трассировка с нулевым вмешательством : используется для реализации распределенной трассировки путем анализа глобального идентификатора транзакции в вызове.
Индивидуальная десенсибилизация : удаление конфиденциальной бизнес-информации в MySQL, Redis и других протоколах.

В будущем мы также предоставим более мощные возможности программирования на основе плагинов Wasm. Например:

Пользовательская фильтрация : фильтрация журналов вызовов на основе URL-адреса, конечной точки и других полей.
Пользовательская выборка : решите, следует ли выполнять выборку и отбрасывать журналы вызовов, анализируя поля отслеживания, такие как TraceID.

07｜Что такое DeepFlow

Проект с открытым исходным кодом DeepFlow направлен на обеспечение глубокого наблюдения за сложными облачными приложениями. На основе eBPF DeepFlow реализует индикаторы Zero Code и Full Stack, отслеживание и сбор журналов, а также реализует универсальную маркировку и эффективный доступ ко всем данным наблюдений с помощью технологии интеллектуальных меток. Используя DeepFlow, облачные приложения могут автоматически получать глубокую возможность наблюдения, тем самым устраняя тяжелое бремя непрерывного инструментирования для разработчиков и предоставляя командам DevOps/SRE возможности мониторинга и диагностики от кода до инфраструктуры.

Адрес GitHub: https://github.com/deepflowio/deepflow.

Посетите демо-версию DeepFlow , чтобы убедиться в отсутствии инструментов, полном охвате и полноценной наблюдаемости.

Внедрение наблюдения за бизнесом с помощью подключаемого модуля DeepFlow Wasm