Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Современные сервисы и особенно микро-сервисы требуют обширного мониторинга. Но дело в том, что кроме общих соображений и статей вроде 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

Denis Anikin

April 13, 2024
Tweet

More Decks by Denis Anikin

Other Decks in Programming

Transcript

  1. Технический лидер в >4 командах Обо мне 2 Стек: python

    + typescript, devops CL python community Выступаю на конференциях Работаю в ПК http://xfenix.ru
  2. О чем будет доклад? О том как надежно мониторить сервисы

    О микросервисах на python О проблемах reliability & resilience О техническом мониторинге (не о бизнес)
  3. 5

  4. 6

  5. USE — Utilization (например: загрузка CPU 90%) — Errors (например:

    50 ошибок за час) — Saturation (это сложная штука, здесь количество отложенной работы; например: topic lag) 9
  6. Много чего — Saturation многие читают по-разному — Их недостаточно

    — Непонятно как внедрить — Прочтение этих «методологий» сложное, статьи объемные, определения обтекаемые 12
  7. — Для виртуалок/реального железа/кубера подходы схожи — Каждый сервер или

    ноду необходимо мониторить — Одна из лучших связок для вас — это Grafana + Prometheus Начнём с ключевых вещей Стартуем 14
  8. Что мониторить на серверах? — CPU каждого сервера — RAM

    каждого сервера — Загрузку сети — I/O вашего диска — Сколько места на дисках занято — Для этого всего вам поможет https://github.com/prometheus/node_exporter 15
  9. 16

  10. 17

  11. Без вопросов, нет — Экспортер поставить было просто, но дальше

    что делать? — Давайте начнём с RPS — Если у вас HTTP приложение («ручки», «эндпоинты», rest, http api, rpc via http, json-rpc), вы можете начать собирать запросы «со входа» Но дальше сложно 21
  12. Мониторинг RPS — Обычно приготовить несложно — Но: если у

    нас микросервисы, то графиков получается много, на какие же опираться? И какие важнее? — Но: не всегда просто отличить трафик одного сервиса от другого, если у вас нет четкого гайда именования На ингрессе 25
  13. 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
  14. 28

  15. Идем с RPS дальше — Возможно, вам понадобится мониторить RPS

    «изнутри» приложения — Для этого подойдет https://github.com/claws/aioprometheus — Так же вам понадобится использовать https://github.com/prometheus/pushgateway — Не забудьте, что в счетчиках учитывать разные воркеры и хосты 29
  16. Latency — Разбиваем на 3 группы: медиана, 95 перцентиль и

    99 перцентиль — Можно снимать с ingress/proxy — Желательно в мс — Ориентир адекватного бекенда: ответ меньше, чем за 150мс 30
  17. 31

  18. Есть нюанс — https://bravenewgeek.com/everything-you-know-about-latency-is-wrong/ вот по этой ссылке можно почитать

    почему разбиение на бакеты может давать не очень корректные результаты — вероятно, hdrhistogram будет давать вам более точные и аккуратные результаты, если мы говорим о действительно высоком SLA в девятках — «простой» способ — это бакеты median/p95/p99 и т.п. 33
  19. 34

  20. Реляционные БД — Количество запросов в секунду — Нагрузка на

    диск — Количество соединений (обязательно) — Топ самых медленных запросов (10, 20): сам запрос + время + количество таких запросов Что мониторить обязательно 36
  21. S3 — Количество бакетов — Количество объектов — Трафик —

    Использование места Что мониторить обязательно 37
  22. 38

  23. Redis — Для редиса есть потрясающий https://github.com/oliver006/redis_exporter — Обычно оттуда

    очень много ценной информации (количество ключей, занятая память, нагрузка, все по red/use заветам) И его NoSQL аналоги 39
  24. 40

  25. Интеграции — Вы должны мониторить ваши интеграции — Иногда имеет

    смысл мониторить даже доступность чужих серверов — Приведу пример: у нас есть интеграция, которая помогает получать по каждому клиенту дополнительную информацию. Без неё мы не можем работать. Мы мониторим доступность этого сервера. Его проблемы «валят» нам latency — Приведу пример 2: мы получаем сообщения из телеграма. Мы мониторим статус вебхука из апи телеграма 42
  26. 43

  27. Любые другие составляющие — Почти для всего есть в том

    или ином виде prometheus exporter — Во многие штуки prometheus метрики вообще встроены — Для чего-то вам пригодится https://github.com/prometheus/blackbox_exporter Вашего сервиса 44
  28. 48

  29. 49

  30. 52

  31. Websocket — Вам необходимо мониторить все промежуточные сервера — Вам

    нужно мониторить количество открытых сокетов на всех серверах — Вам нужно помнить о том, что ограничение на 1 IP — 65k — Вам нужно мониторить количество открытых файловых дескрипторов — Вам нужно мониторить ulimit soft — Вам необходимо мониторить circuit breaker’ы на всех прокси и ингрессах Постоянные соединения — проблема 53
  32. Серьезно — Ваши потенциальные «враги»: envoy, emissary — По-умолчанию оба

    несут ограничение в 1024 — Если вы забудите, то постоянным соединениям конец! Circuit breaker’ы 55
  33. Наше приложение — Вам нужно понять ключевые показатели, которые влияют

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

  35. Опять всё непросто — Алертинг необходим — Определить показатели для

    него — очень сложно — Сделать его без этой работы — не только невозможно, но и вредно… 63
  36. 64

  37. Вам нужно отслеживать ошибки — Просто логов недостаточно — Вам

    нужна группировка и контекст ошибки — На помощь спешит «тяжеловес» — 66
  38. 67

  39. 68

  40. 69

  41. Sentry прекрасен(на?) — Стал платным — Перегружен функциональностью — Очень

    тяжел — Free версию проблематично затаскивать в кубер Но, есть нюансы… 70
  42. Коротко — В моменты большой нагрузки графана генерирует большой трафик

    — Прометеус имеет тендецию падать… — Подумайте о thanos 73
  43. 74

  44. Некоторые итоги — Строить мониторинг дорого — Хороший мониторинг почти

    недостижим и всегда будут «но» — Не всем сервисам нужен мониторинг — Но если вам нужен и вы ещё не начинали его делать — теперь вам будет проще это делать 75