O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Monitoring-driven эксплуатация (rootconf2015)

2.309 visualizações

Publicada em

Слайды с доклада на RootConf2015

Publicada em: Engenharia
  • Seja o primeiro a comentar

Monitoring-driven эксплуатация (rootconf2015)

  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

×