#node.js #firebase #google-cloud-functions #google-cloud-logging
#node.js #firebase #google-cloud-функции #google-cloud-ведение журнала
Вопрос:
Наш продукт в значительной степени основан на Node.js функции firebase версии 10, и до сих пор мы использовали firebase functions logger SDK для ведения журнала. Тем не менее, нам этого уже недостаточно, так как нам нужно отправлять некоторые дополнительные свойства с каждым журналом для лучшей фильтрации в GCP Logging Explorer.
К сожалению, очень полезные functionName executionId метки и не прикреплены к журналам, запускаемым Cloud Logging SDK. Эти метки каким-то образом отображаются Node.js Firebase SDK для того, чтобы я мог вручную прикрепить их к метаданным?
С уважением
Ответ №1:
У нас есть точно такой же стек на работе, и мы просто создаем регистратор, который находится поверх регистратора firebase и выполняет в основном ручное ведение журнала.
// Use the firebase functions logger to report all logs from out logger to
// Can do logger.info, .error, .log, .warn
// Logger is a custom function function that sits on top of console or firebase logger
// This means initialise a logger singleton using the firebase functions logger as a base
logger(functions.logger)
Например, типичный журнал функций будет:
// Use the logger global singleton initialised above
logger.log(`[endpoint-name.methodName] - Execution failed with error code ${error.code} and message ${error.message}`)
Затем мы просто используем поле поиска журнала функций, чтобы найти экземпляр конкретной ошибки. Мы также сообщаем обо всех внутренних ошибках sentry и используем их для отладки.
Надеюсь, это даст вам несколько идей?
Комментарии:
1. Хотя это решение, оно довольно сложное, и я предпочитаю избегать его. Кроме того, как вы получаете имена конечных точек и методов?
2. У нас есть пользовательское промежуточное программное обеспечение, которое добавляет имя нашей конечной точки к нашему объекту запроса, прежде чем он попадет в конечную точку.
[${req.endpointName} - ManuallyAddFuncName] - blob. Я также не думаю, что это хакерское хорошее работоспособное решение.3. Это хорошее работоспособное решение 🙂 Я просто предпочитаю использовать механизм регистратора для functionName и executionId, поскольку эти метки очень полезны в проводнике. Кстати, я использовал вашу идею для получения данных из запроса, но вместо этого я передаю их в метаданных записи журнала. Таким образом, метки отображаются в GCP Logging Explorer.
4. Ах, это хорошая идея — рад, что вы что-то поняли!