Когда вы узнаете, что ваш сервис не работает, вы идете в мониторинг, видите много алертов про CPU/load average/diskIO/и т.д., пускаете слезу и идете читать логи. Сначала на фронтенды, потом дальше по стеку. У многих уже есть grafana и подобные дашборды, но почти всегда там есть только метрики про приложение и пользователей, но нет ничего про сеть, базу и другие подсистемы, от которых зависит работа сервиса. Мониторинг должен помочь быстро понять, в каком сервисе проблема, а, может, даже показать причину проблемы. Я расскажу и покажу на примере hh.ru, как покрыть мониторингом все слои инфраструктуры: - client-side метрики; - метрики с фронтендов (логи nginx); - сеть (что можно добыть из TCP); - приложение (логи); - метрики базы данных (postgresql в нашем случае); - операционная система (cpu usage тоже может пригодиться:).

1. Мониторинг
всех слоев web
проекта
Николай Сивко

2. Мотивация
1 минута простоя hh.ru днем в будни
затрагивает ~30000 пользователей
~15 * HL++

3. Задачи
• Узнать, что сломалось
• Быстро узнать, где сломалось
• Увидеть, что починилось
• Capacity planning
• Планирование оптимизаций
• Контроль оптимизаций

4. Поговорим
• На какие метрики нужно смотреть, если вы
эксплуатируете web проект
• Как смотреть на метрики, чтобы быстро понимать, что
происходит

5. Не затронем сегодня
• Инструменты: чем рисовать графики, как скрещивать
разные решения и т.д.
• Алерты: имея нужные метрики, сделать проверку
триггеров не так сложно
• Методология: workflow, KPI
http://www.slideshare.net/NikolaySivko/rootconf2015

6. hh.ru

7. Физический смысл
• Видеть, как работает система с точки зрения
пользователя
• Видеть, что происходит в каждой подсистеме
• На что уходят ресурсы
• На все это надо смотреть во времени: как было минуту
назад, вчера, в прошлый понедельник

9. Navigation timing API
• js снипет отстреливает метрики на сервер GET запросом
с параметрами
• location = /stat {
return 204;
access_log /var/log/nginx/clientstat.access.log;
}
• парсим лог

10. Client-side timers

12. Работает ли сайт?
• Есть ли ошибки? Сколько?
• Быстро или медленно? У одного пользователя или у
всех?
• Сколько запросов? Как обычно/провал/боты?
• Не тупит ли канал до клиентов?

13. Всё есть в логе nginx
• Конечно, стандартный формат “combined” нам не
подходит
• $request_time
• $upstream_response_time
• Опционально: $upstream_addr, $upstream_status,
$upstream_cache_status

14. $request_time

15. $upstream_response_t

16. HTTP-5xx

17. HTTP-5xx by URL

18. 5xx + 4xx + bots

19. $bytes_sent

20. Про урлы
• Ручные правила для парсинга основных урлов
устаревают
• Нормализация: /vacancy/123?arg=value -> /vacancy/$id
• Динамический top урлов (по rps или
сумме$upstream_response_time)
• Можно отдельный top по ошибкам, но с отсечкой снизу,
чтобы не было мусора

21. Балансировка

23. На что уходит время
2015-10-14 15:12:00,904 INFO: timings for
xhh.pages.vacancy.Page :
prepare=0.83
session=4.99
page=123.84
xsl=36.63
postprocess=13.21
finish=0.23
flush=0.49
total=180.21
code=200

24. Страница вакансии

25. Чем занят кластер?

26. Шаблонизация
2015-10-14 15:12:00,865 INFO: applied XSL
ambient/pages/vacancy/view.xsl in 22.50ms

27. Что оптимизировать?

28. Видим результат

30. Какой сервис сломался

32. Опять стадии
2015-10-21 10:47:10.532 [Grizzly-worker(14)] INFO
r.hh.health.monitoring.TimingsLogger: response: 200; context:
GET /hh-session/full;
total time 10 ms;
jersey#beforeHandle=+0;
HHid#BeforeClient=+0;
HHid#Client=+6;
DB#getHhSession=+3;
pbMappers=+0;
makeHeaderSession=+1;
currentSessionInBothBodyAndHeader=+0;
jersey#afterHandle=+0;

33. Log -> metrics

35. Не поплохело ли PG?

36. Чем занят CPU PG?

37. Кто грузит диски?

38. Кто грузит диски?

40. Вопросы про сеть
• Сервис hhsession ждал ответа от hhid 150ms
• Сервис hhid считает, что он ответил на этот запрос за
5ms (тот же request_id)
• “Между ними только сеть”
• Результатов ping за вчера между ЭТИМИ хостами у вас
нет
• Как исключить сеть?

41. TCP RTT
• TCP Round-Trip Time - время от отправки пакета до
получения ACK
• Стоит рассматривать как некий тренд, не нужно
пытаться сравнивать с ICMP RTT

42. TCP очень сложный
* www.cs.virginia.edu/~cs458/slides/module15-tcp3V2.ppt

43. Что с этим делать
• Периодически снимаем со всех хостов RTT всех текущих
соединений
• Делаем агрегаты для всех remote_ip + listen_port в
пределах вашего сегмента сети (перцентиль)
• Сможем увидеть, как вела себя сеть между нужными
хостами

44. 7ms при ping ~ 0.8ms

45. Немного про OS
• cpu
• memory
• disk
• disk i/o
• net interfaces
• swap
• swap i/o

46. Что это было?

47. Процессы
• CPU per process+user
• Memory per process+user
• Disk I/O per process+user
• Swap per process+user
• Swap I/O per process+user
• FD usage per process+user

48. pg_dump + pbzip2

49. Итого
• Простые графики могут сильно ускорить поиск
проблемы
• Постарайтесь покрыть мониторингом все подсистемы (а
особенно стыки между ними)
• Чем детальнее метрики, тем проще потом разбираться

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