Блог

Я всегда думал, что чем больше у вас протоколирования, тем лучше для отладки / устранения неполадок. Это просто упрощает задачу, учитывая, что вы регистрируете правильные вещи, а не регистрируете ненужные вещи. Я всегда делал это в меньшем масштабе. Как бы вы это сделали в больших системах? Стоит ли это того, или было бы более выгодно просто регистрировать то, что необходимо, чтобы определить, что есть проблема и в чем проблема, но не очень конкретные детали.

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

В небольших масштабах я успешно выполнил следующее, и мне нравится этот подход. Смотрите ниже, просто краткое высокоуровневое проектирование… Да, я разработчик .net :).

• Определенно пользовательский регистратор с глобальным контекстом журнала.
• Файл журнала для каждого запроса с именем файла в качестве RequestName_Timestamp_GUID .
• В папке есть файл _exceptions, в котором каждый запрос, содержащий исключение, имеет строку журнала для идентификации.
• В нем также есть ролик журнала и средство просмотра файлов.
• Любой запрос с ошибкой, с которой начинается файл журнала!~~RequestName_Timestamp_GUID .
• Это упрощает поиск запросов об ошибках, поскольку проводник Windows помещает их в начало.

К вашему сведению: не совсем уверен, что это лучшее место для этого вопроса.

Проблема отладки крупномасштабной системы довольно обширна, поэтому лучше разбить ее на несколько отдельных частей. Вы

Сбор журналов со всех систем

Одним из распространенных способов является использование существующих систем для централизованного сбора журналов и управления ими. Вы можете использовать коммерческое решение, такое как Splunk, или стек с открытым исходным кодом, такой как ELK (Elastic Logstash Kibana). Эти системы обычно состоят из 3 основных частей

1. Сбор журналов — прослушивание выходных данных журнала и пересылка их в централизованное хранилище. Это может быть сделано несколькими различными способами в зависимости от потребностей и используемой технологии.
2. Централизованное хранилище — некоторая система СУБД, которая позволяет хранить большое количество данных и индексировать их, чтобы их можно было эффективно искать
3. Графический интерфейс — чтобы позволить пользователям выполнять поиск в СУБД и настраивать панели мониторинга и оповещения

https://www.elastic.co/what-is/elk-stack

Отслеживание запросов в нескольких системах

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

https://dzone.com/articles/correlation-id-for-logging-in-microservices

Конфигурация регистратора

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