不等待云运行容器内的 log.write() promise 可以吗？

Question

我正在使用 @google-cloud/logging 从云端运行上的 express 应用程序中记录一些内容运行。

像这样：

routeHandler.ts

import { Logging } from "@google-cloud/logging";

const logging = new Logging({ projectId: process.env.PROJECT_ID });
const logName = LOG_NAME; 
const log = logging.log(logName);

const resource = {
  type: "cloud_run_revision",
  labels: { ... }
};

export const routeHandler: RequestHandler = (req,res,next) => {
  try {
    // EXAMPLE: LOG A WARNING
    const metadata = { resource, severity: "WARNING" };
    const entry = log.entry(metadata,"SOME WARNING MSG");
    await log.write(entry);
    return res.sendStatus(200);
  }
  catch(err) {
    // EXAMPLE: LOG AN ERROR
    const metadata = { resource, severity: "ERROR" };
    const entry = log.entry(metadata,"SOME ERROR MSG");
    await log.write(entry);
    return res.sendStatus(500);
  }
};

可以看出log.write(entry)是异步的。所以，理论上，建议等待。但这是 @google-cloud/logging 的文档所说的：

Doc link

我对此没有意见。在我的真实情况下，即使 log.write() 失败，它在 try-catch 内，任何错误都将得到很好的处理。

我的问题是它与 Cloud 运行文档有些冲突：

Doc link

注意：如果我不等待log.write()调用，我将通过响应请求

结束请求周期

而 Cloud 运行确实表现得像那样。几周前，我试图立即响应请求并解雇一些长时间的后台工作。这个过程暂停了一段时间，我认为它在收到另一个请求后会重新启动。完全不可预测。当我运行我在这里提到的这个测试时，我什至在我的云运行服务容器上设置了 MIN_INSTANCE=1。即便如此，我的后台工作也无法顺利运行。因此，我认为当我处理完一个请求后让进程做后台工作是不好的（通过“fire and forget” 方法）。

那么，我应该在这里做什么？

Answer 1

根据 @Karl-JorhanSjögren 在评论中的正确假设将此答案作为社区 Wiki 发布。

对于云中运行应用程序的日志调用运行我们确实鼓励您采用即发即弃的方法，因为您真的不需要强制同步。

正如在回复您关于 CPU 在请求完成后被禁用的问题的评论中提到的那样， CPU 将首先被限制，以便可以快速恢复实例并长时间不活动后完全禁用。因此，触发在大多数情况下会在几毫秒内完成的小型日志记录调用应该不是问题。

文档中提到的内容针对的是运行较长时间段的进程。

不等待云运行容器内的 log.write() promise 可以吗？

Is it fine to not await for a log.write() promise inside a cloud run container?

node.js

express

google-cloud-run

google-cloud-logging

不等待云 运行 容器内的 log.write() promise 可以吗？

Is it fine to not await for a log.write() promise inside a cloud run container?

node.js

express

google-cloud-run

google-cloud-logging

不等待云运行容器内的 log.write() promise 可以吗？