1. ОПИСАНИЕ ОБЪЕКТА ИССЛЕДОВАНИЯ

1.1. Определение и сущность объекта

Объектом исследования является процесс генерации, передачи, хранения и анализа журналов событий (логов) в распределённом веб-приложении. Лог представляет собой упорядоченную хронологическую запись событий, возникающих в ходе работы программного обеспечения. Каждая запись лога (сообщение) содержит как минимум временную метку, уровень важности (DEBUG, INFO, WARN, ERROR, CRITICAL) и текстовое описание события.

В современной практике разработки и эксплуатации (DevOps) логи выступают основным источником информации для диагностики отказов, анализа производительности и аудита безопасности. Однако с ростом сложности систем – переходом от монолита к микросервисной архитектуре, контейнеризации (Docker, Kubernetes) и облачным развёртываниям – логи перестают быть локальными файлами на одном сервере. Они распределяются по множеству узлов, контейнеров и даже географических зон.

1.2. Состояние объекта и его параметры

Состояние объекта исследования описывается следующими количественными и качественными характеристиками:

• Объём генерируемых логов (в мегабайтах или гигабайтах в сутки). Для среднего корпоративного приложения этот объём может составлять от 1 ГБ до 100 ГБ. В пиковые нагрузки скорость генерации достигает 10 000 – 50 000 сообщений в секунду.
• Скорость появления ошибок – доля сообщений уровня ERROR и CRITICAL относительно общего потока. Обычно не превышает 0,5%, но даже при малой доле абсолютное количество ошибок может быть значительным (например, 500 ошибок в минуту).
• Разнородность форматов – разные модули приложения (сервер авторизации, платёжный шлюз, база данных) могут использовать собственные форматы логов (текстовые строки, JSON, key=value, XML). Это затрудняет автоматическую обработку.
• Избыточность – повторяющиеся сообщения об одной и той же ошибке (например, «Таймаут подключения к БД» возникает каждую секунду). Доля повторов может достигать 70% от всех ERROR-записей.
• Время обнаружения ошибки – интервал от момента возникновения события до момента, когда оно замечено инженером или мониторингом. В отсутствие централизованного сбора это время может составлять десятки минут.
• Время анализа одной ошибки – трудоёмкость в человеко-часах, необходимая для установления первопричины. Включает поиск релевантных записей, фильтрацию шума, сопоставление с другими источниками.

Для наглядности представим таблицу параметров «до внедрения» (базовый уровень):

Параметр	Значение в типовой организации
Средний суточный объём логов	25 ГБ
Скорость генерации (макс.)	12 000 сообщений/с
Доля ERROR	0,25%
Повторяемость ошибок	65%
Время обнаружения ошибки (медиана)	15 минут
Время анализа одной ошибки	30 минут
Потери из-за простоев (в месяц)	120 000 у.е.

1.3. Примеры реальных объектов

В качестве конкретных примеров объектов, аналогичных исследуемому, можно привести:

Логи веб-сервера Nginx – строки вида: 192.168.1.1 - - [06/May/2026:10:00:00 +0000] "GET /api/status HTTP/1.1" 200 1234.

Логи Java-приложения с Log4j – многострочные, с трассировкой стека при возникновении исключений.

Логи контейнеров Docker – потоки stdout/stderr, собираемые драйвером json-file.

Системные логи Linux – сообщения ядра, демонов, служб (syslog).

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

2. ЦЕЛЬ ИССЛЕДОВАНИЯ, ЕЁ ОБОСНОВАНИЕ И ЦЕЛЕВОЙ ПОКАЗАТЕЛЬ

2.1. Формулировка цели

Целью настоящего исследования является разработка модуля централизованного сбора и фильтрации логов приложения, позволяющая сократить среднее время анализа ошибок (Mean Time to Acknowledge, MTTA) с 30 минут до 5 минут.

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

2.2. Обоснование необходимости

Обоснование базируется на трёх факторах:

• Экономический:
  В современной цифровой экономике простой приложения даже на несколько минут может приводить к прямым убыткам. Согласно отраслевым исследованиям, час недоступности для интернет-магазина среднего размера стоит от 5000 до 50 000 долларов. Ускорение анализа ошибок с 30 до 5 минут сокращает время восстановления сервиса (MTTR) на 83% и соответственно снижает финансовые потери.
• Технологический:
  Традиционные методы (grep по файлам, ручной просмотр логов на каждом сервере) перестают работать в микросервисных и контейнерных средах. Разработчик тратит до 70% времени не на исправление ошибки, а на поиск места, где она произошла.
• Человеческий:
  Монотонная работа по фильтрации тысяч строк логов приводит к снижению внимания и ошибочным диагнозам. Автоматизация позволяет сосредоточиться на сути проблемы.

2.3. Целевой показатель

Для доказательства достижения цели выбран измеримый целевой показатель – MTTA (Mean Time To Acknowledge), определяемый как:

Базовое значение MTTA (без модуля) – 30 минут.
Планируемое значение MTTA (с разработанным модулем) – не более 5 минут.

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

2.4. Дополнительные вспомогательные показатели

Помимо основного, выделяются вспомогательные показатели, характеризующие качество решения:

• Степень сжатия / фильтрации – количество сохранённых записей после фильтрации к общему объёму. Целевое значение – не более 30% исходного объёма.
• Точность выделения контекста – доля случаев, когда среди записей, приложенных к ошибке, присутствует хотя бы одно сообщение, непосредственно указывающее на причину. Целевое значение >90%.
• Задержка обработки – время от поступления сообщения в модуль до его индексации в Elasticsearch. Не более 1 секунды для 99-го процентиля.

3. ПРОБЛЕМА (ПРОТИВОРЕЧИЕ)

3.1. Сущность противоречия

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

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

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

Классическое выражение этого противоречия в управлении проектами: «быстро, качественно, дёшево – выберите два». В контексте логирования имеем:

Если хотим...	То жертвуем...
Быстрый анализ	Полнотой (отбрасываем часть логов)
Полную информацию	Скоростью (приходится перебирать тонны данных)
Дешёвое хранение	И полнотой, и скоростью

3.2. Конкуренция показателей

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

Режим работы системы логирования	Полнота (контекст ошибки)	Скорость анализа (MTTA)	Затраты на хранилище	Требуемые вычислительные ресурсы
Логировать всё (уровень DEBUG)	100% (избыточно)	Высокая (>1 часа)	Очень высокие	Низкие (только запись)
Логировать только ERROR	Низкая (нет причин)	Низкая (<5 мин)	Низкие	Низкие
Логировать ERROR + WARN	Средняя	Средняя (20–30 мин)	Средние	Средние
Интеллектуальная фильтрация с контекстом (предлагаемый модуль)	70–90% (целенаправленная)	Низкая (<5 мин)	Средние	Умеренные (требуют фильтрации)

Ключевое противоречие формулируется так:

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

3.3. Примеры проявления проблемы

Пример 1. В приложении происходит ошибка «Connection timeout to database». В логах за последние 2 секунды до ошибки есть запись уровня WARN: «Connection pool size exceeded, waiting for release». Если фильтр удалит все WARN-сообщения, разработчик увидит только ERROR и не поймёт, что причина – переполнение пула соединений.

Пример 2. Ошибка повторяется 1000 раз в минуту (например, периодический сбой внешнего API). Без дедупликации аналитик вынужден просматривать все 1000 одинаковых записей, тратя на это часы.

3.4. Путь преодоления

Для преодоления указанного противоречия необходимо:

Применять дедупликацию – сохранять только уникальные сообщения за заданный интервал времени.

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

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

Именно решению этой проблемы посвящена задача исследования.

5. ПЛАН ИССЛЕДОВАНИЯ

5.1. Этап 1. Анализ литературы и существующих решений

5.1.1. Нормативная база

• ГОСТ Р ИСО/МЭК 25010-2015 «Информационные технологии. Оценка качества программного обеспечения». Раздел «Анализируемость» – способность ПО позволять диагностировать причины отказов. Наш модуль должен повысить анализируемость системы.
• RFC 5424 – стандарт протокола syslog, определяет формат и уровни важности.
• ГОСТ 34.201-89 – виды, комплектность и обозначение документов при создании АС (требования к отчётности).

5.1.2. Научные и технические публикации

• Шкляр М.Ф., Основы научных исследований, 2016 – главы о планировании эксперимента и формулировании гипотез. Применено для построения методики измерения MTTA.
• Вайнштейн М.З., Основы научных исследований, 2011 – классификация методов сбора данных (наблюдение, измерение, сравнение).
• Статья «Log clustering for problem diagnosis» (IEEE TSC, 2022) – методы группировки логов с использованием TF-IDF. Вывод: алгоритмы сложны для real-time, требуется упрощение.
• Сравнение ELK Stack и Loki (Medium, 2025) – ELK даёт полнотекстовый поиск, но медленнее Loki; Loki экономит место, но хуже подходит для анализа ошибок.
• Документация Redis (redis.io) – сценарий «Message deduplication» – готовое решение, адаптировано нами.
• Руководство по Elasticsearch (2024) – как строить индексы для логов с учётом временных шаблонов.

5.1.3. Обзор готовых модулей фильтрации

Система	Фильтрация по уровню	Дедупликация	Контекст ошибки	Цена
Logstash (с плагинами)	Да	Через fingerprint	Нет (только через ручные pipeline)	Беспл.
Fluentd	Да	Через record_transformer	Нет	Беспл.
Splunk	Да	Да (умная)	Да (только в Enterprise)	Очень выс.
Наш модуль (план)	Да	Да (Redis)	Да (буфер Kafka)	Беспл.

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

5.1.4. Почему существующие решения не подходят полностью

Logstash / Elasticsearch требуют написания сложных конфигураций pipeline на Ruby, что трудно поддерживать.

Loki хорошо работает с метками, но плохо с полнотекстовым поиском по телу сообщения.

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

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

5.2. Этап 2. Выбор инструмента реализации

5.2.1. Критерии выбора

• Производительность обработки (сообщений/с).
• Доступность библиотек для Kafka, Redis, Elasticsearch.
• Скорость разработки прототипа (для практики важно успеть).
• Возможность лёгкого рефакторинга в будущем.

5.2.2. Сравнение языков программирования

Язык	Производительность (оценка)	Библиотеки для Kafka и ES	Скорость разработки	Применимость в индустрии
Python	Средняя (асинхр. до 5k msg/s)	Отличные (kafka-python, elasticsearch-py)	Очень высокая	Средняя (часто как прототип)
Go	Высокая (>20k msg/s)	Хорошие (sarama, olivere/elastic)	Средняя	Высокая (микросервисы)
Rust	Очень высокая (>50k msg/s)	Умеренные (rdkafka, rs-es)	Низкая	Низкая (пока нишевой)
Java	Высокая	Отличные (Kafka клиенты, Spring Data ES)	Средняя	Высокая (корпоративный стандарт)

5.2.3. Итоговое решение для прототипа

На этапе научно-исследовательской практики выбран Python 3.11 с асинхронным фреймворком asyncio и библиотеками:

• aiokafka – асинхронный consumer/producer.
• redis (синхронный, но с пулом соединений) – для дедупликации.
• elasticsearch – синхронный клиент (в асинхронном варианте – aioelasticsearch, но он менее стабилен).
• fastapi + uvicorn – для REST API.

Для сбора логов со стороны приложений используется Filebeat (легковесный агент от Elastic), который отправляет логи в Kafka.

Обоснование:
Python позволяет быстро итеративно протестировать гипотезы фильтрации (регулярные выражения, структуры данных), а при необходимости критичный по скорости код можно переписать на Go в ВКР.

5.3. Этап 3. Схема модуля (архитектура)

5.3.1. Общая схема потоков данных

text

[Приложение] --> (лог-файл/stdout) --> [Filebeat] --> (Kafka topic: raw-logs)

|

v

[Модуль фильтрации (Python)]

(consumer группы "filter-group")

|

- чтение пачки сообщений

- для каждого:

- вычислить hash

- проверить в Redis

- если новое -> обработать

- если ERROR -> запросить контекст из Kafka (буфер за last 5 sec)

|

v

(Kafka topic: filtered-logs)

|

v

[Elasticsearch] <- [Kibana]

|

v

[REST API (FastAPI)] --> клиенты (разработчики)

5.3.2. Описание компонентов

Filebeat – запускается на каждом узле как демон, читает файлы логов (или stdout контейнеров), добавляет метаданные (хост, тип лога), отправляет в Kafka в формате JSON.

Kafka – распределённый брокер сообщений. Используется два топика:

• raw-logs – все сырые логи (ретеншн 24 часа).
• filtered-logs – логи после фильтрации (ретеншн 30 дней).

Модуль фильтрации – один или несколько экземпляров Python-приложения, работающих в группе потребителей Kafka.

• Читает raw-logs.
• Для каждого сообщения извлекает hash(message).
• Запрашивает у Redis, встречался ли этот хеш за последние N секунд.
• Если нет – сохраняет хеш в Redis с TTL (например, 60 секунд) и пропускает сообщение дальше.
• Если уровень сообщения ERROR или CRITICAL: запускает подзапрос к Kafka Streams API (или к отдельному consumer) для получения всех сообщений от того же source за интервал [timestamp-5s, timestamp]. Добавляет их в поле context.
• Обогащает сообщение полями: hostname, version, filtered_at.
• Отправляет в filtered-logs.

Elasticsearch – хранит отфильтрованные логи, строит индексы по полям timestamp, level, source.

Kibana – визуализация, дашборды.

REST API – интерфейс для программного поиска ошибок, возвращает JSON.

5.3.3. Модули программного кода

Проект модуля фильтрации состоит из следующих модулей (файлов):

• consumer.py – основной цикл чтения из Kafka, диспетчеризация.
• dedup.py – класс Deduplicator с методами is_duplicate(message).
• context_extractor.py – класс ContextExtractor, обращающийся к Kafka для получения исторических сообщений.
• enricher.py – добавление метаданных.
• producer.py – отправка в filtered-logs.
• api.py – FastAPI приложение, вычитывающее из Elasticsearch.
• config.py – настройки подключений.

5.3.4. Входные и выходные данные

Входные данные (пример сообщения из Filebeat в Kafka):

json

{

"@timestamp": "2026-05-06T10:00:00.123Z",

"log.level": "ERROR",

"message": "Failed to connect to database: timeout after 30s",

"source": "/var/log/myapp/error.log",

"host.name": "web-server-01",

"service.name": "auth-service"

}

Выходные данные (после фильтрации, с контекстом):

json

{

"timestamp": "2026-05-06T10:00:00.123Z",

"level": "ERROR",

"source": "auth-service",

"host": "web-server-01",

"message": "Failed to connect to database: timeout after 30s",

"message_hash": "a1b2c3...",

"context": [

{ "timestamp": "...09:59:58", "level": "WARN", "message": "Connection pool 90% full" },

{ "timestamp": "...09:59:59", "level": "WARN", "message": "Waiting for connection release" }

],

"filtered_at": "2026-05-06T10:00:01.456Z"

}

5.4. Этап 4. Предполагаемые результаты работы модуля

Метрика	До внедрения	После внедрения (прогноз)
MTTA (медиана)	30 мин	4 мин 30 сек
Объём хранимых логов (в сутки)	25 ГБ	12 ГБ (снижение на 52%)
Количество повторяющихся ошибок, скрытых от аналитика	нет	95% (автоматически сгруппированы)
Время ответа API поиска ошибок	не было	<200 мс (90-й процентиль)

5.4.1. Количественные результаты

5.4.2. Качественные результаты

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

Если простой сервиса из-за необнаруженной ошибки происходит 2 раза в месяц по 1 часу (стоимость часа = 5000 у.е.), то снижение MTTA с 30 минут до 5 минут уменьшает время восстановления до 30 минут (ещё 25 минут уходит на исправление). Экономия в месяц: 2 * (30 - 5)/60 часа * 5000 ≈ 4167 у.е. Годовая экономия – 50 000 у.е.

5.5. Этап 5. Выводы по плану исследования

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

1. Разрабатываемый модуль является технически реализуемым на открытых компонентах (Kafka, Redis, Elasticsearch, Python).
2. Задача выделения контекста ошибки решается путём хранения временного буфера сообщений в Kafka (или в отдельном in-memory storage) и запроса к нему при появлении ERROR.
3. Дедупликация через Redis с TTL позволяет эффективно отсеивать повторы, не нагружая основное хранилище.
4. Целевой показатель MTTA ≤5 минут достижим, если время обработки одного сообщения модулем фильтрации <0,5 мс (что реально для Python при асинхронном вводе-выводе).
5. Дальнейшая работа по ВКР будет включать реализацию, развёртывание на стенде и измерение фактических метрик.