日志记录是计算中最古老和最普遍的模式之一。对于深入了解从测试环境中的基本故障到生产中最复杂的问题的关键是，它在所有软件堆栈和所有类型的基础设施中都是常见的做法，并且已经存在了几十年。尽管日志功能强大且灵活，但其庞大的数据量往往使从中提取有用信息变得不切实际。相关信息分布在许多单独的日志行中，即使使用最强大的日志处理系统，搜索正确的详细信息也可能很慢，并且需要复杂的查询语法。我们发现，在Stripe中使用对传统日志的轻微扩展非常有用，我们称之为规范日志行。这是一种相当简单的技术：除了正常的日志跟踪之外，请求在末尾还发出一条包含许多关键特征的长日志行。将这些数据放在一条信息密集的行中可以使查询和聚合更快地写入，运行也更快。在我们为帮助深入了解生产而部署的所有工具和技术中，尤其是规范日志行已被证明对增加操作可视性和事件响应非常有用，因此我们几乎将它们放在我们运行的每个服务中，不仅在主API中使用，但是每次发送webhook、我们的PCI保险库标记信用卡或在Stripe仪表板中加载页面时都会发出一个。结构化测井就像计算中的许多其他地方一样，日志记录在api和web服务中被广泛使用。在payments API中，单个请求可能会生成如下所示的日志跟踪：[2019-03-18 22:48:32.990]请求已开始[2019-03-18 22:48:32.991]用户认证[2019-03-18 22:48:32.992]利率限制ran[2019-03-18 22:48:32.998]费用产生[2019-03-18 22:48:32.999]请求完成[2019-03-18 22:48:32.990]请求已开始[2019-03-18 22:48:32.991]用户认证[2019-03-18 22:48:32.992]利率限制ran[2019-03-18 22:48:32.998]费用产生[2019-03-18 22:48:32.999]请求完成结构化日志通过为开发人员提供一种简单的方法用附加数据注释行来增强实践。structured这个词的用法是含糊不清的——它可以指一种本机结构化的数据格式，如JSON，但它通常意味着日志行通过附加key=value对（有时称为logfmt，即使不是通用的）来增强。添加的结构使开发人员可以轻松地用额外的信息标记行，而不必笨拙地将其注入日志消息本身。上述痕迹的丰富形式可能如下所示：[2019-03-18 22:48:32.990]请求启动http_method=POST http_path=/v1/charges Request_id=req_123[2019-03-18 22:48:32.991]用户认证的auth_type=api_key key_id=mk_123 User_id=usr_123[2019-03-18 22:48:32.992]允许的费率限制费率=真实费率费率费率配额=100费率剩余费率=99[2019-03-18 22:48:32.998]费用产生费用_id=ch_123权限_used=账户_write team=获取[2019-03-18 22:48:32.999]请求完成分配计数=9123数据库查询=34持续时间=0.009 http_状态=200[2019-03-18 22:48:32.990]请求启动http_method=POST http_path=/v1/charges Request_id=req_123[2019-03-18 22:48:32.991]用户认证的auth_type=api_key key_id=mk_123 User_id=usr_123[2019-03-18 22:48:32.992]允许的费率限制费率=真实费率费率费率配额=100费率剩余费率=99[2019-03-18 22:48:32.998]费用产生费用_id=ch_123权限_used=账户_write team=获取[2019-03-18 22:48:32.999]请求完成分配计数=9123数据库查询=34持续时间=0.009 http_状态=200添加的结构还使发出的日志具有机器可读性（key=value约定被设计为机器可读性和人类可读性之间的折衷），这使得它们可以被许多不同的日志处理工具接收，其中许多工具提供了近实时查询生产日志的能力。例如，我们可能想知道最后请求的API端点是什么。我们可以使用Splunk这样的日志处理系统及其内置的查询语言来解决这个问题："请求开始"|头"请求开始"|头或者最近是否有任何API请求被速率限制："速率限制运行"允许=假"速率限制运行"允许=假或收集过去一小时内API执行持续时间的统计信息："请求完成"最早=-1h |统计计数p50（持续时间）p95（持续时间）p99（持续时间）"请求完成"最早=-1h |统计计数p50（持续时间）p95（持续时间）p99（持续时间）实际上，从Graphite和statsd等度量系统生成的仪表板中收集这些简单化的关键点会更常见，但它们有局限性。发出的度量和解释它们的仪表盘都是预先设计好的，在紧要关头，它们通常很难以创造性或意想不到的方式进行查询。与这些系统相比，日志记录真正的亮点在于灵活性。日志通常会产生过多的数据，以至于可以从中获取几乎任何信息，甚至是没有人认为他们需要的信息。例如，我们可以查看哪个API路径最受欢迎："请求已启动"|按http路径统计"请求已启动"|按http路径统计或者假设我们看到API正在生成500s（内部服务器错误）。我们可以检查错误的请求持续时间，以了解它们是否可能是由数据库超时引起的："请求完成"状态=500 |统计计数p50（持续时间）p95（持续时间）p99（持续时间）"请求完成"状态=500 |统计计数p50（持续时间）p95（持续时间）p99（持续时间）复杂的日志处理系统也倾向于以与度量仪表板大致相同的方式来支持信息的可视化，因此，我们可以让我们的系统图形化我们特别查询的结果，而不是阅读原始日志跟踪。视觉化的解释更直观，能让我们更容易理解发生了什么。规范日志行：每个服务的每个请求一行虽然日志在上面的示例中提供了额外的灵活性，但是如果我们想跨行查询跟踪中的信息，我们仍然会遇到困难。例如，如果我们注意到API中存在很多速率限制，我们可能会问自己一个问题："哪些用户的速率限制最大？"了解答案有助于区分合法的速率限制（因为用户发出的请求太多）和意外的速率限制（可能是由于我们的系统中存在错误）。关于请求是否是速率限制的以及由哪个用户执行的信息分布在多个日志行中，这使得查询更加困难。大多数日志处理系统仍然可以通过在诸如请求ID之类的东西上整理跟踪的数据并查询结果来做到这一点，但这涉及到扫描大量数据，而且运行速度较慢。它还需要更复杂的语法，这对人类来说更难记住，也更费时去写。我们使用规范的日志行来帮助解决这个问题。这是一个简单的想法：除了正常的日志跟踪之外，请求（或其他正在执行的工作单元）也会在末尾发出一条长长的日志线，将其所有的密钥遥测数据拉到一个位置。它们看起来像这样：[2019-03-18 22:48:32.999]规范日志行alloc_count=9123 auth_type=api_key database_querys=34 duration=0.009 http_method=POST http_path=/v1/charges http_status=200 key_id=mk_123权限_used=account_write rate_allowed=真实速率_quota=100 rate_remaining=99请求_id=req_123 team=获取用户_id=usr_123[2019-03-18 22:48:32.999]规范日志行alloc_count=9123 auth_type=api_key database_querys=34 duration=0.009 http_method=POST http_path=/v1/charges http_status=200 key_id=mk_123权限_used=account_write rate_allowed=真实速率_quota=100 rate_remaining=99请求_id=req_123 team=获取用户_id=usr_123此示例显示规范行可能包含的信息类型包括：HTTP请求谓词、路径和响应状态。经过身份验证的用户和相关信息，如如何进行身份验证（API密钥、密码）以及所使用的API密钥的ID。速率限制器是否允许该请求，以及诸如其分配的配额和剩余部分等统计信息。计时信息，如总请求持续时间和数据库查询所花费的时间。发出的数据库查询数和VM分配的对象数。我们将日志行称为canonical，因为它是特定请求的权威行，与IETF的规范链接关系指定一个权威URL相同。标准线条是人体工程学的特征。通过对所有对我们来说重要的内容进行分类，我们可以通过对人们容易编写的查询来访问这些内容，即使在生产事件的胁迫下也是如此。因为底层日志系统不需要在查询时拼凑多条日志行，所以计算机检索和聚合的成本也很低，这使得它们的使用速度很快。记录的各种各样的信息在可以查询的内容方面提供了几乎无限的灵活性。这在事故的发现阶段尤其有价值，因为在事故发生的过程中，人们知道有什么地方出了问题，但究竟是什么问题仍然是个谜。深入了解我们上面的费率限制问题就变得很简单：规范日志行速率_allowed=false |按用户标识统计计数规范日志行速率_allowed=false |按用户标识统计计数如果只有一个或几个用户受到速率限制，这可能是合理的速率限制，因为他们发出的请求太多。如果有很多不同的用户，我们很可能有一个bug。作为一个稍微复杂一点的例子，我们可以可视化特定用户在一段时间内charges端点的性能，同时还要确保过滤掉由用户引起的4xx个错误。4xx错误倾向于q短路