Николай Сивко "Хорошо поддерживаемое в продакшне приложение"
0 likes466 views
Документ описывает процесс разработки и администрирования приложений, фокусируясь на DevOps и важности диагностики в обеспечении стабильной работы приложений. Обсуждаются методы диагностики и мониторинга, включая использование различных инструментов, таких как nginx, MongoDB и PostgreSQL, для отслеживания производительности и выявления проблем. Основное внимание уделяется разработке логирования и метрик, которые помогут в идентификации ошибок и производительности приложений.
![Nginx: error_log
2016/10/10 12:27:57 [error] 6219#0: *130819912 upstream Imed out (110:
ConnecIon Imed out) while connecIng to upstream, client: 1.2.3.4, server:
okmeter.io, request: "POST /metric/write HTTP/1.1", upstream: "h‘p://
192.168.100.9:8088/metric/write", host: "okmeter.io"
• У какого именно клиента ошибка
• Какой бэкенд не ответил](https://image.slidesharecdn.com/nikolaysivko-161128090127/85/-11-320.jpg)
![Nginx: access_log
1.2.3.4 - - [10/Oct/2016:14:04:38 +0300] "POST /metric/write HTTP/1.1" 200
2 "-" "Go-http-client/1.1" 0.103 - [0.039, 0.064] {192.168.100.5:8088,
192.168.100.4:8088} {504, 200}
• Какой статус вернули клиенту
• Что вернул каждый бэкенд, сколько было попыток
• Сколько ждали каждого бэкенда
• Сколько ждал пользователь](https://image.slidesharecdn.com/nikolaysivko-161128090127/85/-12-320.jpg)
![Лог: сценарий
Вы видите в логе nginx:
….. ”GET /url HTTP/1.1" 504
request_Ime=0.101
upstream_response_Ime=[0.101]
upstream_addr={192.168.1.1:8000}
upstream_status={504}
Что вы будете делать дальше?](https://image.slidesharecdn.com/nikolaysivko-161128090127/85/-33-320.jpg)
![Лог: request_id
Nginx
….. ”GET /url HTTP/1.1" 504
0.101 [0.101] {192.168.1.1:8000} {504} req_id=123456
192.168.1.1:
<Imestamp> id:123456 querying session from session_db1 <Imestamp> id:123456 client
closes connecIon
<Imestamp> id:123456 GET /api/blabla 499 0.101s
PG:
<Imestamp> <pid> <user>@<db> from 192.168.1.1 [vxid:x/y txid:0] [SELECT] LOG:
duraIon: 147.020 ms execute <unnamed>:
/* 123456 */ select * from session where session.id=$1 AND …](https://image.slidesharecdn.com/nikolaysivko-161128090127/85/-36-320.jpg)
Николай Сивко "Хорошо поддерживаемое в продакшне приложение"
- 2. Мир глазами разработчика 1. Есть задача с требованиями 2. Пишу код + тесты 3. Показал demo заказчику 4. Передал в producIon Если баг или проблема в producIon: GOTO #1
- 3. Мир глазами админа • Выкатил новую версию приложения • В 3:00 утра SMS: “HTTP-50x > 20rps” • Приложение жрет 4 ядра, в логе пусто • Фронтенд не дожидается ответа от сервиса за 10s и отдает пользователям 504 • Разработчик просит проверить сеть/БД/… и вообще перезапустить
- 5. С чего обычно начинается DevOps? • ConInuous delivery и деплой 10 раз в час! • Спрячем от разработчика железки за Docker c оркестрацией! • Чтобы все масштабировалось на лету будем ходить за конфигами по сети, целостность нам обеспечит Paxos/Ray! • Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде!
- 6. С чего обычно начинается DevOps? • ConInuous delivery и деплой 10 раз в час! • Спрячем от разработчика железки за Docker c оркестрацией! • Чтобы все масштабировалось на лету будем ходить за конфигами по сети, целостность нам обеспечит Paxos/Ray! • Так мы без проблем будем расти до планетарного масштаба ничего не меняя коде!
- 7. Чего хочет бизнес? • ProducIon должен работать • Если что-то ломается, нужно быстро определить причину и починить • Сделать так, чтобы не повторялось
- 9. Будем говорить про диагностику • Посмотрим, как сделано у популярного софта: nginx, mongo, postgresql • Какие вообще есть подходы? • Как делать у себя?
- 10. • Входящие запросы • Бэкенды • Статика, кэш • Lua, perl, …
- 12. Nginx: access_log 1.2.3.4 - - [10/Oct/2016:14:04:38 +0300] "POST /metric/write HTTP/1.1" 200 2 "-" "Go-http-client/1.1" 0.103 - [0.039, 0.064] {192.168.100.5:8088, 192.168.100.4:8088} {504, 200} • Какой статус вернули клиенту • Что вернул каждый бэкенд, сколько было попыток • Сколько ждали каждого бэкенда • Сколько ждал пользователь
- 13. Nginx: debug log • Показывает все этапы обработки запроса • Можно только для конкретных IP/сетей (debug_connecIon) • Можно в циклический буфер в памяти
- 16. • Данные • Запросы + CPU bound логика (aggregaIon) • Ресурсы: диск, сеть, процессор
- 17. Mongo • serverStatus - server-wide метрики • dbStats- db-wide метрики • collStats – collecIon-wide метрики
- 18. Mongo: query profiler • Capped collecIon с профайлингом запросов • Включается для всех или только для “медленных” • Может негативно повлиять на производительность
- 20. Mongo: тёмные пятна • Какой запрос прямо сейчас всё убивает? • На какие запросы уходят ресурсы? • Какие запросы удерживают локи?
- 21. • Данные • Запросы • Ресурсы: диск, сеть, процессор
- 23. PostgreSQL: запроcы • pg_stat_acIvity – что происходит прямо сейчас • pg_stat_statements – накопленные счетчики по группам запросов
- 24. PostgreSQL: локи • pg_stat_acIvity.wait_event – 9.6+ • pg_locks – можно JOIN на pg_stat_acIvity по pid
- 25. PostgreSQL: тёмные пятна В постгресе почти идельная диагностика. Постгрес умный. Будь как постгрес.
- 26. Зачем мы все это смотрели? • Web приложения похожи на nginx, только больше вычислений после получения данных, у nginx хорошие логи • Mongo – пример того, как всё покрыли счетчиками, но забыли про сценарии использования диагностики • PG – пример того, как должно быть
- 27. Диагностика: вопросы • Чем приложение занято прямо сейчас? • Чем приложение занималось в вчера в 18:43? • На какие задачи/запросы были потрачены ресурсы? • Сколько и каких ошибок было? • Сколько ждали ответа базы вчера/сегодня? • Почему отдали HTTP-400?
- 28. Подходы • Thread/stack dump и аналоги • Лог • Счетчики/таймеры/мгновенные значения
- 29. Thread/stack dump и аналоги • Мгновенный снимок: в каком месте кода находится управление каждого “потока” • Больше про runIme, а не ваш код • Высокоуровневые аналоги: какие запросы сейчас обрабатываем и на какой они стадии
- 31. Высокоуровневые аналоги • PG: pg_stat_acIvity • Mysql: SHOW PROCESSLIST • Apache: mod_status
- 32. Лог • Правильно писать логи очень сложно • Правильно = написать нужное и НЕ писать лишнее • Общего рецепта нет – все системы разные • Предлагаю исходить из сценариев использования
- 33. Лог: сценарий Вы видите в логе nginx: ….. ”GET /url HTTP/1.1" 504 request_Ime=0.101 upstream_response_Ime=[0.101] upstream_addr={192.168.1.1:8000} upstream_status={504} Что вы будете делать дальше?
- 35. Лог: request_id • На входе генерим id запроса (nginx $request_id например) • Ставим заголовком во все запросы дальше: X-Request-Id: 123456 • Во всех сервисах пишем в лог • Можно даже в SQL комментарий
- 36. Лог: request_id Nginx ….. ”GET /url HTTP/1.1" 504 0.101 [0.101] {192.168.1.1:8000} {504} req_id=123456 192.168.1.1: <Imestamp> id:123456 querying session from session_db1 <Imestamp> id:123456 client closes connecIon <Imestamp> id:123456 GET /api/blabla 499 0.101s PG: <Imestamp> <pid> <user>@<db> from 192.168.1.1 [vxid:x/y txid:0] [SELECT] LOG: duraIon: 147.020 ms execute <unnamed>: /* 123456 */ select * from session where session.id=$1 AND …
- 37. Лог: итого • Нужно отличать запросы друг от друга (request id) • Пишем не только законченные действия (бывает нужно ловить залипшие) • Если куда-то идем, пишем конкретный адрес • Пишем все ошибки и как их обработали • Замеряем время значимых операций
- 38. Лог: нагрузка • Подробное логирование создает нагрузку • Если вводим разные уровни логирования, то нужна ручка переключения без перезапуска • К логам можно цеплять парсеры для получения метрик, но это тоже нагрузка
- 39. Метрики приложения • Счетчики событий (ошибки, запросы, …) • Таймеры (замеряем продолжительность каких-то действий) • Мгновенные значения (текущее количество соединений, размер кэша,…)
- 40. Метрики приложения • Теряем часть информации по сравнению с логом • Но сильно дешевле логов • Экспортируем в мониторинг то, что насчитали • Рисуем графики • Настраиваем алерты, если нужно
- 42. Инструменты: <your_lang>-metrics • Либа для вашего приложения, есть для всех ЯП • Аккумулирует замеры в памяти • Экспортирует в различные системы (graphite, influx, лог, …)
- 43. Инструменты: statsd • UDP сервер принимает отстрелы замеров из приложения, агрегирует и экспортирует в мониторинг • Клиенты для всех ЯП • Семантика примерно такая же как в *-metrics • Есть библиотеки с предварительной агрегацией на клиенте
- 44. Счетчики Golang
- 45. Таймеры Golang
- 46. Кейс с HTTP-504
- 48. Цена метрик (golang) • GetOrRegister 122 ns/op • CounterInc 10 ns/op • Timer_Time 879 ns/op • 2xNow 38 ns/op 10.000 rps * (10 таймеров в каждом) = диагностика займет ~9% одного ядра
- 49. Итого • DevOps нужно начинать с диагностики • Диагностика – это просто • Делайте диагностику исходя из сценариев использования • Есть много готовых инструментов • После этого можно docker, CI/CD и 100500 микросервисов :)