Хорошо поддерживаемое в продакшне приложение /...

54
Хорошо поддерживаемое в production приложение Николай Сивко

Upload: ontico

Post on 06-Jan-2017

171 views

Category:

Engineering


5 download

TRANSCRIPT

Page 1: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Хорошо поддерживаемое в 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 2: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Откуда инфа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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 3: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Проблема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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 4: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Мир глазами разработчика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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 5: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Мир глазами админа

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 6: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 7: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

С чего обычно начинается 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 8: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

С чего обычно начинается 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 9: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Чего хочет бизнес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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 10: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 11: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Будем говорить про диагностику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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 12: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 13: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 14: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 15: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 16: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 17: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 18: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 19: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 20: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 21: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 22: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 23: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 24: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 25: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 26: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 27: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 28: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Зачем мы все это смотрели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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 29: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Диагностика вопросы

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 30: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Подходы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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 31: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 32: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 33: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Высокоуровневые аналоги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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 34: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 35: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог сценарийВы видите в логе 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 36: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог сценарий

Вы захотите узнать что в логе у 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 37: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог что такое ЭТОТ запрос

Лог 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 38: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 39: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 40: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог итого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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 41: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Лог нагрузка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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 42: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Метрики приложения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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 43: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Метрики приложения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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 44: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Метрики приложения инструменты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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 45: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Инструменты 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 46: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Инструменты 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 47: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Счетчики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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 48: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Таймеры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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 49: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Кейс с 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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 50: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Цена метрик (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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 51: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Итого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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 52: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Не попало в доклад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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание
Page 53: Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Спасибо за внимание

ВопросыНиколай Сивко С удовольствием поговорим про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)
  • Итого
  • Не попало в доклад
  • Спасибо за внимание