Логгирование зачастую может удовлетоврить потребности в том числе в мониторинге и трейсинге. Рассматривая эволюцию решений "от простого к сложному" очевидно, что проще использовать обогащенное логгирование и усложнять систему по мере надобности, выделяя трейсинг и мониторинг в отдельные решения.
Логгирование - процесс записи событий в хронологическом порядке.
Мониторинг - это процесс наблюдение за состоянием системы. Смотрим метрики, если система
"захворала", то отправляем алерты.
Трассировка - накопление данных, достаточных для последующего отслеживания пути запроса по
распределенной системе.
Все эти инструменты часто пересекаются в своем функционале. В наших системах с небольшой и умеренной нагрузкой мы используем логгирование в качестве решения в том числе задач трассировки и мониторинга.
Объединение логгирования с трейсингом и мониторингом может покрыть лишь часть функционала, т.к. при избыточном логгировании доля ценной информации будет сокращаться. Так, для мониторинга часто лучше подходят time-series БД, а для логов и трейсов документные или реляционные.
Отличие логгирования и трейсинга - объем накапливаемой информации. Трейсинг часто хранит много легких данных о том как контроль выполнения переходит от одной системе к другой. Часто поэтому трейсинг используют, помимо отладки, для мониторинга производительности приложения: сколько запросов в секунду, как долго отрабатывали подсистемы в рамках запроса, частота ошибок, лейтенси и т.д.
Чтобы к логгированию добавить трейсинг нужно, например:
Чтобы к логгированию добавить мониторинг, нужно:
Самое простое решение (и лучшее, если позволяет среда) - это файлы на диске. Удобный легкий поиск в командной строке, легкий менеджмент (ротация, архивирование и т.д.). С файлами работать достаточно просто.
В распределенной среде нужно централизованное хранилище.
При определенном объеме логгирования можно хорошо использовать реляционные БД, например, PostgreSQL. Эта БД вполне хорошо подходит, если писать до 3Гб в день, партицировать по месяцам/неделям и хранить логи не более 3х месяцев. Достаточно легко на PostgreSQL добиться 10 000+ записей в секунду. (использование COPY). Скорость сильно зависит от размеров буфера, автокомита, размера лог-записи, индексов, констрейнтов, дисков и т.д.
ClickHouse. Запись от 50 000 до 200 000 записей в секунду (размер лог-записи до 1Кб). Есть эксприментальная фича с инвертированными индексами для полнотекстового поиска.
У ClickHouse мне очень понравилась страница с бенчмарками: https://benchmark.clickhouse.com/. Видно, что ClickHouse сильно выигрывает, если есть SUM, AVG, COUNT. Однако в запросах по первичному ключу, LIKE '%query%' PostgreSQL впереди (от 2 до 24 раз быстрее).
Ошибка в приложении содержит минимум данных, достаточных для различения одной ошибки от другой, но контекст, в которой возникла ошибка лучше описать в лог-записи.
Лог-записи должны быть короткими, максимально информативными. Когда случается пожар, некогда вчитывать в горы бесполезного текста.
Логгирование часто воспринимается как что-то отвлекающее от решения задачи. Однако часто именно лог-сообщения помогают отличить качественное программное обеспечение от некачественного.
Несколько рекомендаций: