3. Задачи
• Узнать, что сломалось
• Быстро узнать, где сломалось
• Увидеть, что починилось
• Capacity planning
• Планирование оптимизаций
• Контроль оптимизаций
4. Поговорим
• На какие метрики нужно смотреть, если вы
эксплуатируете web проект
• Как смотреть на метрики, чтобы быстро понимать, что
происходит
5. Не затронем сегодня
• Инструменты: чем рисовать графики, как скрещивать
разные решения и т.д.
• Алерты: имея нужные метрики, сделать проверку
триггеров не так сложно
• Методология: workflow, KPI
http://www.slideshare.net/NikolaySivko/rootconf2015
7. Физический смысл
• Видеть, как работает система с точки зрения
пользователя
• Видеть, что происходит в каждой подсистеме
• На что уходят ресурсы
• На все это надо смотреть во времени: как было минуту
назад, вчера, в прошлый понедельник
8.
9. Navigation timing API
• js снипет отстреливает метрики на сервер GET запросом
с параметрами
• location = /stat {
return 204;
access_log /var/log/nginx/clientstat.access.log;
}
• парсим лог
12. Работает ли сайт?
• Есть ли ошибки? Сколько?
• Быстро или медленно? У одного пользователя или у
всех?
• Сколько запросов? Как обычно/провал/боты?
• Не тупит ли канал до клиентов?
13. Всё есть в логе nginx
• Конечно, стандартный формат “combined” нам не
подходит
• $request_time
• $upstream_response_time
• Опционально: $upstream_addr, $upstream_status,
$upstream_cache_status
20. Про урлы
• Ручные правила для парсинга основных урлов
устаревают
• Нормализация: /vacancy/123?arg=value -> /vacancy/$id
• Динамический top урлов (по rps или
сумме$upstream_response_time)
• Можно отдельный top по ошибкам, но с отсечкой снизу,
чтобы не было мусора
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
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;
40. Вопросы про сеть
• Сервис hhsession ждал ответа от hhid 150ms
• Сервис hhid считает, что он ответил на этот запрос за
5ms (тот же request_id)
• “Между ними только сеть”
• Результатов ping за вчера между ЭТИМИ хостами у вас
нет
• Как исключить сеть?
41. TCP RTT
• TCP Round-Trip Time - время от отправки пакета до
получения ACK
• Стоит рассматривать как некий тренд, не нужно
пытаться сравнивать с ICMP RTT
43. Что с этим делать
• Периодически снимаем со всех хостов RTT всех текущих
соединений
• Делаем агрегаты для всех remote_ip + listen_port в
пределах вашего сегмента сети (перцентиль)
• Сможем увидеть, как вела себя сеть между нужными
хостами
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
49. Итого
• Простые графики могут сильно ускорить поиск
проблемы
• Постарайтесь покрыть мониторингом все подсистемы (а
особенно стыки между ними)
• Чем детальнее метрики, тем проще потом разбираться