Для начала повторю то, что каждый разработчик должен знать об этом — надо предохраняться.
Управление логгированием в systemd
12 min
Tutorial
Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.
В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает систематизацию и поиск.
Хранение логов в бинарных файлах также позволяет избежать сложностей с использованием парсеров для разных видов логов. При необходимости логи можно без проблем переконвертировать в другие форматы (более подробно об этом будет рассказано ниже).
Journal может работать как совместно с syslog, так и полностью заменить его.
Для просмотра логов используется утилита journalctl. Об особенностях и тонкостях работы с ней мы расскажем в этой статье.
История одного исследования в log4net и ускорение его более чем в 10 раз
7 min
Начну с того, что данная оптимизация будет работать только, если вы используете значения взятые из Properties (например: NDC, MDC) и не используете UserName.
Делаем лог-систему для Minecraft
5 min
Приветствую, Хаброжители!
Сегодня речь пойдет о мире, о который большинство из вас не знает, но при этом там крутятся многие отличные инженеры-разработчики и большие деньги. Да, как ни странно, речь пойдет о Minecraft.
Minecraft — игра-песочница и на мультиплеер-серверах остро стоит проблема гриферства (от англ. griefing — вредительство), когда игроки рушат чужие постройки. На серверах с этой проблемой справляются по-разному. На публичных используют плагин на 'приват', на остальных же все строится на доверии.
Еще один из способов предотвратить гриферство — бан всех гриферов. И для того чтобы вычислить их, приходиться логгировать установку и удаление блоков. Собственно, о процессе создания такой лог-системы и пойдет речь дальше.
Давайте поговорим о ведении логов
5 min
Translation
Этот пост вдохновлен темой в форуме Go Forum, начатой Nate Finch. Этот пост сконцентрирован на языке Go, но если пройти мимо этого, я думаю, идеи представленные тут широко применимы.
Пакет log в Go не имеет уровней для логов, вы можете сами вручную добавить приставки DEBUG, INFO, WARN, и ERROR. Также logger тип в Go не имеет возможности включить или выключить эти уровни отдельно для выбранных пакетов. Для сравнения давайте глянем на несколько его замен от сторонних разработчиков.
glog от Google имеет уровни:
Посмотрим на другую библиотеку, loggo, разработанную для Juju, в ней доступны уровни:
Loggo также имеет возможность задать уровень детализации лога для нужных пакетов по отдельности.
Перед вами два примера, явно созданных под влиянием других библиотек для логирования на других языках.
Фактически их происхождение можно проследить до syslog(3), возможно, даже раньше. И я думаю, что они не правы.
Я хочу занять противоречивую позицию. Я думаю, что все библиотеки журналов плохи, потому что предлагают слишком много функций; ошеломляющий набор возможностей, который ошеломляет программиста прямо в тот момент, когда он должен ясно думать о том, как общаться с читателем из будущего, с тем, кто будет просматривать эти журналы.
Я утверждаю, что для успешных пакетов логов требуется гораздо меньше возможностей и, конечно, меньше уровней.
Почему нет любви?
Пакет log в Go не имеет уровней для логов, вы можете сами вручную добавить приставки DEBUG, INFO, WARN, и ERROR. Также logger тип в Go не имеет возможности включить или выключить эти уровни отдельно для выбранных пакетов. Для сравнения давайте глянем на несколько его замен от сторонних разработчиков.
glog от Google имеет уровни:
- Info
- Warning
- Error
- Fatal (завершает программу)
Посмотрим на другую библиотеку, loggo, разработанную для Juju, в ней доступны уровни:
- Trace
- Debug
- Info
- Warning
- Error
- Critical
Loggo также имеет возможность задать уровень детализации лога для нужных пакетов по отдельности.
Перед вами два примера, явно созданных под влиянием других библиотек для логирования на других языках.
Фактически их происхождение можно проследить до syslog(3), возможно, даже раньше. И я думаю, что они не правы.
Я хочу занять противоречивую позицию. Я думаю, что все библиотеки журналов плохи, потому что предлагают слишком много функций; ошеломляющий набор возможностей, который ошеломляет программиста прямо в тот момент, когда он должен ясно думать о том, как общаться с читателем из будущего, с тем, кто будет просматривать эти журналы.
Я утверждаю, что для успешных пакетов логов требуется гораздо меньше возможностей и, конечно, меньше уровней.
Быстрое логгирование
11 min
Recovery mode
Translation
В этой статье я поместил бенчмарки наиболее частных вызовов логгеров. Все эксперименты я проводил над log4net и NLog, на Windows 10 x64 Intel с M.2 SSD.
Сырые результаты можно посмотреть на GitHub. В том же репозитории код (для запуска потребуется .Net 4.7.2 + Microsoft Visual Studio 2017+).
Что, как и почему — под катом.
Логирование в распределенном php-приложении
17 min
Tutorial
В статье пойдет речь о том, какую пользу оказывает логирование. Расскажу о логах по PSR. Добавлю немного личных рекомендаций по работе с уровнем, сообщением и контекстом логируемого события. Будет приведен пример, как можно организовать логирование и мониторинг с помощью ELK в приложении, написанном на Laravel и запущенном через Docker на нескольких инстансах. Распишу важное правило системы оповещения. Приведу пример скрипта, который поднимает одной командой весь стек мониторинга.
Trace, Info, Warning, Error, Fatal — кто все эти люди..?
4 min
Все знакомы с библиотеками логирования. Обычно они предлагают из коробки сразу много "уровней" важности, которым Вы можете записывать сообщения. Обычно в документации к ним можно найти рекомендации - как лучше этими уровнями - Info, Warning, Error, Fatal - пользоваться. Проблема в том, что это все не работает без некоторых дополнительных соглашений и уточнений - все равно возникает путаница и споры "какой уровень правильный". Именно об этих необходимых уточнениях я и хотел бы поговорить.
Алгоритм ранжирования ошибок
9 min
Возможно Вам доводилось слышать про протокол журнала событий syslog, в котором можно насчитать аж 8 уровней важности: emergency, alert, critical, error, warning, notice, info, debug. Наверняка Вы, как и я какое-то время назад, думаете, “зачем столько”? А что если я скажу, что количество уровней там просто идеально? И использовать можно все - даже debug - для продакшн. Во всяком случае, каждому из них можно придать формальный критерий. Это особенно иронично для меня самого, так как всего пару месяцев назад я написал статью в духе “зачем так сложно!”. Так что если Вам интересно посмотреть на пример технического “переобувания” или оценить строгий алгоритм ранжирования уровней важности событий в системе - прошу.
И это все о нем? Снова про log4net
13 min
Всем доброго времени суток, это моя первая статья на Habr, надеюсь, это будет кому-то интересно. В этой статье пойдет речь о очень не побоюсь это слова старом, но заслуженном программном решении для ведения журнала. Ведение журнала — это процесс записи действий и состояния приложения во вторичный интерфейс, возможно, в файл или базу данных. Но всегда возникает вопрос, какая информация нам нужна для регистрации в нашем, какие действия и какое состояние приложения мы должны записывать? Можно вести журнал по разным причинам, допустим, вам нужно наблюдать за действиями и состоянием приложения, или использовать журнал для создания статистики, касающейся применения вашего приложения.
Архитектура ELK-RabbitMQ — управление логами для большой IT-инфраструктуры
4 min
Как с помощью брокера AMQP RabbitMQ создать отказоустойчивую архитектуру с минимальными потерями лог-данных при сбоях.
Потеря логов при управлении большой инфраструктурой компании-хостера может обернуться имиджевыми и финансовыми потерями. Вместе с тем большое количество управляемого оборудования не вызывает желания создавать системы, в которых логи будут дублироваться и превращаться в огромный и трудноуправляемый массив информации.
Мы в компании Hostkey не стали изобретать велосипед и построили нашу систему на базе Open Distro. В этой статье мы расскажем о варианте архитектуры этого решения, которое благодаря использованию брокера AMQP RabbitMQ обеспечивает отказоустойчивость и минимальные потери лог-данных при сбоях.