globchanskydenis/file_logger

Удобное логгирование в файлы с буфферизацией и множеством настроек

Универсальный файловый логгер

Файл логгирования автоматически меняется (минимум раз в сутки, логи при смене файла не теряются). Параметром MaxHoursToChangeLogFile можно задавать более частую смену файла логгирования (например 6 часов). По умолчанию рекомендуется устанавливать параметр в 24. Уменьшать параметр имеет смысл в случае высокой нагрузки и одновременно частой необходимости проверять логи (для более быстрого поиска по логам).

Формат логгирования - json. Стандартизированные поля (stamp, time, level, error, message), возможность добавлять нестандартизированные поля, ключи будут отсортированы по алфавиту и вставлены между полями error и message. Точное положение полей делает логи более читаемыми. Поле stamp добавляет удобства при автоматическом поиске логов по времени (не придется парсить время каждой строчки).

Буфферизированный вывод в файл (меньше раз дергает диск)

Содержит удобные настройки буфферизации

MaxHoursToChangeLogFile - если число меньше 24, тогда файл логгирования будет меняться больше одного раза в сутки.

MaxBufSize - максимальное количество логов в буффере. Рекомендованного значения нет - все зависит от нагруженности вашего сервиса.

FileWriteDurationSeconds - частота с периодичностью которой срабатывает триггер и если буффер не пустой - сработает запись в файл. Рекомендуется 1-2 секунды.

WriteChanSize - размер буфферизированного канала передачи логов к горутине записи в файл (при срабатывании триггера заполнения буффера (размер которого мы задаем параметром MaxBufSize)). Рекомендуется задавать небольшое значение больше 1.

EnableServiceDebug EnableBusinessDebug EnableQuery EnableImportant EnableDecision- Включение / выключение соответствующих уровней логгирования

LogFileAmount - Если 1 - то все логгируется в дефолтный файл, если 2 - Fatal Error Important дублируется в отдельный файл.

Пример конфигурационного yaml файла

  LoggerAlias:
    ServiceName: file_logger
    LogFolder: "***"  ## тут указать свой локальный путь
    Permissions: 755
    MaxHoursToChangeLogFile: 24  ## дефолтное значение. Если нужно менять чаще - уменьшить число
    MaxBufSize: 50  ## При накоплении 50 сообщений они будут залогированы не дожидаясь тикера
    FileWriteDurationSeconds: 1 ## Автоматическое логгирование содержимого буффера по тикеру
    WriteChanSize: 5 ## Размер буфферизированного канала передачи между горутинами наполняющими буффер и горутиной (она одна) записи в файл
    EnableServiceDebug: true ## включено логгирование этого уровня
    EnableBusinessDebug: true ## включено логгирование этого уровня
    EnableQuery: true ## включено логгирование этого уровня
    EnableImportant: true ## включено логгирование этого уровня
    EnableDecision: true ## включено логгирование этого уровня
    EnableFileForImportant: true ## дублирование логгирования уровней Fatal Error Important
    EnableFileForQuery: true ## Логгирование уровня Query в отдельный файл вместо default

Внутреннее устройство и пример использования

Функция NewLogger является конструктором для объекта LoggerType. Аргументом передается *sync.WaitGroup который просигнализирует о том что логгер закончил работу (горутина записи в файл и горутина тикера остановлены). Конструктор также является синглтоном (гарантирует что будет создан только один элемент, если он уже существует - вернется существующий). Объект потокобезопасен (кроме сеттеров). При старте работы порождается горутина записи в файл и горутина тайм тикера. Их и будет останавливать метод Stop() логгера.

Важно!!! Останавливать работу логгера нужно тогда когда уже все сервисы пишущие в него уже остановили работу, иначе можно получить панику. Поэтому всегда сначала останавливайте сервисы а потом логгер.

У логгера есть сеттеры. Их использование необязательно. Три сеттера принимают интерфейс триггера который будет запущен при логгировании на уровнях Fatal, Error, Important. Предполагается что такая потребность будет при организации мониторинга. Также один сеттер задает функцию обработки ошибок. Эта функция должна разбирать ошибку на составляющие части (код, тип, сообщение). По дефолту ошибка кладется "как есть" в одно поле.

Важно!!! Сеттеры потоко НЕбезопасны. Применять сеттеры нужно до старта горутин которые пишут в логгер.

Существует 9 типов логгирования: Fatal - для паник и всего подобного, Error - для ошибок (НЕ бизнес логики), Warning - для ошибок бизнес логики, Info - стандартный лог, ServiceDebug - дебаг на уровне сервиса, BusinessDebug - дебаг на уровне бизнес логики, Query - логгирование БД, Important - непредвиденные ситуации вроде таймаута запроса к БД, Decision - тот же дебаг на уровне бизнеса (предполагается что этот тип логгирования будет логгировать только принятие решения программой о пути проведения бизнес логики. Например - это оффлайн заявление, поэтому...)

Логгирование можно вести как в 1 дефолтный файл, так и дублировать уровни Fatal, Error, Important в отдельный файл, а также перевести логиирование уровня Query в отдельный файл.

  wg := &sync.WaitGroup{}
  wg.Add(1)
  logger, err := NewLogger(wg)
  if err != nil { /*  handle error  */ }

  /// Задать сеттеры если нужно

  logger.Info(map[string]interface{}{
    "worker_num": 1,
    "field_n":    "value_n",
  }, "тестовый лог")

  /// Отловить сигнал останова программы (gracefull shutdown)
  /// Остановить сервисы использующие логгер (чтобы больше ничего не писало в него)

  logger.Stop()
  wg.Wait()