Я работаю в качестве SRE в iZettle, и иногда во время дежурства мне бывает сложно понять факторы, способствующие возникновению инцидентов, или природу сбоев, когда они происходят. Для человека, использующего архитектуру микросервисов, нелегко установить в системе какой-то приличный уровень наблюдаемости, чтобы быстро понять, что происходит.

В этой статье я хотел бы поделиться своим опытом о том, как можно улучшить наблюдаемость сервисов с помощью Service Mesh Consul Connect, а позже я объясню свои аргументы в пользу его использования по сравнению с другими альтернативами. Напомню, что сервисная сетка позволяет вам маршрутизировать HTTP-трафик через прокси, которые развернуты как боковые контейнеры для сервиса. Затем эти прокси-серверы могут предоставлять метрики, журналы и трассировки, которые позволяют вам получить полную картину системы, что делает ее более эффективной для быстрой и простой отладки приложений. Consul Connect, кроме того, обеспечивает авторизацию и шифрование между сервисами с использованием взаимного TLS и использует Envoy в качестве плоскости данных для передачи данных. Что касается наблюдаемости, я расскажу об основных показателях уровня 7, журналах доступа и распределенной трассировке с использованием Prometheus, Grafana, AWS CloudWatch Logs и AWS X-Ray.

Весь код для этой демонстрации можно найти в моем репозитории на Github.

Предпосылки

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

Среда Service Mesh

Эта демонстрация предназначена для работы на AWS и использует AWS ECS в качестве предпочтительной оркестровки контейнеров. На следующей диаграмме изображена высокоуровневая архитектура реализации Service Mesh.

Он состоит из следующего:

  • Консульский кластер.
  • Сервисы dashboard и counter, работающие на AWS ECS Fargate. Служба панели мониторинга имеет восходящее соединение со службой счетчика и безопасно взаимодействует с ней для увеличения счетчика.
  • Каждое из Определений задач службы имеет определение контейнера sidecar для прокси-сервера Envoy и агента Consul, который взаимодействует с сервером Consul.
  • Ingress Gateway, управляемый Консулом для внешних сервисов для связи с сервисами внутри сети.

Поскольку Consul является плоскостью управления, он отвечает за настройку каждого из прокси Envoy. Это делается с помощью тех же записей Определения услуг, которые используются для регистрации услуг в Consul. Ниже приведен пример конфигурации:

Здесь поле connect.sidecar_service указывает Consul зарегистрировать прокси-службу со значениями по умолчанию. Подробнее о том, как зарегистрировать сервис коляски, читайте в документации здесь.

Вы также можете определить глобальные настройки по умолчанию для прокси через записи конфигурации proxy-defaults. А если этого недостаточно, это дает вам возможность определять более продвинутые и индивидуальные конфигурации в виде аварийных люков. Полный список опций см. На странице интеграции Envoy здесь.

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

Реализация наблюдаемости

Envoy просто классный! У него есть полный набор опций конфигурации и множество метрик, которыми можно поделиться. Это также компонент, который может предоставить вам обширные журналы доступа и отслеживание HTTP-запросов. Как обсуждалось выше, Consul - это плоскость управления, через которую вы можете настроить Envoy с этими параметрами. В этом разделе я подробно рассмотрю детали реализации того, как это можно сделать.

Метрики HTTP уровня 7

В этой настройке я использовал Prometheus для очистки метрик от всех дополнительных прокси. Установив поле envoy_prometheus_bind_addr в определении службы proxy.config, Envoy можно легко настроить на прослушивание запросов очистки на порту 9102.

Кроме того, Prometheus может автоматически обнаруживать прокси, используя свой механизм Consul service discovery, как показано в примере конфигурации ниже:

Затем эти показатели можно визуализировать в Grafana.

Журналы доступа

Журналы доступа также могут быть настроены в прокси-сервере Envoy с помощью опции Escape-Hatch Override. Эта опция позволяет вам определять настраиваемую конфигурацию слушателя, которая включает ведение журнала доступа, путем установки поля envoy_public_listener_json как части определения proxy.config. Вы также можете определить его как часть записи конфигурации global proxy-defaults, как показано ниже:

С этой конфигурацией (пропуская информацию, относящуюся к трассировке, которая будет рассмотрена в следующем разделе), журналы доступа будут записываться непосредственно в /dev/stdout, автоматически собираться драйвером AWS CloudWatch Logs и помещаться в журналы AWS CloudWatch. Затем вы должны увидеть журналы, подобные приведенным ниже, и, конечно же, вы можете добавить в них дополнительные поля в зависимости от ваших требований:

{
    "method": "GET",
    "request_id": "420e2950-50be-43c3-8d41-9b8e9ac9937b",
    "bytes_sent": "188",
    "origin_path": "/",
    "authority": "dashboard.ingress",
    "x_forward_for": "10.140.21.77",
    "protocol": "HTTP/1.1",
    "upstream_service_time": "10",
    "duration": "10",
    "downstream_remote_addr_without_port": "10.140.21.77",
    "user_agent": "curl/7.61.1",
    "upstream": "127.0.0.1:8080",
    "response_code": "200",
    "bytes_recv": "0",
    "response_flags": "-",
    "start_time": "2020-09-03T11:47:01.662Z"
}

Поле request_id здесь важно, так как с этим полем вы можете соотносить определенные следы запроса, например, в таких инструментах, как AWS X-Ray, и даже в журналах приложений.

Отслеживание HTTP-запросов

Наконец, в Envoy можно настроить отслеживание HTTP-запросов, задав поля envoy_tracing_json и envoy_extra_static_clusters_json в определении службы proxy.config. Первый определяет поставщика трассировки, в моем случае это AWS X-Ray, а второй определяет соответствующую статическую конфигурацию кластера, которая содержит конечную точку AWS X-Ray, чтобы на нее можно было отправлять данные трассировки HTTP-запроса.

Чтобы сохранить сквозную трассировку между всеми сервисами в сервисной сети, самим сервисам требуется код, который извлекает данные трассировки из заголовков запросов при каждом входящем соединении и пересылает их при каждом исходящем соединении. Кроме того, данные трассировки, в частности trace_id и request_id, также должны быть включены в каждое сообщение журнала для прослеживаемости и лучшей отладки. С AWS X-Ray это возможно с помощью SDK для конкретного языка. В случае с Python вы можете добиться этого с помощью aws-xray-sdk. Точно так же есть SDK для Go, Node.js, Java, Ruby и .NET.

Собираем все вместе

Для одного сервиса, работающего в AWS ECS, необходимо как минимум 3 дополнительных контейнера, чтобы он был полностью интегрирован в Consul Service Mesh, это Consul Agent, Envoy Proxy и демон AWS X-Ray. Dockerfile для каждого из них можно найти в связанном репозитории Github выше. Пример списка Определений контейнеров ECS может выглядеть следующим образом:

Для простоты в этой настройке эти контейнеры настроены для работы на AWS ECS Fargate с включенным AWS VPC Task Networking, чтобы все контейнеры получали доступ к одному и тому же локальному хосту и могли взаимодействовать друг с другом через этот интерфейс.

  • Первый контейнер в списке - это образ докера для самой службы приложения. Сервис совершенно не знает Consul или Proxy и предназначен только для собственной бизнес-логики.
  • Второй - это локальный агент Consul, который взаимодействует с Consul Server и отвечает за получение информации о других сервисах в сети, которую нужно передать в Envoy для динамического обнаружения сервисов. Это также дает возможность службам зарегистрироваться в Consul.
  • Третий - это прокси-сервер Envoy, который является плоскостью данных и отвечает за перехват всех входящих и исходящих соединений между службами. В этой настройке контейнер при инициализации получает определение службы Consul и связанную с ней конфигурацию прокси-сервера Consul Connect через переменную consul_service_config_b64, которая закодирована в Base64, и регистрирует ее в Consul через локального агента Consul. Затем он запускает прокси-сервер Envoy.
  • Наконец, нам нужна распределенная трассировка на уровне HTTP и на уровне ведения журнала приложений. Контейнер amazon/aws-xray-daemon sidecar помогает достичь этого, позволяя приложению и прокси-серверу Envoy отправлять ему данные трассировки локально через интерфейс localhost.

Заключение

Если вы все еще читаете это, отлично! Надеюсь, вам понравилось мое пошаговое руководство о том, как можно реализовать настройку Observability с помощью Consul Connect Service Mesh. Это была моя скромная попытка поделиться своим опытом, и я надеюсь, что вы нашли его полезным.

Вы можете спросить, почему Consul Connect? Я думаю, что это действительно отличный продукт от Hashicorp, и его упрощенный дизайн в качестве плоскости управления делает его выигрышным фактором при моем выборе Service Mesh. Это одна из причин, по которой я решил не использовать Istio, в том числе из-за его тесной связи с Kubernetes. AWS AppMesh также является хорошей и простой альтернативой, но на момент написания этой статьи из-за использования Route53 для обнаружения сервисов, что, по моему опыту, привело к отложенному распространению DNS и его ограничению вокруг большего количества настраиваемых конфигураций Envoy. , Я думаю, что Consul Connect может предложить гораздо больше, поэтому я все равно буду внимательно следить за этим и посмотреть, как идут дела.

Что касается AWS CloudWatch Logs, я использовал его в основном для простоты, но в качестве альтернативы можно использовать Splunk, SumoLogic или ELK Stack. С другой стороны, AWS X-Ray - вполне приличный инструмент для трассировки и прост в настройке, но поскольку Consul предоставляет подключаемый механизм для отслеживания поставщиков, можно также использовать Jaeger.

Наконец, я большой поклонник проектирования надежности сайтов, и если вам понравился этот пост, я был бы рад услышать от вас и вашего недавнего опыта внедрения и управления Service Mesh в комментариях ниже. Не стесняйтесь связаться со мной и в LinkedIn. Огромный привет Наталии, Дэви и Кришне за их помощь в редактировании этой статьи.

Полезные ссылки