KharkovPy #12: I/O in Python apps and smart logging (russian)
-
Upload
max-klymyshyn -
Category
Software
-
view
720 -
download
0
Transcript of KharkovPy #12: I/O in Python apps and smart logging (russian)
@maxmaxmaxmaxМАКСИМ КЛИМИШИНCTO GVMachines Inc.
I/O в приложениях, логи со смыслом
I/O?
Состояние?
Логи?
Проблема роста
Проблема
С ростом пользовательской базы возникают проблемы с редкими событиями.
Проблема
Баги в коде или в бизнес логике, возникающие при очень редком стечении обстоятельств превращаются во вполне конкретное время
команды поддержки и/или разработки, потраченные на анализ
Причины
Проблема
Поскольку количество вариантов произвольных данных на входе и выходе требуют слишком
много времени для тестирования, невозможно их исчерпывающе протестировать.
Решения
Первая мысль
Решения
‣ Больше тестов
‣ Больше QA
‣ Итеративно исправлять
Ну да…
Решения
Подходы
Решения
‣ Хранение состояния, gdb, pdb, strace
‣ текстовые логи
‣ логи цепочек, логи изменений объектов
Состояние
Состояние
Вся информация в оперативной памяти, к которой приложение имеет доступ в данный
конкретный момент времени.
Состояние
1. Мы можем хранить слепки состояния
2. Мы можем хранить вывод утилит типа strace, tcpdump
3. Мы можем хранить лог всех изменений внутри приложения (CREATE-UPDATE-DELETE)
Состояние
Общий недостаток таких подходов является то, что на большом объеме это невозможно сделать,
используя разумное количество ресурсов
Когда уместен анализ
Состояние
1. Когда мы знаем, в чем проблема
2. Когда мы знаем где проблема
3. Когда мы можем частично ограничить выполнение приложения для исследования
Пример pdb
Состояние
# test.py from remote_pdb import RemotePdb RemotePdb('127.0.0.1', 4444).set_trace()
# client shell $ socat readline tcp:127.0.0.1:4444
Пример straceСостояние
# shell strace -f python simple_numbers.py
# output:
read(3, "n = input(\"n=\")\na = range(n+1)\na"..., 264) = 264 read(3, "\n i += 1\nprint lst\n", 4096) = 22 close(3) = 0 munmap(0x7fe4f39ec000, 4096) = 0 stat("simple_numbers.py", {st_mode=S_IFREG|0644, st_size=286, ...}) = 0 open("simple_numbers.py", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=286, ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7ffea1fa1e60) = -1 ENOTTY (Inappropriate ioctl for device)
Умные логи
Простые логи
Умные логи
1. Во время разработки возникает желание писать текстовые логи
2. В зависимости от задачи и домена подробность логов варьирует
3. Зачастую пишутся количественные показатели (количество элементов, размеры тп)
Умные логи
Основной принцип – разработчик пишет логи, которые важны и уместны для него в процессе разработки и тестирования, а не в процессе
эксплуатации
Умные логи
Проблема в том, что программист пишет логи, которые предположительно будут полезны во
время эксплуатации приложения
Умные логи
‣ Важно знать когда произошли изменения состояния
‣ Надо писать что изменилось и когда
‣ Возможно, дампить данные, которые были удалены
Умные логи
obj X CREATE X
LOGAPP
…
…TIM
E
obj X UPDATE X
Пример логаУмные логи
# bad one INFO 2016-02-13 02:32:30,901 invalidator 3351 Changed 1 ids within User, start invalidation... INFO 2016-02-13 02:32:30,916 invalidator 3351 Invalidation of User finished within 0.0149869918823 seconds
# better one INFO 2016-02-13 02:32:30 invalidator User 123123 created INFO 2016-02-13 02:40:04 invalidator User 123123 updated
# best one INFO 2016-02-13 02:32:30 invalidator User 123123 created INFO 2016-02-13 02:40:04 invalidator User 123123 updated, fields: name=Jo => John, phone= “” => 8572043434
Умные логи
‣ Можно построить хронологию событий
‣ Можно пользоваться простым grep-ом
‣ Может разобраться пользователь, без досконального понимания архитектуры приложения
В чем разница?
Умные логи
‣ Сделать логи с контекстом – добавлять кусочек JSON
‣ Дополнительно писать домен-специфичные данные – результаты вычислений, время выполнения и т.п.
‣ Агрегировать разные типы лога и создавать цепочки событий
А что еще можно?
Умные логи
‣ Splunk – Because ninjas are too busy
‣ Logstash – Process Any Data, From Any Source
‣ Graylog – Open source log management that actually works
Что уже есть
Этого недостаточно
Умные логи
1. В первый день использования Splunk мы превысили 5GB/день текстовых логов
2. Это было 3.5 года назад!
Проблемы с логами
Умные логи
1. Объем – нужно аккуратно добавлять в инструменты новые логи, следить за объемом за единицу времени
2. Межнодовый трафик – ноды анализаторов лучше держать в одном датацентре с приложениями
Возможные решения
Умные логи
1. Ротировать с какой-то гранулярностью, архивировать и заливать
2. Держать все в одном ДЦ
3. Уменьшать размер log payload
Выводы
Зачем это надо программисту?
Выводы
‣ Писать поддерживаемые системы это круто и ценно
‣ Думать на шаг больше вперед – это отличает хороших от лучших
Спасибо.
Thanks!
@maxmaxmaxmax