Управлять можно только тем, что получается измерить и за чем можно наблюдать. Большой шаг в направлении развития всестороннего мониторинга систем произошел вместе с утверждением единого стандарта 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».