@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