Логгирование.Зачем? Когда? Сколько?          Иван Федоров     Senior Software Engineer      ivan.fedorov@gmail.com
Введение или зачем нам вообще нужны логи?•   Анализ поведения и производительности.•   Диагностика неисправностей.•   Расс...
Что логгировать или когда и сколько?      Логгировать надо всё, что хотя бы в теории может          сломаться или выполнят...
Практическая работа или какими должны             быть хорошие логи?•   Четкая структура, единая для всего проекта.•   Каж...
Немного терминологии.•   Событие — некое событие происходящее внутри системы.•   Свойство — именованная характеристика соб...
Структура записей в логе.•   Все записи должны иметь идентичную структуру.•   Лучше всего использовать только однострочные...
Немного примеров.• ts=2012-06-09T06:00:00.000000Z level=INFO  event=ru.devconf.preparation.end devconf.id=2012  status=0• ...
Стандартные элементы.• ts — Время события.• level — Уровень события.• event — Уникальное имя или тип события.• guid/*.id —...
Время события.                            ts=• Используйте единый формат записи времени во всех логах.• Всегда следите за ...
Уровни события.                           level=•   FATAL — Система или компонент не могут продолжать работу.•   ERROR — В...
Тип события.                         event=• Типы всех событий должны быть уникальны, увидев значение  поля «event» вы дол...
Идентификаторы.                      guid/*.id=• Для каждой цепочки связанных событий должен быть  уникальный идентификато...
Что осталось за кадром?          Генерация и обработка логов.• Обеспечьте себя удобным инструментарием, если ваша система ...
Вопросы?•   Иван Федоров, Senior Software Engineer•   ivan.fedorov@gmail.com•   http://oxyum.moikrug.ru/•   http://ru.link...
Upcoming SlideShare
Loading in …5
×

Логгирование. Зачем? Когда? Сколько?

2,417 views
2,278 views

Published on

Почему нужно вести логи, как делать это правильно и почему не стоит думать что работа с логами - это просто.

Published in: Technology
4 Comments
0 Likes
Statistics
Notes
  • @DmitrijChekmarev Я тоже раньше так думал, но потом осознал, что чем больше вариантов - тем труднее разработчику сделать выбор.

    Я где-то видел схему в которой было штук 10 вариантов!!!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • INFO - простое течение.
    WARN - малый ахтунг, но восстановились (заретраились) и продолжили.
    ERR - средний ахтунг, операция не может быть выполнена, но приложение в целом живёт.
    CRIT - ахтунг, возможно вывалились в корку.

    Чаще встречаю отсутствие CRIT в списке.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Да вот я так и не нашел пользы от WARN, у меня за него 'level=INFO event=*.error' :)
    А GrayLog2 - у меня сейчас под рукой нет настроенного инстанса, чтобы можно было что-то с него показать.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • logLevel=WARN кто за него? ;)
    btw, graylog - няшка, мог бы включить в доклад
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
2,417
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
13
Comments
4
Likes
0
Embeds 0
No embeds

No notes for slide

Логгирование. Зачем? Когда? Сколько?

  1. 1. Логгирование.Зачем? Когда? Сколько? Иван Федоров Senior Software Engineer ivan.fedorov@gmail.com
  2. 2. Введение или зачем нам вообще нужны логи?• Анализ поведения и производительности.• Диагностика неисправностей.• Расследование инцидентов.• Моделирование тестовых сценариев.
  3. 3. Что логгировать или когда и сколько? Логгировать надо всё, что хотя бы в теории может сломаться или выполняться некорректно.• Запуск, настройка и завершение сервисов и модулей.• Ошибки, внутренние и внешние.• Все операции связанные с аутентификацией и авторизацией.• Запуск и завершение функциональных блоков, циклов и т.д.
  4. 4. Практическая работа или какими должны быть хорошие логи?• Четкая структура, единая для всего проекта.• Каждое событие должно иметь уникальное имя.• Каждый объект должен иметь уникальный идентификатор.• Каждая запись должна иметь уровень важности.• Время каждой записи должно быть указано с максимальной точностью.
  5. 5. Немного терминологии.• Событие — некое событие происходящее внутри системы.• Свойство — именованная характеристика события.• Лог — представление потока событий.• Запись — представление одного события в логе.
  6. 6. Структура записей в логе.• Все записи должны иметь идентичную структуру.• Лучше всего использовать только однострочные записи.• Оптимальный алфавит для записей — 7bit-ASCII.• Оптимальный формат для записей — «Ключ=Значение».
  7. 7. Немного примеров.• ts=2012-06-09T06:00:00.000000Z level=INFO event=ru.devconf.preparation.end devconf.id=2012 status=0• ts=2012-06-09T14:45:00.654321Z level=INFO event=ru.devconf.speech.start devconf.id=2012 speech.id=70• ts=2012-06-09T15:00:00.123456Z level=INFO event=ru.devconf.speech.show_slide devconf.id=2012 speech.id=70 slide.id=7
  8. 8. Стандартные элементы.• ts — Время события.• level — Уровень события.• event — Уникальное имя или тип события.• guid/*.id — уникальный идентификатор события или элемента.• event=*.start|*.end|*.error — обозначение этапа события.• status — для этапов *.end и *.error обозначает код завершения.
  9. 9. Время события. ts=• Используйте единый формат записи времени во всех логах.• Всегда следите за системным временем на ваших серверах. Сохраняйте время с максимальной точностью, используйте NTP!• Избегайте неоднозначностей трактовки времени, сохраняйте время в UTC или используйте числовое смещение времени. Не используйте текстовое указание часовых поясов. ts=YYYY-MM-DDTHH:MM:SS.SSSSSSZ ts=YYYY-MM-DDTHH:MM:SS.SSSSSS+0400
  10. 10. Уровни события. level=• FATAL — Система или компонент не могут продолжать работу.• ERROR — Внутренние ошибки в отдельных компонентах.• INFO — Основные события, необходимые для работы системы.• DEBUG — Иногда хочется немного подробностей.• TRACE — Если ваша система позволяет полностью отключить вызов некоторые методов на боевых системах, то можно добавить логгирование всего! level=INFO
  11. 11. Тип события. event=• Типы всех событий должны быть уникальны, увидев значение поля «event» вы должны однозначно понимать где оно произошло.• Достаточно удобным является формат, который принят в Java‑мире: разделенные точками пространства имён. event=ru.devconf.speech.show_slide
  12. 12. Идентификаторы. guid/*.id=• Для каждой цепочки связанных событий должен быть уникальный идентификатор, который позволит связать все события воедино.• Если у объекта есть естественный ключ — используте его.• Если естественного ключа нет, сгенерируйте уникальный ключ. devconf.id=2012 section.id=common guid=f5b092d2-da90-11e1-85f8-17a6b5fa5717
  13. 13. Что осталось за кадром? Генерация и обработка логов.• Обеспечьте себя удобным инструментарием, если ваша система ведения логов неудобна — замените её.• Собирайте логи в одном месте и обрабатывайте их централизованно, только так можно гарантировать достоверность полученных данных.• Для сбора логов можно использовать различные системы и подходы, например, rsyslog или Graylog2.
  14. 14. Вопросы?• Иван Федоров, Senior Software Engineer• ivan.fedorov@gmail.com• http://oxyum.moikrug.ru/• http://ru.linkedin.com/in/oxyum

×