Хорошо поддерживаемое в продакшне приложение /...
TRANSCRIPT
Хорошо поддерживаемое в production приложениеНиколай Сивко
Откуда инфаbull Очень долго руководил эксплуатацией
bull Сейчас okmeterio ndash много общаемся с клиентами про мониторингобнаружение проблем
bull У всех похожие болячки
Проблемаbull Разработчик и админ ndash разные люди
bull По-разному думают
bull Разный кругозор и набор проф интересов
bull Разные цели в работе
Мир глазами разработчика1 Есть задача с требованиями2 Пишу код + тесты3 Показал demo заказчику4 Передал в production
Если баг или проблема в production GOTO 1
Мир глазами админа
bull В 300 утра SMS ldquoHTTP-50x gt 20rpsrdquo
bull Приложение жрет 4 ядра в логе пусто
bull Фронтенд не дожидается ответа от сервиса за 10s и отдает
пользователям HTTP-504
bull Разработчик просит проверить сетьБДhellip и вообще перезапустить
DevOps РазрабАдмин
С чего обычно начинается DevOpsbull Continuous delivery и деплой 10 раз в час
bull Спрячем от разработчика железки за Docker c оркестрацией
bull Чтобы все масштабировалось на лету будем ходить за конфигами по сети целостность нам обеспечит PaxosRaft
bull Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Откуда инфаbull Очень долго руководил эксплуатацией
bull Сейчас okmeterio ndash много общаемся с клиентами про мониторингобнаружение проблем
bull У всех похожие болячки
Проблемаbull Разработчик и админ ndash разные люди
bull По-разному думают
bull Разный кругозор и набор проф интересов
bull Разные цели в работе
Мир глазами разработчика1 Есть задача с требованиями2 Пишу код + тесты3 Показал demo заказчику4 Передал в production
Если баг или проблема в production GOTO 1
Мир глазами админа
bull В 300 утра SMS ldquoHTTP-50x gt 20rpsrdquo
bull Приложение жрет 4 ядра в логе пусто
bull Фронтенд не дожидается ответа от сервиса за 10s и отдает
пользователям HTTP-504
bull Разработчик просит проверить сетьБДhellip и вообще перезапустить
DevOps РазрабАдмин
С чего обычно начинается DevOpsbull Continuous delivery и деплой 10 раз в час
bull Спрячем от разработчика железки за Docker c оркестрацией
bull Чтобы все масштабировалось на лету будем ходить за конфигами по сети целостность нам обеспечит PaxosRaft
bull Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Проблемаbull Разработчик и админ ndash разные люди
bull По-разному думают
bull Разный кругозор и набор проф интересов
bull Разные цели в работе
Мир глазами разработчика1 Есть задача с требованиями2 Пишу код + тесты3 Показал demo заказчику4 Передал в production
Если баг или проблема в production GOTO 1
Мир глазами админа
bull В 300 утра SMS ldquoHTTP-50x gt 20rpsrdquo
bull Приложение жрет 4 ядра в логе пусто
bull Фронтенд не дожидается ответа от сервиса за 10s и отдает
пользователям HTTP-504
bull Разработчик просит проверить сетьБДhellip и вообще перезапустить
DevOps РазрабАдмин
С чего обычно начинается DevOpsbull Continuous delivery и деплой 10 раз в час
bull Спрячем от разработчика железки за Docker c оркестрацией
bull Чтобы все масштабировалось на лету будем ходить за конфигами по сети целостность нам обеспечит PaxosRaft
bull Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Мир глазами разработчика1 Есть задача с требованиями2 Пишу код + тесты3 Показал demo заказчику4 Передал в production
Если баг или проблема в production GOTO 1
Мир глазами админа
bull В 300 утра SMS ldquoHTTP-50x gt 20rpsrdquo
bull Приложение жрет 4 ядра в логе пусто
bull Фронтенд не дожидается ответа от сервиса за 10s и отдает
пользователям HTTP-504
bull Разработчик просит проверить сетьБДhellip и вообще перезапустить
DevOps РазрабАдмин
С чего обычно начинается DevOpsbull Continuous delivery и деплой 10 раз в час
bull Спрячем от разработчика железки за Docker c оркестрацией
bull Чтобы все масштабировалось на лету будем ходить за конфигами по сети целостность нам обеспечит PaxosRaft
bull Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Мир глазами админа
bull В 300 утра SMS ldquoHTTP-50x gt 20rpsrdquo
bull Приложение жрет 4 ядра в логе пусто
bull Фронтенд не дожидается ответа от сервиса за 10s и отдает
пользователям HTTP-504
bull Разработчик просит проверить сетьБДhellip и вообще перезапустить
DevOps РазрабАдмин
С чего обычно начинается DevOpsbull Continuous delivery и деплой 10 раз в час
bull Спрячем от разработчика железки за Docker c оркестрацией
bull Чтобы все масштабировалось на лету будем ходить за конфигами по сети целостность нам обеспечит PaxosRaft
bull Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
DevOps РазрабАдмин
С чего обычно начинается DevOpsbull Continuous delivery и деплой 10 раз в час
bull Спрячем от разработчика железки за Docker c оркестрацией
bull Чтобы все масштабировалось на лету будем ходить за конфигами по сети целостность нам обеспечит PaxosRaft
bull Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
С чего обычно начинается DevOpsbull Continuous delivery и деплой 10 раз в час
bull Спрячем от разработчика железки за Docker c оркестрацией
bull Чтобы все масштабировалось на лету будем ходить за конфигами по сети целостность нам обеспечит PaxosRaft
bull Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
С чего обычно начинается DevOps
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Чего хочет бизнесbull Production должен работать
bull Если что-то ломается нужно быстро определить причину и починить
bull Сделать так чтобы не повторялось
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
DevOps РазрабАдмин Разработчик думает о том как поддерживать приложение в production или сам это делает
ИЛИ
Когда админ начинает писать код (это горе в семье но случается)
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Будем говорить про диагностикуbull Посмотрим как сделано у популярного софта nginx mongo
postgresql
bull Какие вообще есть подходы
bull Как делать у себя
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
bull Входящие запросы
bull Бэкенды
bull Статика кэш
bull Lua perl hellip
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Nginx error_log20161010 122757 [error] 62190 130819912 upstream timed out (110 Connection timed out) while connecting to upstream client 1234 server okmeterio request POST metricwrite HTTP11 upstream http19216810098088metricwrite host okmeterio
bull У какого именно клиента ошибкаbull Какой бэкенд не ответил
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Nginx access_log1234 - - [10Oct2016140438 +0300] POST metricwrite HTTP11 200 2 - Go-http-client11 0103 - [0039 0064] 19216810058088 19216810048088 504 200
bull Какой статус вернули клиентуbull Что вернул каждый бэкенд сколько было попытокbull Сколько ждали каждого бэкендаbull Сколько ждал пользователь
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Nginx debug logbull Показывает все этапы обработки запроса
bull Можно только для конкретных IPсетей (debug_connection)
bull Можно в циклический буфер в памяти
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Nginx stub_statusActive connections 291 server accepts handled requests 16630948 16630948 31070465 Reading 6 Writing 179 Waiting 106
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Nginx тёмные пятнаbull Сколько ждали диск читали данные писали лог
bull Другие блокировки IO loop логика nginx пользовательская логика (lua)
bull Нельзя отличить медленный канал от limit_reqburst в $request_time
bull Если будет много CPU-bound вычислений нужно будет понимать какой именно запрос прямо сейчас держит управление
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
bull Данные
bull Запросы + CPU bound логика (aggregation)
bull Ресурсы диск сеть процессор
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Mongobull serverStatus mdash server-wide метрики
bull dbStats mdash db-wide метрики
bull collStats mdash collection-wide метрики
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Mongo query profilerbull Capped collection с профайлингом запросов
bull Включается для всех или только для ldquoмедленныхrdquo
bull Может негативно повлиять на производительность
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Mongo практикаМетрик много но большинство из них для разработчика mongo
Пользователь может только - прибить плохой запрос - исправить запросысхему данныхиндексы - поменять конфиг - добавить ресурсов
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Mongo тёмные пятнаbull Какой запрос прямо сейчас всё убивает
bull На какие запросы уходят ресурсы
bull Какие запросы удерживают локи
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
bull Данные
bull Запросы
bull Ресурсы диск сеть процессор
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
PostgreSQL данныеbull pg_stat_all_(tables|indexes)
bull pg_statio_all_(tables|indexes)
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
PostgreSQL запроcыbull pg_stat_activity ndash что происходит прямо сейчас
bull pg_stat_statements ndash накопленные счетчики по группам запросов
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
PostgreSQL локиbull pg_stat_activitywait_event ndash 96+
bull pg_locks ndash можно JOIN на pg_stat_activity по pid
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
PostgreSQL тёмные пятна
В постгресе почти идеальная диагностикаПостгрес умныйБудь как постгрес
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Зачем мы все это смотрелиbull Web-приложения похожи на nginx только больше вычислений
после получения данных у nginx хорошие логи
bull Mongo ndash пример того как всё покрыли счетчиками но забыли про сценарии использования диагностики
bull PG ndash пример того как должно быть
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Диагностика вопросы
bull Чем приложение занято прямо сейчас
bull Чем приложение занималось в вчера в 1843
bull На какие задачизапросы были потрачены ресурсы
bull Сколько и каких ошибок было
bull Сколько ждали ответа базы вчерасегодня
bull Почему отдали HTTP-400
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Подходыbull Threadstack dump и аналоги
bull Лог
bull Счетчикитаймерымгновенные значения
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Threadstack dump и аналогиbull Мгновенный снимок в каком месте кода находится управление
каждого ldquoпотокаrdquo
bull Больше про runtime а не ваш код
bull Высокоуровневые аналоги какие запросы сейчас обрабатываем и на какой они стадии
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Threadstack dump и аналогиbull Java jstack ltpidgt
bull Golang bull enable pprof bull curl httpIPPORTdebugpprofgoroutinedebug=2
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Высокоуровневые аналогиbull PG pg_stat_activity
bull Mysql SHOW PROCESSLIST
bull Apache mod_status
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Логbull Правильно писать логи очень сложно
bull Правильно пишем нужное и НЕ пишем лишнего
bull Общего рецепта нет ndash все системы разные
bull Предлагаю исходить из сценариев использования
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Лог сценарийВы видите в логе nginxhellip rdquoGET url HTTP11 504 request_time=0101 upstream_response_time=[0101] upstream_addr=192168118000 upstream_status=504
Что вы будете делать дальше
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Лог сценарий
Вы захотите узнать что в логе у 19216811 по этому запросу
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Лог что такое ЭТОТ запрос
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Лог request_idbull На входе генерим id запроса (nginx $request_id например)
bull Ставим заголовком во все запросы дальше X-Request-Id 123456
bull Во всех сервисах пишем в лог
bull Можно даже комментарий в SQL запрос
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Лог request_idNginxhellip rdquoGET url HTTP11 504 0101 [0101] 192168118000 504 req_id=123456
Backendlttimestampgt id123456 querying session from session_db1 lttimestampgt id123456 client closes connectionlttimestampgt id123456 GET apiblabla 499 0101s
PGlttimestampgt ltpidgt ltusergtltdbgt from 19216811 [vxidxy txid0] [SELECT] LOG duration 147020 ms execute ltunnamedgt 123456 select from session where sessionid=$1 AND hellip
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Лог итогоbull Нужно отличать запросы друг от друга (request id)
bull Пишем не только законченные действия (бывает нужно ловить залипшие)
bull Если куда-то идем пишем конкретный адрес
bull Пишем все ошибки и как их обработали
bull Замеряем время значимых операций
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Лог нагрузкаbull Подробное логирование создает нагрузку
bull Если вводим разные уровни логирования то нужна ручка переключения без перезапуска
bull К логам можно цеплять парсеры для получения метрик но это тоже нагрузка
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Метрики приложенияbull Счетчики событий (ошибки запросы hellip)
bull Таймеры (замеряем продолжительность каких-то действий)
bull Мгновенные значения (текущее количество соединений размер кэшаhellip)
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Метрики приложенияbull Теряем часть информации по сравнению с логом
bull Но сильно дешевле логов
bull Экспортируем в мониторинг то что насчитали
bull Рисуем графики
bull Настраиваем алерты если нужно
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Метрики приложения инструментыbull ltyour_langgt-metrics
bull ltyour_langgt-statsd-client
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Инструменты ltyour_langgt-metricsbull Либа для вашего приложения есть для всех ЯП
bull Аккумулирует замеры в памяти
bull Экспортирует в различные системы (graphite influx лог hellip)
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Инструменты statsdbull UDP сервер принимает отстрелы замеров из приложения
агрегирует и экспортирует в мониторинг
bull Клиенты для всех ЯП
bull Семантика примерно такая же как в -metrics
bull Есть библиотеки с предварительной агрегацией на клиенте
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
СчетчикиGolang
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
ТаймерыGolang
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Кейс с HTTP-504
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Цена метрик (golang)bull GetOrRegister 122 nsopbull CounterInc 10 nsopbull Timer_Time 879 nsopbull 2xNow 38 nsop
10000 rps (10 таймеров в каждом) = диагностика займет ~9 одного ядра
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Итогоbull DevOps нужно начинать с диагностики
bull Диагностика ndash это просто
bull Делайте диагностику исходя из сценариев использования
bull Есть много готовых инструментов
bull После этого можно docker CICD и 100500 микросервисов )
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Не попало в докладbull Детализация метрик приложения
bull Профайлеры в production под нагрузкой
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-
Спасибо за внимание
ВопросыНиколай Сивко С удовольствием поговорим проnsvokmeterio диагностикумониторинг на стенде
- Хорошо поддерживаемое в production приложение
- Откуда инфа
- Проблема
- Мир глазами разработчика
- Мир глазами админа
- DevOps РазрабАдмин
- С чего обычно начинается DevOps
- С чего обычно начинается DevOps (2)
- Чего хочет бизнес
- DevOps РазрабАдмин
- Будем говорить про диагностику
- Slide 12
- Nginx error_log
- Nginx access_log
- Nginx debug log
- Nginx stub_status
- Nginx тёмные пятна
- Slide 18
- Mongo
- Mongo query profiler
- Mongo практика
- Mongo тёмные пятна
- Slide 23
- PostgreSQL данные
- PostgreSQL запроcы
- PostgreSQL локи
- PostgreSQL тёмные пятна
- Зачем мы все это смотрели
- Диагностика вопросы
- Подходы
- Threadstack dump и аналоги
- Threadstack dump и аналоги (2)
- Высокоуровневые аналоги
- Лог
- Лог сценарий
- Лог сценарий (2)
- Лог что такое ЭТОТ запрос
- Лог request_id
- Лог request_id (2)
- Лог итого
- Лог нагрузка
- Метрики приложения
- Метрики приложения (2)
- Метрики приложения инструменты
- Инструменты ltyour_langgt-metrics
- Инструменты statsd
- Счетчики
- Таймеры
- Кейс с HTTP-504
- Slide 50
- Цена метрик (golang)
- Итого
- Не попало в доклад
- Спасибо за внимание
-