Что такое логирование: Логирование как способ отлаживать код / Хабр

Архитектура логирования / Хабр

Мой опыт разработки в основном строится вокруг разнообразных сетевых cервисов под Windows и Linux. Я обычно стремлюсь добиться максимальной кроссплатформенности вплоть до бинарной совместимости. И конечно, накопилось некоторое количество стабильных решений связанных с логированием.

Топик написан как продолжение к этой статье и будет полезен в первую очередь начинающим программистам.

Здесь я собираюсь осветить следующие вопросы:

• Внутреннее свойство логгера и примеры софта который его использует.
• Объемы, уровни и детализация сообщений лога.
• Общие правила конфигурации в разработке, в бою и в расследовании.

Итак, начну со своих дополнений к предыдущей статье.

Я как и автор пользуюсь NLog’ом и разумеется широко использую его особенности. Конечно, после

их реализации в любом другом логгере, нижеописанную практику можно применять и у них.

Кстати, log4net продолжает развиваться.

Собственно, требуемых дополнений к «Фичам добропорядочного логгера» всего два:

1. Наблюдение/перезагрузка файла конфигурации — это уже не просто полезное, а весьма необходимое умение.
2. Минимальное вмешательство в выключенном состоянии.

Под капотом NLog

Сразу обсудим полезность второй фичи.

Часто, при разработке кода, возникает необходимость посмотреть значение какой либо переменной в процессе выполнения. Обычно, используют дебаггер и останавливают программу в интересующем месте. Для меня же, это явный признак, что этом месте будет полезен Trace вывод. В комплекте с юнит-тестами мы сразу получаем развертку этой переменной во времени и протокол для сравнения с тестами в других условиях. Таким образом, дебаггером я практически не пользуюсь.

Очевидно, что в боевом применении, даже выключенное подробное логирование, может мешать как скорости выполнения так и параллельности.

В NLog используются следующие приемы:

• Кэширование уровня логирования в volatile переменной. Это не требует блокировки или синхронизации потоков.
• Простой метод выяснения необходимости логирования. При некоторых условиях может приводить к inline-вставке кода в процессе jit-компиляции. А это превращает логику в простой условный пропуск участка кода и избавляет от копирования и передачи параметров функции логирования.
• Подробные перегрузки методов логирования. Минимизируют преобразование типов, а также берегут от напрасного боксинга, до того как мы выяснили о необходимости логирования.
• Отложенная генерация сообщения делегатом. Позволяет наглядно и легко задавать сложную генерацию сообщений.

Исходный код класса можно посмотреть тут.

Отлично! Для NLog можно быть уверенным, что ваши сколь угодно детальные сообщения могут быть отключены и это минимально скажется на производительности. Но, это не повод посвящать логированию половину кода.

Что и как логировать

Следует придерживаться правил:

• Вывод в лог следует размещать на отдельной строке.
• Сообщение должно быть максимально коротким и информативным.
• Локализовывать можно только редкие или фатальные сообщения.
• Аргументы желательно брать из локальных переменных метода или внутренних переменных класса данного метода.
• Не желательно использовать преобразования типов.

В целом, при выводе в лог, всегда отмечайте, то количество потенциально лишних вычислений, которые потребуются для случая когда лог отключен.

Простой пример (фрагмент некоторого класса):

private static Logger Log = LogManager.GetCurrentClassLogger();<br/>

 <br/>
public string Request(string cmd, string getParams)<br/>
{<br/>

    Uri uri = new Uri(_baseUri, cmd + "?" + getParams);<br/>

    Log.Debug("Request for uri:`{0}'", uri);<br/>

    HttpWebRequest webReq = (HttpWebRequest)WebRequest.Create(uri);<br/>

    webReq.Method = "GET";<br/>

    webReq.Timeout = _to;<br/>

 <br/>

    string respText;<br/>

    try<br/>

    {<br/>

        string page;<br/>

        using (WebResponse resp = webReq.GetResponse())<br/>

        using (Stream respS = resp.GetResponseStream())<br/>

        using (StreamReader sr = new StreamReader(respS))<br/>

            page = sr.ReadToEnd();<br/>

        Log.Trace("Response page:`{0}'", page);<br/>

        return page;<br/>

    }<br/>

    catch(Exception err)<br/>

    {<br/>

        Log.Warn("Request for uri:`{0}' exception: {1}", uri, err.Message);<br/>

        throw;<br/>

    }<br/>
}

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

Вообще, в текущем обработчике ошибок полезно детализировать контекст который к привел к исключению и специфичные особенности исключения. В примере было бы полезно вывести поле Status для случая WebException.

Гарантии сохранности лога

Несмотря на некоторые возможности NLog по авто записи логов, нет гарантии сохранности лога при завершении процесса.

Что интересно, попытка завершить запись обработкой события AppDomain.ProcessExit не совсем корректна. В конфигурации может быть настроено много разных способов записи в лог, в том числе и по сети. А обработчик этого события находится в ограниченном окружении. В .Net это время работы не более 2х секунд, а в Mono это остановленный ThreadPool. Поэтому, полезно позаботиться о завершении процесса в более дружественном окружении.

Первое, что следует сделать, это обработать событие AppDomain.UnhandledException. В нем следует записать в лог полную информацию об ошибке и вызвать LogManager.Flush(). Обработчик этого события использует тот же поток, который и вызвал исключение, а по окончании, немедленно выгружает приложение.

private static readonly Logger Log = LogManager.GetCurrentClassLogger();<br/>

 <br/>
public static void Main(string[] args)<br/>
{<br/>

    AppDomain.CurrentDomain.UnhandledException += OnUnhandledException;<br/>

    (...)<br/>

    LogManager.Flush();<br/>
}<br/>

 <br/>
static void OnUnhandledException(object sender, UnhandledExceptionEventArgs e)<br/>
{<br/>

    Log.Fatal("Unhandled exception: {0}", e.ExceptionObject);<br/>

    LogManager.Flush();<br/>
}

Кроме того, следует вызывать LogManager.Flush() везде, где потенциально возможно завершение процесса. В конце всех не фоновых потоков.

Если ваше приложение представляет собой win-service или Asp.Net, то следует обработать соответствующие события начала и завершения кода.

Сколько логировать

Серьезная проблема для разработчика. Всегда хочется получать больше информации, но код начинает выглядеть очень плохо. Я руководствуюсь следующими соображениями.

Вывод в лог это по сути комментарий. Логирование уровня Trace по большей части их и заменяет.

Уровни Trace и Debug читают разработчики, а все что выше — техподдержка и админы. Поэтому до уровня Info сообщения должны точно отвечать на вопросы: «Что произошло?», «Почему?» и по возможности «Как исправить?». Особенно это касается ошибок в файлах конфигурации.

Качественный состав уровней логирования уже разобран в предыдущей статье, здесь рассмотрим только количественный состав:

• Trace — вывод всего подряд. На тот случай, если Debug не позволяет локализовать ошибку. В нем полезно отмечать вызовы разнообразных блокирующих и асинхронных операций.
• Debug — журналирование моментов вызова «крупных» операций. Старт/остановка потока, запрос пользователя и т.п.
• Info — разовые операции, которые повторяются крайне редко, но не регулярно. (загрузка конфига, плагина, запуск бэкапа)
• Warning — неожиданные параметры вызова, странный формат запроса, использование дефолтных значений в замен не корректных. Вообще все, что может свидетельствовать о не штатном использовании.
• Error — повод для внимания разработчиков. Тут интересно окружение конкретного места ошибки.
• Fatal — тут и так понятно. Выводим все до чего дотянуться можем, так как дальше приложение работать не будет.

Боевое развертывание

Предположим, разработка дошла до внедрения.

Отложим вопросы ротации логов, размера файлов и глубины истории. Это все очень специфично для каждого проекта и настраивается в зависимости от реальной работы сервиса.

Остановлюсь только на смысловой организации файлов. Их следует разделить на 3 группы. Может потребуется развести логи модулей в разные файлы, но дальше я все равно буду говорить об одном файле для каждой группы.

1. Группа Info, с соответствующим уровнем для всех источников. Это информация для администратора. Здесь могут быть следующие вещи: когда приложение стартовало, правильно ли вычитаны конфиги, доступны ли требуемые сервисы, и т.д. Его основное свойство: файл изменяет размер только при перезагрузке приложения. В процессе работы, файл расти не должен. Это поможет обеспечить автоматизированный внешний контроль успешности запуска приложения. Достаточно проверить отсутствие в файле ключевых слов Error и Fatal. Проверка всегда будет занимать предсказуемо малое время.
2. Группа Warning. Это тоже информация для администратора. Этот файл при нормальной работе должен отсутствовать или быть пустым. Соответственно мониторинг его состояния сразу укажет на сбои в работе. Гибко настроив фильтры по разным источникам, можно подобрать достаточно точный критерий, когда вообще следует обратить внимание на сервис.
3. Группа Наблюдение. Как правило в ходе внедрения выделяются некоторые проблемные модули. Информация от них в детализации Debug как раз и направляется сюда.

Если приложение успешно внедрено, то в работе остаются только первые две группы.

Расследование сбоев

Когда работающий сервис подает признаки ошибки, то не следует его пытаться сразу перезагружать. Возможно нам «повезло» поймать ошибки связанные с неверной синхронизацией потоков. И не известно сколько в следующий раз ждать ее повторения.

В первую очередь следует подключить заготовленные заранее конфиги для группы наблюдения. Как раз это и должен позволять делать приличный логгер. Когда мы получили подтверждение о том, что новая конфигурация успешно применена, то пытаемся опять спровоцировать сбой. Желательно несколько раз. Это обеспечит возможность для его воспроизведения в «лабораторных» условиях. Дальше уже работа программистов. А пока можно и перезагрузиться.

Вывод в лог желательно сделать асинхронным.

Пример, боевой настройки.

<nlog autoReload="true"><br/>

  <targets><br/>

    <target name="fileInfo" type="AsyncWrapper" queueLimit="5000" overflowAction="Block"><br/>

      <target type="File" fileName="${basedir}/logs/info.log" /><br/>

    </target><br/>

    <target name="fileWarn" type="AsyncWrapper" queueLimit="5000" overflowAction="Block"><br/>

      <target type="File" fileName="${basedir}/logs/warn.log" /><br/>

    </target><br/>

  </targets><br/>

 <br/>

  <rules><br/>

    <logger name="*" minlevel="Info" writeTo="fileInfo" /><br/>

    <logger name="*" minlevel="Warn" writeTo="fileWarn" /><br/>

  </rules><br/>
</nlog>

При настройке фильтров следует учитывать относительность уровней логирования для каждой из подсистем. Например, некоторый модуль, имея Info сообщение об инициализации, может быть создан для каждого подключенного пользователя. Разумеется, его вывод в Info группу следует ограничить уровнем Warn.

Чего с логгером делать не следует

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

Что бы ни было тому причиной, надо точно помнить, что в первую очередь, такие удобства напрочь убивают компилятору возможность оптимизации.

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

Чего же мне еще не хватает в NLog?

• Дополнительные перегрузки методов логгера, для того чтобы избежать генерации классов лямбда-функций. Хочется иметь вызов вида
  Log.Trace<TArg1, TArg2>(Func<TArg1, TArg2, string> messageCreater, TArg1 arg1, TArg2 arg2)
  
  Но на текущий момент, самый короткий человекочитаемый вариант подразумевает скрытую генерацию класса:
  Log.Trace(() => MessageCreate(arg1, arg2))
• Бинарная совместимость. Помогает быстро тестировать сервисы на разных платформах. В NLog очень много инструкций условной компиляции в зависимости от платформы. Т.е. бинарник для Mono может неожиданно работь в DotNet. А очень желательна предсказуемость, хотя бы и в ограниченной комплектации.
• Условная расширяемость. Понятно, что с бинарной совместимостью придется жертвовать функционалом, но у нас уже есть удобный механизм расширений. Осталось только, чтобы он фильтровал расширения в зависимости от платформы. Вместе с предыдущей возможностью, это еще и дает простое развертывание через копирование директории с IL-бинарниками.
• Логгирование внутренних сообщений в общем контексте. Был бы полезен список создаваемых в системе логгеров. К сожалению, не уверен, что можно избежать рекурсии. Например, когда вывод в файл начнет писать ошибки вывода в себя же.

NLog, Log4Net, Enterprise Library, SmartInspect…

Разнообразные сравнения логгеров между собой, упускают одну важную деталь.

Важно сравнивать не только ограничения/возможности, но и возможность быстро добавить свои «хотелки».

Поэтому, буду пока дружить с NLog.

Чего и Вам желаю.

Распределенное логирование и трассировка для микросервисов

Логирование — важная часть любого приложения. Любая система логирования проходит три основных шага эволюции. Первый — вывод на консоль, второй — запись логов в файл и появление фреймворка для структурированного логирования, и третий — распределенное логирование или сбор логов различных сервисов в единый центр.

Если логирование хорошо организовано, то позволяет понимать, что, когда и как идет не так, как задумано, и передавать нужную информацию людям, которым предстоит эти ошибки исправлять. Для системы, в которой каждую секунду отправляется 100 тысяч сообщений в 10 дата-центрах на 190 стран, а 350 инженеров каждый день что-то деплоят, система логирования особенно важна.

Иван Летенко — тимлид и разработчик в Infobip. Чтобы решить проблему централизованной обработки и трассировки логов в микросервисной архитектуре при таких огромных нагрузках, в компании пробовали различные комбинации стека ELK, Graylog, Neo4j и MongoDB. В итоге, спустя много грабель, написали свой лог-сервис на Elasticsearch, а как БД для дополнительной информации взяли PostgreSQL.

Под катом подробно, с примерами и графиками: архитектура и эволюция системы, грабли, логирование и трассировка, метрики и мониторинг, практика работы с кластерами Elasticsearch и их администрирования в условиях ограниченных ресурсов.

Чтобы ввести вас в контекст, расскажу немного о компании. Мы помогаем клиентам-организациям доставлять сообщения их клиентам: сообщения от службы такси, СМС от банка о списании или одноразовый пароль при входе в ВК. В день через нас проходит 350 млн сообщений для клиентов в 190 странах. Каждое из них мы принимаем, обрабатываем, биллим, роутим, адаптируем, отсылаем операторам, а в обратном направлении обрабатываем отчеты о доставке и формируем аналитику.

Чтобы всё это работало в таких объемах, у нас есть:

• 36 дата-центров по всему миру;
• 5000+ виртуальных машин;
• 350+ инженеров;
• 730+ различных микросервисов.

Это сложнейшая система, и ни один гуру не сможет в одиночку понять весь масштаб. Одна из основных целей нашей компании — это высокая скорость доставки новых фич и релизов для бизнеса. При этом всё должно работать и не падать. Мы над этим работаем: 40 000 деплоев в 2017 году, 80 000 в 2018, 300 деплоев в день.

У нас 350 инженеров — получается, что каждый инженер ежедневно что-то деплоит. Еще несколько лет назад такая производительность была только у одного человека в компании — у Крешимира, нашего principal-инженера. Но мы добились того, что каждый инженер чувствует себя так же уверенно, как Крешимир, когда нажимает кнопку «Deploy» или запускает скрипт.

Что для этого нужно? Прежде всего уверенность в том, что мы понимаем, что происходит в системе и в каком состоянии она находится. Уверенности придает возможность задать системе вопрос и выяснить причину проблемы во время инцидента и при разработке кода.

Чтобы добиться этой уверенности, мы инвестируем в наблюдаемость (observability). Традиционно этот термин объединяет три компоненты:

• логирование;
• метрики;
• трассировка.

Об этом и поговорим. Прежде всего, посмотрим на наше решение для логирования, но метрик и трассировки также обязательно коснемся.

Эволюция

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

Первый шаг — это вывод на консоль.

Второй — мы начинаем писать логи в файл, появляется фреймворк для структурированного вывода в файл. Обычно мы используем Logback, потому что живем в JVM. На этом этапе появляется структурированное логирование в файл, понимание, что разные логи должны иметь разный уровень, warnings, errors.

Как только экземпляров нашего сервиса или разных сервисов становится уже несколько, появляется задача централизованного доступа к логам для разработчиков и поддержки. Мы переходим к распределенному логированию — объединяем различные сервисы в единый сервис логирования.

Распределенное логирование

Самый известный вариант — стек ELK: Elasticsearch, Logstash и Kibana, но мы выбрали Graylog. У него классный интерфейс, который заточен на логирование. Из коробки идут алерты уже в бесплатной версии, чего нет в Kibana, например. Для нас это отличный выбор с точки зрения логов, а под капотом тот же Elasticsearch.

В Graylog можно строить алерты, графики аналогично Kibana и даже метрики по логам.

Проблемы

Наша компания росла, и в определенный момент стало понятно, что с Graylog что-то не так.

Чрезмерная нагрузка. Появились проблемы с производительностью. Многие разработчики стали использовать классные возможности Graylog: строили метрики и дашборды, которые выполняют агрегацию по данным. Не лучший выбор строить сложную аналитику на кластере Elasticsearch, на который идет мощная нагрузка на запись.

Коллизии. Команд много, единой схемы нет. Традиционно, когда один ID первый раз попал в Graylog в качестве long, автоматически произошел маппинг. Если другая команда решит, что туда надо записать UUID в виде строки — это сломает систему.

Первое решение

Разделили логи приложений и коммуникационные логи. У разных логов разные сценарии и способы применения. Есть, например, логи приложений, к которым у разных команд разные требования по разным параметрам: по времени хранения в системе, по скорости поиска.

Поэтому первое, что мы сделали, — разделили логи приложений и коммуникационные логи. Второй тип — важные логи, которые хранят информацию о взаимодействии нашей платформы с внешним миром и о взаимодействии внутри платформы. Мы еще поговорим об этом.

Заменили существенную часть логов на метрики. В нашей компании стандартный выбор — это Prometheus и Grafana. Какие-то команды используют и другие решения. Но важно, что мы избавились от большого количества дашбордов с агрегациями внутри Graylog, перевели все на Prometheus и Grafana. Это значительно облегчило нагрузку на серверы.

Посмотрим на сценарии применения логов, метрик и трейсов.

Логи

Высокая размерность, отладка и исследование. Чем хороши логи?

Логи — это события, которые мы логируем.

У них может быть большая размерность: можно логировать Request ID, User ID, атрибуты запроса и другие данные, размерность которых не ограничена. Они также хороши для отладки и исследования, чтобы задавать вопросы системе о том, что происходило, и искать причины и следствия.

Метрики

Низкая размерность, агрегация, мониторинг и алерты. Под капотом всех систем сбора метрик находятся time series базы данных. Эти БД отлично справляются с агрегацией, поэтому метрики подходят для агрегации, мониторинга и построения алертов.

Метрики очень чувствительны к размерности данных.

Для метрик размерность данных не должна превышать тысячи. Если мы будем добавлять какие-то Request ID, у которых размер значений не ограничен, то быстро столкнемся с серьезными проблемами. Мы уже наступали на эти грабли.

Корреляция и трассировка

Логи должны быть коррелированы.

Структурированных логов недостаточно, чтобы мы могли удобно искать по данным. Должны быть поля с определенными значениями: Request ID, User ID, другие данные с сервисов, с которых логи пришли.

Традиционное решение — присваивать транзакции (логу) на входе в систему уникальный ID. Затем этот ID (контекст) пробрасывается через всю систему по цепочке вызовов внутри сервиса или между сервисами.

Корреляция и трассировка.

Есть устоявшиеся термины. Трассировка разбивается на spans и демонстрирует стек вызовов одного сервиса относительно другого, одного метода относительно другого относительно временной шкалы. Наглядно прослеживается путь сообщения, все тайминги.

Сначала мы использовали Zipkin. Уже в 2015 году у нас был Proof of Concept (пилотный проект) этих решений.

Распределенная трассировка.

Чтобы получить такую картину, код нужно инструментировать. Если вы уже работаете с кодовой базой, которая существует, нужно по ней пройтись — она требует изменений.

Для полной картины и чтобы получать выгоду от трейсов, необходимо инструментировать все сервисы в цепочке, а не один сервис, на котором вы сейчас работаете.

Это мощный инструмент, но он требует значительных затрат на администрирование и железо, поэтому мы перешли от Zipkin на другое решение, которое предоставляется «as a service».

Отчеты о доставке

Логи должны быть коррелированы. Трейсы тоже должны быть коррелированы. Нам нужен единый ID — общий контекст, который можно пробрасывать по всей цепочке вызовов. Но зачастую это невозможно — корреляция происходит внутри системы в результате ее работы. Когда мы начинаем одну или несколько транзакций, мы еще не знаем, что они часть единого большого целого.

Рассмотрим первый пример.

Отчеты о доставке.

• Клиент отправил запрос на сообщение, и наша внутренняя платформа его обработала.
• Сервис, который занимается взаимодействием с оператором, отправил это сообщение оператору — появилась запись в системе логов.
• Позже оператор присылает нам отчет о доставке.
• Сервис, который занимается процессингом, не знает, к какому конкретно сообщению относится этот отчет о доставке. Эта взаимосвязь создается внутри нашей платформы позже.

Две связанные транзакции — части единой целой транзакции. Эта информация очень важна для инженеров поддержки и разработчиков интеграций. Но это совершенно невозможно видеть, исходя из единой трассировки или единого ID.

Второй случай похож — клиент присылает нам сообщение в большой пачке, потом мы их разбираем, они возвращаются тоже пачками. Количество пачек даже может меняться, но все они потом объединяются.

С точки зрения клиента, он отправил сообщение и получил ответ. Но мы получили несколько независимых транзакций, которые необходимо объединять. Получается связь один ко многим, а с отчетом о доставке — один к одному. По сути, это граф.

Строим граф.

Раз мы видим граф, то адекватный выбор — графовые БД, например, Neo4j. Выбор был очевиден, потому что Neo4j дарит на конференциях классные футболки и бесплатные книжки.

Neo4j

Мы реализовали Proof of Concept: хост на 16 ядер, который мог обрабатывать граф 100 млн нод и 150 млн связей. Граф занимал всего 15 ГБ диска — тогда нам это подходило.

Наше решение. Архитектура логов.

Кроме Neo4j у нас появился несложный интерфейс для просмотра связанных логов. С ним инженеры видят картину целиком.

Но довольно быстро мы разочаровались в этой БД.

Проблемы с Neo4j

Ротация данных. У нас мощные объемы и данные необходимо ротировать. Но при удалении ноды из Neo4j данные на диске не очищаются. Пришлось строить сложное решение и полностью перестраивать графы.

Производительность. Все графовые БД заточены на чтение. На запись производительность заметно меньше. Наш случай абсолютно противоположный: мы много пишем и относительно редко читаем — это единицы запросов в секунду или даже в минуту.

High availability и кластерный анализ платно. В наших масштабах это выливается в приличные затраты.

Поэтому мы пошли другим путем.

Решение с PostgreSQL

Мы решили, что раз читаем редко, то граф можно строить на лету при чтении. Так мы в реляционной базе PostgreSQL храним список смежности наших ID в виде простой таблички с двумя столбцами и индекс по обоим. Когда приходит запрос, мы обходим граф связанности по знакомому алгоритму DFS (обход в глубину), и получаем все связанные ID. Но это по необходимости.

Ротация данных тоже решается легко. На каждый день заводим новую табличку и через несколько дней, когда приходит время — удаляем её и освобождаем данные. Простое решение.

Сейчас в PostgreSQL у нас 850 млн связей, они занимают 100 ГБ диска. Мы пишем туда со скоростью 30 тыс в секунду, и для этого в БД всего две VM по 2 CPU и 6 GB RAM. Что и требовалось доказать — PostgreSQL умеет быстро писать longs.

Еще есть небольшие машины для самого сервиса, которые ротируют и управляют.

Как изменилась наша архитектура.

Сложности с Graylog

Компания росла, появлялись новые дата-центры, нагрузка заметно увеличивалась, даже с решением с коммуникационными логами. Мы задумались о том, что Graylog подходит уже не идеально.

Единая схема и централизация. Хочется иметь единый инструмент управления кластерами в 10 дата-центрах. Также встал вопрос единой схемы маппинга данных, чтобы не было коллизий.

API. Мы используем собственный интерфейс для отображения связей между логами и стандартное API Graylog не всегда было удобно использовать, например когда нужно отобразить данные с разных дата-центров, правильно их рассортировать и пометить. Поэтому нам хотелось иметь возможность менять API как нам нравится.

Производительность, трудно оценить потери. Наш трафик — 3 ТБ логов в день, что прилично. Поэтому Graylog не всегда стабильно работал, нужно было залезать в его внутренности, чтобы понять причины сбоев. Получалось, что мы используем его уже не как инструмент — с этим надо было что-то делать.

Задержки обработки (очереди). Нам не нравилась стандартная реализация очереди в Graylog.

Необходимость поддерживать MongoDB. Graylog тащит за собой MongoDB, приходилось администрировать еще и эту систему.

Мы поняли, что на данном этапе хотим собственное решение. Возможно, там меньше классных функций по алертингу, которые уже не использовались, по дашбордам, но свое лучше.

Наше решение

Мы разработали собственный Logs service.

Сервис логов.

В тот момент у нас уже была экспертиза по обслуживанию и поддержанию крупных кластеров Elasticsearch, поэтому за основу взяли Elasticsearch. Стандартный стек в компании — это JVM, но для бэкенда мы классно используем и Kotlin, поэтому для сервиса взяли этот язык.

Первый вопрос — как ротировать данные и что делать с маппингом. Мы используем фиксированный маппинг. В Elasticsearch лучше иметь индексы одинакового размера. Но с такими индексами нам нужно как-то маппить данные, особенно для нескольких дата-центров, распределенной системы и распределенного состояния. Были идеи прикрутить ZooKeeper, но это опять усложнение обслуживания и кода.

Поэтому мы решили просто — пишем по времени.

Один индекс на один час, в других дата-центрах 2 индекса на час, в третьих один индекс на 3 часа, но все по времени. Индексы получаются разного размера, поскольку ночью трафик меньше, чем днем, но в целом работает. Опыт показал, что усложнения не нужны.

Для простоты миграции и учитывая большой объем данных мы выбрали протокол GELF — простой протокол Graylog на основе TCP. Так у нас появился GELF-сервер на Netty и GELF-декодер.

Потом JSON кодируется для записи в Elasticsearch. Мы используем официальное Java API от Elasticsearch и пишем Bulk’ами.

Для высокой скорости записи нужно писать Bulk’ами.

Это важная оптимизация. API предоставляет Bulk-процессор, который автоматически накапливает запросы и потом отправляет на запись их пачкой или по времени.

Проблема с Bulk-процессор

Вроде бы все хорошо. Но мы запустили и поняли, что упираемся в Bulk-процессор — это было неожиданно. Мы не можем добиться тех значений, на которые рассчитывали — проблема пришла из ниоткуда.

В стандартной реализации Bulk-процессор однопоточный, синхронный, несмотря на то, что там есть настройка параллелизма. В этом и была проблема.

Покопались и оказалось, что это известная, но не решенная бага. Мы немного изменили Bulk-процессор — сделали явную блокировку через ReentrantLock. Только в мае похожие изменения были внесены в официальный репозиторий Elasticsearch и будут доступны только с версии 7.3. Текущая — 7.1, а мы пользуемся версией 6.3.

Если вы также работаете с Bulk-процессором и хотите разогнать запись в Elasticsearch — посмотрите эти изменения на GitHub и обратно портируйте под вашу версию. Изменения затрагивают только Bulk-процессор. Сложностей не возникнет, если нужно портировать на версию ниже.

Все отлично, Bulk-процессор пошел, скорость разогналась.

Производительность Elasticsearch на запись нестабильна во времени, поскольку там происходят различные операции: мёрджинг индексов, flush. Также производительность на некоторое время замедляется во время обслуживания, когда выбывает часть нод из кластера, например.

В связи с этим мы поняли, что нам нужна реализация не только буфера в памяти, но и очереди. Мы решили, что будем отправлять в очередь только отклоненные сообщения — только те, что Bulk-процессор не смог записать в Elasticsearch.

Retry fallback

Это простая реализация.

• Сохраняем в файл отклоненные сообщения — RejectedExecutionHandler.
• Повторно отправляем с заданным интервалом в отдельном executor.
• При этом мы не задерживаем новый трафик.

Для инженеров поддержки и разработчиков новый трафик в системе заметно важнее, чем тот, который почему-то задержался во время спайка или замедления Elasticsearch. Он задержался, но прибудет потом — ничего страшного. Новый трафик приоритетнее.

Наша схема стала выглядеть так.

Теперь поговорим как мы готовим Elasticsearch, какие параметры использовали и как настраивали.

Конфигурация Elasticsearch

Проблема, с которой мы столкнулись — необходимость разгонять Elasticsearch, оптимизировать его на запись, поскольку количество чтений заметно меньше.

Мы использовали несколько параметров.

"ignore_malformed": true — отбрасываем поля с неверным типом, а не весь документ. Нам все-таки хочется хранить данные, даже если почему-то туда просочились поля с неправильным маппингом. Этот параметр не совсем связан с производительностью.

Для железа у Elasticsearch есть нюанс. Когда мы начали просить большие кластеры, то нам сказали, что RAID-массивы из SSD-дисков под ваши объемы это жутко дорого. Но массивы не нужны, потому что отказоустойчивость и партиционирование уже встроено в Elasticsearch. Даже на официальном сайте есть рекомендация брать больше дешевого железа, чем меньше дорогого и хорошего. Это касается и дисков, и количества ядер процессоров, потому что весь Elasticsearch очень хорошо параллелится.

"index.merge.scheduler.max_thread_count": 1 — рекомендовано для HDD.

Если вам достались не SSD, а обычные диски HDD, то в этот параметр выставляйте единицу. Индексы пишутся кусочками, потом эти кусочки мёржатся. Это чуть-чуть экономит диск, но, прежде всего, ускоряет поиск. Также, когда вы перестали записывать в индекс, можно сделать force merge. Когда нагрузка на кластер поменьше, оно автоматически мёржится.

"index.unassigned.node_left.delayed_timeout": "5m" — задержка реаллокации при пропадании ноды. Это время через которое Elasticsearch начнет реаллоцировать индексы и данные, если какая-то нода перезагрузилась, деплоится или выведена для обслуживания. Но если у вас мощная нагрузка на диск и сеть, то реаллокация это тяжелая операция. Чтобы их не перегрузить, этот таймаут лучше контролировать и понимать, какие задержки необходимы.

"index.refresh_interval": -1 — не обновлять индексы, если нет поисковых запросов. Тогда индекс будет обновляться при появлении поискового запроса. Этот индекс может быть выставлен в секундах и минутах.

"index.translogDurability": "async" — как часто выполнять fsync: при каждом запросе или по времени. Дает прирост производительности для медленных дисков.

Еще у нас появился интересный способ применения. Поддержка и разработчики хотят иметь возможность полнотекстового поиска и применения regexp’ов по всему телу сообщения. Но в Elasticsearch это невозможно — он может искать только по токенам, которые уже есть в его системе. RegExp и wildcard можно использовать, но токен не может начинаться с какого-то RegExp. Поэтому мы добавили word_delimiter в фильтр:

"tokenizer": "standard"	
"filter" : [ "word_delimiter" ]

Он автоматически разбивает слова на токены:

• «Wi-Fi» → «Wi», «Fi»;
• «PowerShot» → «Power», «Shot»;
• «SD500» → «SD», «500».

Подобным образом пишется название класса, разная отладочная информация. С ним мы закрыли часть проблем с полнотекстовым поиском. Советую добавлять такие настройки, когда работаете с логином.

О кластере

Количество шард должно равняться количеству дата-нод для распределения нагрузки. Минимальное количество реплик — 1, тогда каждая нода будет иметь один основной шард и одну реплику. Но если у вас ценные данные, например, финансовые транзакции, — лучше 2 и более.

Размер шарда от нескольких ГБ до нескольких десятков ГБ. Количество шардов на ноде не больше 20 на 1 ГБ хипа Elasticsearch, естественно. Дальше Elasticsearch замедляется — мы на это тоже наступали. В тех дата-центрах где трафика немного, данные не ротировались по объему, появлялись тысячи индексов и система падала.

Используйте allocation awareness, например, по имени гипервизора на случай обслуживания. Помогает разбрасывать индексы и шарды по разным гипервизорам, чтобы они не пересекались, когда выбывает какой-то гипервизор.

Создавайте индексы предварительно. Хорошая практика, особенно когда пишем по времени. Индекс сразу горячий, готовый и нет задержек.

Ограничьте число шард одного индекса на ноде. "index.routing.allocation.total_shards_per_node": 4 — это максимальное количество шард одного индекса на ноде. В идеальном случае их 2, мы ставим 4 на всякий случай, если всё-таки у нас окажется меньше машин.

В чем здесь проблема? Мы используем allocation awareness — Elasticsearch знает, как правильно разбросать индексы по гипервизорам. Но мы выяснили, что после того, как нода была долго выключена, а потом обратно приходит в кластер, Elasticsearch видит, что на ней формально меньше индексов и они восстанавливаются. Пока данные не синхронизируются, формально на ноде мало индексов. При необходимости аллоцировать новый индекс Elasticsearch старается как можно плотнее забить эту машину свежими индексами. Так нода получает нагрузку не только от того, что на нее реплицируются данные, но еще и свежим трафиком, индексами и новыми данными, которые попадают на эту ноду. Контролируйте и ограничивайте это.

Рекомендации по обслуживанию Elasticsearch

Тем, кто работает с Elasticsearch, эти рекомендации уже знакомы.

Во время планового обслуживания применяйте рекомендации для rolling upgrade: disable shard allocation, synced flush.

Disable shard allocation. Отключите аллокацию реплик шард, оставьте возможность аллоцировать только primary. Это заметно помогает Elasticsearch — он не будет переаллоцировать данные, которые вам не нужны. Например, вы знаете, что через полчаса нода поднимется — зачем перебрасывать все шарды с одной ноды на другую? Ничего страшного не случится, если полчаса пожить с желтым кластером, когда доступны только primary-шарды.

Synced flush. В этом случае нода при возвращении в кластер синхронизируется намного быстрее.

При сильной нагрузке на запись в индекс или восстановлении можно уменьшить количество реплик.

Если вы загружаете большой объем данных, например, пик нагрузки, можно отключить шарды и позже дать команду, чтобы Elasticsearch их создал, когда нагрузка будет уже меньше.

Приведу несколько команд, которыми я люблю пользоваться:

• GET _cat/thread_pool?v — позволяет посмотреть thread_pool на каждой ноде: что сейчас горячо, какие очереди на запись и чтение.
• GET _cat/recovery/?active_only=true — какие индексы куда реаллоцируются, где происходит восстановление.
• GET _cluster/allocation/explain — в удобном человеческом виде почему и какие индексы или реплики не аллоцировались.

Для мониторинга мы используем Grafana.

Есть прекрасный экспортер и Grafana teamplay от Vincent van Hollebeke, который позволяет наглядно смотреть состояние кластера и все его основные параметры. Мы добавили его в наш Docker-образ и все метрики при деплое у нас из коробки.

Выводы по логированию

Логи должны быть:

• централизованы — единая точка входа для разработчиков;
• доступны — возможность быстрого поиска;
• структурированы — для быстрого и удобного извлечения ценной информации;
• коррелированы — не только между собой, но и с другими метриками и системами, которые вы используете.

Недавно проходил шведский конкурс Melodifestivalen. Это отбор представителей от Швеции на Евровидение. Перед конкурсом к нам обратилась наша служба поддержки: «Сейчас в Швеции будет большая нагрузка. Трафик достаточно чувствительный и мы хотим коррелировать некоторые данные. У вас в логах есть данные, которых не хватает на дашборде Grafana. У нас есть метрики, которые можно взять из Prometheus, но нам нужны данные по конкретным ID-запросам».

Они добавили Elasticsearch как источник Grafana и смогли коррелировать эти данные, закрыть проблему и получить достаточно быстро хороший результат.

Эксплуатация собственных решений заметно проще.

Сейчас вместо 10 кластеров Graylog, которые работали для этого решения, у нас несколько сервисов. Это 10 дата-центров, но у нас нет даже специально выделенной команды и людей, которые их обслуживают. Есть несколько человек, которые работали над ними и что-то меняют по необходимости. Эта маленькая команда прекрасно вписана в нашу инфраструктуру — деплоить и обслуживать легче и дешевле.

Разделяйте кейсы и используйте соответствующие инструменты.

Это отдельные инструменты для логирования, трассировки и мониторинга. Нет «золотого инструмента», который закроет все ваши потребности.

Чтобы понять, какой именно инструмент нужен, что именно мониторить, какие где использовать логи, какие требования логам, нужно обязательно обратиться к SLI/SLO — Service Level Indicator/Service Level Objective. Нужно знать, что важно для ваших клиентов и вашего бизнеса, на какие индикаторы они смотрят.

Уже через неделю в СКОЛКОВО состоится HighLoad++ 2019. Вечером 7 ноября Иван Летенко расскажет, как живется с Redis на проде, а всего в программе 150 докладов на самые разные темы.

Если у вас не получается посетить HighLoad++ 2019 вживую, у нас хорошие новости. В этом году конференция пройдет сразу в трех городах — в Москве, Новосибирске и Санкт-Петербурге. Одновременно. Как это будет и как попасть — узнайте на отдельной промостранице события.

Что такое лог (log) программы.

Решая различные компьютерные задачи, можно не раз столкнуться с таким понятием как лог (с англ. log). Лог какой-то программы. Давайте попробуем разобраться что это такое и для чего это нужно. 

Log (с англ. журнал). У большинства программ, которые установлены на вашем компьютере, есть этот самый журнал. 

Журнал — это специальный текстовый файл, в который программа может вносить какие-то записи. 

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

Зачем же программе вести какие-то записи, какой-то журнал?

Дело в том, что если мы с вами будем следить за человеком, который работает на компьютере, мы можем сказать, что этот человек делал в конкретный момент времени, какие программы он запускал, какие ошибки он совершал при работе на компьютере и.т.д.

Но, если мы говорим о компьютерной программе, здесь все не так ясно. Все действия, которые производит программа, они скрыты от взгляда обычного пользователя. Они обычно происходят с такой большой скоростью событий, что человеческий глаз просто не успеет за все этим уследить.

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

Лог файлов для программы может быть несколько. В зависимости от назначения может быть так называемый access_log — это журнал, где фиксируются все взаимодействия пользователей с этой программой, что они делали и.т.д.

В лог файле может множество записей. Каждая текстовая строка — это одно взаимодействие с программой.

В каждой записи содержится информация о том, что происходило с программой и когда это происходило.

Также можно часто встретить так называемый error_log — это лог тех ошибок, которые возникали при работе с программой. В этом логе можно увидеть код ошибки, которая произошла в программе, когда эта ошибка произошла, каким пользователем операционной системы эта ошибка была вызвана и.т.д.

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

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

Лог — это первоисточник, в который нужно заглядывать если ваша программа работает с каким-то ошибками и не так, как нужно. 

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

На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK

На рынке представлено огромное количество систем логирования — как открытых, так и проприетарных. У каждой из них своя функциональность, свои достоинства и недостатки.

Сегодня мы решили поделиться опытом выбора системы логирования и рассказать, почему мы в 1cloud остановились на ELK.

/ Pixabay / picupyourphoto / PD

Минутка теории

При переходе в продакшн, приложения превращаются в своеобразные «черные ящики». Их работу нужно постоянно мониторить, чтобы предотвращать и реагировать на потенциальные ЧП, отлавливать «узкие места».

Системы логирования — обязательный инструмент, без которого не обойтись в этом процессе. Проводя подробный анализ собираемых данных, можно идентифицировать «вторжения» в сеть, выявить неправильно настроенное оборудование и оперативно принять меры. Также логирование является обязательным требованием при прохождении разного рода сертификаций, например PCI DSS.

Для автоматизации процессов логирования есть специальные фреймворки: log4j, log4net, Retrace, Logback, Logstash и другие — их множество. Свои инструменты для логирования имеют отдельные средства разработки, например JDK — там есть java.util.logging. Разумеется, функциональность различных инструментов логирования отличается, и необходимый набор функций нужно выбирать исходя из требований бизнеса. Однако есть ряд общих моментов, которые стоит отметить при выборе системы анализа логов.

Простота использования и размеры сообщества

Простота — один из ключевых компонентов при выборе системы логирования. С лог-фреймворками работают все разработчики в команде, потому опыт использования этого инструмента должен быть положительным и не превращать анализ логов в кошмар. API фреймворка должен быть интуитивно понятным, чтобы все, кто раньше не работал с системой, могли быстро разобраться, как она устроена и настроена.

Если рассматривать опенсорсную систему логирования, то имеет смысл оценить сообщество, которое сформировалось вокруг неё. Для этого можно изучить, насколько часто её упоминают на профильных площадках (Stack Overflow), а также в профильных тредах, например на Reddit. Как вариант — посмотреть популярность проекта на GitHub (количество звезд) и посмотреть, как часто его вписывают в различные подборки инструментов в сети (наподобие таких). Очевидно, чем больше сообщество, тем выше вероятность, что вам помогут в случае возникновения непредвиденных трудностей.

Что касается выбора проприетарных систем логирования, то здесь в первую очередь стоит смотреть на скорость ответов и адекватность службы поддержки выбираемого решения, а также его цену.

Возможность сбора «разнокалиберных» логов

Не все платформы для логирования способны обрабатывать большое количество данных и предоставлять полную информацию об используемых системах.

Перед выбором решения стоит определиться, какие именно логи вы планируете собирать: HTTP-логи (помогут понять поведение пользователей на сайте), API-логи (дадут возможность оценить, какие сервисы чаще всего запрашиваются по API), логи об ошибках и просто записи изменений в системе (укажут на «узкие места», если таковые есть).

Масштабируемость

Инструмент логирования должен собирать логи с каждого системного компонента и предоставлять к ним доступ в одном месте. Если система не приспособлена для масштабирования, качество лог-анализа упадет.

Мы в 1cloud изначально использовали для логирования MS SQL. Однако с ростом числа клиентов и сервисов (например, совсем недавно мы разместили оборудование в минском ЦОД и добавили поддержку IPv6), у нас появились территориально разнесенные компоненты инфраструктуры, у которых не было доступа к БД. А одной из главных наших задач было сохранение возможности анализа логов из единого места.

Система логирования 1cloud

Как мы уже отметили, для хранения логов в 1cloud раньше использовался MS SQL, а для их записи — log4net. И это начало создавать для нас определенные трудности. Из-за территориально разнесенных компонентов, стало невозможно держать сетевую связанность с БД и обеспечивать единую точку для анализа.

При этом большой объем логов и невозможность построить индексы по всем необходимым нам для поиска полям привели к излишнему упрощению лог-анализа — нам приходилось отказываться от функциональности в угоду производительности.

Чтобы решить эту проблему и обеспечить масштабируемость, мы внедрили новую систему логирования. Всего мы изучили больше пятидесяти различных решений и выделили четыре, которые полностью удовлетворяли нашим требованиям:

• единое место хранения логов;
• горизонтальное масштабирование системы при необходимости;
• обработка больших объемов данных;
• мощная система анализа логов.

Этими четырьмя решениями стали: Fluentd, Graylog, Logalyse и Logstash.

Logstash

Решение имеет 9,2 тыс. звезд на GitHub. Logstash распространяется по лицензии Apache 2.0 и является частью стека ELK. Имеет большое количество плагинов (на GitHub их насчитывается порядка 250 штук). Работает под Windows и Linux и имеет высокую производительность, практически не зависящую от объемов данных.

Система дает быстро проводить обзор и анализ событий с рабочих станций, файрволов, маршрутизаторов и коммутаторов. Это связано с тем, что нет необходимости в «нормализации» событий.

Однако стоит понимать, что это «голый» движок, потому он не предоставляет готовых визуализаций. Из других недостатков отметим необходимость ставить Java на все серверы, так как Logstash написан на Ruby (JRuby).

У решения довольно обширное сообщество: имеется IRC-канал и отдельный форум. В сети есть примеры по конфигурации всей системы и API. Используют Logstash следующие организации: CERN Control Center, GitHub, SoundCloud.

Fluentd

6,6 тыс. звезд на GitHub. Распространяется по лицензии Apache 2.0 фондом CNCF (Cloud Native Computing Foundation) — он основан компанией Google и The Linux Foundation для продвижения технологий контейнеров.

Fluentd работает под Linux, Windows и Mac и написан на Ruby (CRuby). Fluentd имеет гибкую систему плагинов, которая расширяет его функциональные возможности.

Решение имеет унифицированный формат логирования: полученные данные Fluentd старается привести к формату JSON. Для обеспечения надежности работы не требуются сторонние решения, однако для этого приходится проводить дополнительную настройку. Также не рекомендуется устанавливать его на серверы, генерирующие логи.

Сообщество большое: имеется канал в Slack, а также тред в Google Groups. На официальном сайте проекта есть примеры конфигураций и API. Fluentd используют такие компании, как Microsoft, Amazon, change.org и Nintendo.

Graylog

4,3 тысячи звезд на GitHub. Распространяется по лицензии GNU GPL v3. Работает только под Linux. Централизованная экосистема плагинов и настраиваемая система буферизации. Для удобства позволяет по ключевому слову объединять поступающие сообщения в потоки и группировать эти потоки с разных хостов.

Система использует функции Elasticsearch, но несмотря на частые обновления Graylog и развитое сообщество (есть форум, IRC-канал, на официальном сайте проекта есть примеры конфигураций и API.), интеграция актуальных версий Elasticsearch в проект занимает длительное время. Например, в прошлом году возникла ситуация, когда Graylog 2.2.1 (на то время последний) работал только с Elasticsearch версии 2.4.4, которая считалась устаревшей.

В своей работе Graylog использует Европейское агентство по окружающей среде, компании Dial Once, Stockopedia и др.

LOGalyze

Работает под Linux и Windows. Cистема обладает высокой производительностью и умеет составлять подробные отчеты по ключевым словам. Есть серьезный недостаток — LOGalyze собирает логи в свою файловую БД, где затем их индексирует, занимая значительный объем дискового пространства.

Разработчики LOGalyze ведут свой блог, также обсуждение решения проходит в группах Google. Есть руководство по настройке системы и миграции данных, а также CLI.

Оценив эти четыре варианта, мы остановили свой выбор на Logstash и решили организовать стек ELK (ElasticSearch, Logstash, Kibana). Из них Elasticsearch — это поисковый движок, Logstash представляет собой механизм сбора и анализа логов, а Kibana «занимается» аналитикой и визуализацией данных.

Мы выбрали ELK, так как все три компонента разрабатывает один «производитель», потому они хорошо интегрируются друг с другом. При необходимости мы сможем использовать каждый из этих инструментов в отдельности для решения других задач.

Такой подход делает продукт гибким и универсальным. Все это позволит эффективнее обрабатывать уже существующие объемы данных и быстрее внедрять новые сервисы — их будет легче подключать.

Сейчас готова тестовая среда. Она «покрывает» все сервисы, логи которых мы будем анализировать. Мы заканчиваем последние отладочные процессы и планируем полноценный запуск решения уже в ближайшее время.

Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд, в итоге не обошлось и без ложки дегтя. При тестировании решения мы столкнулись с ситуацией, когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем. Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.

После запуска мы займемся настройкой систем мониторинга, чтобы максимально оперативно реагировать на сбои в работе лог-сервиса. Мы рассчитываем, что новый стек технологий позволит улучшить пользовательский опыт наших клиентов и в дальнейшем быстрее развивать наши сервисы.

Материалы из нашего корпоративного блога:

логирование — Викисловарь

Содержание

• 1 Русский
  • 1.1 Морфологические и синтаксические свойства
  • 1.2 Произношение
  • 1.3 Семантические свойства
    • 1.3.1 Значение
    • 1.3.2 Синонимы
    • 1.3.3 Антонимы
    • 1.3.4 Гиперонимы
    • 1.3.5 Гипонимы
  • 1.4 Родственные слова
  • 1.5 Этимология
  • 1.6 Фразеологизмы и устойчивые сочетания
  • 1.7 Перевод
  • 1.8 Библиография

Морфологические и синтаксические свойства[править]

логирование

Существительное, неодушевлённое, средний род (тип склонения ?? по классификации А. А. Зализняка).

Корень: —.

Произношение[править]

Семантические свойства[править]

Значение[править]

1. запись в лог, ведение лога ◆ Выполнить чистку всех сохранённых данных по аудиту, в которых проведено логирование всей цепочки прошедших операций. Константин Муравьёв, «Неучтённый», 2015 г.

Синонимы[править]

Антонимы[править]

Гиперонимы[править]

Гипонимы[править]

Родственные слова[править]

Этимология[править]

Происходит от ??

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Библиография[править]

Как правильно писать логи (?) / Хабр

Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).

Есть такая linux утилита, а также по совместительству сетевой протокол под названием syslog. И есть целый набор RFC посвящённый syslog, один из них описывает уровни логирования https://en.wikipedia.org/wiki/Syslog#Severity_level (https://tools.ietf.org/html/rfc5424). Согласно rfc 5424 для syslog определено 8 уровней логирования, для которых также дается краткое описание. Данные уровни логирования были переняты многими популярными логерами для разных языков программирования. Например, http://www.php-fig.org/psr/psr-3/ определяет те же самые 8 уровней логирования, а стандартный Ruby logger использует немного сокращённый набор из 5 уровней. Несмотря на формальное указание в каких случаях должен быть использован тот или иной уровень логов, зачастую используется комбинация вроде debug/info/fatal — первый для логирования во время разработки и тестирования, второй и третий в расчёте на продакшен. Потом в какой то момент на продакшене начинает происходить что то не понятное и вдруг оказывается, что info логов не хватает — бежим включать debug. И если они не сильно нагружают систему, то зачастую так и остаются включенными в продакшен окружении. По факту остаётся два сценария, когда нужно иметь логи:

• что-то происходит и надо знать что
• что-то сломалось и нужно дополнительно активировать триггер

По триггеру может происходить: уведомление об ошибке на email, аварийное завершение или перезапуск программы или другие типичные сценарии.

В языке Go в котором всё упрощено до предела, стандартный логер тоже прилично покромсали и оставили следующие варианты:

• Fatal — вывод в лог и немедленный выход в ОС.
• Panic — вывод в лог и возбуждение «паники» (аналог исключения)
• Print — просто выводит сообщение в лог

Запутаться, что использовать в конкретной ситуации уже практически невозможно. Но сообщения в таком сильно усеченном виде сложно анализировать, а также настраивать системы оповещения, типично реагирующих на какой нибудь Alert\Fatal\Error в тексте лога.

Я часто при написании программы с нуля повсеместно использую debug уровень для логирования с расчётом, что на продакшене будет выставлен уровень логирования info и тем самым сократится зашумлённость сообщениями. Но в таком подходе часто возникают ситуация, что логов вдруг становится не хватать. Трудно угадать, какая информация понадобиться, что бы отловить редкий баг. Возможно рационально всегда использовать по умолчанию уровень info, а в обработчиках ошибок уровень error и выше. Но если у вас сотни и больше сообщений лога в секунду, то тогда наверно есть смысл тонкой настройки между info/debug. В таких ситуациях уже имеет смысл использовать специализированные решения что бы не просаживать производительность.

Есть ещё тонкий момент, когда вы пишите что то вроде logger.debug(entity.values) — то при выставленном уровне логирования выше debug содержимое entity.values не попадёт в лог, но оно каждый раз будет вычисляться отъедая ресурсы. В Ruby логеру можно передать вместо строки сообщения блок кода: Logger.debug { entity.values }. В таком случае вычисления будут происходить только при выставленном соответствующем уровне лога. В языке Go для реализации ленивого вычисления в логер можно передать объект поддерживающий интерфейс Stringer.

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

Типичный формат строки сообщения в логе можно условно разделить на следующие составные части:

[system info] + [message] + [context]

Где:

• system info: метка времени, ид процесса, ид потока и другая служебная информация
• message: текст сообщения
• context: любая дополнительная информация, контекст может быть общим для сообщений в рамках какой то операции.

Для того, чтобы связать пары запрос\ответ часто используется http заголовок X-Request-ID. Такой заголовок может сгенерировать клиент, или он может быть сгенерирован на стороне сервера. Добавив его в контекст каждой строчки лога появится возможность лёгким движением руки найти все сообщения возникшие в рамках выполнения конкретного запроса. А в случае распределенных систем, заголовок можно передавать дальше по цепочке сетевых вызовов.

Но с единым контекстом в рамках запроса возникает проблема с различными ORM, http клиентами или другими сервисами\библиотеками, которые живут своей жизнью. И ещё хорошо, если они предоставляют возможность переопределить свой стандартный логер хотя бы глобально, а вот выставить контекст для логера в рамках запроса зачастую не реально. Данная проблема в основном актуальна для многопоточной обработки, когда один процесс обслуживает множество запросов. Но например в фрэймворке Rails имеется очень тесная интеграция между всеми компонентами и запросы ActiveRecord могут писаться в лог вместе с глобальным контекстом для текущего сетевого запроса. А в языке Go некоторые библиотеки логирования позволяют динамически создавать новый объект логера с нужным контекстом, выглядит это примерно так:

reqLog := log.WithField("requestID", requestID)

После этого такой экземпляр логера можно передать как зависимость в другие объекты. Но отсутствие стандартизированного интерфейса логирования (например как psr-3 в php) провоцирует создателей библиотек хардкодить малосовместимые реализации логеров. Поэтому если вы пишите свою библиотеку на Go и в ней есть компонент логирования, не забудьте предусмотреть интерфейс для замены логера на пользовательский.

Резюмируя:

• Логируйте с избытком. Никогда заранее не известно сколько и какой информации в логах понадобится в критический момент.
• Восемь уровней логирования — вам действительно столько надо? По опыту должно хватить максимум 3-4, и то при условии, что для них настроены обработчики событий.
• По возможности используйте ленивые вычисления для вывод сообщений в лог
• Всегда добавляйте текущий контекст в каждое сообщение лога, как минимум requestID.
• По возможности настраивайте сторонние библиотеки таким образом, чтобы они использовали логер с текущим контекстом запроса.

Лог файлы Linux по порядку / Хабр

Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе Linux, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.

Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

• приложения;
• события;
• службы;
• системный.

Большинство же лог файлов содержится в директории /var/log.

• /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
• /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
• /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.

Поддерживаемые уровни журналирования (приоритеты):
   emerg - система неиспользуемая
   alert - действие должно быть произведено немедленно
    crit - условия критичности
     err - условия ошибок
    warn - условия предупреждений
  notice - обычные, но значимые условия
    info - информационный
   debug - отладочные сообщения

(5:520)$ dmesg -l err
[1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81
[1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81

• /var/log/alternatives.log — Вывод программы update-alternatives, в котором находятся символические ссылки на команды или библиотеки по умолчанию.
• /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
• /var/log/audit — Записи, созданные службой аудита auditd.
• /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
• /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
• /var/log/cups — Все, что связано с печатью и принтерами.
• /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog.
• var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
• /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
• /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
• /var/log/samba/ — Логи файлового сервера Samba, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
• /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
• /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.

• /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
• /var/log/emerge.log — Для ebuild-ов установленных из Portage с помощью emerge в Gentoo Linux.
• /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

• /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last.
• /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2.
• /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
• /var/log/utmp — Список входов пользователей в систему на данный момент.
• /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump.

(5:535)$ sudo utmpdump /var/log/wtmp
[5] [02187] [l0  ] [        ] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:07 2015]
[1] [00000] [~~  ] [shutdown] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:08 2015]
[2] [00000] [~~  ] [reboot  ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[8] [00368] [rc  ] [        ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[1] [20019] [~~  ] [runlevel] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]

И другие журналы

Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.

• /var/log/mysql/ — Лог базы данных MySQL.
• /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
• /var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

• ~/.xsession-errors — Вывод stderr графических приложений X11.

Initializing  "kcm_input" :  "kcminit_mouse"
Initializing  "kcm_access" :  "kcminit_access"
Initializing  "kcm_kgamma" :  "kcminit_kgamma"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing.
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
Qt: Session management error: networkIdsList argument is NULL

• ~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f. Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>.

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

$ aptitude install lnav #Debian/Ubuntu/LinuxMint
$ yum install lnav #RedHat/CentOS
$ dnf install lnav #Fedora
$ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords
$ yaourt -S lnav #Arch

Навигатор журналов lnav понимает ряд форматов файлов.

• Access_log веб сервера.
• CUPS page_log
• Syslog
• glog
• dpkg.log
• strace
• Произвольные записи с временными отметками
• gzip, bzip
• Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

Программа умеет напрямую открывать архивный файл.

(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу <i>. Это с моего syslog-а.

Mon May 02 20:25:00        123 normal         3 errors         0 warnings         0 marks
Mon May 02 22:40:00          2 normal         0 errors         0 warnings         0 marks
Mon May 02 23:25:00         10 normal         0 errors         0 warnings         0 marks
Tue May 03 07:25:00         96 normal         3 errors         0 warnings         0 marks
Tue May 03 23:50:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 07:40:00         96 normal         3 errors         0 warnings         0 marks
Wed May 04 08:30:00          2 normal         0 errors         0 warnings         0 marks
Wed May 04 10:40:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 11:50:00        126 normal         2 errors         1 warnings         0 marks

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.

Использованные материалы

1. lnav — An Advanced Log File viewer for Linux
2. What Are Linux Logs? How to View Them, Most Important Directories, and More
3. Как посмотреть логи в Linux

Руководство по управлению журналами

: что такое журналы и зачем они нужны разработчикам

Что такое управление журналами?

Управление журналами — это процесс обработки событий журнала, генерируемых всеми программными приложениями и инфраструктурой, в которых они работают. Он включает в себя сбор, агрегирование, синтаксический анализ, хранение, анализ, поиск, архивирование и удаление журналов с конечной целью использования данных для устранения неполадок и получения бизнес-информации, а также обеспечения соответствия и безопасности приложений и инфраструктуры.

Журналы обычно записываются в один или несколько файлов журналов. Управление журналами позволяет собирать данные в одном месте и рассматривать их как часть целого, а не как отдельные объекты. Таким образом, вы можете анализировать собранные данные журнала, выявлять проблемы и закономерности, чтобы вы могли нарисовать четкую и наглядную картину того, как все ваши системы работают в любой момент.

Ведение журнала стало неотъемлемой частью любой команды DevOps. Решения для управления журналами различаются по использованию: от использования популярного стека ELK с открытым исходным кодом, обычно развертываемого в вашей собственной инфраструктуре, до полностью управляемых решений для управления журналами, таких как Sematext Cloud.

Основы управления журналами: что такое файл журнала

Файл журнала — это текстовый файл, в который приложения, включая операционную систему, записывают события. Журналы показывают, что происходило за кулисами и когда это происходило, так что если что-то пойдет не так с вашими системами, у вас будет подробный отчет обо всех действиях, предшествовавших аномалии.

Таким образом, файлы журналов упрощают разработчикам, DevOps, системным администраторам или SecOps получение аналитических сведений и определение основной причины проблем с приложениями и инфраструктурой.

Хотите избежать проблем с управлением журналами на своих серверах?
Отправляйте журналы в Sematext Logs и просматривайте все журналы и показатели под одной крышей, чтобы упростить свою работу и быстро устранить неполадки.
Начните 30-дневную бесплатную пробную версию Ознакомьтесь с нашими тарифными планами
Кредитная карта не требуется — начните за секунды

Журналы также полезны, когда системы работают нормально. Вы можете получить представление о том, как ваше приложение реагирует и работает, чтобы улучшить его.

Существует множество различных источников журналов, а также типов журналов.Вот некоторые из основных источников журналов, которые мы видим сегодня, начиная с нижней части стека.

Сетевое оборудование

Поскольку мы взаимодействуем с мобильными приложениями, веб-приложениями, веб-сайтами и т. Д., Мы генерируем большой сетевой трафик. Сетевое оборудование — сетевые маршрутизаторы, сетевые коммутаторы и т. Д. — может создавать журналы об этом трафике. В отличие от журналов серверов и приложений, которые, как правило, используют более современные форматы и все более структурированные журналы, сетевое оборудование по-прежнему использует различные виды системного журнала.

Также читайте:

Журналы серверов и приложений

Традиционными источниками событий журнала являются серверы и приложения, работающие на этих серверах.Ядро выдает сообщения журнала, например, какие драйверы оно загружает, был ли вызван убийца OOM и т. Д. Кроме того, существуют системные службы, например, когда пользователь вошел в систему. Эта информация помогает диагностировать проблемы стабильности и безопасности, а также узкие места производительности на уровне системы. Отправляет ли ядро ​​файлы cookie SYN? Это может быть атака или сеть может быть перегружена.

Что касается приложений, у вас могут быть журналы веб-сервера Nginx, веб-приложение Java, работающее в Apache Tomcat, или приложение PHP, работающее на веб-сервере Apache.Они будут генерировать различные информационные события, события журнала ошибок или отладки.

Некоторые из этих журналов используют стандартные форматы, такие как Common Log Format, в то время как другие используют различные настраиваемые форматы, включая различные структурированные форматы журналов, такие как key = value или даже журналы JSON.

Если вы пишете собственное приложение, мы настоятельно рекомендуем структурированный формат ведения журнала. Анализировать конвейер намного проще.

Контейнерные бревна

В настоящее время все больше и больше приложений развертывается в контейнерах.Таким образом, контейнеры и приложения, работающие внутри них, являются еще одним большим источником журналов. В отличие от традиционных приложений и серверов, и, конечно же, сетевого оборудования, контейнеры очень «беспорядочные». Фреймворки оркестровки контейнеров, такие как Kubernetes, перемещают контейнеры с хоста на хост, адаптируясь к спросу и доступности ресурсов. Средняя продолжительность жизни контейнера меньше, чем у светлячка или пчелы.

Вдобавок к этому практика «ssh in», поиска по журналам, отслеживания и поиска в журналах для устранения неполадок считалась плохой практикой в ​​облачном мире.Следовательно, различные проблемы мониторинга Docker и управления журналами требуют новых подходов и новых инструментов управления журналами Docker.

Дополнительная литература:

Журналы мобильных устройств и приложений

Мобильные приложения и устройства распространены повсеместно. Вы можете не думать о них как об источниках журналов, потому что вы не можете (легко) получить доступ к журналам системы или приложений на устройстве iOS или Android. Ограниченное дисковое пространство и ненадежная сеть означают, что вы не можете регистрировать подробные сообщения локально и не можете рассчитывать, что будете отправлять журналы в центральное место в реальном времени.

Несмотря на эти проблемы, важно знать, вылетает ли мобильное приложение и почему. Помимо этого, как приложение ведет себя и работает. Как правило, вы буферизуете до N сообщений локально и отправляете их в централизованную службу ведения журнала. Это то, что делают библиотеки Sematext Cloud для Android и iOS.

Датчики, Интернет вещей, Промышленный Интернет вещей

В сфере потребления у нас есть датчики в автомобилях, интеллектуальные термостаты, подключенные к Интернету холодильники и другие устройства для умного дома и, в более широком смысле, умные города.

Промышленный Интернет вещей, или IIoT, соединяет машины и устройства в таких отраслях, как транспорт, электроэнергетика, производство и здравоохранение.

Обычно нас интересуют показатели, генерируемые этими устройствами. Например, мы собираем некоторые уровни загрязнения воздуха (PM2,5, PM10) и отправляем их в Sematext Cloud. Но журналы, отправленные с этих устройств, также важны: этот датчик запустился правильно? Нужна ли перекалибровка? Сколько раз датчики выходили из строя за последние 6 месяцев? Основываясь на этой информации, какой производитель самый надежный? Это всего лишь несколько примеров метаданных, которые можно извлечь из журналов Интернета вещей.

Почему важна регистрация. Ключевые преимущества и сценарии использования

Управление журналами позволяет оценить работоспособность и соответствие ваших систем и приложений.

Без него вы бы спотыкались в темноте в надежде определить источники проблем с производительностью, ошибок, неожиданного поведения и других подобных проблем. Вам придется вручную проверять несколько файлов журнала, пытаясь устранить производственные проблемы. Это очень медленно, подвержено ошибкам, дорого и не масштабируется.

Управление журналами особенно важно для облачных приложений из-за их динамического, распределенного и эфемерного характера. В отличие от традиционных приложений, облачные приложения часто запускаются в контейнерах и выводят журналы на стандартный вывод, а не записывают их в файлы журналов. Это означает, что у вас нет «опции по умолчанию» для ручного поиска журналов. Как правило, вы собираете журналы и отправляете их в решение для централизованного управления журналами.

Вкратце, управление журналами позволяет операторам приложений и инфраструктуры (разработчикам, DevOps, системным администраторам и т. Д.)) для устранения проблем и позволяет заинтересованным сторонам бизнеса (менеджерам по продукту, маркетингу, BizOps и т. д.) получать информацию из данных, встроенных в события журнала. Журналы также являются одним из ключевых источников данных для аналитики безопасности — обнаружения угроз, обнаружения вторжений, соответствия, сетевой безопасности и т. Д., Известных под общим названием SIEM (Security Information and Event Management).

Чтобы полностью понять важность управления журналами, мы собрали некоторые из основных преимуществ ниже:

Мониторинг и устранение неисправностей

Наиболее распространенным вариантом использования управления журналами является устранение неполадок программного обеспечения и инфраструктуры.События журнала идут рука об руку с мониторингом приложений и мониторингом серверов. Разработчики, DevOps, системные администраторы и SecOps используют как метрики, так и журналы, чтобы получать предупреждения о проблемах с производительностью и работоспособностью приложений и инфраструктуры, а также для поиска первопричины этих проблем. Наличие хороших инструментов управления журналами помогает сократить MTTR (среднее время восстановления), что, в свою очередь, помогает улучшить взаимодействие с пользователем. Длительные простои или даже плохо работающие приложения и инфраструктура также могут привести к потере прибыли.Таким образом, программное обеспечение для управления журналами играет решающую роль в сокращении MTTR.

Однако журналы

не ограничиваются поиском и устранением неисправностей. Если ваши журналы структурированы — либо из источника, либо проанализированы в конвейере, — вы можете извлечь интересные метаданные. Например, мы часто просматриваем журналы медленных запросов во время консультаций по Solr или Elasticsearch. Тогда мы сможем ответить на множество вопросов, например, какие типы запросов возникают чаще, какие запросы выполняются медленно, какова разбивка по каждому клиенту или у нас есть «шумные» клиенты? Все это помогает нам оптимизировать настройку, от архитектуры до запросов.Если все пойдет хорошо, мы получим более стабильную, быструю и более экономичную систему. И мы упрощаем работу по поддержке собственного производства!

Менее «технический» источник журналов может быть каналом продаж. Если мы регистрируем действия клиентов на каждом этапе — вместе с метаданными клиентов — мы можем оптимизировать. Сколько из тех, кто создает учетную запись, в конечном итоге входят в систему? Могут ли они успешно пользоваться нашим сервисом или нам следует улучшить процесс адаптации? Существуют ли определенные категории клиентов (например, из какого-либо региона мира), у которых возникают проблемы? Мы можем получить эти идеи, если централизовать журналы.

Управление журналами по сравнению с APM

Несмотря на то, что ведение журнала и мониторинг частично совпадают, важно отметить, что это не разные слова для одного и того же процесса. Хотя оба они важны для понимания того, что пошло не так с вашей системой, у каждого из них разные цели. Ведение журнала занимается управлением данными внутри журналов и делает их доступными для чтения в любое время. Мониторинг или мониторинг производительности приложений (APM) берет эти данные и анализирует их, чтобы нарисовать картину поведения системы и помочь вам отследить причину.

Существуют отдельные инструменты, которые вы можете использовать для каждой функции, или вы можете выбрать комплексное решение, такое как Sematext Cloud, которое имеет функции, необходимые для эффективного ведения журналов и мониторинга.

Дополнительная литература :

Улучшенные операции

По мере того, как приложения и системы становятся все более и более сложными, увеличиваются и размер, и сложность ваших операций. SecOps, SysAdmins и DevOps будет труднее контролировать все «вручную», что потребует больше времени и финансовых ресурсов.

С помощью ведения журнала вы можете выявлять тенденции во всей инфраструктуре вашей компании, что позволяет быстро адаптироваться и предлагать решения, которые предотвращают «пожары», а не «тушат их».

Лучшее использование ресурсов

Когда дело доходит до проблем с производительностью системы, перегрузка системы всегда похожа на нависшее темное облако. Однако вы должны помнить, что это не всегда ваша ошибка программного обеспечения, а скорее запросы, которые у вас есть на вашем сервере. Независимо от того, их слишком много или слишком сложно, ваша система может столкнуться с трудностями при их работе.

В этом случае управление журналом помогает отслеживать использование ресурсов. Затем вы можете увидеть, когда ваша система близка к перегрузке, чтобы вы могли лучше распределить свои ресурсы.

Мониторинг производительности может сообщить вам, если есть проблемы с производительностью, например, что запросы 90-го процентиля выполняются медленно. Они также могут выявить узкие места. Если придерживаться примера, вы можете обнаружить, что ввод-вывод перегружен, когда запросы выполняются медленно. Тем не менее, вам понадобятся журналы запросов, чтобы получить более полезную информацию, например о содержании более дорогих запросов, о том, сколько данных затрагивает эти запросы и сколько из них выполняется параллельно.В отличие от показателей, с журналами у вас есть больше метаданных для фильтрации и визуализации.

Пользовательский опыт

Как и в предыдущем примере, одна из самых больших головных болей, о которых люди сообщают, работая с приложениями, — это длительное время ответа на запросы или отсутствие ответа вообще. Управление журналами позволяет отслеживать запросы на любом уровне (API, база данных и т. Д.) И видеть, какие из них неэффективны. Это позволяет вам вмешаться и понять, почему возникли такие проблемы, и тем самым держать вас под контролем пользователей.

Заинтересованы в решении, которое поможет вам обеспечить безупречный пользовательский интерфейс?
Sematext Logs предлагает оповещения в реальном времени как по показателям, так и по журналам, чтобы помочь обнаружить проблемы еще до того, как они затронут конечных пользователей.
Начать Ознакомьтесь с нашими тарифными планами
Бесплатно в течение 30 дней. Кредитная карта не требуется

Понимание поведения посетителей сайта

Управление журналами, наряду с реальным мониторингом пользователей (RUM), может помочь отслеживать переход ваших пользователей по вашему сайту или платформе, чтобы вы могли лучше понять их поведение и улучшить их опыт.Здесь управление журналами и мониторинг реального пользователя (RUM) дополняют друг друга.

Инструменты

RUM предоставляют доступ к точке зрения пользователя, такой как количество посетителей вашего сайта, на какие страницы они проводили больше всего времени, есть ли изменения в количестве посетителей и многое другое.

Из журналов у вас есть доступ к метаданным, близким к вашей бизнес-логике: сколько пользователей в конечном итоге заплатили, как выглядели внутренние запросы и т. Д. Сопоставляя эти два источника данных, вы можете определить возможности, например, когда запускать новый продукт , когда закрыть сайт на техническое обслуживание или предложить скидки.

В Sematext мы предлагаем управление RUM и журналами под одной крышей — Sematext Cloud. Вы можете создавать информационные панели с информацией из обоих.

Дополнительная безопасность

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

Так что всякий раз, когда кто-то пытается пробить ваши стены — будь то внутренняя или внешняя угроза, вы лучше понимаете, что произошло на самом деле. Вы также можете получить уведомление до того, как возникнут аномалии, чтобы вы могли отреагировать до того, как проблема обострится.

Политика аудита и ведения журнала безопасности

Лучший способ обеспечить соответствие требованиям безопасности и аудита — создать политику ведения журналов и мониторинга.

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

Обеспечение соответствия нормам

Поскольку виртуальные атаки становится все труднее обнаруживать и устранять, очень важно, чтобы ваша компания соответствовала требованиям политик безопасности, аудита, регулирования и криминалистики.

Одними из наиболее важных являются HIPPA (Закон о переносимости и подотчетности в медицинском страховании), PCI DSS (Стандарт безопасности данных индустрии платежных карт) и GDPR (Общие правила защиты данных). Кроме того, ужесточающиеся правила требуют, чтобы вы собирали данные журналов, хранили их и защищали от угроз, в то же время имея их доступными для аудита. В противном случае, если произойдет утечка данных, ваша компания может быть уязвима к потере прибыли, а также к крупным штрафам из-за различных правил, введенных несколькими организациями.

Управление журналами поможет предупредить нужных людей о любой подозрительной активности в отношении пользовательских данных.

Прочтите также :

Жизненный цикл управления журналами

: как это работает?

Управление журналами имеет 5 ключевых функций, выполнение которых обеспечит бесперебойную работу журналов и мониторинга. Давайте посмотрим, что это за 5 элементов:

Коллекция бревен

Как упоминалось выше, все ваши системы и приложения в любой момент генерируют файлы журналов, которые могут храниться в различных местах в вашем программном стеке, операционной системе, контейнерах, облачной инфраструктуре и сетевых устройствах.

Под сбором журнала мы подразумеваем получение данных из источника (например, файла журнала) или прием данных, отправленных из этого источника (через UNIX или сетевой сокет). Затем вы можете отправить его на следующий переход в конвейере.

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

Связанные статьи по отгрузке журналов :

Агрегация журналов в централизованное хранилище журналов

Следующим ключевым элементом в управлении журналами является агрегирование журналов.

Типичный конвейер агрегирования журналов может:

• собираем логи из необходимых источников, как мы описали выше.
• буферизует журналы на случай проблем с сетью или пропускной способностью.
• анализирует журналы, чтобы преобразовать их в формат, который можно индексировать. Например, Elasticsearch использует JSON, поэтому вам нужно преобразовать ваши журналы в JSON

.

• , при желании, можно дополнить их различными метаданными.Например, зная IP-адрес источника, вы можете отметить отдел компании этого хоста или его географическое местоположение.

Вы можете или не хотите разделять эти роли. Вот несколько примеров архитектур:

• делаю все близко к источнику . Это будет автоматически масштабироваться с увеличением количества источников, но может стать проблемой, если у вас ограниченные ресурсы (например, сеть или мобильные устройства). В качестве примеров вы можете установить облегченную программу доставки журналов, такую ​​как rsyslog или Logagent, на каждый хост, который генерирует журналы.
• имеют выделенный сервер (ы), который выполняет буферизацию, синтаксический анализ и обогащение . Предпочтительно в этом порядке, чтобы данные можно было буферизовать, если обработка слишком дорога. Примером такой схемы является централизованный Logstash, получающий данные от облегченного отправителя журналов, такого как Filebeat.
• имеют выделенную буферизацию, обычно это кластер Kafka . (Легковесный) отправитель журналов отправит данные в Kafka. С другой стороны, у вас есть Потребитель (например, Logstash или Logagent), отвечающий за синтаксический анализ, обогащение и отправку данных в окончательное хранилище.

Это последнее хранилище можно развернуть внутри компании, например, с помощью Elasticsearch или Solr. Или это может быть управляемый сервис, например Sematext Cloud. Управляемая служба может позаботиться о некоторых частях конвейера за вас. Например, вы можете отправить системный журнал прямо со своих устройств в Sematext Cloud, где он буферизируется, анализируется и индексируется. Он также может автоматически создавать резервные копии в вашей корзине AWS S3 в целях архивирования / соответствия требованиям.

Узнайте больше об агрегировании журналов, о том, что это такое и как работает, в нашем руководстве по агрегированию журналов: Инструменты и учебные пособия.

Поиск и анализ журнала

Сохраненные и проиндексированные ваши агрегированные файлы журналов теперь доступны для поиска. Обычно с помощью структурированного языка, такого как синтаксис запросов Lucene, используемый в Sematext Cloud. Так вам будет проще погрузиться в анализ первопричин.

Анализ журналов — это больше, чем просто поиск. Даже при устранении неполадок часто бывает полезно иметь возможность визуализировать разбивку данных: не подскакивает ли в какой-то момент общий объем? Как насчет объема трафика? Или количество ошибок на хост? Если ваши журналы структурированы во время индексации, вы можете получить всю эту информацию и многое другое.

Мониторинг журнала и оповещение

Управление журналами помогает держать вас в напряжении, постоянно предоставляя данные о работе ваших систем и приложений. Он также информирует вас о том, нормально ли работает ваша инфраструктура, есть ли аномалии активности или нарушения безопасности.

Ключевой частью этого процесса является то, что он позволяет настраивать правила и предупреждения, чтобы нужные группы или люди получали уведомления в режиме реального времени, чтобы принять меры до того, как это затронет пользователей.

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

Статьи по теме:

Визуализация журналов и создание отчетов

Все члены команды — и другие члены кросс-функциональной команды — должны иметь доступ к одной и той же информации, чтобы все были на одной странице. Отчеты и визуализация делают все, что происходит за кулисами, доступным для всех, в том числе для людей вне ИТ-отдела.

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

Наличие четкого представления о том, насколько большие объемы данных изменяются с течением времени, упрощает выявление тенденций или аномалий в поведении. Затем вы можете просто перейти к строке журнала, в которой произошел всплеск.

Ищете решение, которое упростит получение более точной информации из журналов?
Sematext Logs имеет богатые информационные панели и возможности отчетности, которые помогают быстрее обнаруживать аномалии, а также извлекать бизнес-ключевые показатели эффективности.
Попробуйте бесплатно в течение 30 дней Ознакомьтесь с нашими тарифными планами
Кредитная карта не требуется

Проблемы управления журналами в современных ИТ-средах

При переходе приложений от монолитной к микросервисной архитектуре вы продолжите добавлять более сложные уровни поверх примитивной инфраструктуры.Это, в свою очередь, усложняет отслеживание вашего стека. В то время как облачные вычисления и практически «неограниченное» хранилище решили некоторые из традиционных проблем управления журналами, современные приложения создают дополнительные и разные задачи

• Распределенные системы генерируют огромные объемы данных, которые дорого хранить и которые сложно запрашивать.
• Сбор журналов, доставка, мониторинг и оповещение должны выполняться в режиме реального времени, чтобы группы могли немедленно приступить к устранению неполадок.
• Облачная архитектура требует эффективных журналов, предупреждений, автоматизации, инструментов анализа, упреждающего мониторинга и отчетности, которых нет в
• поддерживается традиционным управлением журналами.
• Журналы бывают разных форматов, которые необходимо поддерживать

К счастью, современные системы управления журналами с их 5 функциями — сбор журналов, агрегирование, поиск и анализ, мониторинг и оповещение, визуализация и отчетность — могут помочь преодолеть эти проблемы журналирования.Однако эти функции должны быть построены на основе облачных принципов, таких как высокая доступность, масштабируемость, отказоустойчивость и автоматизация. Кроме того, многолетний опыт и метод проб и ошибок позволили выявить некоторые советы и рекомендации, которые можно использовать для эффективного ведения журнала даже в таких сложных средах. Давайте рассмотрим это дальше.

Политика управления журналами

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

В то же время это помогает снизить затраты. Может быть трудно добиться нужного уровня видимости при минимальных затратах. Чем больше журналов вы соберете, тем больший бюджет вы должны выделить на свои потребности в мониторинге.Следовательно, сбор журналов на основе политики ведения журналов позволяет вам иметь обширную и правильную информацию для ваших вариантов использования.

Обычно политики ведения журналов требуются для определенных стандартов сертификации, но даже если вы не подпадаете под действие правил или сертификации, все равно важно знать, какие журналы нужно отслеживать, поскольку это позволяет вам расследовать мошенничество и конфиденциальность ваших пользователей. играть.

Внедрение политики управления журналами — это трехэтапный процесс: создание политики, передача ее всей компании, а затем ее применение.Однако вы должны иметь в виду, что вам нужны разные политики для требований аудита и требований безопасности, потому что… x

Зачем нужны инструменты управления журналами?

Как упоминалось ранее, вы можете пройти все этапы управления журналом самостоятельно. Однако, если вы не используете инструменты управления журналами, вам потребуется потратить много времени и энергии.

Решения

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

Как выбрать программное обеспечение для управления журналами: основные функции и требования

Существует множество поставщиков, которые предлагают управление журналами как услугу для DevOps, как бесплатную, так и платную с открытым исходным кодом.Ознакомьтесь с нашим сравнением лучших инструментов и фреймворков для управления журналами (платных и бесплатных).

Что общего у этих инструментов? При поиске программного обеспечения для управления журналами следует соблюдать несколько основных требований:

• Простота подключения и интеграции с уже существующими системами
• Поддержка SSL-шифрования для передаваемых данных и доступа на основе ролей
• Соответствует действующим нормативным требованиям
• Интуитивно понятный пользовательский интерфейс
• Функции быстрого и интуитивного поиска и фильтрации
• Поддержка расширенной аналитики, такой как машинное обучение и обнаружение аномалий, для решения проблем с большими данными
• Масштабируемость и гибкость по мере роста объема данных без увеличения затрат
• Оповещения и уведомления в реальном времени

Sematext как решение для централизованного ведения журнала

Sematext Cloud — это облачная платформа с полным набором функций наблюдения, которая устраняет разрыв между мониторингом инфраструктуры, трассировкой, управлением журналами, синтетическим мониторингом и мониторингом реальных пользователей, повышая эффективность и быстрее предоставляя полезные аналитические данные.Вы можете легко выявлять и устранять проблемы до того, как они повлияют на ваших пользователей, и выявить возможности для стимулирования роста бизнеса — мы рекомендуем вам изучить эту проблему более подробно здесь.

Следующие шаги

Надеюсь, это руководство помогло вам понять, что такое управление журналами, как оно работает и как выбрать правильные инструменты. Следующий шаг — выбрать правильный инструмент и начать регистрацию. Ознакомьтесь с некоторыми передовыми методами управления и мониторинга журналов, которым вы должны следовать, чтобы в полной мере воспользоваться преимуществами данных журнала.

.

Что такое удаленное ведение журнала? | Анализ журнала

Это первая из трех публикаций в блоге, описывающих некоторые технологии, которые я использую ежедневно:

1. Что такое удаленное ведение журнала?
2. Как писать эффективные журналы с помощью Loggly
3. Как на самом деле использовать Loggly?

Почему всем следует вести журнал удаленно

Итак, что такое удаленное ведение журнала?

Удаленное ведение журнала не является загадкой. Вы записываете файлы журнала на удаленный компьютер, а не локально.До Loggly у этого были свои недостатки. Хуже, чем очистить файл журнала размером 200 МБ для воспроизведения ошибки, которую вы не понимаете, — это очистить 15 из них. До появления мобильных телефонов и Интернета вещей даже мыть 15 из них было разумным. Однако в сегодняшней взаимосвязанной глобальной сети связи в режиме реального времени данные вышли из-под контроля. Теперь у нас есть 96 подписок на сотовые телефоны на каждые 100 человек с потенциально 2 миллиардами смартфонов и (невероятно) 6,4 миллиардами «вещей, которые общаются по IP», включая потребительские товары, бизнес-утилиты и специализированные бизнес-устройства [Источник: Gartner].

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

У разработчиков большая работа. Что еще хуже, огромное количество пользователей обнаруживает гораздо больше угловых случаев, чем явное тестирование QA, модульное тестирование, интеграционное тестирование, сквозное тестирование и обезьяны.

Все программы содержат ошибки. [Источник: Reddit] У вашего программного обеспечения будут проблемы, которые вы не сможете воспроизвести или предвидеть.Почему бы вам просто не открыть журнал устройства, на котором возникла ошибка, и не прочитать, что произошло? Войдите в удаленное ведение журнала.

Краткое описание удаленного ведения журнала

Поставщик удаленного ведения журнала создает безопасную конечную точку POST с шифрованием HTTPS в виде дампа строки. Вы, вместо того, чтобы записывать журналы в консоль или в файл журнала, записываете все свои журналы прямо в эту прекрасную конечную точку публикации. Конечная точка — дамп строки. Для этого не нужен сложный список аргументов; не требует тщательного строительства и демонтажа.Это строковый дамп, например:

Удаленное ведение журнала: новая реальность отладки

Всем знакомо использование операторов отладки для отслеживания потока кода. Фактически, до популярности графических IDE с их графическими трассировками стека, указателями на текущий контекст выполнения и функциональностью перехода / пошагового выполнения в стиле GDB, ведение журнала консоли было самой популярной формой отладки. В моей карьере отладка на основе журналов была в значительной степени непопулярной. Однако теперь Loggly и другие подобные службы удаленного ведения журналов определенно заставляют это измениться.

Представьте, что вы новичок в проекте Ruby on Rails среднего размера. Ваш босс приходит к вам с жалобой клиента. Данные теряются после того, как клиент пытается сохранить свой профиль. Никто не знает, куда идут данные или почему они теряются. Поскольку вы новичок в этом проекте, у вас есть только один разумный подход к решению ошибки: подключитесь к серверу, ответственному за потерю данных, и прочитайте его журналы, пока вы не сможете определить момент времени, в который возникает ошибка. Поскольку это проект Ruby on Rails среднего размера, допустим, у вас меньше 10 серверов и практически нет специализированных инструментов.Ваше решение: подключитесь по SSH к серверам один за другим и просматривайте их журналы, пока не найдете сервер, ответственный за выполнение недопустимого кода. Я называю это бревенчатым скрабом. Это может быть легко, а может быть и безрезультатно.

Теперь, используя Loggly, это почти всегда просто. Фактически, это обязательно. Loggly предоставляет бесплатные, простые в использовании библиотеки, которые направляют системный журнал (или любой другой файл или канал, если на то пошло) с каждого сервера на удаленный хост. Вместо log-scrub вы как системный администратор / dev-ops / tech support просто входите на портал входа в систему Loggly и пытаетесь выполнить поиск (так же, как мы используем переполнение стека), пока не обнаружите проблему.Каждый поиск обеспечивает простое устранение неоднозначности на сервере, простой поиск по поисковому запросу и встроенный набор индексов ключа / значения JSON для категоризации данных.

Удаленное ведение журнала повышает подотчетность

Когда кто-то задает вам вопрос или когда он сталкивался с каким-либо вариантом использования, которого у вас нет, он говорит: «Мы расследуем это» — не является большой ответственностью. Сказать: «У нас есть журналы и мы знаем, в какой строке кода произошла ошибка» — это ответственность.

С Loggly вы получаете ответственность и уверенность в поиске ошибок.Если вам задают вопрос о программном обеспечении, особенно о варианте использования, которого вы не видели, у вас есть возможность ответить конкретнее. Сказать: «Мы исследуем эту ошибку» вместо «Дай мне посмотреть журналы и найти строку кода, в которой произошла ошибка» — вот разница между приемлемым сервисом и ответственным решением проблем в реальном времени.

Loggly улучшает взаимодействие в обоих направлениях в проектах программного обеспечения. Уменьшая двусмысленность с помощью удаленного ведения журнала, разработчики, менеджеры и клиенты могут свободно общаться.Когда менеджер не уверен в «разрешимости» ошибки или когда клиент не уверен, что его или ее контрактные сотрудники говорят всю правду, люди, как правило, замолкают. Это может стать похоронным звонком для небольшого программного проекта. Когда вы можете сказать: «У нас есть эти журналы — скажите мне, когда это произошло», это доказывает, что вы можете исправить это, и позволяет вам сделать это, как только это будет необходимо. Упрощается даже сортировка ошибок, поскольку гораздо меньшее количество отчетов о дефектах станет бездонной ямой потери производительности.

Клиенты хотят добиться прогресса, но понимают, что ошибки будут. Loggly делает исправление этих ошибок более надежным. Одно из моих любимых ощущений во время цикла разработки — разговаривать с клиентами по телефону после того, как они обнаружили ошибку. Вместо того, чтобы говорить: «Я не знаю, почему это произошло, но исправить это будет моей первоочередной задачей!» Я уверенно говорю: «Давайте поговорим о том, что произошло, и я буду читать журналы вашего устройства на своем компьютере, пока это происходит. С вероятностью 90% мы обнаружим ошибку и исправим ее, пока вы говорите со мной по телефону.”

У меня был пункт « устранять ошибки профессионально. ”Правильно, уважаемые читатели, это профессиональная разработка программного обеспечения.

Удаленное ведение журнала — будущее

Удаленное ведение журнала применяется к разработке IoT, мобильной разработке, разработке веб-приложений, разработке аппаратного / микропрограммного обеспечения и большей части домашней электроники. Удаленное ведение журнала может стать законом, когда автомобили станут более интеллектуальными. Использование полосы пропускания может быть проблемой для Loggly, особенно для мобильных пользователей (о чем мы поговорим в следующей статье «Как эффективно входить в журнал с помощью Loggly»).Однако Loggly всегда будет использовать крошечную долю полосы пропускания по сравнению с потоковой передачей аудио / видео — незначительную, бессмысленную полосу пропускания по сравнению с преимуществами ее использования.

В следующий раз

Как вести удаленный журнал эффективно, информативно и безопасно с помощью Loggly.

Подробнее: Что такое удаленное ведение журнала? »

Начните удаленное ведение журнала сегодня, нажмите, чтобы подписаться на бесплатную 30-дневную учетную запись для мониторинга журналов.

---

О компании Thomson

Получив М.Имеет степень бакалавра компьютерных наук в Государственном университете Колорадо. В настоящее время Томсон предоставляет консультационные услуги по запросу в компании Cardinal Peak, LLC недалеко от Боулдера, штат Колорадо. Когда он не создает пользовательские интерфейсы, не анализирует данные и не проверяет протоколы безопасности, он проводит время, путешествуя по семи морям с женой и четырьмя детьми. Клиентами Cardinal Peak являются Samsung, Beyond Oblivion, Yonder, Time Warner Cable, Dish Network, Ball Aerospace, Cable Labs, Covidien, Comcast, а также ряд крупных новых клиентов, которые появляются и приходят в Интернет вещей (IoT).Следуйте за ним в Twitter: @thomcom.

Торговые марки, знаки обслуживания и логотипы Loggly и SolarWinds являются исключительной собственностью SolarWinds Worldwide, LLC или ее дочерних компаний. Все остальные товарные знаки являются собственностью соответствующих владельцев.

.

c ++ — В чем смысл и цель библиотеки журналов?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Что такое структурированное ведение журнала? — DZone DevOps

В течение длительного периода моей карьеры разработчика я полагал, что ведение журнала подходит только для приложений, не имеющих пользовательского интерфейса. Мы когда-либо использовали его только для диагностики ошибок. Как только программное обеспечение поступит в производство, мы будем получать уведомления всякий раз, когда операции сообщают о трассировке стека. Иногда мы сразу понимали, в чем проблема. Чаще всего у нас не было достаточно информации о последовательности событий, которые привели к проблеме, и решение потребовало бы много вдохновляющих догадок и детективной работы.

Затем я заметил, что Thoughtworks порекомендовала внедрить что-то под названием «Структурированное ведение журнала» в своем радаре технологий в мае 2015 года. Какого черта это было? Ясно, что упустил кое-что важное…

С тех пор я пришел к пониманию, что ведение журнала может и, вероятно, должно использоваться не только для диагностики ошибок. Хорошо спроектированная система регистрации может также использоваться для бизнес-аналитики (например, как используется система), а также для мониторинга системы (например,г., какие нагрузки мы испытываем).

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

Что для нас может сделать структурированная регистрация?

Клиенты часто считают, что поддержка бизнес-аналитики имеет гораздо меньший приоритет, чем добавление новых функций.В конце концов, мы всегда можем добавить это позже, верно? Мой опыт показывает, что к тому времени, когда наступает «позднее», попытки модифицировать программное обеспечение становятся непосильными … если только вы не использовали структурированное ведение журнала все время. В этом случае добавить поддержку бизнес-аналитики оказывается очень просто. Во многих случаях все, что вам нужно сделать, это создать несколько стандартных отчетов с помощью инструментов анализа журналов.

Вот еще несколько вопросов, на которые структурированное ведение журнала поможет нам легко ответить, если оно реализовано с самого начала:

• Диагностика

• Аналитика

  • Кто пользуется нашими услугами?

  • Как будет выглядеть использование с течением времени?

  • Для чего наши клиенты используют нашу систему?

• Мониторинг

Практические вопросы

В нашей отрасли происходит бурный рост объемов данных.Масштабный рост машин и инфраструктуры. Возможность обнаруживать ошибки и соотносить информацию из распределенных систем становится критически важной. Наша система регистрации должна обеспечивать возможность отслеживать операции на многих машинах и системах. Это действительно практично только в том случае, если мы используем стандартный формат ведения журнала, делаем наши журналы машиночитаемыми и вводим токены, которые идентифицируют операции, которые пересекают границы компьютера.

Формат регистрации

Итак, какой хороший формат делает наши журналы машиночитаемыми (так же как и людьми)? Хотя есть альтернативы — XML, пары имя-значение, столбцы фиксированной ширины и т. Д.- наиболее очевидным форматом для машиночитаемого формата событий журналирования является JSON, и оказывается, что существует довольно много инструментов, которые с удовольствием используют журналы JSON. Вместо того, чтобы использовать промежуточные инструменты, такие как logstash, конвертировать наши журналы в JSON, кажется более эффективным сначала просто войти в JSON.

Что мы должны регистрировать?

Стандартные библиотеки журналов, такие как Simple Logging Facade для Java (SLF4J), уже включают много полезной информации: отметку времени, pid, поток, уровень, имя журнала и т. Д.Нам просто нужно расширить этот список атрибутами, специфичными для нашего программного обеспечения.

Если мы хотим отслеживать операцию на нескольких машинах и системах, нам нужно включить идентификационный токен в журналы. Иногда это называется идентификатором запроса или идентификатором транзакции. Включение этого токена позволит нашим инструментам ведения журнала извлекать только те события, которые относятся к этому запросу, даже если в его обслуживании могут участвовать несколько систем.

Значения, такие как идентификатор транзакции, должны быть переданы между нашими системами, чтобы это работало.Некоторые способы сделать это — это настраиваемые заголовки HTTP, дополнительные поля сообщений и столбцы базы данных.

Стандартизированные уровни ведения журнала

Различные компоненты нашей системы должны согласованно использовать уровни ведения журнала. Обычно в производственной системе используется уровень ведения журнала INFO, а в процессе разработки — уровень ведения журнала DEBUG. Исходя из этого, вот предложение о том, когда следует использовать другие уровни:

• ОШИБКА: непредвиденные ошибки, например.g., потеря связи, логические ошибки, неправильная конфигурация.

• WARN: Ожидаемые ошибки, например, ошибка аутентификации пользователя.

• ИНФОРМАЦИЯ: все, что нам нужно увидеть в производственной системе, относящееся к бизнес-аналитике, диагностике или мониторингу, например, запуск / завершение пользовательского запроса, моментальные снимки использования ресурсов, информация о времени.

• DEBUG: Разработчики должны видеть, например, вход в различные архитектурные уровни с параметрами.

• TRACE: Разработчики могут временно включиться, например.ж., сложная логика ветвления, дампы структур данных.

Некоторые инструменты для лесозаготовок

Существует постоянно расширяющийся набор инструментов для выполнения такого рода анализа журналов. Некоторые примеры: Graylog, Elasticsearch / Logstash / Kibana (ELK), Loggly и Splunk.

Все они могут потреблять и искать события регистрации в формате JSON. Однако установка и использование этих инструментов выходит за рамки данной статьи.

В моем следующем блоге я расскажу о реализации структурированного ведения журнала в Groovy.

.

No related posts.