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

  • 1,785 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • @DmitrijChekmarev Я тоже раньше так думал, но потом осознал, что чем больше вариантов - тем труднее разработчику сделать выбор.

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

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

Views

Total Views
1,785
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
11
Comments
4
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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