Комментарии 16
Чем вам https://sentry.io/ не угодил? Там есть все что вам нужно и даже больше. Подключается и настраивается быстро и легко
Битриксоиды любят создавать проблемы из ничего и решать их, придумывая костыли.
Нет обёртки для чистого PHP, поддерживаются фреймворки Laravel и Symfony. Yii2, Zend - так же в пролёте.
Есть PHP SDK от Сентри. В ваш метод write можно добавить вызов сентри и готово :)
Описаный подход будет работать на небольших проектах с малым количеством ошибок. А если так, то и старый-добрый php-errors log можно поразбирать раз в день :)
Немного комментов по теме:
много отдельных маленьких файлов - плохо, тем более в одной директории. Что если использовать SQLite? Не потеряв в функционале и стабильности вы получите более удобную работу с данными и возможность расширения функционала в будущем;
мне, как разработчику, не хватает информации: как часто ошибка возникала и когда (время);
получать айди ошибки из текста+файла+строки, не самая лучшая идея. Например текст ошибки может содержать в себе переменную составляющую (типа Notice: Undefined offset: 102 <<), то же самое и со строкой - она может меняться при изменении вышестоящего кода;
при возникновении ошибки необходимо всё-таки её проверять во всех директориях (ignore, processed, system) - в статье мы проверяем только processed;
не вешайте на хэндлер ошибок слишком много (в статье вы допускаете отправку почты на возникновение ошибки). В идеале хэндлер должен содержать в себе какой-то один условный сисколл (типа запись в файл) и не заниматься поиском файликов в разных директориях, итп.
"Шел в комнату, попал в другую" © Горе от ума
Довольно странное построение статьи, которая начинается про забавных енотисов, затем идёт весьма спорное утверждение про то что их все игнорируют (видимо, это в порядке вещей для экосистемы битрикс, как и работа со сваленными в кучу входными данными через $_REQUEST), и дальше объясняется про обращение к несуществующему элементу массива, которое в современном РНР внезапно никакой не "енотис", а полноценный E_WARNING.
И тут выясняется, что на самом деле статья представляет собой несколько бессвязные абстрактные размышления о написании самопального трекера ошибок для битрикса. А про "енотисов" уже никто до самого конца и не вспоминает.
Хотя от статьи с таким заголовком ожидаешь хоть каких-то рекомендаций по борьбе с этими самыми "енотисами". Хотя бы пояснения — а как, собственно, отключить игнорирование ошибок уровня E_NOTICE. А так же стандартного предупреждения о том что бездумное подавление этой ошибки через null coalescing operator не слишком будет отличаться от игнорирования. И что надо в первую очередь разделить переменные на создаваемые в скрипте и получаемые извне.
И для первых ввести жесткое правило, что внутренние переменные всегда должны быть инициализированы (при этом для комплексных структур отлично подойдут DTO).
Внешние же переменные в свою очередь разделить на обязательные и необязательные. И проверку на существование делать только для первых. А для обязательных определиться со стратегией, которая с одной стороны, не будет являться тем же игнорированием, а с другой — не будет заваливать логи фальшивыми срабатываниями, когда очередной скрипт-кидди решит попарсить ваш сайт, забыв заполнить половину полей формы. Но опять же, эту проблему надо решать только по мере её появления, а по умолчанию использовать нотисы для внешних переменных строго по назначению — разбираться с тем, почему обязательная переменная не была передана.
Хз, действительно велосипед. Таких самодельных логов уже насмотрелся. Нужно использовать готовое.
Что касается обработки исключений - считаю что исключения обрабатывать в большинстве случаев не нужно, как минимум потому, что правильно это делать умеют единицы, у остальных вся обработка сводится к подавлению, что приносит только вред: попробуй потом найди, почему код не работает как нужно.
Исключения нужно обрабатывать в действительно исключительных ситуациях, и только те, что ожидаешь: если исключение для алгоритма естественно, является нормальным сценарием. Например как при работе с апи исключение при попытке соединения - нормальная ситуация, и требует просто отключить логику, которая зависит от апи, падать тут смысла нет, если сценарий работы без апи предусмотрен. И опять же - тут обрабатываем только ошибки коннекта, остальные случаи обрабатывать обычно не стоит: в случае неожиданной ошибки апи гораздо ценнее если код полностью упадет, заставив обратить внимание на действительно исключительную ситуацию - очевидно что апи поменялось, нужно изучить вопрос и адаптировать код под новые условия, а не подавлять ошибку.
Что касается логирования - по мне требуется использовать как минимум три подхода: отдельные каналы с группировкой по сущности (например заказу, чтобы все, относящееся к заказу, было доступно в отдельном канале), отдельные каналы на каждую из ключевых подсистем (чтобы исследовать работу подсистемы в проблемных ситуациях - можно поднять логи конкретной системы и посмотреть что было на входе, на выходе, в ключевых точках, отладка с такими логами - минутное дело), и отдельные каналы на общие исключения, которые стоит перехватывать через отдельные неблокирующие обработчики исключений (что кстати редко наблюдаю) - это те самые проблемы, на которые нужно обращать внимание в первую очередь, такие логи показывают жёсткие падения, что явно ненормальная ситуация.
Все эти логи, особенно по подсистемам, весят очень много - их хранение отдельная большая тема. И файловые логи тут - наихудшее решение: они огромные, нет удобных инструментов для работы/поиска/анализа. Гораздо удобнее использовать специальные брокеры/бд для логов, типа эластика, где можно партицировать/удалять/фильтровать отдельные логи по каналам/времени/содержимому, и сами записи из множества каналов/логов можно сшивать в единый поток или анализировать отдельно - это гораздо удобнее, чем возиться с файлами или собирать данные по нескольким файлам. К тому же размер логов - больная тема, файлы менеджерить не особо удобно. А с такими бд можно всегда устаревшие логи отправить в архив, и поднять обратно, если всплывёт что-то, что требует исторического анализа.
Нотисы же тут мало интересны - это не особо критичные проблемы в коде, больше относящиеся к стилю, их лучше отлавливать через дебаг-панели, там просто висит счётчик нотисов, есть время/желание - бери и рефактори, убирай устаревший код, но конкретно на cms это неблагодарная работа - сами cms это источник тысяч нотисов.
А почему, собственно, решили писать велосипед вместо того же Elastic? Он же как раз заточен изначально под сбор информации из логов и её анализ
Позволю себе ответить за автора цитатой из статьи: "Это отдельное ПО, которое нужно настраивать, поддерживать и оплачивать вычислительные мощности."
Если у меня простой L(A)MP (а то и шаред - так исторически сложилось) и CMS с тремя пользователями в день и один разраб - куда здесь эластик.. :) Оверинжениринг - лютое зло.
Я извиняюсь, а вот этот вот самопал из статьи на таком сетапе будет не оверинжениринг? :)
Позволю себе ответить цитатой из другого комментатора: если у вас CMS с тремя пользователями в день и один разраб, "то и старый-добрый php-errors log можно поразбирать раз в день :)".
У нас вот не CMS, а небольшой магазинчик с тремя (сотнями тысяч) пользователей в день, и мы прекрасно справляемся с обычными логами. Потому что ошибка — это не поразбирать, а форс-мажор, это значит что что-то поломалось — или в инфраструктуре, или в новом коде косяк, который не получилось отловить при стандартном тестировании — и надо чинить, а не "складировать".
Сейчас конечно внедряется всякая кибана, но мне как-то надёжнее со своим простым сторожевым пёсиком, который начинает гавкать в почту и телеграмм, если ошибки в лог идут потоком, и сразу притаскивает пример ошибки.
а вот этот вот самопал из статьи на таком сетапе будет не оверинжениринг? :)
отнюдь. Это какая-никакая степень удобства по разбору ошибок вместо tail.
надо чинить, а не "складировать"
бесспорно, но речь в статье про "енотисы", которые возникают постоянно и не всегда в подконтрольном коде.
Сейчас конечно внедряется всякая кибана, но мне как-то надёжнее со своим простым сторожевым пёсиком
если есть ресурсы (и необходимость) на поддержку ELK - очень здорово, "сырые" логи перестают работать тогда, когда в инфре становится >=2 скриптовых машин и появляется необходимость в централизованной обработке логов.
Не, ну вы уж определитесь :)
Или речь про "CMS с тремя пользователями в день" — и тогда всё, что сложнее tail, здесь будет overkill.
Или про систему где нотисы льются потоком, и все равно пилить какую-то систему сортировки. Но тогда непонятно, зачем конкретно этот самопал, и почему нельзя делать сразу нормально.
Если бы автор хотя бы приложил к статье код, то тогда, возможно, для каких-то частных случаев, можно было бы говорить о его применении. А так — я реально не вижу, зачем кто-то будет их применять вместо того чтобы делать сразу нормально.
Хотя возможно, конечно, это специфическое решение для какого-то адова легаси типа битрикса. Тут я не копенгаген, не сталкивался.
Определиться с чем? :)
"сразу нормально" это как? обычно приходится выбирать: или сразу, или нормально))
Тут и без кода понятно какую проблему автор решал для себя, и, в целом, единственная "нормальная" альтернатива - это sentry, но есть нюансы в виде непостоянства нашего интернета (да и мира в целом), а если разворачивать on premise - то выйдет дороже ELK.
Ну и да, описан специфичный кейс, который вполне может кому-нибудь пригодиться как идея. Доработать немного и будет легковесный менеджер ошибок.
Любой нормальный фреймворк в эксепшены превратит ваши енотисы и хз кто еще таким не пользуется.
Ну а для не нормальных set_error_handler.
Ловим Енотисов при отладке на PHP: руководство для программистов