Symfony Практика использования Symfony2 Monolog

Lewik · 22 Июн 2014

1. Остается ли на проде логирование с уровня debug? (Мне кажется надо оставлять с info или выше)
2. Остается ли в коде после разработки отправка debug-сообщений? При разработке они указываются где надо и так и остаются на будущее?
2.1. Если да: Отключают ли каким либо образом debug-логирование при разработке, чтобы оно не мешало в логе?

Гуглил, не нашел. Ответ не должен быть истиной в последней инстанции, напишите как вы сами это делаете?

hell0w0rd · 22 Июн 2014

Lewik,
1 - нет
2 - да, я так понимаю
http://symfony.com/doc/current/cookbook/logging/monolog.html

Lewik · 22 Июн 2014

Я вот знал что мне дадут такую ссылку. Я даже картинку приготовил: http://cs618129.vk.me/v618129229/bcbb/2lhge9jNNDM.jpg

За конкретные ответы - спасибо.

Еще вот такой вопрос: логи идут с вот таким заголовком:
Если его отправляет соответствующая "часть", то это security.INFO, event.DEBUG и т.п.
Если я его отправляю - то app.*
Это называется channel

Вот интересно как фильтровать сообщения по этим app.* на уровне настройки окружения. (Для разработки не удобно смотреть сразу общий лог, хочется разделить его) Ну или решать через просмотр логов: http://phpclub.ru/talk/threads/Требуется-просмотрщик-логов.78409

Lewik · 22 Июн 2014

Код:

monolog:
    handlers:
        main:
            type: group
            members: [streamed_all, streamed_info]
        streamed_all:
            type:  stream
            path:  "%path_to_common_log%"
            level: debug
        streamed_info:
            type:  stream
            path:  "%path_to_info_log%"
            level: info
            channels: [app]
        firephp:
            type:  firephp
            level: info
        chromephp:
            type:  chromephp
            level: info

Упорно не работает
Пишет в streamed_info и app.INFO и request.INFO
Надо писать все app.*

Код:

        streamed_info:
            type:  stream
            path:  "%path_to_info_log%"
            channels: [app]

Пробовал, пишет вообще все.

hell0w0rd · 22 Июн 2014

Прочитайте cookbook целиком, полезно

http://symfony.com/doc/current/cookbook/logging/channels_handlers.html#switching-a-channel-to-a-different-handler

Lewik · 22 Июн 2014

Не нашел я этого в кукбуке.

Но

Всем спасибо, разобрался:

Код:

monolog:
    handlers:
        main:
            type:  stream
            path:  "%path_to_common_log%"
            level: debug
        streamed_info:
            type:  stream
            path:  "%path_to_info_log%"
            level: info
            channels:
                type: inclusive
                elements:
                    - app

Надо было убрать групповой логгер и сконфигурировать streamed_info как показано выше. При это будет логировать только нужный канал. Если указать level, то все сооббщения этого канала будут отфильтрованы по указанному уровню.
Еще походу можно

Код:

            channels:
                type: exclusive
                elements:
                    - !app

Который понятно что делает. При exclusive элементы elements должны начинаться c ! иначе получите эксепшн.

Lewik · 22 Июн 2014

Нету этого на сайте:
http://symfony.com/search?q=inclusive&src={referrer:source?}

hell0w0rd · 22 Июн 2014

Я вам прямую ссылку дал, как сделать, а вы таки извратились

Код:

# app/config/config.yml
monolog:
    handlers:
        main:
            type:    stream
            path:    /var/log/symfony.log
            channels: ["!doctrine"]
        doctrine:
            type:    stream
            path:    /var/log/doctrine.log
            channels: [doctrine]

вот так исключают/подключают нужные каналы.

keltanas · 23 Июн 2014

Lewik написал(а):
Ну или решать через просмотр логов: http://phpclub.ru/talk/threads/Требуется-просмотрщик-логов.78409

А просмотрщик, встроенный в профайлер симфони не нравится?
Научись им пользоваться, и вопросов будет на порядок меньше ))

Lewik · 23 Июн 2014

Подразумевал. Сейчас посмотрел. Но он показывает только последний реквест. Надо токен указать на другой реквест. У меня есть и фоновые процессы. Не могу посмотреть все сразу или несколько логов вместе. Не красится. Нет автообновления.
Если я где-то не прав - пожалуйста поправьте =)

hell0w0rd написал(а):
Я вам прямую ссылку дал, как сделать, а вы таки извратились

Да. Действительно =) Я это умею.

keltanas · 23 Июн 2014

Lewik, там есть
1. кнопочка "View last 10"
2. есть панелька "Search" для поиска реквестов по параметрам

Автообновление в этом случае будет злом. Хотя опционально может и имело бы смысл.

keltanas · 23 Июн 2014

Lewik написал(а):
2. Остается ли в коде после разработки отправка debug-сообщений? При разработке они указываются где надо и так и остаются на будущее?

Если посмотреть список сервисов, выводимых через app/console container:debug то видно, что наприме:

Код:

debug.event_dispatcher                                               container Symfony\Component\HttpKernel\Debug\TraceableEventDispatcher                               
event_dispatcher                                                     n/a       alias for "debug.event_dispatcher"

который представляет из себя

PHP:

interface TraceableEventDispatcherInterface extends EventDispatcherInterface
class TraceableEventDispatcher implements TraceableEventDispatcherInterface

    public function __construct(EventDispatcherInterface $dispatcher, Stopwatch $stopwatch, LoggerInterface $logger = null)
    {
        $this->dispatcher = $dispatcher;
        $this->stopwatch = $stopwatch;
        $this->logger = $logger;
        $this->called = array();
    }

Lewik · 23 Июн 2014

keltanas, я использую профайлер в других случаях, но в этом случае - логирование при разработке - мне чет ну совсем не хочется его использовать. Автообновление в данном случае критично. Вообще, можно сделать вебдванольный просмотрщик логов - там уже извращаться можно будет как душа пожелает. Но тут снова минус - просто так покрутить и поискать не совсем получится. Десктопный крутить получится.

Оно не кажет команды.
http://symfony.com/doc/current/book/internals.html#internals-profiler : When enabled, the Symfony2 profiler collects useful information about each request made to your application and store them for later analysis. Ну и гугл это тоже подтверждает.

Тут еще влияет как программист кодит: у меня, например, окно лога должно висеть на всех рабочих столах, чтобы я мог отдебажить что при работе с кодом, что с пхп что еще где то. И делать любое лишнее движение на лог - я совсем не хочу =)

--------

Я не догнал про app/console container:debug =) Ну... есть некий сервис debug.event_dispatcher....
Сейчас мне кажется, что логично в коде оставить в нужных, ключевых местах $this->getLogger->debug('ну очень полезная инфа'). Например в важных ifах или типа того. Оставить в коде то есть навсегда. Я хотел спросить - как люди относятся к такому решению? Пока я нашел только одного, кто против этого (потому что это "чужой" дебаг и его бесит).

... а что бы вы посоветовали почитать/поделать/и т. п. начинающему симфонисту?

keltanas · 23 Июн 2014

Монолог позволяет писать логи куда угодно: в файлы, в мемкеш, в редис, в любое другое хранилище, для которого напишешь handler. И, соответственно, ничто не мешает аяксово брать логи из этого хранилища и крутить как хочешь ))
Профайлер позволяет не просто какие-то там логи анализировать. В нем гораздо больше возможностей.
Но, для консоли, согласен. Надо логи крутить.
С другой стороны - команда консоли - это то же самое, что экшен для хттп-запроса. Т.е. она должна только проксировать другие службы, а сама должна отвечать только за передачу службам параметров и за вывод их фидбека.
Так что выходит, надо писать тесты на те службы, которые использует консоль, и таким образом отлаживать работу приложения. Если вся логика выполняется в коде команды, то значит что-то не так с архитектурой приложения.

В девел-окружении все критичные сервисы оборачиваются в Traceable-декораторы, которые и ведут журналирование работы этих служб. На продакшене службы не декорируются и соответственно отладка в консоль не валится (а зачем продакшен этим забивать?).

На продакшене я обычно включаю отправку сообщений начиная с warning на email. Это позволяет оперативно узнавать о багах еще до того, как юзеры успеют тебе сообщить.

Lewik · 24 Июн 2014

А в курсе, что монолог может писать куда угодно, я в курсе что профайлер много чего умеет.
Да, команда консоли по сути то же что и экшен, я согласен полностью. И относиться к ней надо соответствующе. (я вот налажал в этом смысле, и откормил команды. Перенести будет не сложно.)

Вот это "Traceable-декораторы" первый раз слышу. Загуглю.
По-моему в консоль ничего не выводят. Ну если это не конкретно консольная команда. Если команда предназначена для фоновой работы - не надо ничего выводить в консоль.
А логи уровня debug можно отключить настройкой уровня в хендлерах. Но при этом в коде остаются методы. (Вероятно Traceable это и решает).

А скиньте конфиг монолога типичного продакшена.

keltanas · 24 Июн 2014

Можно так, например. Все зависит от конкретного случая и потребностей

Код:

monolog:
    handlers:
        main:
            type:        fingers_crossed
            action_level: warning
            handler:      grouped
        grouped:
            type:    group
            members: [streamed, buffered]
        streamed:
            type:  stream
            path:  "%kernel.logs_dir%/%kernel.environment%.log"
            level: info
        buffered:
            type:    buffer
            handler: swift
        swift:
            type:      swift_mailer
            from_email: "%mailer_user%"
            to_email:  "%email_for_notification%"
            subject:    An Error Occurred!
            level:      debug

Вот это "Traceable-декораторы" первый раз слышу. Загуглю.

Код изучай.

Lewik · 24 Июн 2014

Взял мне http://symfony.com/doc/current/cookbook/logging/monolog_email.html сбросил =) Я думал что то хитрое сделано =)

АГА!!! Значит ->debug все же оставляют в коде! Я знал =)

keltanas · 24 Июн 2014

Lewik, хэндлер main пропускает только записи уровня warning. А вот если warning сработал, то и уровень debug на почту отправляется.
Но, стоит заметить, что сообщения уровня debug в продакшене отправляют далеко не все каналы.
Так что ты кукбук читаешь, а сути не видишь )) И код все равно не смотришь ))
А изучение исходников фреймворка - это неотъелемая часть изучения любого фреймворка.

Lewik · 24 Июн 2014

http://stickerish.com/wp-content/uploads/2012/03/YouDontSayBlackSS.png
Кеп, как мне наконец то донести до вас, что я понимаю то, что вы пишете. Иначе - я прямо пишу чего не понял. Например про "Traceable-декораторы".
Хотя вы можете попытаться поразить меня магией подстановки %параметров% может, крит пройдет.

Признаться, я бы не посылал почтой не debug, а тот же warning, ну или как минимум отключил канал доктрины в почте. А вот в лог - писал бы все до debug.

Symfony Практика использования Symfony2 Monolog

Lewik

Новичок

hell0w0rd

Продвинутый новичок

Lewik

Новичок

Lewik

Новичок

hell0w0rd

Продвинутый новичок

Lewik

Новичок

Lewik

Новичок

hell0w0rd

Продвинутый новичок

keltanas

marty cats

Lewik

Новичок

keltanas

marty cats

keltanas

marty cats

Lewik

Новичок

keltanas

marty cats

Lewik

Новичок

keltanas

marty cats

Lewik

Новичок

keltanas

marty cats

Lewik

Новичок