Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•Download as PPTX, PDF•
•
Ontico
Ontico

Огромная часть работы службы эксплуатации, так или иначе, связана с мониторингом существующей инфраструктуры. Если система мониторинга настроена хорошо, она позволяет сократить время простоя, какие-то проблемы показать на ранней стадии, формализовать рабочие процессы команды админов. То есть она является носителем знания о нашей инфраструктуре и о том, как именно работают админы. Можно ли извлечь дополнительную пользу из этого? В hh.ru мы используем систему мониторинга ещё и как check list для повседневных задач админов (алерты в данном случае являются задачами для человека: сделал задачу - триггер проверил результат и погас), идея взята из TDD. Также расскажу, как мы работаем с внештатными ситуациями: реагируем на алерты, чиним, разбираем и классифицируем. Еще на основе разобранных инцидентов мы считаем показатели работы службы эксплуатации, из этих показателей высчитываются наши премии (данный KPI получился удачным: с ним согласен и бизнес и админы).

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

More Related Content

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

  • 2. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 3. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 4. Требования бизнеса • Сайт должен работать • Есть ответственный за работоспособность сайта • Сайт должен работать быстро (говорят, это влияет на разные важные коверсии :) • Минимальные операционные и капитальные затраты
  • 5. Сайт работает (было) • Раз в минуту проходят основные пользовательские сценарии • Время ответа укладывается в нужные рамки
  • 6. Сайт работает (сейчас) • количество ошибок < 20/s • 95-я персентить времени ответа < 4s (на самом деле обычно ~500ms) • внешние чеки на случай проблем с каналами
  • 7. Сайт работает (хотим) • количество ошибок < 20/s • 95-я персентить времени ответа < 4s • количество запросов не упало • пользовательская активность на нужном уровне (в нашем случае: активность по резюме, вакансиям, откликам)
  • 8. Кто отвечает за аптайм • На практике: админы И разработчики • На инциденты всегда реагируют админы
  • 9. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 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
  • 18. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 19. Первый квартал c KPI • Оказывается, нужно работать :) • Надо привыкать думать над каждым действием • Многие операции перевели в разряд “рискованных”, их выполнять стали в часы минимальной нагрузки, объявляя плановый downtime • Начали проводить учения, тестировать сценарии деградации системы (выключать rabbitmq, memcached, свои сервисы, без которых все должно жить)
  • 20. Первый квартал c KPI • Мониторинг начал ловить очень много всего нового • Logrotate, разные cron’ы давали 500ки, на которые раньше не реагировали • Начали вдумчиво настраивать таймауты, ретраи итд • Где-то пересмотрели архитектуру и запланировали переделку • Самое сложное: выяснять причины ВСЕХ инцидентов • Перестал устраивать существующий мониторинг
  • 21. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 22. Требования • Узнать, что есть проблема • Видеть, что происходит: насколько проблема масштабна, какие компоненты затронуты • Иметь достаточно метрик, чтобы копаться “задним числом” • Ускорять выявление проблем, все важное из логов вынести на графики • Простота расширения
  • 23. Что у нас было • Nagios + centreon (+ патчи) • Nagios + своя штука для графиков + свой poller SNMP • У разработчиков всегда были свои cacti, graphite итд • Свое решение - monik (был выделенный разработчик мониторинга)
  • 24. Проблемы • У нас нет цели разрабатывать мониторинг • Зато есть много другой работы • Всё, что мы разрабатывали устаревает, появляются новые требования • Взять и попробовать что-то новое – тоже время • В opensource практически нет full-stack решений, есть отдельно хранилища, собиралки, алертилки, дашбордилки • Практически всё нужно доделывать под себя
  • 25. SaaS мониторинг • Не нужно писать код • У нас нет супер-секретных метрик • Специализированная компания: они могут себе позволить тесты, мониторинг мониторинга, отказоустойчивость (у нас всегда мониторинг жил на 1 сервере) • Мы “большой” клиент, можем договориться о доработках под нас • Ценник сравним с выделенным разработчиком у нас • Мы работаем с okmeter.io
  • 26. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 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
  • 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
  • 40. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 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 сообщений
  • 47. План • Взгляд на службу эксплуатации с точки зрения бизнеса • Договариваемся про KPI • Как жить с KPI • Мониторинг: требования • Мониторинг: метрики • Мониторинг: триггеры • Мониторинг: инцидент
  • 48. Сайт лёг - инцидент • SMS/еmail уведомление • Мониторинг создает задачу в JIRA (начало инцидента) • Админ реагирует, подтверждает это переводом задачи в статус “Проблемой занимаются” (любой сотрудник в компании это видит)
  • 49. Чиним • Смотрим текущие алерты • Синхронизируемся в чате • Основной график – “Светофор” + рядом ~10 графиков
  • 52. После восстановления • Починили, мониторинг меняет статус задачи на “Инцидент исчерпан” • Поиск причины, общение в JIRA • Заполняем класс проблемы в задаче, перевод в статус “Закрыто” • Если по результатам нужна разработка, есть продолжение workflow
  • 54. По результатам • Человеческая ошибка: обсудить, почему произошло, как избежать (может автоматизировать что-то) • Проблемы с релизом: доработка автотестов, процедуры выкладки • Проблема в приложении: задача в разработку • Железо/сеть/каналы/ДЦ: задача для админов (починить/уменьшить вероятность/обеспечить самовосстановление/уменьшить downtime в будущем)
  • 55. По результатам • Добавить метрик в мониторинг? • Детализировать метрики ? • Новый триггер ? • Новый “говорящий” график на дашборд?
  • 56. Спасибо за внимание! Вопросы? Николай Сивко hh.ru email: sivko@hh.ru, n.sivko@gmail.com