В случае услуг, ориентированных на клиента, проверка доступности ресурса/услуги имеет жизненно важное значение для обеспечения максимально удобного взаимодействия с клиентом. В GCP стандартным способом для этого является проверка времени безотказной работы.
Начиная с октября 2022 года GCP повысила цены на свои проверки работоспособности, и с необходимой частотой для обеспечения высокой доступности они стали очень дорогими. В итоге у вас остается четыре варианта:
- Планируйте дополнительные расходы
- Уменьшите частоту проверок работоспособности
- Уменьшите количество проверок работоспособности
- Ищите альтернативные способы мониторинга ваших услуг
Уменьшение частоты проверок работоспособности увеличивает время до обнаружения простоя службы. При уменьшении количества проверок работоспособности критически важные компоненты могут быть упущены. С бюджетными ограничениями для большинства команд и компаний единственным возможным решением является создание собственных проверок времени безотказной работы за небольшую часть цены.
Как создать свои собственные проверки работоспособности
Поскольку каждая настройка инфраструктуры выглядит по-разному, предоставить подробные инструкции по их настройке невозможно. Однако я могу предоставить вам основные шаги и потенциальные ловушки, с которыми вы можете столкнуться при их реализации.
Прежде чем начать, краткий список знаний/навыков, которые вам понадобятся:
- Среднее знание 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 дополнительных ресурса для каждой проверки работоспособности.
- Экземпляр облачного планировщика, который запускает облачную функцию с определенной службой в качестве цели. Обязательно отправьте запрос балансировщику нагрузки облачной функции, а не напрямую облачной функции.
- метрика на основе журнала, которая фильтрует ваши журналы, чтобы найти предоставленную схему (UPTIME_CHECK: {service_name}).
- Политика предупреждений для метрики на основе журнала, чтобы отправить вам предупреждение о превышении порогового значения или об отсутствии метрики.
В идеале вы создаете свой собственный модуль terraform для создания экземпляров облачного планировщика, метрик на основе журналов и политик оповещения.
Если вы хотите проверить, работают ли запросы из разных регионов, вы можете определить больше экземпляров облачного планировщика в разных регионах для каждой службы.
Краткое содержание
Подводя итог, в этой статье мы рассмотрели ресурсы, которые необходимы для создания собственных проверок работоспособности. Сначала вам нужно определить, какие конечные точки вы хотите отслеживать, и как обеспечить их доступность. Затем вы можете создать облачную функцию, обрабатывающую все детали запросов. Наконец, вы предоставляете задания облачного планировщика, метрику на основе журнала и политику оповещения для каждой службы, которую вы хотите отслеживать.
Спасибо за чтение и следите за новостями