Что мониторим?

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

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

Я не пытаюсь объять всё возможное, но если вы пишите back сервисы, используете rest, вебсокеты, event driven архитектуру и пока не успели обрасти мониторингом, то в этом докладе вы сможете найти много полезного.

Выступление на весенней Стачке 2024
https://ul24.nastachku.ru/%D1%87%D1%82%D0%BE-%D0%BC%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%BC

Transcript

1. Что мониторим? Денис Аникин https://xfenix.ru
2. Технический лидер в >4 командах Обо мне 2 Стек: python + typescript, devops CL python community Выступаю на конференциях Работаю в ПК http://xfenix.ru
3. О чем будет доклад? О том как надежно мониторить сервисы О микросервисах на python О проблемах reliability & resilience О техническом мониторинге (не о бизнес)
4. Поговорим о RED/USE и золотых сигналах 01 4
7. А может? 7
8. RED — Rate (например: RPS) — Errors (например: 500, 501, 502) — Duration (например: latency) 8
9. USE — Utilization (например: загрузка CPU 90%) — Errors (например: 50 ошибок за час) — Saturation (это сложная штука, здесь количество отложенной работы; например: topic lag) 9
10. 4 golden signals — latency — traffic — errors — saturation 10
11. Что с ними не так? 11
12. Много чего — Saturation многие читают по-разному — Их недостаточно — Непонятно как внедрить — Прочтение этих «методологий» сложное, статьи объемные, определения обтекаемые 12
13. Мониторим базовые вещи 02 13
14. — Для виртуалок/реального железа/кубера подходы схожи — Каждый сервер или ноду необходимо мониторить — Одна из лучших связок для вас — это Grafana + Prometheus Начнём с ключевых вещей Стартуем 14
15. Что мониторить на серверах? — CPU каждого сервера — RAM каждого сервера — Загрузку сети — I/O вашего диска — Сколько места на дисках занято — Для этого всего вам поможет https://github.com/prometheus/node_exporter 15
18. Что это было? 18
19. Это была база 19
20. Достаточно ли мне базы? 20
21. Без вопросов, нет — Экспортер поставить было просто, но дальше что делать? — Давайте начнём с RPS — Если у вас HTTP приложение («ручки», «эндпоинты», rest, http api, rpc via http, json-rpc), вы можете начать собирать запросы «со входа» Но дальше сложно 21
22. Что на входе? 22
23. Тут разное бывает 23
24. Какие бывают ингресы? 24
25. Мониторинг RPS — Обычно приготовить несложно — Но: если у нас микросервисы, то графиков получается много, на какие же опираться? И какие важнее? — Но: не всегда просто отличить трафик одного сервиса от другого, если у вас нет четкого гайда именования На ингрессе 25
26. Если нужно собирать из nginx https://github.com/vozlt/nginx-module-vts вам поможет nginx vts модуль 26
27. Ingress контролеры — https://www.getambassador.io/docs/emissary/latest/howtos/prometheus у emissary — у свежего apisix https://apisix.apache.org/docs/apisix/plugins/prometheus/ тоже — https://docs.nginx.com/nginx-ingress-controller/logging-and-monitoring/prometheus/ ingres nginx Почти всегда оснащены экспортерами by default 27
29. Идем с RPS дальше — Возможно, вам понадобится мониторить RPS «изнутри» приложения — Для этого подойдет https://github.com/claws/aioprometheus — Так же вам понадобится использовать https://github.com/prometheus/pushgateway — Не забудьте, что в счетчиках учитывать разные воркеры и хосты 29
30. Latency — Разбиваем на 3 группы: медиана, 95 перцентиль и 99 перцентиль — Можно снимать с ingress/proxy — Желательно в мс — Ориентир адекватного бекенда: ответ меньше, чем за 150мс 30
32. 3 бакета существуют не просто так 32
33. Есть нюанс — https://bravenewgeek.com/everything-you-know-about-latency-is-wrong/ вот по этой ссылке можно почитать почему разбиение на бакеты может давать не очень корректные результаты — вероятно, hdrhistogram будет давать вам более точные и аккуратные результаты, если мы говорим о действительно высоком SLA в девятках — «простой» способ — это бакеты median/p95/p99 и т.п. 33
35. Инфраструктура+ 03 35
36. Реляционные БД — Количество запросов в секунду — Нагрузка на диск — Количество соединений (обязательно) — Топ самых медленных запросов (10, 20): сам запрос + время + количество таких запросов Что мониторить обязательно 36
37. S3 — Количество бакетов — Количество объектов — Трафик — Использование места Что мониторить обязательно 37
39. Redis — Для редиса есть потрясающий https://github.com/oliver006/redis_exporter — Обычно оттуда очень много ценной информации (количество ключей, занятая память, нагрузка, все по red/use заветам) И его NoSQL аналоги 39
41. Сертификаты 41
42. Интеграции — Вы должны мониторить ваши интеграции — Иногда имеет смысл мониторить даже доступность чужих серверов — Приведу пример: у нас есть интеграция, которая помогает получать по каждому клиенту дополнительную информацию. Без неё мы не можем работать. Мы мониторим доступность этого сервера. Его проблемы «валят» нам latency — Приведу пример 2: мы получаем сообщения из телеграма. Мы мониторим статус вебхука из апи телеграма 42
44. Любые другие составляющие — Почти для всего есть в том или ином виде prometheus exporter — Во многие штуки prometheus метрики вообще встроены — Для чего-то вам пригодится https://github.com/prometheus/blackbox_exporter Вашего сервиса 44
45. Более сложные вещи 04 45
46. Event driven architecture 46
47. Главное для мониторинга EDA — Сколько сообщений необработано (например: topic lag) — Сколько подключено потребителей 47
50. Если этого не сделать 50
51. Websocket 51
53. Websocket — Вам необходимо мониторить все промежуточные сервера — Вам нужно мониторить количество открытых сокетов на всех серверах — Вам нужно помнить о том, что ограничение на 1 IP — 65k — Вам нужно мониторить количество открытых файловых дескрипторов — Вам нужно мониторить ulimit soft — Вам необходимо мониторить circuit breaker’ы на всех прокси и ингрессах Постоянные соединения — проблема 53
54. Circuit breaker — это не шутки, не забывайте! 54
55. Серьезно — Ваши потенциальные «враги»: envoy, emissary — По-умолчанию оба несут ограничение в 1024 — Если вы забудите, то постоянным соединениям конец! Circuit breaker’ы 55
56. 56 У вебсокетов есть лицо. Позвольте показать его вам
57. Мониторим бизнес 05 57
58. Наше приложение — Вам нужно понять ключевые показатели, которые влияют на доступность — Например, в одной из команд у нас это количество операторов на линии и количество чатов, разбитых по специальным категориям — Есть еще масса других показателей, но для нас это ключевые. Небольшие отклонения показывают нам очень многое — Ваша задача определить минимум. Вам не нужно делать в техническом мониторинге полноценный бизнес-мониторинг 58
59. Как же выглядит всё это в сборе? 06 59
61. И так более 70 экранов мониторинга 61
62. Алертинг 07 62
63. Опять всё непросто — Алертинг необходим — Определить показатели для него — очень сложно — Сделать его без этой работы — не только невозможно, но и вредно… 63
65. Ошибки 08 65
66. Вам нужно отслеживать ошибки — Просто логов недостаточно — Вам нужна группировка и контекст ошибки — На помощь спешит «тяжеловес» — 66
70. Sentry прекрасен(на?) — Стал платным — Перегружен функциональностью — Очень тяжел — Free версию проблематично затаскивать в кубер Но, есть нюансы… 70
71. Альтернатива? 71
72. Обслуживание 09 72
73. Коротко — В моменты большой нагрузки графана генерирует большой трафик — Прометеус имеет тендецию падать… — Подумайте о thanos 73
75. Некоторые итоги — Строить мониторинг дорого — Хороший мониторинг почти недостижим и всегда будут «но» — Не всем сервисам нужен мониторинг — Но если вам нужен и вы ещё не начинали его делать — теперь вам будет проще это делать 75
76. Спасибо 76 https://xfenix.ru