Логирование действий пользователя php
Логирование в PHP с помощью Zend Log
В каждом реальном PHP приложений время от времени возникают ошибки и исключения, выскакивают предупреждения, сообщения. Если мы не будим записывать эту информацию (логировать), то в один прекрасный момент станет невозможным понять, в какой же части приложения возникают эти ошибки и исключения, и, соответственно, не сможем решить их. К тому же, существуют такие ситуации, когда логирование событий, действий просто необходимо, как в случае, с входом пользователя в систему и выходом из нее, например.
В PHP уже существуют необходимые средства для журналирования: функция error_log() – для отправки сообщения в системный журнал, функция set_error_handler(), для перехвата предупреждений и ошибок. Эти функции могут быть использованы для пользовательского управления ошибками, давая разработчику кода возможность самостоятельного управления логикой обработки и фильтрации ошибок.
Однако такой низкоуровневый доступ приводит к частому дублированию кода, и что еще более важно, такой код более подвержен ошибкам. Поэтому на помощь программисту приходят уже готовые компоненты, хорошо протестированные и зарекомендовавшие себя в “боевых” условиях.
К таким компонентам относится компонент zend-log из фреймворка Zend. Компонент zend-log может быть использован в качестве многоцелевого компонента логирования, эдакий мастер на все руки. Он поддерживает множество форматов журнальных сообщений и разновидностей баз логирования (файлы, базы данных), плюс ко всему имеет проработанную систему фильтрации сообщений и много чего еще. Также zend-log совместим с PSR-3 стандартом логирования. Устанавливается так:
сomposer require zendframework/zend-log
Используется следующим образом (для примера используется файл index.php в корне проекта):
Результат выполнения кода выше:
2017-09-26T10:40:34+03:00 INFO(6): Некая информация
Итоговая строка включает время события, приоритет и сообщение. Формат выводимого сообщения, безусловно, может быть изменен, в случае необходимости с помощью метода setFormatter(). По умолчанию, строка лога описывается следующим шаблоном:
Если Вы захотите изменить формат сообщения, то это делается следующим образом:
// Логировать ошибки
Logger::registerErrorHandler($logger);
// Логировать исключения
Logger::registerExceptionHandler($logger);
Как упоминалось ранее, zend-log предоставляет нам возможность фильтрации сообщений для логирования, т.е. перед тем как записать сообщение в лог, мы может посмотреть удовлетворяет ли оно нашим критериям, и если да, то записываем.
В данном примере, мы будем логировать только те сообщения, чей приоритет меньше или равен критическому (Logger::CRIT).
Полный список приоритетов, определенных в классе Zend\Log\Logger:
Мы также можем фильтровать сообщения на основе регулярных выражений, временных меток и т.д. Таким образом, логирование в PHP – это важная и порой необходимая вещь при разработке web-приложений.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Комментарии ( 0 ):
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Copyright © 2010-2021 Русаков Михаил Юрьевич. Все права защищены.
Что такое логирование?
Известно, что программисты проводят много времени, отлаживая свои программы, пытаясь разобраться, почему они не работают — или работают неправильно. Когда говорят про отладку, обычно подразумевают либо отладочную печать, либо использование специальных программ – дебагеров. С их помощью отслеживается выполнение кода по шагам, во время которого видно, как меняется содержимое переменных. Эти способы хорошо работают в небольших программах, но в реальных приложениях быстро становятся неэффективными.
Сложность реальных приложений
Возьмем для примера типичный сайт. Что он в себя включает?
И это только самый простой случай. Реальность же значительно сложнее: множество разноплановых серверов, системы кеширования (ускорения доступа), асинхронный код, очереди, внешние сервисы, облачные сервисы. Все это выглядит как многослойный пирог, внутри которого где-то работает нами написанный код. И этот код составляет лишь небольшую часть всего происходящего. Как в такой ситуации понять, на каком этапе был сбой, или все пошло не по плану? Для этого, как минимум, нужно определить, в каком слое произошла ошибка. Но даже это не самое сложное. Об ошибках в работающем приложении узнают не сразу, а уже потом, — когда ошибка случилась и, иногда, больше не воспроизводится.
Логирование
И для всего этого многообразия систем существует единое решение — логирование. В простейшем случае логирование сводится к файлу на диске, куда разные программы записывают (логируют) свои действия во время работы. Такой файл называют логом или журналом. Как правило, внутри лога одна строчка соответствует одному действию.
Выше небольшой кусок лога веб-сервера Хекслета. Из него видно ip-адрес, с которого выполнялся запрос на страницу и какие ресурсы загружались, метод HTTP, ответ бекенда (кода) и размер тела ответа в HTTP. Очень важно наличие даты. Благодаря ей всегда можно найти лог за конкретный период, например на то время, когда возникла ошибка. Для этого логи грепают:
Когда программисты только начинают свой путь, они, часто не зная причину ошибки, опускают руки и говорят «я не знаю, что случилось, и что делать». Опытный же разработчик всегда первым делом говорит «а что в логах?». Анализировать логи — один из базовых навыков в разработке. В любой непонятной ситуации нужно смотреть логи. Логи пишут все программы без исключения, но делают это по-разному и в разные места. Чтобы точно узнать, куда и как, нужно идти в документацию конкретной программы и читать соответствующий раздел документации. Вот несколько примеров:
Многие программы логируют прямо в консоль, например Webpack показывает процесс и результаты сборки:
Во фронтенде файлов нет, поэтому логируют либо прямо в консоль, либо к себе в бекенды (что сложно), либо в специализированные сервисы, такие как LogRocket.
Уровни логирования
Чем больше информации выводится в логах, тем лучше и проще отладка, но когда данных слишком много, то в них тяжело искать нужное. В особо сложных случаях логи могут генерироваться с огромной скоростью и в гигантских размерах. Работать в такой ситуации нелегко. Чтобы как-то сгладить ситуацию, системы логирования вводят разные уровни. Обычно это:
Поддержка уровней осуществляется двумя способами. Во-первых, внутри самой программы расставляют вызовы библиотеки логирования в соответствии с уровнями. Если произошла ошибка, то логируем как error, если это отладочная информация, которая не нужна в обычной ситуации, то уровень debug.
Во-вторых, во время запуска программы указывается уровень логирования, необходимый в конкретной ситуации. По умолчанию используется уровень info, который используется для описания каких-то ключевых и важных вещей. При таком уровне будут выводиться и warning, и error. Если поставить уровень error, то будут выводиться только ошибки. А если debug, то мы получим лог, максимально наполненный данными. Обычно debug приводит к многократному росту выводимой информации.
Уровни логирования, обычно, выставляются через переменную окружения во время запуска программы. Например, так:
Существует и другой подход, основанный не на уровнях, а на пространствах имен. Этот подход получил широкое распространение в JS-среде, и является там основным. Фактически, он построен вокруг одной единственной библиотеки debug для логирования, которой пронизаны практически все JavaScript-библиотеки как на фронтенде, так и на бекенде.
Принцип работы здесь такой. Под нужную ситуацию создается специализированная функция логирования с указанием пространства имен, которая затем используется для всех событий одного процесса. В итоге библиотека позволяет легко отфильтровать только нужные записи, соответствующие нужному пространству.
Запуск с нужным пространством:
Ротация логов
Со временем количество логов становится большим, и с ними нужно что-то делать. Для этого используется ротация логов. Иногда за это отвечает сама программа, но чаще — внешнее приложение, задачей которого является чистка. Эта программа по необходимости разбивает логи на более мелкие файлы, сжимает, перемещает и, если нужно, удаляет. Подобная система встроена в любую операционную систему для работы с логами самой системы и внешних программ, которые могут встраиваться в нее.
С веб-сайтами все еще сложнее. Даже на небольших проектах используется несколько серверов, на каждом из которых свои логи. А в крупных проектах тысячи серверов. Для управления такими системы созданы специализированные программы, которые следят за логами на всех машинах, скачивают их, складывают в заточенные под логи базы данных и предоставляют удобный способ поиска по ним.
Здесь тоже есть несколько путей. Можно воспользоваться готовыми решениями, такими как DataDog Logging, либо устанавливать и настраивать все самостоятельно через, например, ELK Stack
Логирование всех POST и GET запросов
Простой способ вести логи средствами php. Статья рассчитана для новичков в программировании.
Бывают ситуации, когда необходимо посмотреть входящие запросы ко всем файлам CMS, либо к файлам в отдельно взятой директории. При большом числе посетителей сайта, анализ файлов access.log становится затруднительным.
Представленный ниже пример отлично справляется с этой задачей. Данный способ ведения логов рекомендуется использовать «здесь и сейчас», непосредственно на время отладки. В отличие от стандартного способа, предлагаемого любым нормальным хостинг-провайдером, в данном примере не предусмотрена очистка логов, а по сему его стоит использовать кратковременно, во избежание разрастания файлов post.log и get.log. Данный модуль позволяет записывать лог всех POST и GET запросов к php файлам в выбранной папке (включая вложенные папки).
1. Для начала создаём в корне сайта папку modules, в которой в свою очередь создаём папку log.
2. В ней создадим 2 файла. Назовём их post.log и get.log. В них мы будем записывать логи POST и GET запросов соответственно.
3. В этой же папке создадим файл save_log.php со следующим содержимым:
Кратко разберем данный файл. Используя суперглобальный массив $_SERVER, определяем путь к корневой директории сервера. Затем, используя конкатенацию, получаем полный путь к файлам get.log и post.log. В итоге в переменной $file_get получаем путь вида: «/home/site/public_html/modules/log/get.log«.
Затем, в зависимости от типа запроса, открываем файл post.log, либо get.log, с параметром «a«. Благодаря данному параметру, при каждой последующей записи, указатель перемещается в конец файла. Таким образом, в отличие от параметра «w«, при добавлении новых записей, старые не удаляются.
При помощи функции var_export, записываем информацию о POST, либо GET запросе. Не забываем закрыть файл при помощи функции fclose.
Отлично. Теперь все POST и GET запросы, приходящие на файл save_log.php, бережно сохраняются. Но как же сохранить запросы к другим файлам?
4. Для этого воспользуемся файлом .htaccess. Его необходимо создать в директории, для которой нужно вести логи. В качестве примера используем файл .htaccess, находящийся в корневой папке сайта. Допишем в начало файла следующую строчку:
Где /home/site/public_html/ — путь до корневой папки сайта.
Как правильно писать логи (?)
Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).
Есть такая linux утилита, а также по совместительству сетевой протокол под названием syslog. И есть целый набор RFC посвящённый syslog, один из них описывает уровни логирования https://en.wikipedia.org/wiki/Syslog#Severity_level (https://tools.ietf.org/html/rfc5424). Согласно rfc 5424 для syslog определено 8 уровней логирования, для которых также дается краткое описание. Данные уровни логирования были переняты многими популярными логерами для разных языков программирования. Например, http://www.php-fig.org/psr/psr-3/ определяет те же самые 8 уровней логирования, а стандартный Ruby logger использует немного сокращённый набор из 5 уровней. Несмотря на формальное указание в каких случаях должен быть использован тот или иной уровень логов, зачастую используется комбинация вроде debug/info/fatal — первый для логирования во время разработки и тестирования, второй и третий в расчёте на продакшен. Потом в какой то момент на продакшене начинает происходить что то не понятное и вдруг оказывается, что info логов не хватает — бежим включать debug. И если они не сильно нагружают систему, то зачастую так и остаются включенными в продакшен окружении. По факту остаётся два сценария, когда нужно иметь логи:
В языке Go в котором всё упрощено до предела, стандартный логер тоже прилично покромсали и оставили следующие варианты:
Я часто при написании программы с нуля повсеместно использую debug уровень для логирования с расчётом, что на продакшене будет выставлен уровень логирования info и тем самым сократится зашумлённость сообщениями. Но в таком подходе часто возникают ситуация, что логов вдруг становится не хватать. Трудно угадать, какая информация понадобиться, что бы отловить редкий баг. Возможно рационально всегда использовать по умолчанию уровень info, а в обработчиках ошибок уровень error и выше. Но если у вас сотни и больше сообщений лога в секунду, то тогда наверно есть смысл тонкой настройки между info/debug. В таких ситуациях уже имеет смысл использовать специализированные решения что бы не просаживать производительность.
Есть ещё тонкий момент, когда вы пишите что то вроде logger.debug(entity.values) — то при выставленном уровне логирования выше debug содержимое entity.values не попадёт в лог, но оно каждый раз будет вычисляться отъедая ресурсы. В Ruby логеру можно передать вместо строки сообщения блок кода: Logger.debug < entity.values >. В таком случае вычисления будут происходить только при выставленном соответствующем уровне лога. В языке Go для реализации ленивого вычисления в логер можно передать объект поддерживающий интерфейс Stringer.
После того, как разобрались с использованием уровней логов, нужно ещё уметь связывать разрозненные сообщения, особенно это актуально для многопоточных приложений или связанных между собой отдельных сервисов, когда в логах все сообщения оказываются вперемешку.
Типичный формат строки сообщения в логе можно условно разделить на следующие составные части:
Но с единым контекстом в рамках запроса возникает проблема с различными ORM, http клиентами или другими сервисами\библиотеками, которые живут своей жизнью. И ещё хорошо, если они предоставляют возможность переопределить свой стандартный логер хотя бы глобально, а вот выставить контекст для логера в рамках запроса зачастую не реально. Данная проблема в основном актуальна для многопоточной обработки, когда один процесс обслуживает множество запросов. Но например в фрэймворке Rails имеется очень тесная интеграция между всеми компонентами и запросы ActiveRecord могут писаться в лог вместе с глобальным контекстом для текущего сетевого запроса. А в языке Go некоторые библиотеки логирования позволяют динамически создавать новый объект логера с нужным контекстом, выглядит это примерно так:
После этого такой экземпляр логера можно передать как зависимость в другие объекты. Но отсутствие стандартизированного интерфейса логирования (например как psr-3 в php) провоцирует создателей библиотек хардкодить малосовместимые реализации логеров. Поэтому если вы пишите свою библиотеку на Go и в ней есть компонент логирования, не забудьте предусмотреть интерфейс для замены логера на пользовательский.
Логирование в распределенном php-приложении
В статье пойдет речь о том, какую пользу оказывает логирование. Расскажу о логах по PSR. Добавлю немного личных рекомендаций по работе с уровнем, сообщением и контекстом логируемого события. Будет приведен пример, как можно организовать логирование и мониторинг с помощью ELK в приложении, написанном на Laravel и запущенном через Docker на нескольких инстансах. Распишу важное правило системы оповещения. Приведу пример скрипта, который поднимает одной командой весь стек мониторинга.
Польза логирования
Хорошо организованное логирование позволяет, как минимум, следующее:
Сама по себе запись в лог вам всего этого не скажет, но с помощью логов будет возможность самостоятельно узнать подробности событий, либо настроить систему мониторинга логов, которая будет иметь возможность оповещать о проблемах. Если сообщения в логах сопровождаются достаточным объемом контекста, то это значительно упрощает отладку, потому что вам будет доступно больше данных о ситуации, в которой произошло событие.
Чем писать и что писать
Частью php-сообщества разработаны рекомендации по некоторым задачам написания кода. Одна из таких рекомендаций PSR-3 Logger Interface. Она как раз описывает то, чем нужно логировать. Для этого разработан интерфейс Psr\Log\LoggerInterface пакета «psr/log». При его использовании нужно знать о трёх составляющих события:
Уровни события по PSR-3
Уровни заимствованы из RFC 5424 — The Syslog Protocol, примерное описание их следующее:
Описание есть, но следовать им не всегда получается легко, из-за сложности определения важности некоторых событий. Например, в контексте одного запроса не удалось выполнить обращение к подключаемому ресурсу. При записи этого события мы не знаем, один ли такой запрос завершился неудачей, а может только у одного пользователя такие запросы завершаются неудачей. От этого зависит, требуется безотлагательное вмешательство или это редкий случай, может подождать или даже его можно проигнорировать. Такие вопросы решаются в рамках мониторинга логов. Но уровень определить всё равно надо. Поэтому об уровнях логирования в команде можно договориться. Пример:
Сообщение события
Контекст события
В Laravel можно для событий автоматически вписывать в контекст данные. Это можно сделать через Global Log Context (только для непойманных исключений или через report() ), либо через LogFormatter (для всех событий). Обычно, добавляется информация с id текущего пользователя, request URI, IP, request UUID и подобное.
При использовании Elasticsearch в качестве хранилища логов следует помнить, что в нём используются фиксированные типы данных. То есть, если вы передавали в контексте customer_id числом, то при попытке сохранить событие с другим типом, например строкой (uuid), то такое сообщение не запишется. Типы в индексе фиксируются при первом получении значения. Если индексы создаются каждый день, то новый тип запишется только на следующий день. Но даже это не избавит от всех проблем, потому что для Kibana типы будут смешанными и часть операций, привязанных к типу, будет недоступна пока будут смешанные индексы.
Для предотвращения этой проблемы рекомендую придерживаться правил:
Вызов логгера из кода
Для быстрой записи события в лог можно придумать несколько вариантов. Рассмотрим некоторые из них.
Где в коде вызывать логгер
При организации кода в проекте может возникнуть вопрос, в каком классе мне следует писать в лог. Должен ли это быть сервис? Или это нужно делать там, откуда сервис вызываем: контроллер, фоновая задача, консольная команда? Или каждое исключение само должно решать, что ему писать в лог с помощью его метода report (Laravel)? Простого ответа сразу на все вопросы нет.
Может показаться, что мы всегда можем логировать только в сервисах. Действительно, в некоторых сервисах можно сделать логирование. Но рассмотрим сервис, который не зависит от проекта и, вообще, мы планируем вынести его в отдельный пакет. Тогда этот сервис не знает о своей важности в проекте, а, значит, не сможет определить уровень логирования. Например, сервис интеграции с конкретным SMS-шлюзом. Если мы получили сетевую ошибку, то это ещё не значит, что она достаточно серьезная. Возможно, в системе есть сервис интеграции с другим SMS-шлюзом, через который будет вторая попытка отправки, тогда ошибку от первого можно репортить как warning, а ошибку второго как error. Только вот все эти интеграции должны быть вызваны из другого сервиса, который как раз и будет логировать. Получается, что ошибка в одном сервисе, а логируем в другом. Но иногда у нас нет сервиса-обёртки над другим сервисом — мы вызываем сразу из контроллера. В этом случае я считаю допустимым писать в лог в контроллере вместо того, чтобы писать сервис-декоратор для логирования.
Пример, показывающий использование зависимости и передачу контекста:
Куда писать
Рассмотрим следующие варианты.
* В php-fpm 7.2 при записи логов в stdout получаем «WARNING: [pool www] child X said into stdout. «, и длинные сообщения обрезаются. Одно из решений этой проблемы здесь. В php-fpm 7.3 такой проблемы нет.
Варианты формата записи:
Любой из вариантов предполагает, что логи подвергаются маршрутизации — как минимум, отправке в единую систему обработки (хранения) логов по следующим причинам:
Какую комбинацию всех возможностей мест назначений и форматов записи выбрать вы можете решить для вашего проекта самостоятельно.
Использование Filebeat + ELK + Elastalert
Кратко роль каждого сервиса можно описать так:
Дополнительно можно: zabbix, metricbeat, grafana и прочее.
Теперь подробнее о каждом.
Filebeat
Logstash
Умеет принимать события от многих источников, но здесь мы рассматриваем Filebeat.
В каждом событии кроме самого события из stdout/stderr есть метаданные (хост, контейнер и т. п.). Много встроенных фильтров обработки: парсить по регуляркам, разбирать json, изменять, добавлять, удалять поля и т. п. Подходит для парсинга как логов приложения, так и nginx access.log в произвольном формате. Умеет передавать данные в разные хранилища, но здесь рассматриваем Elasticsearch.
Elasticsearch
Elasticsearch очень мощный инструмент для большого спектра задач, но с целью мониторинга логов его можно использовать зная лишь некоторый минимум.
Сохраненные события — это документ, документы хранятся в индексах.
Каждый индекс — это схема, в которой определен тип для каждого поля документа. Нельзя сохранить событие в индексе, если хотя бы у одного поля неподходящий тип.
Разные типы позволяют делать разные операции над группой документов (для чисел — sum, min, max, avg и т. п., для строк — нечеткий поиск и так далее).
Для логов руководства обычно рекомендуют использовать дневные индексы — каждый день новый индекс.
Обеспечение стабильной работы Elasticsearch с ростом объема данных — задача, требующая более глубоких знаний об этом инструменте. Но быстрым решением проблемы стабильности можно выбрать автоматическое удаление устаревших данных. Для этого я предлагаю разбивать в logstash уровни событий по разным индексам. Это позволит дольше хранить редкие, но более важные события.
Для автоматического удаления устаревших индексов предлагаю использовать программу от Elastic Curator. Запуск программы добавляется в расписание Cron, сама конфигурация может храниться в отдельном файле.
Для долговечного хранения событий предлагаю использовать альтернативные системы хранения, которые могут быть подключены как сервисы приёма от Filebeat или Logstash, либо полностью отдельно. В недавних версиях Elasticsearch ввели разбиение на горячие-теплые-холодные индексы, возможно, их следует вам рассмотреть.
Kibana
Kibana здесь используется как инструмент для чтения журнала событий. Это веб-приложение, которое выполняет запросы к Elasticsearch. Позволяет строить дашборды с разными визуализациями показателей.
Типичное использование Kibana — это ежедневный просмотр списка недавних событий в разделе Discovery с некоторыми фильтрами. Например, отдельная страница Discovery с отображением списка недавних событий из app с уровнем warning и выше, где выводятся столбцы time, message, exception class, host, client_id.
Другой пример, страница Discovery с отображением списка недавних событий из nginx, у которых неуспешные статусы и не 404 с отображением столбцов time, message, request, status.
Кроме того Kibana используется для дебага, так как в ней можно быстро отфильтровать события: по сообщению, по уровню, по любому значению из контекста. Например, выбрать все события по конкретному клиенту (делается в один клик по одному событию нужного клиента).
Elastalert
Elastalert используется для выполнения запросов к Elasticsearch и оповещению на основе их результатов. Другими словами, алертинг. Есть широкий набор типов правил, с помощью которых можно построить эффективную систему оповещения об отклонениях.
Для каждого правила можно указать расписание запуска, интервал для повторной отправки по тому же условию (реалерт), список сервисов для оповещения и многое другое.
Некоторые примеры правил:
При подключении автоматических оповещений о событиях следует не допустить очень серьезную ошибку — слишком частое оповещение. Я рекомендую настраивать автоматическое оповещение таким образом, чтобы уведомления шли только по событиям, требующим безотлагательного вмешательства. Всё остальное нужно привыкать смотреть самостоятельно используя Kibana.
Если вы настроили правило, например, что успешных http-кодов должно быть не менее 75% за час, затем получили оповещение об отклонении, проверили и обнаружили, что ничего страшного не произошло, то правило нужно менять. Если какое-то правило постоянно срабатывает, но ничего критичного не происходит, и уже нечего менять в правиле, то лучше его отключить совсем.
Если ваша система постоянно дает сбой неделю за неделей, то, скорее всего, вы и сами уже знаете, чего ждать в списке событий в Kibana, поэтому отключите автоматические уведомления и проверяйте состояние вручную.
Рекомендую границу в 5 уведомлений в неделю в среднем. Если их получается больше, значит, это уже не внезапные отклонения, а ожидаемые, а значит, уведомления по ним не нужны.
Я уделил особое внимание частоте оповещений, потому что нарушение этого правила приводит к полному игнорированию оповещений. Это сводит пользу автоматических уведомлений на нет.
При получении оповещения хорошей привычкой может стать обзор ситуации через просмотр Kibana по всем недавним событиям. Это позволит точнее оценить ситуацию и корректно расставить приоритеты при решении проблемы.
Всё вместе
Всё описанное можно запускать в docker-контейнерах. Причём всё конфигурируется таким образом, что всем стеком можно пользоваться как локально при разработке, так и в staging- и production-окружениях, где переменными остаются только переменные окружения.
Все описанные сервисы, за исключением Elastalert, позволяют использовать переменные окружения в конфигурациях. Проблему Elastalert удалось разрешить, используя команду вида
envsubst /opt/elastalert/config.yaml в entrypoint-скрипте и доустановкой зависимостей, чтобы это работало.
Конфигурации каких сервисов стека оставлять в репозитории проекта, а какие выносить в отдельный репозиторий мониторинга, зависит от наличия других проектов и того, как они будут переиспользовать стек.
Такой вариант стека имеет следующие преимущества:
Стоит заметить, что в данном подходе не используется ни один из xpack-плагинов.
Допустим вариант использования docker-compose. Главное, что основная конфигурация, состоящая из Dockerfile-ов, конфига Filebeat, конфигов Logstash, правил оповещения, правил автоудаления индексов, находится под системой контроля версий, получая возможность быстрого переразвертывания, хранения истории изменений и всех других преимуществ VCS.
Важно уделять внимание автоматической проверки работоспособности стека. Я предлагаю организовать проверку следующим образом. В самом приложении создается задача, исполняемая по расписанию (в Laravel для этого есть scheduler), скажем, раз в неделю за 5 минут до дейлимитинга. Сама задача вызывает логгер и записывает сообщение с уровнем ALERT. Если весь стек функционирует нормально, то вы получите оповещение. Если такого оповещения нет, а вы к нему привыкли, то это станет сигналом для разбирательств.
Заключение
Я описал, какую пользу можно извлечь из логирования, рассказал о некоторых вариантах, которые можно выбирать на каждом шаге построения стека логирования и мониторинга. Привёл пример стека с описанием каждого компонента. Надеюсь, вы нашли что-то полезное для себя в этом материале. Данные мной рекомендации были опробованы на нескольких проектах и хорошо себя показали в бою. Но следует помнить, что всегда есть, что улучшить.