Тимур Малик

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

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

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

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

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

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

Именно тогда я задумался: а почему работа с логами не может начинаться гораздо проще?

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

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

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

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

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

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

Мне захотелось изменить именно этот этап работы.

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

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

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

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

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

Именно поэтому я вижу PulseLog не просто как программу для просмотра логов, а как инструмент для расследования инцидентов.

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

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

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

Ради этого я и начал создавать PulseLog.