Что скажете о моей реализации логирования?

Question

[v- smerti]

Привет. Я сделал гибкую систему для ведения логов. Я в конфиг могу добавлять новые типы логов и удалять их

"Types"     : [
		"Debug",
		"Info",
		"Warn",
		"Error",
		"Fatal"
	]

Также я могу с лёгкостью добавить тип о котором надо уведомлять на емейл

"EmailSend" : [
		"Error",
		"Fatal"
]

Теперь об архитектуре
Есть библиотека которую я использую в своём коде. Её использование элементарно
logs.New("Debug","test")
Она проверяет данные и пишет их в формате

('time log','type log','message log'),('time log','type log','message log'),('time log','type log','message log')

в редис. В фоне висит демон который каждые n-секунд удаляет данные с редиса и помещает их пачкой в бд (на данный момент в mysql). В итоге я могу хоть 800к логов загнать в бд без большой нагрузки на неё. Какие будут советы по улучшению моей поделки? стоит о ней писать статейку на хабре и заливать на github ? Всем спасибо.

UPD

Данные в редисе pastebin.com/PUvLpRgL
Конфиг pastebin.com/GeZxCnGU

Из данных в редисе я удаляю последнюю кому и пихаю их в sql запрос

DB.Exec("INSERT INTO " + MysqlTable + " (type,time,messages) VALUES" + strings.TrimRight(data, ","))

И обновляю данные в редисе на пробел. И так в вечном цикле (он тормозит с помощью time.Sleep на количество секунд указанных в конфиге)

Я только что 1 000 000 записей в мускуль добавил за 25мс на слабеньком впс (частота 1.6; 1ядро, 2 гб озу) в коробочной конфигурации.

Статья + весь код на хабре

Comments

[Константин Нагибович]

В гитхаб конечно залейте, а для хабра этого маловато.

[v- smerti]

Константин Нагибович: а если для первой статьи?

[Яков Е]

Владимир Грабко: пишите, заодно получите ценных замечаний по реализации.

[v- smerti]

Яков: вместо замечаний получил минусов :D

Answer 1

[Александр Павлюк]

1. Заменить строки константами, желательно числовыми. Будет меньше вероятности ошибиться, ибо константы проверяются при компиляции, плюс, работать будет быстрее (в случае числовых констант).
2. Стоит попробовать RabbitMq для управления очередью записи в БД вместо велосипеда. Или можно попробовать специализированные БД, которые созданы именно для хранения логов.

Comments

[v- smerti]

тут не очередь. тут что то вроде

"INSERT INTO " + MysqlTable + " (type,time,messages) VALUES" + strings.TrimRight(data, ",")

Где strings.TrimRight(data, ",") == пачка добавляемых записей. Работает очень быстро. Я только что 1 000 000 записей в мускуль добавил за 25мс на слабеньком впс (частота 1.6; 1ядро, 2 гб озу) в коробочной конфигурации.

[v- smerti]

и да конфиги все хранятся в json файле который читает как библиотека так и демон

[Александр Павлюк]

Владимир Грабко: тогда зачем вам прослойка в виде демона? Почему не пишете сразу в MySQL? Данные эскейпятся, кстати?

[v- smerti]

Александр Павлюк: да. А надо это для того что бы составить пачку для запроса в редисе. Сейчас накидаю на пастебин пример данных что бы понятнее было

[Александр Павлюк]

Владимир Грабко: ну вот я и говорю, у вас очередь, накапливающая данные и отправляющая их пачками

[v- smerti]

Александр Павлюк: ага. Обновил пост

[Александр Павлюк]

Владимир Грабко: у колонки type в MySQL тип enum, надеюсь?

Answer 2

[index0h]

Магические текстовки нужно заменить на константы.

В итоге я могу хоть 800к логов загнать в бд без большой нагрузки на неё.

Круть. За какой период времени? Какое железо? Нагрузка и на редис и на БД постоянная?

Чем ваш логгер лучше https://github.com/Sirupsen/logrus ?

-- --

Посмотрел статью на хабре, увы там комментировать возможности не имею.

Кровь из глаз((

0. Посмотрите logrus и переименуйте статью на "еще один логгер". Ваш логгер не гибкий, примите за исходную.

1.

Данные в редисе

вы правда думаете кто-то будет это читать?))

2.

Я долго бился голов об клавиатуру искал багу в коде...

верно ошибка не в коде, такого просто делать нельзя. Нужно понимать как работает redis и что происходит при записи/обновлении данных.

3.

1 000 000 записей в мускуль добавилось за 25мл.сек

Что-то слабо верится(( Сколько выполняется запись просто из файла, такого же объема данных. Интересует сравнение времени.

4.

правда в редис эти данные писались около 6 минут

Ну дык правильно, нужно понимать, как работает редис и что происходит, когда вы обновляете ключ, при этом расширяя его непомерно.

5.

конфиг

Кровь из глаз, конфиги если уже json делаете - хотя бы делайте человеко понятными, не используйте массивы там, где должны быть объекты!!!

6.

библиотека

То, что вы делаете в init - это как минимум богомерзко((( Ваш логгер абсолютно не управляем. Его настройка приколочена 100-тыми говздями и заварена арматурой, как у вас вообще возникла мысль говорить о гибкости?))

7.

//Путь к файлу с конфигами
config_file string = "/home/v-smerti/localhost/api/src/microService/config/log.json"

8.

демон

Вы хоть сами смотрели?))

9. Вы нигде не обрабатываете ошибку отправки почты, это вообще как? Если связь с сервером нарушено - логов не будет?))

10. SQL:
`id` int(11) NOT NULL AUTO_INCREMENT,
Я надеюсь вы осмысленно допускаете отрицательные id.

11. SQL:
`type` text NOT NULL,
эт пи*дец.

12. SQL:
KEY `type` (`type`(191))
Если не секрет - почему не 192?

Comments

[v- smerti]

только на редис. На бд 1 запрос каждые n-секунд. Вобщем обновил пост

Answer 3

[Кирилл]

с этим жить нельзя

Answer 4

[sim3x]

Велосипедостроение прекрасно, а для продакшена лучше
https://www.elastic.co/products/kibana

А вообще логи не просто так пишут сначала в текстовик, а не в бд

Comments

[v- smerti]

а не чего что редис пишет в озу потом в файл?)

[sim3x]

Владимир Грабко: так получается еще хуже, если, конечно, потеря 1кк записей не норма на проекте

Answer 5

[Oleg Shevelev]

Посмотрите в сторону уже готовых систем логирования (Graphite, influxdb, прочее) и мониторинга (mrtg, rrd).

Качество вашего кода и дизайна самого приложения прилично низкое. Бенчмарков не делали вообще никаких. Не поймите не правильно, код читается не плохо, достаточно чистый, но по сути бесполезный.

По поводу бенчмарков. Вы утверждаете что "вставка в редис"+"вставка в mysql" работает быстрее чем "вставка в mysql". Это по меньшей мере выглядит заблуждением, потому что тот же редис на том же сервере (на сколько я понял) и производительности прибавить не может. Изменился разве что немного подход к записи в MySQL.

Варианты которые у вас были при написании своего логера:
1. писать в MySQL по запросу каждый раз когда срабатывает некое событие и появляется запись в логе
2. накапливать пачку логов в оперативной памяти - пушить в MySQL точно так же как после редиса (долой редис), за одно научитесь ограничивать потребление памяти (вы ведь не можете бесконечно склодировать данные)
3. накапливать пачку логов в файл (банальный бинарный файл), раз в N минут менять лог-файл
4. вариант тот же что и третий, только старые логи переносить в базу в фоне.

Тут надо так же обратить внимание на то для чего логи пишутся:
1. что бы точно знать кто где и что делал (доктилоскопия пользователей)
2. что бы делать реал-тайм подстройку других алгоритмов в зависимости от поведения пользователей, системы и всего такого
3. что бы просто быть в курсе что приложение упало (кстати в этом случае ваш код отправит емейл?:))

У меня есть задача по сохранении метрики всякой. Условия:
1. MySQL - для показа потом агрегированных графиков и просто списков что сделалось за определённый промежуток времени.
2. Shared-хостинг где можно запускать бинарники, но нельзя делать fork'и и по сути ставить ничего кроме Golang приложения и PHP скриптов.
3. Golang приложение которое щёлкает задачки как семечки и метрик просто туча - считай только их и писать.

Без накопления и группировки MySQL только и занимается что вставкой в таблицу с метрикой. В планах хранить в бинарных блобах. Ставить тот же Графит на Shared-хостинг для такой простой задачки считаю избыточно:)

Comments

[v- smerti]

3. Смотря как отловить падение))

[Oleg Shevelev]

Владимир Грабко: если интересно можете раскрыть тему отлова падений, будет интересно.