日志采样率

by Yan Cui

崔燕

为什么要在生产中采样调试日志 (Why you should sample debug logs in production)

It’s com­mon prac­tice to set your log lev­el to warning for pro­duc­tion due to traf­fic vol­ume. This is because you have to con­sid­er var­i­ous cost fac­tors:

通常的做法是将您的日志级别设置为警告 ，以防流量增加。 这是因为您必须考虑各种成本因素：

• Cost of log­ging : Cloud­Watch Logs charges $0.50 per GB ingest­ed. In my expe­ri­ence, this is often much high­er than the Lamb­da invo­ca­tion costs

  记录的费用 ：CloudWatch的日志费$ 0.50每GB摄入。 以我的经验，这通常比Lambda调用成本高得多

• Cost of stor­age : Cloud­Watch Logs charges $0.03 per GB per month, and its default reten­tion pol­i­cy is Nev­er Expire! A com­mon prac­tice is to ship your logs to anoth­er log aggre­ga­tion ser­vice and to set the reten­tion pol­i­cy to X days. See this post for more details.

  存储成本的 ：CloudWatch的日志每月收取每GB $ 0.03，它的默认保留策略永不过期 ！ 一种常见的做法是将日志发送到另一个日志聚合服务，并将保留策略设置为X天。 有关更多详细信息，请参见此帖子 。

• Cost of pro­cess­ing : if you’re pro­cess­ing the logs with Lamb­da, then you also have to fac­tor in the cost of Lamb­da invo­ca­tions.

  处理成本 ：如果你和λ处理日志，那么你还必须因素LAMBDA调用的成本。

But, doing so leaves us with­out any debug logs in pro­duc­tion. When a prob­lem hap­pens in pro­duc­tion, you won’t have the debug logs to help iden­ti­fy the root cause.

但是，这样做会使我们在生产中没有任何调试日志。 当生产中出现问题时，您将没有调试日志来帮助确定根本原因。

Instead, you have to waste pre­cious time deploying a new ver­sion of your code to enable debug log­ging. Not to men­tion that you shouldn’t for­get to dis­able debug log­ging when you deploy the fix.

相反，您必须浪费宝贵的时间来部署新版本的代码以启用调试日志记录。 更不用说在部署修补程序时，您不应忘记禁用调试日志记录。

With microser­vices, you often have to do this for more than one ser­vice to get all the debug mes­sages you need.

对于微服务，您经常必须对多个服务执行此操作，才能获得所需的所有调试消息。

All these increas­e the mean time to recov­ery (MTTR) dur­ing an inci­dent. That’s not what we want.

所有这些增加了事故期间的平均恢复时间 (MTTR)。 那不是我们想要的。

It doesn’t have to be like that.

不一定要那样。

There is a hap­py mid­dle ground between hav­ing no debug logs and hav­ing all the debug logs. Instead, we should sam­ple debug logs from a small per­cent­age of invo­ca­tions.

在没有调试日志和拥有所有调试日志之间有一个中间的幸福基础。 相反，我们应该从一小部分调用中提取调试日志。

I demoed how to do this in the Log­ging chap­ter of my video course Pro­duc­tion-Ready Server­less. You need two basic things:

我演示了如何在我的视频课程的记录章节做生产准备无服务器 。 您需要两件事：

• a log­ger that lets you to change the log­ging lev­el dynam­i­cal­ly, for example via envi­ron­ment vari­ables一个使您可以动态更改日志记录级别的记录器，例如通过环境变量

• a mid­dle­ware engine such as mid­dy

  中间件引擎，例如Middy

With Lamb­da, I don’t need most of the fea­tures from a ful­ly-fledged log­ger such as pino. Instead, I pre­fer to use a sim­ple log­ger mod­ule like this one. It’s writ­ten in a hand­ful of lines and gives me the basics:

和λ，我不需要从一个完全成熟的记录器的大部分功能，如皮诺 。 相反，我更喜欢使用像这样的简单记录器模块。 它用几行代码编写，并为我提供了基本知识：

• struc­tured log­ging with JSON

  JSON的结构化日志记录

• abil­i­ty to log at dif­fer­ent lev­els能够以不同级别登录
• abil­i­ty to con­trol the log lev­el dynam­i­cal­ly via envi­ron­ment vari­ables通过环境变量动态控制日志级别的能力

Using mid­dy, I can cre­ate a mid­dle­ware to dynam­i­cal­ly update the log lev­el to debug. It does this for a con­fig­urable per­cent­age of invo­ca­tions. At the end of the invo­ca­tion, the mid­dle­ware would restore the pre­vi­ous log lev­el.

使用middy，我可以创造一个中间件动态更新的日志级别调试 。 这样做是为了实现可配置的调用百分比。 在调用结束时，中间件将恢复先前的日志级别。

You might notice that we also have some spe­cial han­dling for when the invo­ca­tion errs.

您可能会注意到，对于调用错误，我们还进行了一些特殊处理。

This is to ensure we cap­ture the error with as much con­text as pos­si­ble, includ­ing:

这是为了确保我们在尽可能多的上下文中捕获错误，包括：

• the unique AWS Request ID唯一的AWS请求ID

• the invo­ca­tion event, so we can replay the invo­ca­tion event local­ly and debug the prob­lem

  调用事件，因此我们可以在本地重播调用事件并调试问题

• the error mes­sage and stack­trace错误消息和stacktrace

Hav­ing debug logs for a small per­cent­age of invo­ca­tions is great. But when you’re deal­ing with microser­vices, you need to make sure that your debug logs cov­er an entire call chain.

具有一小部分调用的调试日志非常棒。 但是，在处理微服务时，需要确保调试日志覆盖整个调用链。

That is the only way to put togeth­er a com­plete pic­ture of every­thing that hap­pened on that call chain. Oth­er­wise, you will end up with frag­ments of debug logs from many call chains but nev­er the com­plete pic­ture of one.

这是对呼叫链上发生的所有事情进行完整描述的唯一方法。 否则，您将获得来自许多调用链的调试日志的片段，但永远不会完整地看到一个。

You can do this by for­ward­ing the deci­sion to turn on debug log­ging as a cor­re­la­tion ID. The next func­tion in the chain would respect this deci­sion, and pass it on. See this post for more detail.

您可以通过转发决定打开调试日志记录作为相关ID来做到这一点。 链中的下一个职能将尊重这一决定，并将其继续下去。 有关更多详细信息 ，请参见这篇文章 。

So that’s it, anoth­er pro tip on how to build observ­abil­i­ty into your server­less appli­ca­tion. If you want to learn more about how to go all in with server­less, check out my 10-step guide here.

就是这样，这是有关如何在无服务器应用程序中建立可观察性的另一个提示。 如果您想了解更多有关如何使用无服务器的方法的更多信息，请在此处查看我的十步指南。

Until next time!

直到下一次！

翻译自: https://www.freecodecamp.org/news/why-you-should-sample-debug-logs-in-production-39d78ef3968d/

日志采样率