В случае услуг, ориентированных на клиента, проверка доступности ресурса/услуги имеет жизненно важное значение для обеспечения максимально удобного взаимодействия с клиентом. В GCP стандартным способом для этого является проверка времени безотказной работы.

Начиная с октября 2022 года GCP повысила цены на свои проверки работоспособности, и с необходимой частотой для обеспечения высокой доступности они стали очень дорогими. В итоге у вас остается четыре варианта:

  1. Планируйте дополнительные расходы
  2. Уменьшите частоту проверок работоспособности
  3. Уменьшите количество проверок работоспособности
  4. Ищите альтернативные способы мониторинга ваших услуг

Уменьшение частоты проверок работоспособности увеличивает время до обнаружения простоя службы. При уменьшении количества проверок работоспособности критически важные компоненты могут быть упущены. С бюджетными ограничениями для большинства команд и компаний единственным возможным решением является создание собственных проверок времени безотказной работы за небольшую часть цены.

Как создать свои собственные проверки работоспособности

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

Прежде чем начать, краткий список знаний/навыков, которые вам понадобятся:

  • Среднее знание terraform и как создавать модули
  • Расширенные знания о вашей инфраструктуре, вам нужно будет знать, как подключиться ко всем ресурсам, которые вы хотите контролировать извне.
  • Язык программирования, который вам удобен и с помощью которого можно развернуть облачную функцию.

Итак, без лишних слов, давайте приступим к делу.

Если вы переносите существующие проверки работоспособности GCP, вы уже знаете, какие службы вы хотите отслеживать, и связанные с ними конечные точки REST. Если вы начинаете с нуля, вы должны сначала определить конечные точки и убедиться, что они доступны извне безопасным образом.

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

Когда дело доходит до самой облачной функции, у вас есть выбор. В Gen1 облачная функция больше подходит для маршрутизации различных запросов к службам. Если вы знакомы с облачными функциями Gen2, вы можете создать отдельный образ Docker с выделенными конечными точками для проверки доступности службы. В обоих случаях облачная функция должна записывать в журнал сообщение о том, был ли запрос к службе успешным или нет. В идеале у вас должна быть схема, позволяющая легко идентифицировать эти сообщения. В python сообщение может выглядеть примерно так:

def custom_uptime_check(_: Request) -> Tuple[str, int]:
    # Send a request to your endpoints
    log.info("UPTIME_CHECK: {service_name} successful"
    return "Success", 200

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

  1. Экземпляр облачного планировщика, который запускает облачную функцию с определенной службой в качестве цели. Обязательно отправьте запрос балансировщику нагрузки облачной функции, а не напрямую облачной функции.
  2. метрика на основе журнала, которая фильтрует ваши журналы, чтобы найти предоставленную схему (UPTIME_CHECK: {service_name}).
  3. Политика предупреждений для метрики на основе журнала, чтобы отправить вам предупреждение о превышении порогового значения или об отсутствии метрики.

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

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

Краткое содержание

Подводя итог, в этой статье мы рассмотрели ресурсы, которые необходимы для создания собственных проверок работоспособности. Сначала вам нужно определить, какие конечные точки вы хотите отслеживать, и как обеспечить их доступность. Затем вы можете создать облачную функцию, обрабатывающую все детали запросов. Наконец, вы предоставляете задания облачного планировщика, метрику на основе журнала и политику оповещения для каждой службы, которую вы хотите отслеживать.

Спасибо за чтение и следите за новостями