Мониторинг всех слоев web проекта / Сивко Николай (hh.ru)
TRANSCRIPT
Мониторинг всех слоев web проектаНиколай Сивко
Мотивация 1 минута простоя hh.ru днем в будни
затрагивает ~30000 пользователей
~15 * HL++
Задачи• Узнать, что сломалось
• Быстро узнать, где сломалось
• Увидеть, что починилось
• Capacity planning
• Планирование оптимизаций
• Контроль оптимизаций
Поговорим• На какие метрики нужно смотреть, если вы
эксплуатируете web проект
• Как смотреть на метрики, чтобы быстро понимать, что происходит
Не затронем сегодня• Инструменты: чем рисовать графики, как
скрещивать разные решения и т.д.
• Алерты: имея нужные метрики, сделать проверку триггеров не так сложно
• Методология: workflow, KPI http://www.slideshare.net/NikolaySivko/rootconf2015
hh.ru
Физический смысл• Видеть, как работает система с точки зрения
пользователя
• Видеть, что происходит в каждой подсистеме
• На что уходят ресурсы
• На все это надо смотреть во времени: как было минуту назад, вчера, в прошлый понедельник
Navigation timing API• js снипет отстреливает метрики на сервер GET
запросом с параметрами
• location = /stat { return 204; access_log /var/log/nginx/clientstat.access.log; }
• парсим лог
Client-side timers
Работает ли сайт?• Есть ли ошибки? Сколько?
• Быстро или медленно? У одного пользователя или у всех?
• Сколько запросов? Как обычно/провал/боты?
• Не тупит ли канал до клиентов?
Всё есть в логе nginx• Конечно, стандартный формат “combined” нам не
подходит
• $request_time
• $upstream_response_time
• Опционально: $upstream_addr, $upstream_status, $upstream_cache_status
$request_time
$upstream_response_t
HTTP-5xx
HTTP-5xx by URL
5xx + 4xx + bots
$bytes_sent
Про урлы• Ручные правила для парсинга основных урлов
устаревают
• Нормализация: /vacancy/123?arg=value -> /vacancy/$id
• Динамический top урлов (по rps или сумме$upstream_response_time)
• Можно отдельный top по ошибкам, но с отсечкой снизу, чтобы не было мусора
Балансировка
На что уходит время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
Страница вакансии
Чем занят кластер?
Шаблонизация2015-10-14 15:12:00,865 INFO: applied XSL ambient/pages/vacancy/view.xsl in 22.50ms
Что оптимизировать?
Видим результат
Какой сервис сломался
Опять стадии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;
Log -> metrics
Не поплохело ли PG?
Чем занят CPU PG?
Кто грузит диски?
Кто грузит диски?
Вопросы про сеть• Сервис hhsession ждал ответа от hhid 150ms
• Сервис hhid считает, что он ответил на этот запрос за 5ms (тот же request_id)
• “Между ними только сеть”
• Результатов ping за вчера между ЭТИМИ хостами у вас нет
• Как исключить сеть?
TCP RTT• TCP Round-Trip Time - время от отправки пакета
до получения ACK
• Стоит рассматривать как некий тренд, не нужно пытаться сравнивать с ICMP RTT
TCP очень сложный
* www.cs.virginia.edu/~cs458/slides/module15-tcp3V2.ppt
Что с этим делать• Периодически снимаем со всех хостов RTT всех
текущих соединений
• Делаем агрегаты для всех remote_ip + listen_port в пределах вашего сегмента сети (перцентиль)
• Сможем увидеть, как вела себя сеть между нужными хостами
7ms при ping ~ 0.8ms
Немного про OS• cpu• memory• disk• disk i/o• net interfaces• swap• swap i/o
Что это было?
Процессы• 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
pg_dump + pbzip2
Итого• Простые графики могут сильно ускорить поиск
проблемы
• Постарайтесь покрыть мониторингом все подсистемы (а особенно стыки между ними)
• Чем детальнее метрики, тем проще потом разбираться
