Новости
04.03.2025
Книга: «Linux для разработчиков»
Многие разработчики программного обеспечения недостаточно хорошо разбираются в системах семейства Unix, хотя они повсеместно встречаются в мире разработки. Некоторые программисты даже не подозревают, что в их должностные обязанности входит работа с Unix или подобными системами на своих компьютерах (macOS), в среде разработки (контейнеры Docker), в системах сборки и автоматизации (процессы непрерывной интеграции и GitHub), в среде развертывания (серверы и контейнеры Linux) и в других обстоятельствах.
Книга «Linux для разработчиков» поможет вам вывести свои навыки на новый уровень. В ней вы найдете теорию, практические примеры и проекты, которые сделают вас более уверенным и эффективным разработчиком.
Если вы уверенно владеете командной строкой Linux, то сможете добиваться большего, чем обычно ожидают от разработчика. Например, вы сумеете:
- экономить время благодаря тому, что вы знаете, когда лучше использовать встроенные средства Linux, вместо того чтобы писать тысячи строк собственных сценариев или вспомогательных программ;
- отлаживать сложные отказы в среде эксплуатации, для чего часто требуется задействовать серверы на основе Linux и обращаться к приложениям через их интерфейсы;
- быть наставником для джуниор-разработчиков;
- яснее понимать, как программное обеспечение, которое вы разрабатываете, вписывается в бОльшую экосистему и технологический стек.
Для кого эта книга?
Книга предназначена для разработчиков, которые:
- Плохо знакомы с Linux и командной строкой.
- Хотят освежить свои навыки после долгого перерыва.
- Чувствуют себя неуверенно, работая с Linux на продакшен-серверах.
- Стремятся подтянуть знания, чтобы продвинуться по карьерной лестнице.
- Просто любознательны и хотят работать эффективнее, используя возможности командной строки.
Чего в книге нет?
Авторы книги сосредоточились на том, что действительно важно для разработчиков. Они исключили всё, что не относится к профессиональной деятельности или фундаментальным понятиям Linux.
«Linux для разработчиков» — это не исчерпывающий курс по Linux. Она не предназначена для системных инженеров или разработчиков ядра Linux. Это компактное и практичное руководство, которое можно освоить за несколько дней, например, во время спокойного рабочего спринта.
«Linux для разработчиков» — это не исчерпывающий курс по Linux. Она не предназначена для системных инженеров или разработчиков ядра Linux. Это компактное и практичное руководство, которое можно освоить за несколько дней, например, во время спокойного рабочего спринта.
Как извлечь максимальную пользу из книги?
Для работы с примерами из книги вам понадобится командная оболочка Linux. Её можно получить разными способами:
Чтобы начать, вам понадобятся только базовые навыки:
- Открыть командную оболочку в Ubuntu, если установить эту систему в виртуальной машине или запустить как контейнер Docker.
- Использовать подсистему WSL в Windows.
- Работать в macOS, которая сама относится к семейству Unix (большинство команд будут работать «из коробки»).
Чтобы начать, вам понадобятся только базовые навыки:
- Работа с файлами и каталогами.
- Установка программ.
- Использование интегрированной среды разработки (IDE).
Почему стоит прочитать?
Книга «Linux для разработчиков» — это инструмент, который поможет вам стать более уверенным и эффективным разработчиком, способным решать сложные задачи и лучше понимать, как ваше ПО взаимодействует с окружающей экосистемой.
Если вы хотите прокачать свои навыки и выйти на новый уровень, эта книга — отличный старт. Прочитайте главу «Журналы приложений» в этой статье. Она посвящена протоколированию в Unix и Linux. Авторы покажут, как (и где) регистрируются журнальные сообщения в большинстве современных систем Linux с помощью systemd, а также как работают более традиционные подходы (в реальной практике вы столкнетесь и с тем и с другим).
Добро пожаловать в мир журналов Linux! Разработчикам ПО крайне важно разбираться в том, как устроены журналы и протоколирование в Linux, и владеть соответствующими инструментами (в частности, systemd и journald). Предлагаем вашему вниманию обзор знаний и навыков, которые пригодятся вам в профессиональной деятельности.
Журнал — это протокол событий, которые происходят в приложении или операционной системе. Журналы устроены довольно гибко, и почти каждое приложение ведет их в своем собственном формате, но в современных системах принят более-менее единообразный подход к тому, как их обрабатывать, как хранить и как извлекать из них данные. Вам как разработчику очень важно ориентироваться в журналах, доступных в Linux, потому что они помогают понять, почему операционная система и приложения, которые в ней функционируют, ведут себя тем или иным образом. Это позволит исправлять ошибки, оценивать производительность приложений и отлаживать их. Журналы — это первая линия обороны в области устранения неполадок, так что будьте готовы досконально в них разобраться.
Эта глава посвящена основам журналов и протоколирования в Unix и Linux, и в ней рассказывается, как разработчики ПО чаще всего обращаются с журналами. Вот о чем пойдет речь:
Кроме того, мы дадим несколько советов о том, как извлечь из структурированных журналов максимальную пользу и как избежать распространенных опасностей, которые подстерегают разработчиков.
Как вы уже наверняка знаете, журналы — это просто собрания сообщений о событиях, которые происходят в приложении или операционной системе. Как и для большинства понятий Linux, в этой области есть грубое практическое правило: даже если вы пишете сценарий из двух строк, выводящий дату и время в текстовый файл, это можно считать журналом. Ряд журналов — это просто строки в формате обычного текста, которые записываются в файлы в стандартных расположениях, а другие представляют собой хорошо структурированные двоичные данные, которыми управляет специальная служба вроде
Вы как разработчик наверняка знакомы с уровнями протоколирования. Это метки, обозначающие, насколько неотложно то или иное событие, которое произошло в вашем программном обеспечении. В своей профессиональной деятельности вы часто натыкаетесь на сообщения с заголовками вроде «Ошибка», «Информация» или «Диагностическое сообщение». Чуть позже мы поговорим об этих стандартных уровнях протоколирования, а сейчас отметим, что вам следует знать о трех основных источниках журнальных сообщений в современной полнофункциональной среде Linux: это системные, служебные и прикладные журналы (журналы приложений, которые не относятся к службам). По источнику можно судить о контексте, который важен, чтобы правильно понять то или иное сообщение.
Системные журналы порождаются самой операционной системой (ядром). В них заносятся сообщения об ошибках, о событиях оборудования, потреблении и ограничениях ресурсов, конфигурации и безопасности, а также о существенных изменениях в состоянии системы.
Служебные журналы формируются службами, которые выполняются в системе. В частности, в Linux сообщения для этих журналов поступают от служб, которыми управляет подсистема инициализации systemd; она протоколирует события с помощью службы journald. Из служебных журналов можно узнать о работоспособности и состоянии различных служб.
В системах, с которыми вам предстоит иметь дело, системными и служебными журналами чаще всего управляет
Приложения, которыми не управляет systemd, — это аутсайдеры, чьи события обычно не протоколируются с помощью journald. Как правило, в их документации написано, где искать их журналы, хотя порядочные приложения обычно хранят журналы в каталоге вроде
По мере того как мы будем углубляться в эту главу, вам станет понятно, почему важно разбираться в командах
К этому моменту вы уже убедились, что системы семейства Unix отличаются невероятной гибкостью. Если вам не нравится, как что-нибудь устроено по умолчанию, вы можете пойти своим путем и перенастроить что угодно и как угодно.
Но эта гибкость оборачивается серьезными затруднениями для тех, кто изучает основы Unix и Linux. Дело в том, что многие параметры — от конфигурации программ до свойств пользователя по умолчанию — можно настраивать в нескольких разных местах, и в новой среде часто нет другого способа узнать, какие соглашения здесь приняты, кроме как спросить коллег (а иногда выяснить методом проб и ошибок).
Это более чем отчетливо проявляется в области протоколирования, которую особенно затронули недавние изменения в том, как бизнес строит свою IT-инфраструктуру. Несколько предыдущих десятилетий компании напрямую покупали, конфигурировали и долговременно поддерживали физические серверы, на которые устанавливалась отдельная операционная система. По мере того как рабочая нагрузка переместилась в облако и обычным делом стало множество операционных систем на одном компьютере (благодаря виртуальным машинам) и даже множество сред в одной операционной системе (благодаря контейнерам), традиционные подходы к протоколированию тоже претерпели изменения.
Какой главный вывод можно из этого сделать? Когда вам нужно выяснить, как работать с журналами на новом месте или в новой команде, стоит спрашивать не о том, как устроено протоколирование в Linux в целом, а о том, как оно организовано именно здесь. Все во многом зависит от того, какие решения принимали создатели программ, которые вы используете в работе. Не забывайте об этом, пока будете изучать эту главу.
Чаще всего службы либо регистрируют свои события с помощью специальных библиотек, либо просто выводят сообщения в stdout. Впрочем, в системах семейства Unix также предусмотрена команда, которая отправляет сообщения syslog-серверу. (Далее в этой главе мы подробно поговорим о том, что это такое.) Поскольку в любой системе и
Эта команда зарегистрирует сообщение
Если используется подсистема инициализации
Чтобы извлекать данные из журналов
Основы работы с
Прежде всего нужно находить и просматривать текущие журналы. С помощью
Например, чтобы просмотреть последние 100 сообщений в
Вы наверняка заметили, что это похоже на работу команды
Возможно, вам также понадобится просматривать поступающие журнальные сообщения в режиме реального времени. Например, если отслеживать, какие сообщения ваше приложение порождает во время запуска, это часто помогает выяснить, в какой конкретно момент что-то пошло не так:
Длинная форма флага
Даже если вы сузили выборку из журналов до отдельного модуля, который вас интересует, в ней все равно может оказаться слишком много сообщений. Здесь может помочь фильтр по времени, особенно если вы пытаетесь найти связь между известной внешней проблемой (аварией, ошибкой сети и т. д.) и журналами приложений непосредственно до или непосредственно после сбоя. Здесь вам пригодятся параметры
Некоторые моменты времени можно указывать в сокращенной записи: например,
Параметры
Журналы можно фильтровать и по таким дополнительным параметрам, как идентификаторы пользователей и групп.
Если вы ищете именно ошибку, то можете настроить journalctl так, чтобы отображались только ошибки:
Можно указывать и другие уровни протоколирования; все они перечислены на странице wiki.archlinux.org/title/Systemd/Journal#Priority_level.
Иногда ситуация выходит из-под контроля, отказывают критически важные компоненты, и из-за этого система перезагружается. В таких случаях часто требуется просматривать журналы от предыдущих загрузок. Параметр
Затем с помощью флага
Флаг
Во введении мы упомянули, что журнальные сообщения уровня системы порождает операционная система (ядро в терминологии Linux). Чтобы просматривать только такие сообщения, используйте флаг
Стандартный подход к журналам в контейнерах Docker состоит в том, чтобы просто предполагать, что нас интересует вывод главного процесса контейнера и что он выводит журнальные сообщения в стандартный поток вывода (
Протокол syslog может показаться немного архаичным по сравнению c
В системах семейства Unix протоколирование syslog часто сводится к тому, что сообщения записываются в файл в каталоге
Служба syslog принимает все сообщения, которые ей направлены, и записывает их в тот или иной файл в зависимости от различных параметров, — например, от категории сообщения, которые будут перечислены ниже. Почти во всех системах это файл
Syslog — это стандартный протокол для ведения журналов. Хотя на момент написания этой книги соответствующая служба
Как уже упоминалось, syslog — это протокол. Хотя чаще всего его применяют приложения (например, базы данных, которые ведут локальные журналы), в средах эксплуатации обычно тоже бывает центральный сервер журналов, куда направляются сообщения. Многие программные продукты, например PostgreSQL или nginx, умеют передавать сообщения по протоколу syslog, а различные механизмы журналов — например, Logstash, Loki, syslogd и syslog-ng — умеют принимать эти сообщения. Обычно для этого используется порт 514 (UDP) или 6514 (TCP).
Поскольку syslog — это очень старый протокол из 1980-х, некоторые его особенности могут выглядеть архаичными. Например, он использует стандартный набор категорий (субъектов), которые обозначают, откуда поступило журнальное сообщение. У каждой категории есть свой код:
Во многих системах в каталоге
Обратите внимание, что нет единого стандарта того, какие именно события нужно протоколировать в каждой категории. Скорее всего, вы встретитесь с ситуациями, когда разные операционные системы или программы похожего назначения расходятся во мнениях о том, в какую категорию заносить журнальные сообщения.
Возможно, это понятие вам знакомо лучше. Журнальным сообщениям присваиваются уровни важности по шкале от 0 (самый важный) до 7 (наименее важный):
Как и в случае с категориями, от конкретного программного обеспечения зависит, к какому уровню важности относится то или иное сообщение.
У syslog есть много реализаций, которые обычно позволяют настраивать фильтрацию, а также сохранять и пересылать сообщения в зависимости от категории и уровня важности. Некоторые реализации поставляются со службами, такими как
Разные программные продукты ведут журналы по-разному, и принципы того, какое протоколирование считать «правильным» или «неправильным», во многом зависят от конкретного проекта, а также меняются со временем. Однако в большинстве случаев следует учитывать общие соображения, которые мы сейчас рассмотрим.
Если ваше программное обеспечение порождает структурированные журналы, постарайтесь не только добиться того, чтобы для стандартных понятий, например таких, как запросы или идентификаторы пользователей, использовались привычные ключевые слова, но и избежать коллизий, когда одними и теми же ключевыми словами обозначаются похожие, но все-таки не одинаковые понятия. В зависимости от того, какую базу данных вы используете, вы также можете наткнуться на проблемы с типами, например, в ситуации, когда идентификатор user может быть ключом для числового поля, строкового поля или специально созданной структуры вроде объекта JSON.
Чтобы избежать коллизий, иногда удается создавать отдельное пространство имен для каждой службы, а также поддерживать список «глобальных» ключей вместе с их определениями.
Когда вы разрабатываете ПО, имеет смысл составить внутренний документ о том, по каким критериям присваивать сообщению тот или иной уровень важности. Это поможет избегать ситуаций, когда неудачные попытки входа на общедоступный сайт или ошибки 404, которые возникают из-за того, что поисковые роботы запрашивают несуществующие ресурсы, вызывают сигнал тревоги и будят ваших коллег посреди ночи. Но даже если таких неприятностей не происходит, то вам будет гораздо проще отлаживать код и выявлять проблемы, если вы будете присваивать уровни важности по единой логически выстроенной схеме.
Имеет смысл четко различать такие варианты:
По мере того как ПО разрастается и к нему добавляются новые службы, журналы склонны усложняться, так что вы не ошибетесь, если с самого начала выработаете четкие правила о том, какие события и когда протоколировать.
В корпоративной среде принято работать с журналами централизованно, что помогает разбираться в проблемных ситуациях. Кроме того, при этом не требуется по отдельности изучать каждый журнал на каждом физическом компьютере, в каждой виртуальной машине и в каждом контейнере. Централизованные службы управления журналами обычно позволяют просто и быстро анализировать огромные объемы журналов, особенно если они ведутся структурированно, а отдельные службы согласованы с единой схемой журналов.
Эти службы управления журналами могут быть либо самостоятельными продуктами, такими как Loki, стек ELK (Elastic Search, Logstash и Kibana) и Graylog, а могут быть управляемыми службами, например, если это версия одного из упомянутых продуктов, которая развернута на хостинге, или если это специализированное облачное решение, например Google Cloud Operations (ранее известное как Stackdriver), AWS CloudWatch или Azure Monitor. Эти системы во многом похожи: они умеют извлекать журналы из файлов либо извлекать их с помощью того или иного API, фильтровать и реорганизовывать их и в итоге сохранять в конечное хранилище, где к ним можно обращаться с запросами.
В микросервисной архитектуре вместе с сообщениями обычно передается контекст, например идентификатор запроса, чтобы можно было легко проследить путь запроса от клиента через различные службы, а это крайне важно для отладки в архитектурах с большим количеством служб.
Как уже упоминалось, у большинства этих систем есть механизмы для того, чтобы передавать журналы центральному серверу или кластеру журналов. К таким продуктам относятся, например, Logstash (от которого происходит буква L в названии стека ELK) и Promtail (который используется вместе с Loki); обычно эти системы умеют получать журналы множеством разных способов. Например, их можно настроить так, чтобы они функционировали как сервер HTTP или syslog-сервер, подключались к
Как видите, хотя с протоколированием связано множество технологий и продуктов, все они попадают в одну из категорий, описанных выше, так что если вы налаживаете централизованные журналы в своей среде, эта схема поможет вам понять, как все эти компоненты связаны друг с другом.
Журналы приложений
Добро пожаловать в мир журналов Linux! Разработчикам ПО крайне важно разбираться в том, как устроены журналы и протоколирование в Linux, и владеть соответствующими инструментами (в частности, systemd и journald). Предлагаем вашему вниманию обзор знаний и навыков, которые пригодятся вам в профессиональной деятельности.
Журнал — это протокол событий, которые происходят в приложении или операционной системе. Журналы устроены довольно гибко, и почти каждое приложение ведет их в своем собственном формате, но в современных системах принят более-менее единообразный подход к тому, как их обрабатывать, как хранить и как извлекать из них данные. Вам как разработчику очень важно ориентироваться в журналах, доступных в Linux, потому что они помогают понять, почему операционная система и приложения, которые в ней функционируют, ведут себя тем или иным образом. Это позволит исправлять ошибки, оценивать производительность приложений и отлаживать их. Журналы — это первая линия обороны в области устранения неполадок, так что будьте готовы досконально в них разобраться.
Эта глава посвящена основам журналов и протоколирования в Unix и Linux, и в ней рассказывается, как разработчики ПО чаще всего обращаются с журналами. Вот о чем пойдет речь:
- Как система и приложения под ее управлением формируют журналы.
- Где хранятся журналы в большинстве современных систем Linux.
- Как было устроено протоколирование в прежних системах (это пригодится в работе со многими действующими системами, которые могут вам встретиться).
- Как искать и просматривать журналы, когда вы устраняете неполадки в приложениях.
- Как налажена централизация журналов в корпоративной среде и в приложениях, которые развертываются в облачных средах.
Кроме того, мы дадим несколько советов о том, как извлечь из структурированных журналов максимальную пользу и как избежать распространенных опасностей, которые подстерегают разработчиков.
Введение в протоколирование и журналы в Linux
Как вы уже наверняка знаете, журналы — это просто собрания сообщений о событиях, которые происходят в приложении или операционной системе. Как и для большинства понятий Linux, в этой области есть грубое практическое правило: даже если вы пишете сценарий из двух строк, выводящий дату и время в текстовый файл, это можно считать журналом. Ряд журналов — это просто строки в формате обычного текста, которые записываются в файлы в стандартных расположениях, а другие представляют собой хорошо структурированные двоичные данные, которыми управляет специальная служба вроде
systemd.Вы как разработчик наверняка знакомы с уровнями протоколирования. Это метки, обозначающие, насколько неотложно то или иное событие, которое произошло в вашем программном обеспечении. В своей профессиональной деятельности вы часто натыкаетесь на сообщения с заголовками вроде «Ошибка», «Информация» или «Диагностическое сообщение». Чуть позже мы поговорим об этих стандартных уровнях протоколирования, а сейчас отметим, что вам следует знать о трех основных источниках журнальных сообщений в современной полнофункциональной среде Linux: это системные, служебные и прикладные журналы (журналы приложений, которые не относятся к службам). По источнику можно судить о контексте, который важен, чтобы правильно понять то или иное сообщение.
Системные журналы порождаются самой операционной системой (ядром). В них заносятся сообщения об ошибках, о событиях оборудования, потреблении и ограничениях ресурсов, конфигурации и безопасности, а также о существенных изменениях в состоянии системы.
Служебные журналы формируются службами, которые выполняются в системе. В частности, в Linux сообщения для этих журналов поступают от служб, которыми управляет подсистема инициализации systemd; она протоколирует события с помощью службы journald. Из служебных журналов можно узнать о работоспособности и состоянии различных служб.
В системах, с которыми вам предстоит иметь дело, системными и служебными журналами чаще всего управляет
journald. Далее в этой главе мы подробнее поговорим о systemd и journald (а также journalctl).Приложения, которыми не управляет systemd, — это аутсайдеры, чьи события обычно не протоколируются с помощью journald. Как правило, в их документации написано, где искать их журналы, хотя порядочные приложения обычно хранят журналы в каталоге вроде
/var/log/название_приложения.По мере того как мы будем углубляться в эту главу, вам станет понятно, почему важно разбираться в командах
journald и journalctl. Однако прежде всего стоит упомянуть о некоторых особенностях журналов в Linux.Журналы в Linux: не все так просто
К этому моменту вы уже убедились, что системы семейства Unix отличаются невероятной гибкостью. Если вам не нравится, как что-нибудь устроено по умолчанию, вы можете пойти своим путем и перенастроить что угодно и как угодно.
Но эта гибкость оборачивается серьезными затруднениями для тех, кто изучает основы Unix и Linux. Дело в том, что многие параметры — от конфигурации программ до свойств пользователя по умолчанию — можно настраивать в нескольких разных местах, и в новой среде часто нет другого способа узнать, какие соглашения здесь приняты, кроме как спросить коллег (а иногда выяснить методом проб и ошибок).
Это более чем отчетливо проявляется в области протоколирования, которую особенно затронули недавние изменения в том, как бизнес строит свою IT-инфраструктуру. Несколько предыдущих десятилетий компании напрямую покупали, конфигурировали и долговременно поддерживали физические серверы, на которые устанавливалась отдельная операционная система. По мере того как рабочая нагрузка переместилась в облако и обычным делом стало множество операционных систем на одном компьютере (благодаря виртуальным машинам) и даже множество сред в одной операционной системе (благодаря контейнерам), традиционные подходы к протоколированию тоже претерпели изменения.
Какой главный вывод можно из этого сделать? Когда вам нужно выяснить, как работать с журналами на новом месте или в новой команде, стоит спрашивать не о том, как устроено протоколирование в Linux в целом, а о том, как оно организовано именно здесь. Все во многом зависит от того, какие решения принимали создатели программ, которые вы используете в работе. Не забывайте об этом, пока будете изучать эту главу.
Как отправлять сообщения в журнал
Чаще всего службы либо регистрируют свои события с помощью специальных библиотек, либо просто выводят сообщения в stdout. Впрочем, в системах семейства Unix также предусмотрена команда, которая отправляет сообщения syslog-серверу. (Далее в этой главе мы подробно поговорим о том, что это такое.) Поскольку в любой системе и
syslogd, и systemd обеспечивают syslog-сервер, сообщения в журнал можно отправлять с помощью единой команды logger:logger Привет!Эта команда зарегистрирует сообщение
Привет!. У команды logger много параметров, и она бывает чрезвычайно полезна, когда приходится отлаживать код, вносить сообщения в журнал из сценария командной оболочки или объяснять, как устроены журналы.Журнал подсистемы инициализации systemd
Если используется подсистема инициализации
systemd, то за ведение журнала отвечает journald. Это первое место, где стоит искать журналы, если вы устраняете неполадки на компьютере под управлением Linux, на котором работает systemd. По умолчанию служба journald регистрирует весь вывод из процессов, находящихся под ее наблюдением. Все, что направляется в stderr, считается сообщением об ошибке. Так что если программное обеспечение не настроено так, чтобы выводить журнальные сообщения не в stderr/stdout (в зависимости от ПО это может быть либо задано с помощью конфигурации, либо жестко закодировано), то события регистрируются в журнале подсистемы systemd.Чтобы извлекать данные из журналов
journald, используйте команду journalctl. Она позволяет ограничивать запросы определенными службами, периодами времени и промежутками между перезагрузками системы, а также поддерживает примерно те же аргументы, что и команда tail. Давайте перейдем от теории к практике и посмотрим, как использовать journalctl.Некоторые команды journalctl
Основы работы с
journalctl очень просты. Начнем с ответа на такой вопрос: когда вы устраняете неполадки в приложении, какие операции вам нужно совершать с его журналами?Прежде всего нужно находить и просматривать текущие журналы. С помощью
journalctl это можно сделать, но вы быстро убедитесь, что на самом деле вам нужны не все журнальные записи, а только несколько самых свежих. Их можно выбрать с помощью флага -n.Например, чтобы просмотреть последние 100 сообщений в
journald, запустите такую команду:journalctl –n 100Вы наверняка заметили, что это похоже на работу команды
tail, с которой вы уже встречались в этой книге. Если вы запускали предыдущую команду, то среди выведенных записей будет ваше сообщение Привет!.Как выводить активные записи журнала для модуля в реальном времени
Возможно, вам также понадобится просматривать поступающие журнальные сообщения в режиме реального времени. Например, если отслеживать, какие сообщения ваше приложение порождает во время запуска, это часто помогает выяснить, в какой конкретно момент что-то пошло не так:
journalctl -fu имя_модуляДлинная форма флага
-f — --follow, а флага -u — --unit; этот флаг обозначает модуль (службу), по которому вы хотите отфильтровать журналы.Как фильтровать журналы по времени
Даже если вы сузили выборку из журналов до отдельного модуля, который вас интересует, в ней все равно может оказаться слишком много сообщений. Здесь может помочь фильтр по времени, особенно если вы пытаетесь найти связь между известной внешней проблемой (аварией, ошибкой сети и т. д.) и журналами приложений непосредственно до или непосредственно после сбоя. Здесь вам пригодятся параметры
--since и --until:journalctl --since "2021-01-01 00:00:00"Некоторые моменты времени можно указывать в сокращенной записи: например,
today:journalctl --until todayПараметры
--since и --until можно совмещать, чтобы узко фильтровать результаты, например:journalctl --since "2021-01-01 00:00:00" --until "1 hour ago"ПРИМЕЧАНИЕ
Когда вы просматриваете временнЫе метки в журналах или фильтруете записи по времени, почти всегда имеет смысл запускать командуjournalctlс параметром--utc, благодаря которому дата и время выводятся в UTC. Если вы помогаете специалистам технической поддержки устранять последствия аварии, вы почти всегда оперируете временем по UTC, чтобы не возникало путаницы с часовыми поясами.
Журналы можно фильтровать и по таким дополнительным параметрам, как идентификаторы пользователей и групп.
Как фильтровать журналы по определенному уровню протоколирования
Если вы ищете именно ошибку, то можете настроить journalctl так, чтобы отображались только ошибки:
journalctl -p4 errМожно указывать и другие уровни протоколирования; все они перечислены на странице wiki.archlinux.org/title/Systemd/Journal#Priority_level.
Как анализировать журналы от предыдущих загрузок
Иногда ситуация выходит из-под контроля, отказывают критически важные компоненты, и из-за этого система перезагружается. В таких случаях часто требуется просматривать журналы от предыдущих загрузок. Параметр
--list-boots позволяет вывести список всех доступных загрузок:journalctl --list-bootsЗатем с помощью флага
-b можно выбрать из списка конкретную загрузку. Допустим, нас интересует загрузка с меткой 2:journalctl -b –2Флаг
-b без метки означает текущую загрузку системы.Сообщения ядра
Во введении мы упомянули, что журнальные сообщения уровня системы порождает операционная система (ядро в терминологии Linux). Чтобы просматривать только такие сообщения, используйте флаг
-k (по историческим причинам его длинная форма — --dmesg).Журналы в контейнерах Docker
Стандартный подход к журналам в контейнерах Docker состоит в том, чтобы просто предполагать, что нас интересует вывод главного процесса контейнера и что он выводит журнальные сообщения в стандартный поток вывода (
stdout). Системы координации контейнеров (Kubernetes, Nomad и др.), а также различные облачные службы, которые управляют контейнерами, по умолчанию воспринимают stdout как поток соответствующих журнальных сообщений и в зависимости от конфигурации перенаправляют его в тот или иной приемник. Мы поговорим об этом подробнее чуть дальше в разделе «Централизованные журналы».Введение в Syslog
Протокол syslog может показаться немного архаичным по сравнению c
systemd/journald, о которых шла речь раньше. Syslog отличается богатой историей: хотя он существует с 1980-х годов, он остается практичным, гибким и широко востребованным средством ведения журналов. Что еще более важно, вы почти наверняка встретитесь с syslog в реальных средах эксплуатации, так что стоит знать его основы, чтобы не растеряться, если придется устранять аварию, когда время играет против вас.В системах семейства Unix протоколирование syslog часто сводится к тому, что сообщения записываются в файл в каталоге
/var/log, причем большинство из них — в /var/log/messages. Однако имейте в виду: не все, что находится в /var/log, поступает туда через syslog. Многие программные компоненты реализуют свои собственные способы протоколирования, вообще не задействуя службу syslog.Служба syslog принимает все сообщения, которые ей направлены, и записывает их в тот или иной файл в зависимости от различных параметров, — например, от категории сообщения, которые будут перечислены ниже. Почти во всех системах это файл
/var/log/messages, и если вы практиковались по ходу этой главы, то именно в нем вы увидите сообщение Привет!, которое создавали выше.Syslog — это стандартный протокол для ведения журналов. Хотя на момент написания этой книги соответствующая служба
syslogd в основном оперирует строковыми сообщениями, текущий стандарт RFC 5424 также предусматривает структурированное протоколирование. Впрочем, оно не так широко поддерживается, поэтому мы ограничимся тем, что вкратце обсудим основы этого протокола в контексте строкоориентированных журналов. Если вы вовсе не работаете с syslog, можете спокойно пропустить этот раздел.Как уже упоминалось, syslog — это протокол. Хотя чаще всего его применяют приложения (например, базы данных, которые ведут локальные журналы), в средах эксплуатации обычно тоже бывает центральный сервер журналов, куда направляются сообщения. Многие программные продукты, например PostgreSQL или nginx, умеют передавать сообщения по протоколу syslog, а различные механизмы журналов — например, Logstash, Loki, syslogd и syslog-ng — умеют принимать эти сообщения. Обычно для этого используется порт 514 (UDP) или 6514 (TCP).
Категории
Поскольку syslog — это очень старый протокол из 1980-х, некоторые его особенности могут выглядеть архаичными. Например, он использует стандартный набор категорий (субъектов), которые обозначают, откуда поступило журнальное сообщение. У каждой категории есть свой код:
Во многих системах в каталоге
/var/log бывают файлы, имена которых соответствуют этим категориям. Например, если вам понадобится устранять неполадки в заданиях cron в системе, где не используется journald, то нужные журналы вы, скорее всего, найдете в файлах вроде /var/log/cron, /var/cron/log, /var/log/messages и т. п.Обратите внимание, что нет единого стандарта того, какие именно события нужно протоколировать в каждой категории. Скорее всего, вы встретитесь с ситуациями, когда разные операционные системы или программы похожего назначения расходятся во мнениях о том, в какую категорию заносить журнальные сообщения.
Уровни важности сообщений
Возможно, это понятие вам знакомо лучше. Журнальным сообщениям присваиваются уровни важности по шкале от 0 (самый важный) до 7 (наименее важный):
Как и в случае с категориями, от конкретного программного обеспечения зависит, к какому уровню важности относится то или иное сообщение.
Конфигурация и реализации
У syslog есть много реализаций, которые обычно позволяют настраивать фильтрацию, а также сохранять и пересылать сообщения в зависимости от категории и уровня важности. Некоторые реализации поставляются со службами, такими как
syslogd, rsyslog или syslog-ng, которые можно настраивать с помощью конфигурационных файлов в каталогах /etc/syslog.conf или /etc/syslog-ng. В Loki, Logstash и других системах распределенного управления журналами протоколирование конфигурируется по-своему — обычно с помощью трехуровневой структуры, где на одном уровне поступают входные данные, на другом они фильтруются и преобразовываются, а на третьем программа сохраняет или пересылает выходные данные.Как вести журналы
Разные программные продукты ведут журналы по-разному, и принципы того, какое протоколирование считать «правильным» или «неправильным», во многом зависят от конкретного проекта, а также меняются со временем. Однако в большинстве случаев следует учитывать общие соображения, которые мы сейчас рассмотрим.
Тщательно выбирайте ключевые слова при структурированном протоколировании
Если ваше программное обеспечение порождает структурированные журналы, постарайтесь не только добиться того, чтобы для стандартных понятий, например таких, как запросы или идентификаторы пользователей, использовались привычные ключевые слова, но и избежать коллизий, когда одними и теми же ключевыми словами обозначаются похожие, но все-таки не одинаковые понятия. В зависимости от того, какую базу данных вы используете, вы также можете наткнуться на проблемы с типами, например, в ситуации, когда идентификатор user может быть ключом для числового поля, строкового поля или специально созданной структуры вроде объекта JSON.
Чтобы избежать коллизий, иногда удается создавать отдельное пространство имен для каждой службы, а также поддерживать список «глобальных» ключей вместе с их определениями.
Уровень важности
Когда вы разрабатываете ПО, имеет смысл составить внутренний документ о том, по каким критериям присваивать сообщению тот или иной уровень важности. Это поможет избегать ситуаций, когда неудачные попытки входа на общедоступный сайт или ошибки 404, которые возникают из-за того, что поисковые роботы запрашивают несуществующие ресурсы, вызывают сигнал тревоги и будят ваших коллег посреди ночи. Но даже если таких неприятностей не происходит, то вам будет гораздо проще отлаживать код и выявлять проблемы, если вы будете присваивать уровни важности по единой логически выстроенной схеме.
Имеет смысл четко различать такие варианты:
- ситуации, которые могут указывать на проблему;
- ситуации, которые не должны происходить, но могут произойти;
- ситуации, которые заведомо указывают на дефект или более серьезную проблему.
По мере того как ПО разрастается и к нему добавляются новые службы, журналы склонны усложняться, так что вы не ошибетесь, если с самого начала выработаете четкие правила о том, какие события и когда протоколировать.
Централизованные журналы
В корпоративной среде принято работать с журналами централизованно, что помогает разбираться в проблемных ситуациях. Кроме того, при этом не требуется по отдельности изучать каждый журнал на каждом физическом компьютере, в каждой виртуальной машине и в каждом контейнере. Централизованные службы управления журналами обычно позволяют просто и быстро анализировать огромные объемы журналов, особенно если они ведутся структурированно, а отдельные службы согласованы с единой схемой журналов.
Эти службы управления журналами могут быть либо самостоятельными продуктами, такими как Loki, стек ELK (Elastic Search, Logstash и Kibana) и Graylog, а могут быть управляемыми службами, например, если это версия одного из упомянутых продуктов, которая развернута на хостинге, или если это специализированное облачное решение, например Google Cloud Operations (ранее известное как Stackdriver), AWS CloudWatch или Azure Monitor. Эти системы во многом похожи: они умеют извлекать журналы из файлов либо извлекать их с помощью того или иного API, фильтровать и реорганизовывать их и в итоге сохранять в конечное хранилище, где к ним можно обращаться с запросами.
В микросервисной архитектуре вместе с сообщениями обычно передается контекст, например идентификатор запроса, чтобы можно было легко проследить путь запроса от клиента через различные службы, а это крайне важно для отладки в архитектурах с большим количеством служб.
Как уже упоминалось, у большинства этих систем есть механизмы для того, чтобы передавать журналы центральному серверу или кластеру журналов. К таким продуктам относятся, например, Logstash (от которого происходит буква L в названии стека ELK) и Promtail (который используется вместе с Loki); обычно эти системы умеют получать журналы множеством разных способов. Например, их можно настроить так, чтобы они функционировали как сервер HTTP или syslog-сервер, подключались к
journald, извлекали данные из любых других служб доставки журналов, обращались к облачным API или просто применяли команду tail к файлам. Они запускаются либо в качестве дополнительных системных служб (как, например, Pod в Kubernetes), либо как часть конфигурации Nomad. Поскольку предназначение этих инструментов — централизовать журналы независимо от того, какое программное обеспечение используется, они обычно умеют принимать самые разные входные данные и чрезвычайно гибко настраиваются: например, с их помощью можно создать иерархию, пересылая данные от одних служб доставки журналов к другим. В системах координации контейнеров, таких как Kubernetes или Nomad, эту структуру часто реализуют с помощью sidecar-контейнера, который выполняется рядом с контейнерами ваших приложений и регистрирует журналы из всех контейнеров в соответствующем поде (размещении, узле) перед тем, как доставлять их по назначению.Как видите, хотя с протоколированием связано множество технологий и продуктов, все они попадают в одну из категорий, описанных выше, так что если вы налаживаете централизованные журналы в своей среде, эта схема поможет вам понять, как все эти компоненты связаны друг с другом.
Об авторах
Дэвид Коэн (David Cohen) в течение последних 15 лет побывал системным администратором Linux, разработчиком программного обеспечения, инженером по инфраструктуре, специалистом по надежности сайтов, экспертом по информационной безопасности, веб-разработчиком, а также опробовал несколько других профессий. В свободное время он ведет на YouTube канал tutoriaLinux, где уже обучил сотни тысяч посетителей основам Linux, программированию и DevOps. С 2019 года Дэвид трудится в компании HashiCorp: сначала он разрабатывал исследовательское ПО, затем эталонные архитектуры, а сейчас занимает должность инженера-программиста.
Кристиан Штурм (Christian Sturm) — консультант по программной и системной архитектуре, более десяти лет проработавший на разных технических должностях. Он создавал приложения для фронтенда и бэкенда в больших и маленьких компаниях, таких как zoomsquare или Plutonium Labs. Кроме того, он активно участвует в различных проектах с открытым исходным кодом и выступает в качестве эксперта в нескольких областях, включая операционные системы, сетевые протоколы, информационную безопасность и системы управления базами данных.
Кристиан Штурм (Christian Sturm) — консультант по программной и системной архитектуре, более десяти лет проработавший на разных технических должностях. Он создавал приложения для фронтенда и бэкенда в больших и маленьких компаниях, таких как zoomsquare или Plutonium Labs. Кроме того, он активно участвует в различных проектах с открытым исходным кодом и выступает в качестве эксперта в нескольких областях, включая операционные системы, сетевые протоколы, информационную безопасность и системы управления базами данных.
О научном редакторе русского издания
Денис Квист — ведущий инженер-эксперт по виртуализации в компании Orion soft с более чем 24-летним опытом работы в IT. Его профессиональный путь начался с должности системного администратора и программиста в Национальном архиве Республики Карелия, где он стоял у истоков цифровизации архивной отрасли.
За свою карьеру Денис занимал ведущие позиции в различных организациях, включая гостиницу ParkInn, Республиканский перинатальный центр, Республиканский медицинский информационно-аналитический центр. Под его руководством более двухcот студентов прошли обучение по основам Linux-систем на платформе GeekBrains. Сегодня он применяет знания как в личных проектах (обслуживает и развивает три FM-радиостанции), так и в профессиональной среде: активно участвует в разработке и поддержке системы виртуализации zVirt.
За свою карьеру Денис занимал ведущие позиции в различных организациях, включая гостиницу ParkInn, Республиканский перинатальный центр, Республиканский медицинский информационно-аналитический центр. Под его руководством более двухcот студентов прошли обучение по основам Linux-систем на платформе GeekBrains. Сегодня он применяет знания как в личных проектах (обслуживает и развивает три FM-радиостанции), так и в профессиональной среде: активно участвует в разработке и поддержке системы виртуализации zVirt.
Чтобы ознакомиться с книгой «Linux для разработчиков», переходите на сайт издательства.
Комментарии: 0
Пока нет комментариев