Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

sur

Monitoring-driven эксплуатация (rootconf2015) Slide 1 Monitoring-driven эксплуатация (rootconf2015) Slide 2 Monitoring-driven эксплуатация (rootconf2015) Slide 3 Monitoring-driven эксплуатация (rootconf2015) Slide 4 Monitoring-driven эксплуатация (rootconf2015) Slide 5 Monitoring-driven эксплуатация (rootconf2015) Slide 6 Monitoring-driven эксплуатация (rootconf2015) Slide 7 Monitoring-driven эксплуатация (rootconf2015) Slide 8 Monitoring-driven эксплуатация (rootconf2015) Slide 9 Monitoring-driven эксплуатация (rootconf2015) Slide 10 Monitoring-driven эксплуатация (rootconf2015) Slide 11 Monitoring-driven эксплуатация (rootconf2015) Slide 12 Monitoring-driven эксплуатация (rootconf2015) Slide 13 Monitoring-driven эксплуатация (rootconf2015) Slide 14 Monitoring-driven эксплуатация (rootconf2015) Slide 15 Monitoring-driven эксплуатация (rootconf2015) Slide 16 Monitoring-driven эксплуатация (rootconf2015) Slide 17 Monitoring-driven эксплуатация (rootconf2015) Slide 18 Monitoring-driven эксплуатация (rootconf2015) Slide 19 Monitoring-driven эксплуатация (rootconf2015) Slide 20 Monitoring-driven эксплуатация (rootconf2015) Slide 21 Monitoring-driven эксплуатация (rootconf2015) Slide 22 Monitoring-driven эксплуатация (rootconf2015) Slide 23 Monitoring-driven эксплуатация (rootconf2015) Slide 24 Monitoring-driven эксплуатация (rootconf2015) Slide 25 Monitoring-driven эксплуатация (rootconf2015) Slide 26 Monitoring-driven эксплуатация (rootconf2015) Slide 27 Monitoring-driven эксплуатация (rootconf2015) Slide 28 Monitoring-driven эксплуатация (rootconf2015) Slide 29 Monitoring-driven эксплуатация (rootconf2015) Slide 30 Monitoring-driven эксплуатация (rootconf2015) Slide 31 Monitoring-driven эксплуатация (rootconf2015) Slide 32 Monitoring-driven эксплуатация (rootconf2015) Slide 33 Monitoring-driven эксплуатация (rootconf2015) Slide 34 Monitoring-driven эксплуатация (rootconf2015) Slide 35 Monitoring-driven эксплуатация (rootconf2015) Slide 36 Monitoring-driven эксплуатация (rootconf2015) Slide 37 Monitoring-driven эксплуатация (rootconf2015) Slide 38 Monitoring-driven эксплуатация (rootconf2015) Slide 39 Monitoring-driven эксплуатация (rootconf2015) Slide 40 Monitoring-driven эксплуатация (rootconf2015) Slide 41 Monitoring-driven эксплуатация (rootconf2015) Slide 42 Monitoring-driven эксплуатация (rootconf2015) Slide 43 Monitoring-driven эксплуатация (rootconf2015) Slide 44 Monitoring-driven эксплуатация (rootconf2015) Slide 45 Monitoring-driven эксплуатация (rootconf2015) Slide 46 Monitoring-driven эксплуатация (rootconf2015) Slide 47 Monitoring-driven эксплуатация (rootconf2015) Slide 48 Monitoring-driven эксплуатация (rootconf2015) Slide 49 Monitoring-driven эксплуатация (rootconf2015) Slide 50 Monitoring-driven эксплуатация (rootconf2015) Slide 51 Monitoring-driven эксплуатация (rootconf2015) Slide 52 Monitoring-driven эксплуатация (rootconf2015) Slide 53 Monitoring-driven эксплуатация (rootconf2015) Slide 54 Monitoring-driven эксплуатация (rootconf2015) Slide 55 Monitoring-driven эксплуатация (rootconf2015) Slide 56
Prochain SlideShare
Мониторинг качества работы вашего проекта
Suivant
Télécharger pour lire hors ligne et voir en mode plein écran

19 j’aime

Partager

Télécharger pour lire hors ligne

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

Télécharger pour lire hors ligne

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

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
  • kostyakeeper

    May. 7, 2017
  • nordicdyno

    Mar. 5, 2017
  • ikurochkin

    Jun. 12, 2016
  • TimofeyCherkasovcher

    Mar. 31, 2016
  • zabaika

    Jan. 13, 2016
  • BelkovVlad

    Dec. 19, 2015
  • MaximZubov

    Dec. 15, 2015
  • gregryzhov

    Dec. 15, 2015
  • alterrebe

    Dec. 13, 2015
  • GfFerre1

    Dec. 8, 2015
  • ssuser5a2151

    Nov. 6, 2015
  • RomanKosenko

    Aug. 11, 2015
  • ssuser7a5126

    Jun. 26, 2015
  • ssuser6756c7

    Jun. 25, 2015
  • ssuserc3b0bd

    Jun. 24, 2015
  • ssuser3e6bdc

    May. 26, 2015
  • artemiyrodionov

    May. 24, 2015
  • zhurbilo

    May. 23, 2015
  • dmitrytsoy

    May. 23, 2015

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

Vues

Nombre de vues

2 557

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

22

Actions

Téléchargements

49

Partages

0

Commentaires

0

Mentions J'aime

19

×