Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,082 views

Published on

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

Если система мониторинга настроена хорошо, она позволяет сократить время простоя, какие-то проблемы показать на ранней стадии, формализовать рабочие процессы команды админов.
То есть она является носителем знания о нашей инфраструктуре и о том, как именно работают админы.
Можно ли извлечь дополнительную пользу из этого?

В hh.ru мы используем систему мониторинга ещё и как check list для повседневных задач админов (алерты в данном случае являются задачами для человека: сделал задачу - триггер проверил результат и погас), идея взята из TDD.

Также расскажу, как мы работаем с внештатными ситуациями: реагируем на алерты, чиним, разбираем и классифицируем.

Еще на основе разобранных инцидентов мы считаем показатели работы службы эксплуатации, из этих показателей высчитываются наши премии (данный KPI получился удачным: с ним согласен и бизнес и админы).

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Monitoring- driven эксплуатация Николай Сивко
  2. 2. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  3. 3. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  4. 4. Требования бизнеса • Сайт должен работать • Есть ответственный за работоспособность сайта • Сайт должен работать быстро (говорят, это влияет на разные важные коверсии :) • Минимальные операционные и капитальные затраты
  5. 5. Сайт работает (было) • Раз в минуту проходят основные пользовательские сценарии • Время ответа укладывается в нужные рамки
  6. 6. Сайт работает (сейчас) • количество ошибок < 20/s • 95-я персентить времени ответа < 4s (на самом деле обычно ~500ms) • внешние чеки на случай проблем с каналами
  7. 7. Сайт работает (хотим) • количество ошибок < 20/s • 95-я персентить времени ответа < 4s • количество запросов не упало • пользовательская активность на нужном уровне (в нашем случае: активность по резюме, вакансиям, откликам)
  8. 8. Кто отвечает за аптайм • На практике: админы И разработчики • На инциденты всегда реагируют админы
  9. 9. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  10. 10. Попытка #1 • Нужно, чтобы админы просыпались по SMS, чинили сайт, если не могут починить, будили кого-то из девелоперов и чинили вместе • Выходит, что KPI админов - это время реакции на инцидент!
  11. 11. Попытка #1 “Время простоя за квартал 5 часов, максимальные время реакции 2 минуты, мы молодцы, сделали всё, что можем, хотим премию!”
  12. 12. Попытка #2 • Админы должны отвечать за аптайм • Но приложение сайта для админов black box • Мы вложимся в QA, все проблемы включая производительность будем ловить на стендах (утопия) • Человек должен отвечать только за то, на что может влиять!
  13. 13. Попытка #3 • Давайте поделим аптайм на зоны ответственности • Админы будут отвечать только за свое • Что делать со всем остальным решим потом
  14. 14. Формализуем • любой выход за пределы SLA - считаем , что сайт лежит (даже если что-то работает) • на любой инцидент реагируют админы (дежурные или все сразу) • по каждому инциденту обязательный разбор, поиск причины, классификация • считаем суммарный downtime • делим по зонам ответственности
  15. 15. Классы проблем • Проблема с релизом (взорвалось или были ошибки при деплое) • Ошибка в приложении (утекло, тяжелый запрос убил базу, не отработал таймаут до удаленного сервиса, итд) • Железо + сеть + каналы + ДЦ • Ошибка админа • Проблемы с БД • Плановый downtime (иногда нужно) • Ошибка мониторинга (чтобы не удалять инциденты никогда)
  16. 16. Зона ответственности СЭ • Проблема с релизом • Ошибка в приложении • Железо + сеть + каналы + ДЦ • Ошибка админа • Проблемы с БД • Плановый downtime • Ошибка мониторинга
  17. 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
  18. 18. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  19. 19. Первый квартал c KPI • Оказывается, нужно работать :) • Надо привыкать думать над каждым действием • Многие операции перевели в разряд “рискованных”, их выполнять стали в часы минимальной нагрузки, объявляя плановый downtime • Начали проводить учения, тестировать сценарии деградации системы (выключать rabbitmq, memcached, свои сервисы, без которых все должно жить)
  20. 20. Первый квартал c KPI • Мониторинг начал ловить очень много всего нового • Logrotate, разные cron’ы давали 500ки, на которые раньше не реагировали • Начали вдумчиво настраивать таймауты, ретраи итд • Где-то пересмотрели архитектуру и запланировали переделку • Самое сложное: выяснять причины ВСЕХ инцидентов • Перестал устраивать существующий мониторинг
  21. 21. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  22. 22. Требования • Узнать, что есть проблема • Видеть, что происходит: насколько проблема масштабна, какие компоненты затронуты • Иметь достаточно метрик, чтобы копаться “задним числом” • Ускорять выявление проблем, все важное из логов вынести на графики • Простота расширения
  23. 23. Что у нас было • Nagios + centreon (+ патчи) • Nagios + своя штука для графиков + свой poller SNMP • У разработчиков всегда были свои cacti, graphite итд • Свое решение - monik (был выделенный разработчик мониторинга)
  24. 24. Проблемы • У нас нет цели разрабатывать мониторинг • Зато есть много другой работы • Всё, что мы разрабатывали устаревает, появляются новые требования • Взять и попробовать что-то новое – тоже время • В opensource практически нет full-stack решений, есть отдельно хранилища, собиралки, алертилки, дашбордилки • Практически всё нужно доделывать под себя
  25. 25. SaaS мониторинг • Не нужно писать код • У нас нет супер-секретных метрик • Специализированная компания: они могут себе позволить тесты, мониторинг мониторинга, отказоустойчивость (у нас всегда мониторинг жил на 1 сервере) • Мы “большой” клиент, можем договориться о доработках под нас • Ценник сравним с выделенным разработчиком у нас • Мы работаем с okmeter.io
  26. 26. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  27. 27. Проблемы • Как правило мониторингом покрывают только самые критичные подсистемы • Мы пробовали включать покрытие мониторингом в процедуру выпуска новых сервисов – не работает • Часто снимают не всё (где-то забыли включить jmx, где- то пустить мониторинг в postgresql) • Инфраструктура меняется: запускаются новые jvm, pg, nginx, haproxy итд • Метрики сильно обобщены, видно, что есть проблема, но не видно, где конкретно
  28. 28. Подход • Все что можно снять без конфига, снимаем всегда и со всех машин • Если агенту нужны права или донастройка, это алерт в мониторинге • Метрики максимально детальные в пределах разумного, агрегаты можно сделать на лету • Ждем: алерт, если поймали TCP соединения с хостов, на котором не стоит агент
  29. 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. 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. 31. Про каждый TCP LISTEN • Если remote IP из той же сети – все метрики для каждого IP отдельно • Количество соединений в разных состояниях (ESTABLISHED, TIME_WAIT, …) • 95я персентиль TCP RTT (с учетом SACK не является реальным RTT в сети, но для сравнения было-стало работает хорошо) • Количество соединений в backlog и лимит • Похожие метрики для исходящих TCP соединений
  32. 32. Nginx • Если есть работающий процесс nginx, находится и парсится конфиг • Парсится log_format и access_log • Если лог нельзя распарсить – алерт • Если в логе нет $request_time, $upstream_response_time - алерт • RPS в разрезе status, top urls, cache_status, method • Персентили и гистограммы для таймингов в тех же разрезах
  33. 33. Jvm • Если есть работающий процесс jvm, парсятся аргументы запуска • Определяем параметры JMX, если выключено – алерт • Снимаем heap, GC, memory pools, threads • Если есть mbeans cassandra – снимаем детальные метрики • Так же планируем снимать метрики jetty, grizzly, c3p0, hibernate,…
  34. 34. Postgresql • Пробуем с predefined паролем • Если не пускает - алерт с просьбой настроить пароль или загрантить • Если не настроено pg_stat_statements - алерт с просьбой включить • Если не хватает прав – алерт • Снимаем всё про top запросов/таблиц/индексов, bgwriter, текущие соединения, локи итд (pg_stat_*)
  35. 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. 36. Метрики из логов metrics: - type: rate name: api.nativeapps.rate labels: build: =build device: =device os: =os
  37. 37. Метрики из логов
  38. 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. 39. Метрики из SQL
  40. 40. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  41. 41. Принципы • Проактивного мониторинга не существует (disk usage если только) • В нагруженной системе всё меняется за доли секунды, понять последовательность событий нереально даже при секундном разрешении (как правило достаточно минутного) • зависимости между алертами хорошо сделать невозможно • в нормальном состоянии не должно быть активных алертов
  42. 42. Принципы • Critical событие – это то, на что нужно срочно среагировать и починить (CPU usage > 90% не нужно срочно чинить) • У нас 3 critical триггера (HTTP-5xx, Q95, ext http check) • Все остальные Warning, Info – всего лишь подсказки, у большинства нет нотификаций вообще • Лучше зажечь много warning-ов и выбрать глазами причину проблемы, чем пытаться автоматически определить, где причина, а где следствие
  43. 43. Принципы • Чтобы после SMS не ждать recovery, а сразу чинить - есть отложенная нотификация (notify after 2 min) • Идеально - увидеть проблему в списке алертов • Если нет, нужно смотреть на дашборды, где нужно глазами исключать возможные причины • В следующий раз такая же проблема должна быть в списке алертов
  44. 44. Принципы • Если есть алерт, который вы не собираетесь чинить - выключайте • Если есть постоянный поток писем от мониторинга, он заруливается в отдельную папку в почте и не читается, проще выключить • Если вас не интересует CPU usage на hadoop машине – настройте исключение
  45. 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. 46. Наши триггеры • Живы все nginx, haproxy, … – там где они были хоть раз запущены (если загорается лишний – закрываем руками) • Давно нет данных от агента на каком-то сервере • Нет данных от JVM/pg/…. • Jvm heap usage > 99% на протяжении 2 минут (ловим OOM, не везде настроена автоперезапускалка) • Time offset > 10 seconds • В важных очередях > N сообщений
  47. 47. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  48. 48. Сайт лёг - инцидент • SMS/еmail уведомление • Мониторинг создает задачу в JIRA (начало инцидента) • Админ реагирует, подтверждает это переводом задачи в статус “Проблемой занимаются” (любой сотрудник в компании это видит)
  49. 49. Чиним • Смотрим текущие алерты • Синхронизируемся в чате • Основной график – “Светофор” + рядом ~10 графиков
  50. 50. Конкретный сервис
  51. 51. Или база
  52. 52. После восстановления • Починили, мониторинг меняет статус задачи на “Инцидент исчерпан” • Поиск причины, общение в JIRA • Заполняем класс проблемы в задаче, перевод в статус “Закрыто” • Если по результатам нужна разработка, есть продолжение workflow
  53. 53. Разобрались
  54. 54. По результатам • Человеческая ошибка: обсудить, почему произошло, как избежать (может автоматизировать что-то) • Проблемы с релизом: доработка автотестов, процедуры выкладки • Проблема в приложении: задача в разработку • Железо/сеть/каналы/ДЦ: задача для админов (починить/уменьшить вероятность/обеспечить самовосстановление/уменьшить downtime в будущем)
  55. 55. По результатам • Добавить метрик в мониторинг? • Детализировать метрики ? • Новый триггер ? • Новый “говорящий” график на дашборд?
  56. 56. Спасибо за внимание! Вопросы? Николай Сивко hh.ru email: sivko@hh.ru, n.sivko@gmail.com

×