Методика сравнения событий из журнала для поиска изменений в AccentOS

Иногда перед администратором возникает задача выяснения изменений поведения какого-то процесса или пользователя с помощью системных журналов. Для поиска и сравнения событий, зарегистрированных в системных журналах, формируемых ОС Linux, утилитами, AccentOS, приложениями, в разрезе типа события, параметра события, источника события рекомендуется использовать комбинацию стандартных утилит командной строки ОС Linux, в частности, grep, awk, sed, sort, uniq, и специализированных инструментов Opesearch или Graana для анализа записей журналов.

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

1. Подход с использованием командной строки Этот подход использует конвейеры команд (pipes) для фильтрации и сравнения данных непосредственно в терминале. Фильтрация по источнику и типу: На первом этапе необходимо извлечь соответствующие записи из файла журнала (например, /var/log/syslog или /var/log/messages) за т париды времени, которы необходимо провести сравнение. Для этого для каждого интервала времени запускается утилита grep для фильтрации по ключевым словам, связанным с источником (например, именем службы, процесса) и типом события. bash grep «имя_источника» /var/log/syslog | grep «ключевое_слово_типа_события» > filtered_logs.txt

Удаление переменных данных: Записи журнала содержат динамические данные, такие как метки времени (timestamp), идентификаторы процессов (PID) или другие переменные значения. Для исключения ненужных сравнений при сравнениb типов событий эти переменные части необходимо удалить или заменить. Для этого нужно использовать утилиты sed или awk . Пример удаления меток времени и PID: Предположим, записи выглядят так: Nov 21 03:33:00 hostname appname[12345]: Сообщение… bash awk „{$1=$2=$3=$4=»«; print $0}“ filtered_logs.txt | sed „s/[[0-9]*]: /: /“ > normalized_logs.txt Используйте код с осторожностью. Эта команда awk удаляет первые 4 поля (дата, время, хост). Затем sed удаляет PID в квадратных скобках и двоеточие. Сравнение и подсчет: На втором этапе, когда данные нормализованы, необходимо использовать утилиты sort и uniq -c для группировки одинаковых строк и подсчета их частоты. bash sort normalized_logs.txt | uniq -c | sort -nr Результат покажет количество вхождений каждого уникального типа события, отсортированных по убыванию частоты. Это позволит быстро увидеть повторяющиеся события и их различия.

2. Подход с использованием специализированных инструментов Для более сложных задач анализа и сравнения удобно использовать специализированные инструменты: journalctl: В системах, использующих утилиты systemd, journalctl являются мощным инструментом для запросов к системному журналу (который хранится в бинарном формате). Он позволяет фильтровать по юнитам (службам), временным рамкам, приоритетам и другим параметрам. Пример фильтрации: journalctl _SYSTEMD_UNIT=sshd.service -p warning Дальнейший анализ можно проводить, экспортировав вывод в текстовый формат и используя методы командной строки, описанные выше.

Opensearch / Grafana Loki:
Это комплексное решение для централизованного сбора, парсинга, анализа и визуализации больших объемов журналов. Оно предоставляет мощные интерфейсы для поиска, фильтрации и сравнения событий, включая обнаружение аномалий и корреляцию событий.
Хранение и поиск данных выполняется с помощью OpenSearch
Cбор и анализ логов выполняется с помощью Grafana Loki с агентами (например, Promtail). В Grafana Loki можно использовать язык запросов LogQL для фильтрации логов по источнику, типу и времени, а в OpenSearch — его собственный язык запросов для аналогичных задач.

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

Сравнение в OpenSearch Использование: OpenSearch и его визуализационное расширение OpenSearch Dashboards — мощное решение для индексации, поиска и анализа больших объемов логов. Механизм работы: Для сравнения логов от одного источника в OpenSearch необходимо создать запрос, который фильтрует записи по конкретным полям, таким как hostname, source или service. Пример запроса: В OpenSearch Dashboards можно использовать фильтры на панели Discover или построить запрос с помощью специального языка запросов для поиска совпадений и различий. Сравнение в Grafana Loki Использование: Loki, в сочетании с Grafana, является более легковесным решением для сбора и анализа логов, оптимизированным для работы в контейнеризированных средах. Механизм работы: Агент (Promtail): Агент устанавливается на каждый узел, откуда требуется собирать логи (например, с помощью Docker, Kubernetes). Он отправляет журналы в Loki. Язык запросов (LogQL): В Grafana можно использовать LogQL для фильтрации журналов. Пример запроса: logql {job=»syslog», hostname=»my-server»} | line_format «{{.line}}» | json Этот запрос извлекает логи для job=»syslog» с hostname=»my-server». Ключевые различия OpenSearch и Loki Простота: Loki проще и легче в настройке, особенно для контейнерных сред. Мощность: OpenSearch предлагает более мощные возможности поиска и анализа, но требует больше ресурсов. Экосистема: Grafana Loki лучше интегрируется с другими продуктами экосистемы Grafana (например, Prometheus, Grafana), в то время как OpenSearch имеет свою собственную экосистему.