Методы мониторинга Golden Signals и RED представляют собой шаблоны для построения мониторинга сервисов и определяют ключевые показатели, необходимые для мониторинга.
Раньше об этих методах знали только администраторы мониторинга или инженеры SRE. Сейчас тема инструментирования приложений уже не является чем-то новым и об этих методах знают более-менее все.
В этом посте я расскажу, как использовать PostgreSQL в мониторинге с использованием методов RED и Golden Signals. Подсистема мониторинга в Postgres была реализована в то время, когда RED и Golden Signals еще не существовало и, по моему скромному мнению, она имеет некоторые недостатки и сразу установка RED или Golden Signals на Postgres может показаться сложной задачей.
В этом посте я попытаюсь кратко рассмотреть возможности, которые предоставляет Postgres для реализации мониторинга с помощью методов RED/Golden Signals, и дам конкретные указания по реализации этого.
Более того, это не так сложно, как вы думаете.
Я знаком с RED и Golden Signals относительно давно, и есть несколько причин, по которым вам следует использовать эти методы:
- мониторинг этими методами позволяет быстро (но при этом поверхностно) определить, все ли в порядке с сервисом.
- Если есть широкий охват других метрик, при изучении проблемы можно пойти глубже в нужном направлении, исключив менее важные.
- они более или менее универсальны и применимы как к веб-сервисам, так и к системным сервисам, не ориентированным на непосредственную работу с пользователем.
- являются хорошим началом для удовлетворения основных потребностей в мониторинге любой службы.
В результате мы получаем базовый минимум (в виде дашборда), который в целом дает достаточное представление о том, хорошо или плохо работает сервис.
Затем вы можете реализовать более подробные или специфичные для сервиса вещи.
Однако у этих методов есть и недостатки, поэтому не стоит думать, что эти методы покроют все возможные потребности в метриках.
Что ж, надеюсь получилось убедительно, перейдем к Постгресу.
Суть RED и Golden Signals заключается в измерении количественных характеристик трафика, проходящего через сервис, на примере RED:
- Скорость запросов — количество запросов в секунду.
- Ошибки запросов — количество ошибочных запросов в секунду.
- Длительность запроса — время, затраченное на выполнение запросов (в идеале гистограмма с распределением количества запросов по времени выполнения).
Хотя оба эти метода были предложены для мониторинга (микро)сервисов HTTP, их также можно использовать для мониторинга других сервисов, ориентированных на запросы, включая СУБД.
Любую СУБД можно представить как сервис, обслуживающий запросы от клиентов (Запросы), запросы могут выполняться как успешно, так и с ошибками (Ошибки), запросы выполняются в течение определенного времени (Продолжительность), доступ к ресурсам осуществляется конкурентно с использованием блокировок.
и доступ может быть ограничен в В результате образуется очередь из людей (Насыщение).
Небольшое отступление.
Прежде чем продолжить, стоит определиться, что будет пониматься под «просьбой».
Обычный SQL-запрос или SQL-транзакция? Отдельный запрос будет считаться SQL-запросом, поскольку приложение оперирует отдельными командами и может организовывать их в транзакции только при необходимости, поэтому 1 запрос = 1 SQL-команда.
Также с точки зрения собственной наблюдаемости приложение может иметь свои RED-метрики и дополнительно предоставлять каждой SQL-команде метаданные о ней (request_id, информацию об отправителе, методе/контроллере и т. д.).
Запросы
Начнем по порядку, R — запросы.Запросы — это активность клиента, нет клиентов — нет запросов.
Для мониторинга активности клиента в Postgres имеется несколько представлений.
Но пока интерес представляет только один из них.
Это отдельное расширение, которое нужно отдельно настроить и включить .
В этом представлении собирается статистика по каждому оператору, и для каждого оператора (запроса) есть поле звонки который показывает, сколько раз был вызван этот конкретный запрос.
Сумма всех вызовов показывает количество обработанных запросов.
Важно отметить, что pg_stat_statements записывает только успешно выполненные запросы.
Однако с pg_stat_statements есть нюанс.
Расширение имеет собственный режим отслеживания — параметр pg_stat_statements.track указывает, как производить подсчет. Параметр имеет 2 значения.
Первое значение" вершина " указывает на подсчет только прямых вызовов запросов.
И второе значение " все " указывает на подсчет вызовов, вложенных в хранимые процедуры и функции.
С точки зрения мониторинга запросов предпочтительно иметь значение " вершина ", поскольку если клиент отправляет запрос на вызов хранимой функции, то все запросы, вложенные в функцию, выполняются на стороне СУБД и не могут считаться отдельными запросами от приложения.
Чтобы получить данные, вам достаточно сделать достаточно простой запрос на pg_stat_statements .
Полученную цифру нужно обернуть в метрику с помощью тех инструментов, которые приняты в конкретной экосистеме мониторинга.SELECT sum(calls) FROM pg_stat_statements;
Например, в случае с Прометеем эту задачу реализует экспортер, в Zabbix это будет Пользовательский параметр .
А еще может прийти в голову идея использовать pg_stat_activity или pg_stat_database .
Давай отбросим эту мысль pg_stat_activity не подходит для подсчета запросов, т.к.
показывает снимки активности в момент обращения, а что происходит между обращениями, остается неизвестным.
Во втором, хотя есть интересные поля типа хакт_коммит, но для нашей задачи он не совсем подходит, т.к.
управляет транзакциями.
Однако мы воспользуемся этой идеей дальше.
Ошибки
Чтобы оценить количество ошибок или, скажем, «запросов, завершившихся с ошибкой», вернемся к ранее упомянутому pg_stat_database .В этом представлении есть поле xact_rollback который является счетчиком отката транзакции.
Откат обычно происходит из-за ошибки запроса внутри транзакции или приложение может явно вызвать откат. Таким образом, всего одной ошибки в транзакции достаточно, чтобы привести к откату всей транзакции.
А теперь важный момент: отдельно выполненная SQL-команда (даже если она явно не обернута в блок BEGIN.END) также считается транзакцией и ошибка при выполнении команды также будет записана в xact_rollback .
Отсюда следует, что поля xact_rollback достаточно для записи ошибок при выполнении запросов.
Опять же, для получения информации не требуются глубокие знания SQL. SELECT sum(xact_rollback) FROM pg_stat_database;
Однако есть небольшой недостаток: такой подход показывает только ошибки, связанные с обработкой запроса.
Но в течение всей работы СУБД могут возникать и другие ошибки, не связанные с обработкой запросов.
Хотя такие ошибки редки, все же важно о них знать.
К сожалению, в Postgres пока нет представления, которое обеспечивало бы удобный интерфейс статистики ошибок и такую информацию можно получить только из логов.
Продолжительность
Для расчета времени выполнения запроса нам снова понадобится pg_stat_statements и конкретно поле общее время .В этом поле отображается время выполнения (включая ожидание) для каждого типа запроса в миллисекундах.
Соответственно, чтобы получить общее время выполнения запроса, нужно добавить общее время все запросы.
SELECT sum(total_time) FROM pg_stat_statements;
Значение будет в миллисекундах, при желании можно умножить, потому что, например, в Прометее принято конвертировать время в секунды.
В идеале, конечно, хотелось бы иметь гистограмму с распределением количества запросов по временным диапазонам, но pg_stat_statements Под капотом осуществляется собственное агрегирование и наружу выходят только агрегаты.
Кроме общее время Есть также мин_время , максимальное_время, среднее_время , stddev_time .
Начиная с 13 версии добавлены новые поля, показывающие время планирования запросов.
Но это вещи, специфичные для администраторов баз данных, возможно, мы поговорим о них как-нибудь в другой раз.
Насыщенность
Последний пункт — насыщенность, которой нет в методе RED, но присутствует в Golden Signals. Напомню, что насыщенность (она же насыщенность) — это ситуация, когда выполнение запроса откладывается в очередь, поэтому в контексте обработки запросов в СУБД нам важно видеть ситуации, когда запросы не обрабатываются.(и ошибок нет).
Немного теории Количество одновременных подключений к базе данных ограничено значением параметра max_connections .
Однако на практике этого предела редко кто достигает; проблемы обычно начинаются раньше.
Для достижения состояния насыщения достаточно выполнить два условия: 1) нужно праздный транзакция 2) нужен более-менее стабильный тпс с запросами на запись внутри.
Если эти два условия выполняются, то проблемная ситуация обычно выглядит так: приложение обновляет строки таблицы в транзакции, оставляет транзакцию открытой (чтобы вернуться к ней позже), но не возвращается.
Конкурентные обновления ставятся в очередь и ждут завершения первой транзакции.
Новые запросы приходят и ставятся в очередь, вытесняя все остальные, пока не будет достигнут лимит max_connections, после чего все новые запросы будут отклонены с ошибкой.
Либо до завершения первой транзакции, либо до принудительного выполнения администратором.
Чтобы обнаружить ситуации, когда запросы откладываются, нам нужно представление pg_stat_activity .
Это не идеальный вариант, но лучшего пока нет, будем использовать то, что есть.
Почему не лучший? До этого момента для получения статистики мы рассматривали счетчики (СЧЕТЧИК), которые накапливают информацию в фоновом режиме.
Счетчики удобны тем, что не «теряют» информацию (сброс счетчика или его переполнение не в счет, такое явление пока редкость).
Если значение счетчика менялось быстро или, наоборот, медленно, это можно увидеть, построив частотный график.
Производительность pg_stat_activity по сути представляет собой набор ДАТЧИКОВ (шкалы) и показывает текущие данные только на момент доступа.
Поэтому неизвестно, что произошло в момент между звонками.
И много чего может случиться — например, при OLTP-нагрузке тысячи запросов/транзакций могут быть выполнены за одну секунду, а при работе с GAUGE мы этого просто не узнаем.
Это существенный недостаток метрик типа GAUGES. Если закрыть глаза на недостатки GAUGE, то в целом минутной детализации при снятии значений нам достаточно для устранения проблем.
И если есть возможность брать значения чаще, то это хорошо.
Итак, нам нужно:
- количество и статус клиентов (активны, простаивают в транзакции, ожидают).
SELECT
Теги: #postgresql #sre #мониторинг #золотые сигналы #admin #красный метод
-
Сервис Notes И Приложение Catch Закрываются
19 Oct, 24 -
Добавление Фотографий Из Panoramio На Карту
19 Oct, 24 -
Intel Ларраби Непрактичен
19 Oct, 24 -
Две Картины С Заказчиком
19 Oct, 24 -
13 Советов Для Самомотивации
19 Oct, 24
