Как стать автором
Обновить
602.83
OTUS
Цифровые навыки от ведущих экспертов

Генерация тестов на основе трассировки для высоконагруженных систем

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров2.1K

Управлять можно только тем, что получается измерить и за чем можно наблюдать. Большой шаг в направлении развития всестороннего мониторинга систем произошел вместе с утверждением единого стандарта OpenTelemetry, который объединил единым протоколом отправку операционных метрик, протоколов работы сервисов, а также возможность распределенной трассировки сервисов. Но недостаточно только собрать данные, нужно сделать их обобщение и автоматизировать проверку отклонение от ранее полученных трассировок для обнаружения аномалий. В этом может помочь инструмент Tracetest и в этой статье мы разберемся как его можно использовать для диагностики отклонений в высоконагруженной системе.

В качестве основы приложения мы возьмем официальную демонстрацию от OpenTelemetry, которая представляет собой микросервисное приложение интернет-магазина, которое дополнено инструментами для визуализации операционных метрик (Prometheus + Grafana), просмотра временных отрезков трассировки распределенной системы (Jaeger), а также инструменты для имитации нагрузки (сервис load-generator). Начнем с развертывания приложения:

git clone https://github.com/open-telemetry/opentelemetry-demo
docker compose up -d

После запуска всего стека подключимся к главной странице магазина по адресу http://localhost:8080и добавим несколько товаров в корзину и перейдем к покупке. Теперь мы можем посмотреть данные трассировок http://localhost:32786 , выбрать соответствующий сервис (например, cartservice) и увидеть зарегистрированные замеры обработки запроса микросервисами (спаны). Эти данные будут использоваться для настройки мониторинга Tracetest.

Установим сервер Tracetest:

curl -L https://raw.githubusercontent.com/kubeshop/tracetest/main/install-cli.sh | bash -s
tracetest server install

Для первой установки сделаем развертывание в Docker Compose и установим TraceTest вместе с OpenTelemetry Collector и тестовое приложение, в дальнейшем подключимся к телеметрии от OpenTelemetry Demo.

После установки запустим интерфейс tracetest и приложение (включает в себя кэш на redis, RabbitMQ, демонстрационное приложение с REST/gRPC с базой данных PostgreSQL, рабочий процесс для обработки заданий из RabbitMQ и OpenTelemetry Collector). Tracetest публикуется на порт 11633.

docker compose -f tracetest/docker-compose.yaml up -d

Для выполнения тестов будет использоваться периодический опрос HTTP/gRPC адресов сервиса с дальнейшим извлечением данных через OpenTelemetry и обнаружением аномалий как во времени полного ответа, так и на отдельных этапах обработки. Подключимся через браузер к http://localhost:11633. Создадим тест Create -> Create New Test.

Тест может быть создан для HTTP/gRPC-адресов, а также на основе существующего TraceID для Jaeger или любого инструмента, который может возвращать данные в формате OpenTelemetry. Запрос может также создавать из Postman-коллекции. В параметрах запроса можно указывать протокол, метод, адрес точки подключения, аутентификацию, заголовки, тело запроса (для POST/PUT). После выполнения теста собирается информация о результате (код ответа, время ответа), визуализация результатов трассировки (вкладка Trace), а также предоставляется возможность создавать автоматические тесты (вкладка Test).

Пример трассировки
Пример трассировки

Теперь перейдем во вкладку Test и создадим пустой тест. Для теста нужно определить спецификацию используемых спанов трассировки (например, можно выбрать спаны, относящиеся к конкретному сервису span[service.name contains "api"] или определенного span[service.type="http"]), использовать модификаторы выбора первого, последнего и произвольного элемента из обнаруженных (нумерация идет в хронологическом порядке от времени начала выполнения спана). Подробнее про селекторы можно посмотреть в документации. При создании теста описывается набор утверждений для сравнения значения атрибутов (например, кода ответа http-сервера attr:http.status_code). Так, например, для проверки что все http-сервисы возвращают код 200 можно использовать селектор для спанов span[tracetest.span.type="http"] и утверждение attr.http.status_code=200

Наиболее важным является возможность проверки продолжительности спана для определенных типов сервисов, например можно проверить, что все запросы к базам данных выполняются за время <50 мс (селектор span[tracetest.span.type="database"], утверждение attr:tracetest.span.duration<50ms).

После создания или выбора спецификации теста можно запустить тест (Run Test). В качестве источника данных Tracetest может использовать как OpenTelemetry (настроено по умолчанию для подключения к http://tracetest:21321), но также можно подключить в качестве источников данных Jaeger, Grafana Tempo, OpenSearch, Elastic APM, SignalFX. Настройка может выполняться как через веб-интерфейс, так и в консольном инструменте tracetest

  • tracetest completion [bash|fish|powershell|zsh] - создает сценарий для настройки автодополнения для соответствующей оболочки

  • tracetest configure - настройка подключения к серверу tracetest

  • tracetest environment - конфигурация окружения для выполнения тестов

  • tracetest test- управление существующими тестами (просмотр списка - list, export -o <file> --id <id> экспорт описания теста в файл, run -d <file>запуск теста из файла yaml (возвращает ненулевой код, если не выполнились assertions.

Описание теста включает в себя конфигурацию проверяемой точки подключения и спецификации проверок, например:

type: Test
spec:
  id: _8WwyfEVg
  name: Pokeshop - List
  description: Get a Pokemon
  trigger:
    type: http
    httpRequest:
      url: http://demo-api:8081/pokemon?take=20&skip=0
      method: GET
      headers:
      - key: Content-Type
        value: application/json
  specs:
  - name: 'All HTTP Spans: Status  code is 200'
    selector: span[tracetest.span.type="http"]
    assertions:
    - attr:http.status_code = 200

Теперь добавим поддержку Tracetest к демонстрации OpenTelemetry. OpenTelemetry Collector сам подключается к адресу для извлечения данных и поэтому либо Tracetest должен находиться в той же сети (например, можно добавить в тот же Docker Compose) или быть доступным через внешний адрес. Заменим файл по умолчанию (opentelemetry-demo/src/otelcollector/otelcol-config.yaml) на следующий:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
    timeout: 100ms

exporters:
  logging:
    loglevel: debug
  otlp/1:
    endpoint: tracetest:21321
    tls:
      insecure: true

service:
  pipelines:
    traces/1:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/1]

И добавим запуск стека Tracetest (вместе с его базой данных) в docker-compose.yaml от OpenTelemetry Demo и заменим точки подключения в tracetest-provision.yaml на соответствующие:

type: Demo
spec:
  name: telemetrydemo
  type: telemetrydemo
  enabled: true
  telemetrydemo:
    httpEndpoint: http://frontend:8080

Еще проще обеспечить настройку tracetest при установке в Kubernetes, поскольку там будет достаточно указать в качестве точки экспорта для OpenTelemetry Collector tracetest.default.svc.cluster.local:21321. Также нужно будет использовать соответствующий адрес API внутри CI/CD или инструментов для запуска тестов, поскольку консольная утилита должна подключаться к реестру tracetest для извлечения конфигурации и накопления результатов тестов.

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


Каждый инженер слышал о масштабировании. А вот вопрос, известный уже не каждому — сколько измерений масштабирования принято рассматривать? В 2007 году авторы книги «The Art of Scalability» ввели термин «The Scale Cube» и три измерения масштабирования.

Рекомендую всем желающим посетить открытый урок, на котором участники рассмотрят Scale Cube на примерах и поговорят о двух видах шардирования — горизонтальном и вертикальном. А также познакомятся с примерами СУБД, которые поддерживают те или иные виды шардирования. Записаться на урок можно на странице онлайн‑курса «Highload Architect».

Теги:
Хабы:
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
Всего голосов 9: ↑9 и ↓0+9
Комментарии0

Публикации

Информация

Сайт
otus.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
OTUS