Monitoring driven эксплуатация / Николай Сивко (HeadHunter)

1. Monitoring- driven эксплуатация Николай Сивко

2. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент

4. Требования бизнеса • Сайт должен работать • Есть ответственный за работоспособность сайта • Сайт должен работать быстро (говорят, это влияет на разные важные коверсии :) • Минимальные операционные и капитальные затраты

5. Сайт работает (было) • Раз в минуту проходят основные пользовательские сценарии • Время ответа укладывается в нужные рамки

6. Сайт работает (сейчас) • количество ошибок < 20/s • 95-я персентить времени ответа < 4s (на самом деле обычно ~500ms) • внешние чеки на случай проблем с каналами

7. Сайт работает (хотим) • количество ошибок < 20/s • 95-я персентить времени ответа < 4s • количество запросов не упало • пользовательская активность на нужном уровне (в нашем случае: активность по резюме, вакансиям, откликам)

8. Кто отвечает за аптайм • На практике: админы И разработчики • На инциденты всегда реагируют админы

10. Попытка #1 • Нужно, чтобы админы просыпались по SMS, чинили сайт, если не могут починить, будили кого-то из девелоперов и чинили вместе • Выходит, что KPI админов - это время реакции на инцидент!

11. Попытка #1 “Время простоя за квартал 5 часов, максимальные время реакции 2 минуты, мы молодцы, сделали всё, что можем, хотим премию!”

12. Попытка #2 • Админы должны отвечать за аптайм • Но приложение сайта для админов black box • Мы вложимся в QA, все проблемы включая производительность будем ловить на стендах (утопия) • Человек должен отвечать только за то, на что может влиять!

13. Попытка #3 • Давайте поделим аптайм на зоны ответственности • Админы будут отвечать только за свое • Что делать со всем остальным решим потом

14. Формализуем • любой выход за пределы SLA - считаем , что сайт лежит (даже если что-то работает) • на любой инцидент реагируют админы (дежурные или все сразу) • по каждому инциденту обязательный разбор, поиск причины, классификация • считаем суммарный downtime • делим по зонам ответственности

15. Классы проблем • Проблема с релизом (взорвалось или были ошибки при деплое) • Ошибка в приложении (утекло, тяжелый запрос убил базу, не отработал таймаут до удаленного сервиса, итд) • Железо + сеть + каналы + ДЦ • Ошибка админа • Проблемы с БД • Плановый downtime (иногда нужно) • Ошибка мониторинга (чтобы не удалять инциденты никогда)

16. Зона ответственности СЭ • Проблема с релизом • Ошибка в приложении • Железо + сеть + каналы + ДЦ • Ошибка админа • Проблемы с БД • Плановый downtime • Ошибка мониторинга

17. Премия = f(аптайм) Простой за квартал Аптайм, % % оклада в премию <= 12 минут >= 99.99 120 <= 40 минут >= 99.97 100 <= 1 часа >= 99.95 80 <= 2 часов >= 99.90 60 <= 3 часов >= 99.85 50 > 3 часов < 99.85 0

19. Первый квартал c KPI • Оказывается, нужно работать :) • Надо привыкать думать над каждым действием • Многие операции перевели в разряд “рискованных”, их выполнять стали в часы минимальной нагрузки, объявляя плановый downtime • Начали проводить учения, тестировать сценарии деградации системы (выключать rabbitmq, memcached, свои сервисы, без которых все должно жить)

20. Первый квартал c KPI • Мониторинг начал ловить очень много всего нового • Logrotate, разные cron’ы давали 500ки, на которые раньше не реагировали • Начали вдумчиво настраивать таймауты, ретраи итд • Где-то пересмотрели архитектуру и запланировали переделку • Самое сложное: выяснять причины ВСЕХ инцидентов • Перестал устраивать существующий мониторинг

22. Требования • Узнать, что есть проблема • Видеть, что происходит: насколько проблема масштабна, какие компоненты затронуты • Иметь достаточно метрик, чтобы копаться “задним числом” • Ускорять выявление проблем, все важное из логов вынести на графики • Простота расширения

23. Что у нас было • Nagios + centreon (+ патчи) • Nagios + своя штука для графиков + свой poller SNMP • У разработчиков всегда были свои cacti, graphite итд • Свое решение - monik (был выделенный разработчик мониторинга)

24. Проблемы • У нас нет цели разрабатывать мониторинг • Зато есть много другой работы • Всё, что мы разрабатывали устаревает, появляются новые требования • Взять и попробовать что-то новое – тоже время • В opensource практически нет full-stack решений, есть отдельно хранилища, собиралки, алертилки, дашбордилки • Практически всё нужно доделывать под себя

25. SaaS мониторинг • Не нужно писать код • У нас нет супер-секретных метрик • Специализированная компания: они могут себе позволить тесты, мониторинг мониторинга, отказоустойчивость (у нас всегда мониторинг жил на 1 сервере) • Мы “большой” клиент, можем договориться о доработках под нас • Ценник сравним с выделенным разработчиком у нас • Мы работаем с okmeter.io

27. Проблемы • Как правило мониторингом покрывают только самые критичные подсистемы • Мы пробовали включать покрытие мониторингом в процедуру выпуска новых сервисов – не работает • Часто снимают не всё (где-то забыли включить jmx, где- то пустить мониторинг в postgresql) • Инфраструктура меняется: запускаются новые jvm, pg, nginx, haproxy итд • Метрики сильно обобщены, видно, что есть проблема, но не видно, где конкретно

28. Подход • Все что можно снять без конфига, снимаем всегда и со всех машин • Если агенту нужны права или донастройка, это алерт в мониторинге • Метрики максимально детальные в пределах разумного, агрегаты можно сделать на лету • Ждем: алерт, если поймали TCP соединения с хостов, на котором не стоит агент

29. Общие метрики • cpu, memory, swap, swap i/o • net: bandwidth, pps, errors • disk: usage, inodes usage, i/o read/write ops/bytes/time(%) • time offset относительно эталона (+хотим проверять таймзону) • состояния raid (array/BBU)

30. Про каждый процесс • CPU time (user/system) • Memory (RSS) • Disk I/O (read/write bytes, ops) • Swap Usage -> Swap Rate • Thread count • Open FDs count • Open files limit

31. Про каждый TCP LISTEN • Если remote IP из той же сети – все метрики для каждого IP отдельно • Количество соединений в разных состояниях (ESTABLISHED, TIME_WAIT, …) • 95я персентиль TCP RTT (с учетом SACK не является реальным RTT в сети, но для сравнения было-стало работает хорошо) • Количество соединений в backlog и лимит • Похожие метрики для исходящих TCP соединений

32. Nginx • Если есть работающий процесс nginx, находится и парсится конфиг • Парсится log_format и access_log • Если лог нельзя распарсить – алерт • Если в логе нет $request_time, $upstream_response_time - алерт • RPS в разрезе status, top urls, cache_status, method • Персентили и гистограммы для таймингов в тех же разрезах

33. Jvm • Если есть работающий процесс jvm, парсятся аргументы запуска • Определяем параметры JMX, если выключено – алерт • Снимаем heap, GC, memory pools, threads • Если есть mbeans cassandra – снимаем детальные метрики • Так же планируем снимать метрики jetty, grizzly, c3p0, hibernate,…

34. Postgresql • Пробуем с predefined паролем • Если не пускает - алерт с просьбой настроить пароль или загрантить • Если не настроено pg_stat_statements - алерт с просьбой включить • Если не хватает прав – алерт • Снимаем всё про top запросов/таблиц/индексов, bgwriter, текущие соединения, локи итд (pg_stat_*)

35. Метрики из логов plugin: logparser config: file: /var/log/hhapi/hhapi.log #2015-02-17 00:07:44,604 INFO User-Agent: HH-Live/41 (iPhone; iOS 8.1.3; Scale/2.00) regex: '(?P<dt>d{4}-d{2}-d{2} d{2}:d{2}:d{2}),d+ [^:]+ User-Agent: HH- Live/(?P<build>d+) ((?P<device>[A-Za-z]+); (?P<os>[^;]+)' time_field: dt time_field_format: 2006-01-02 15:04:05

36. Метрики из логов metrics: - type: rate name: api.nativeapps.rate labels: build: =build device: =device os: =os

37. Метрики из логов

38. Метрики из SQL plugin: postgresql_query config: … query: SELECT count(*) as value, COALESCE(old_value, 'NULL') as old_status, new_value new_status from resume_field_change_history where change_date >= now() - INTERVAL '60 seconds' and change_date < now() and field_name='status' group by old_value, new_value metric_name: resume.changes.count

39. Метрики из SQL

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

42. Принципы • Critical событие – это то, на что нужно срочно среагировать и починить (CPU usage > 90% не нужно срочно чинить) • У нас 3 critical триггера (HTTP-5xx, Q95, ext http check) • Все остальные Warning, Info – всего лишь подсказки, у большинства нет нотификаций вообще • Лучше зажечь много warning-ов и выбрать глазами причину проблемы, чем пытаться автоматически определить, где причина, а где следствие

43. Принципы • Чтобы после SMS не ждать recovery, а сразу чинить - есть отложенная нотификация (notify after 2 min) • Идеально - увидеть проблему в списке алертов • Если нет, нужно смотреть на дашборды, где нужно глазами исключать возможные причины • В следующий раз такая же проблема должна быть в списке алертов

44. Принципы • Если есть алерт, который вы не собираетесь чинить - выключайте • Если есть постоянный поток писем от мониторинга, он заруливается в отдельную папку в почте и не читается, проще выключить • Если вас не интересует CPU usage на hadoop машине – настройте исключение

45. Наши триггеры • Про все внутренние сервисы – warning по http-5xx+499, q95 • Про все процессы: open files usage > 90% • Про все LISTEN сокеты: TCP ack backlog usage > 90% • Про диски: usage > 95%, IO usage > 99% в течении 10 минут • Про raid: status, bbu, operations (если идет проверка mdraid может просесть i/o, если на железке идет профилактика батарейки – может отключиться write cache)

46. Наши триггеры • Живы все nginx, haproxy, … – там где они были хоть раз запущены (если загорается лишний – закрываем руками) • Давно нет данных от агента на каком-то сервере • Нет данных от JVM/pg/…. • Jvm heap usage > 99% на протяжении 2 минут (ловим OOM, не везде настроена автоперезапускалка) • Time offset > 10 seconds • В важных очередях > N сообщений

48. Сайт лёг - инцидент • SMS/еmail уведомление • Мониторинг создает задачу в JIRA (начало инцидента) • Админ реагирует, подтверждает это переводом задачи в статус “Проблемой занимаются” (любой сотрудник в компании это видит)

49. Чиним • Смотрим текущие алерты • Синхронизируемся в чате • Основной график – “Светофор” + рядом ~10 графиков

50. Конкретный сервис

51. Или база

52. После восстановления • Починили, мониторинг меняет статус задачи на “Инцидент исчерпан” • Поиск причины, общение в JIRA • Заполняем класс проблемы в задаче, перевод в статус “Закрыто” • Если по результатам нужна разработка, есть продолжение workflow

53. Разобрались

54. По результатам • Человеческая ошибка: обсудить, почему произошло, как избежать (может автоматизировать что-то) • Проблемы с релизом: доработка автотестов, процедуры выкладки • Проблема в приложении: задача в разработку • Железо/сеть/каналы/ДЦ: задача для админов (починить/уменьшить вероятность/обеспечить самовосстановление/уменьшить downtime в будущем)

55. По результатам • Добавить метрик в мониторинг? • Детализировать метрики ? • Новый триггер ? • Новый “говорящий” график на дашборд?

56. Спасибо за внимание! Вопросы? Николай Сивко hh.ru email: sivko@hh.ru, n.sivko@gmail.com

Monitoring driven эксплуатация / Николай Сивко (HeadHunter)

Ontico

Monitoring driven эксплуатация / Николай Сивко (HeadHunter)