Дешевое, но эффективное решение для ведения журнала в частном API-интерфейсе микросервисов отдыха
Как я уже упоминал в комментариях, я бы оспорил некоторые утверждения в вашем вопросе. В основном это:
Серверная часть регистрирует только необычные ответы об ошибках, т. Е. Имеющие статус> = 500. Остальное (я полагаю, журналы доступа и анализ производительности) будут выполняться с помощью телеметрии.
Для начала давайте обсудим определение телеметрии:
Телеметрия — это сбор на месте измерений или других данных в удаленных точках и их автоматическая передача на приемное оборудование (телекоммуникации) для контроля.
Другими словами, телеметрия — это просто журнал, который отправляется куда-то еще. Есть некоторые коннотации этого термина в программном обеспечении и ИТ, которые подразумевают определенный тип ведения журнала, но думать об этом как о чем-то принципиально отличном от ведения журнала - неправильное представление, ИМО. Телеметрия очень полезна, особенно в больших сложных средах, где журналы могут быть объединены вместе, и есть такие проекты, как Open Telemetry, которые могут принести большую пользу с небольшими усилиями. Но использование этих методов несколько ортогонально вопросу о том, какую информацию вы должны регистрировать для устранения ошибок.
Есть несколько плохих предположений с вашим утверждением выше:
- Все дефекты в вашем коде приведут к ошибке 500.
- Код ошибки и/или описание укажут на основную проблему.
Для № 1 многие ошибки вообще никогда не приводят к ошибке. Также возможно, что ошибка, которую ваш код рассматривает как ошибку пользователя, является вашим дефектом, например: обработка действительного действия пользователя как недопустимого.
Подумайте об этом так: если вы были способны правильно идентифицировать и классифицировать свои ошибки со 100% точностью, вы должны быть в состоянии построить систему без каких-либо дефектов. Другими словами, дефекты — это то, что вы не учли или внедрили неправильно. На самом деле не имеет смысла думать, что вы знаете, как поведет себя система, если она ведет себя не так, как вы ожидали. Ключевой момент с 500 ошибками — убедиться, что вы не раскрываете детали своей реализации клиенту, например, записываете трассировку стека в ответ.
Что касается № 2, в случаях, когда вы регистрируете ошибку как 500, вам, вероятно, потребуется больше, чем просто краткое описание события, которое было зафиксировано как ошибка. Часто последним, что происходит, будет что-то действительно бесполезное, например, ошибка нулевого указателя или недопустимый параметр для запроса к БД. Проблема в том, что вы можете не знать, что было передано в БД или откуда взялось это неверное значение, и тогда вы будете хвататься за соломинку, пытаясь понять, как воспроизвести сценарий с ограниченной информацией о положении вещей. В большинстве случаев это может быть очевидно, но, поскольку это конкретные сценарии, которые вы не смогли должным образом учесть, вы, вероятно, столкнетесь с проблемой, которую не сможете понять, просто взглянув на сообщение об ошибке и подумав об этом. .
Логирование — это искусство. Это то, с чем, я думаю, почти все борются. Существует тонкая грань между регистрацией соответствующей информации и засорением ваших журналов бесполезными подробностями. Но в целом чем больше, тем лучше. Я (как правило) не буду регистрировать каждое выполнение цикла, но я буду регистрировать все параметры функции, поиск в БД или вызов службы вместе с тем, какой вызов был сделан.
Инструменты «телеметрии» могут помочь в этом. Эти инструменты могут делать такие вещи, как регистрировать каждый вызов функции вместе с ее параметрами и отправлять их в какой-либо приемник журналов. Вопрос: почему вы должны регистрировать ошибки по-другому? В чем смысл отдельной регистрации ошибок? Мне кажется, что проще всего было бы хранить все ваши данные в одном месте, организованном таким образом, чтобы вы могли легко и просто отследить источник проблемы.
Что касается ресурсов, связанных с этим, если вы уже собираетесь собирать телеметрию, информация об ошибках является незначительным дополнением. Я не вижу никаких реальных причин для их разделения.
При ведении журналов (независимо от того, используете ли вы телеметрию или нет) необходимо учитывать два важных момента: цель может обрабатывать объем журналов и объем используемого вами хранилища. Удовлетворение первому ограничению, как правило, приводит к некоторой асинхронной обработке, т. е. к решению с высокой доступностью и минимальной задержкой при записи в приемник журналов. Хорошей новостью в отношении второго ограничения является то, что хранение относительно дешево, но вам, скорее всего, придется подумать о том, насколько давно вы храните полные журналы.
Наконец, обязательно отслеживайте метки времени для всех событий регистрации в источнике из-за того, что время обработки события приемником регистрации может сильно отличаться от времени, когда оно произошло. Использование некоторого идентификатора корреляции для ваших транзакций также является действительно хорошей идеей. Во все ответы клиенту вы должны включать этот идентификатор. Таким образом, если ваш клиент столкнется с проблемой, вы сможете легко найти связанные с ней журналы. Этот идентификатор также будет основным способом изоляции транзакций при просмотре журналов. Вы можете обнаружить, что вам нужны идентификаторы субкорреляции, чтобы действительно понимать данные, когда вы ставите вещи на место.
Желаю вам удачи в вашем начинании. Если у вас есть вопросы, дайте мне знать в комментариях.