监控是一个基本的难题,这很烦人,因为它听起来应该很容易。我们构建了这个服务或应用程序,现在我们要做的就是跟踪它的性能;很简单,对吧?不过,和大多数事情一样,细节才是关键。我们要监视什么?我们说表演是什么意思?在第一个关口,似乎真的很有诱惑力,只是把每一个可能的数据,我们可以进入普罗米修斯毕竟,数据越多不是越好吗?然后你的磁盘空间在一小时内就满了,所有你正在爬行的那些花哨的指标都用光了你所有的带宽,实际上,你无法弄清楚这些,因为你的仪表盘都是超负荷的,以至于它们都停了下来——更不用说你有这么多不同的指标和警报,以至于你无法跟踪任何东西是什么。今天,我不打算回答所有这些问题,因为我对大多数问题都没有答案(如果我有答案,我会写一些精彩的书,告诉大家去买)。我要做的是解释我们在OkCupid是如何通过直接从中提取我们的延迟来恢复我们的理智的188bet金宝搏官网单倍体使用弗伦特.

为什么是延迟?延迟被广泛认为是一个非常好的监控信号;例如,它包含在谷歌的黄金信号. 延迟,就像一般的监视一样,感觉应该很容易收集——在服务器上的代码路径的开头启动一个计时器,然后在最后停止它。然而,大多数工程师可能对最后一句话感到畏缩,因为很少有系统如此简单。例如,在OkCupid中,一个普通的用户请求经过负载均衡器和ssl终止层、几个不同的服务(通常在不同的服务器上),有时还经过数据库,然后才能返回给用户。一个可能的解决方案是实现一个分布式跟踪系统。除了捕获端到端的延迟外,它们还有一些非常大的好处,但也有很多复杂性(以及对运行非常热的服务的潜在性能影响),这使得实现一个生产就绪的分布式跟踪系统变得有点长。相反,我们选择利用我们的基础设施中已经存在188bet金宝搏官网的两个软件,HAProxy和Fluentd(特别是td代理版本),这为我们提供了一个相当好的延迟度量,而且风险和工作量都小得多。

HAProxy是一个很好的获取延迟的地方,因为它提供了一个稳健的指标集. 正如这篇关于媒体的文章,对于延迟,助教尤其有用,因为这样可以测量:“HTTP请求的总活动时间,在代理接收到请求头的第一个字节和响应体的最后一个字节之间。”前面提到的文章实际上是我们迈出的伟大的第一步,我们从HAProxy配置和最初的Fluentd配置开始,您一定要检查它出去!我们很快就遇到了两个路障。第一个问题是什么时候打开httplognormal公司我们的日志文件被大量的请求淹没,十分钟内就被填满了。发生这种情况的原因是,以前我们将错误记录到日志文件中,这些日志文件可以发送到Scalyr或其他来源。如果我们想通过fluentd从HAProxy获得我们的度量,我们还需要开始通过fluentd将我们的错误记录到文件中,这意味着我们需要在fluentd中添加一个额外的步骤来过滤错误并记录它们,或者接受我们将失去一些我们不愿意妥协的可观察性。我们的下一个问题是,我们希望能够在Grafana中绘制每个端点的延迟。我们的HAProxy后端处理成百上千个不同的端点,因此,如果不能按端点的请求进行拆分,那么我们的延迟度量将非常模糊,实际上对我们没有用处。这意味着我们需要解析实际的请求,所以我们必须修改tomfawcett提供的regex。
为了通过Fluentd处理错误解析,我们添加了记录\u修饰符块以拉出状态代码:
状态代码
然后,在构造直方图之后,我们添加了一个重写标记筛选器块以过滤错误并记录它们:
日志错误
第二个问题有点复杂。我们回到绘图板上,决定将请求捕获组分为三组:HTTP动词(在空格前为一个单词)、HTTP请求(在空格前为任何单词)和HTTP请求版本(在空格前为HTTP\d.\d)。这是一个相当幼稚的第一关,很快就让我们失望了;我敢肯定,一些普罗米修斯迷看到了这一关的走向。我们没有拆分请求和参数/费率卡?国家代码=美国和像这样的请求是不一样的/比率?国家代码=英国这将导致我们获取的延迟度量数量激增,最终导致本文顶部讨论的场景。因此,我们将HTTP请求组分为两组:请求\u uri请求\u参数(以a分隔)?). 这似乎工作得很好,但我们遇到了另一个问题:对于某些端点(比如我们的概要文件端点),用户的概要文件uuid是路径的一部分,会导致更多的碎片。所以我们在系统中添加了一个过滤器请求\u uri捕获组以筛选出任何单独由/[0-9]/:
正则表达式
这似乎奏效了一段时间。直到我们遇到下一期,我们生成了太多的时间序列,导致Prometheus花费很长时间来刮取端点,导致我们需要在增加刮取时间和延迟监控解决方案(可能是无限期的)之间做出决定,或者需要时不时地重新启动Fluentd(我们在容器中运行Fluentd,所以这可能已经发生了)实际上这是一个合理的方法,但我们认为它感觉有点太黑)。我们发现,这是由于一些请求仍然嵌入了用户的用户名(这被我们否决了,很可能是用户使用书签链接造成的),或者包含了其他我们并不特别感兴趣的信息。这使我们试图设计一种方法来编辑请求\u uri请求\u参数. 我们不想编写自己的过滤器,所以我们使用了一个嵌入在record\u修饰符中的小ruby函数:
过滤器列表
这个清单需要一点监控,并逐渐扩大,但我们得到了一些我们满意的结果。然后,我们将这些指标导入到Grafana中,并创建了一些漂亮的图形来可视化我们的端点,这些端点可以通过端点、状态代码或服务器进行过滤:
格拉法纳

这是一个非常有趣的项目,它让我们深入了解了端到端的延迟以及我们收到的一些有趣的请求。其中有些只是有趣的一看;例如:有一天,我们有约100个不同的变化的请求okcupid.com/赌场(虽然爱情有时像赌博,但我们绝对不会开赌场)。其他时候,这可能会说明对漏洞模糊化的实际尝试;例如:我们经常看到明显在寻找sqldumps或openadminer端点的请求。我们还可以了解返回500的请求数,并对这些请求数的增加发出警报。我很想听听你是如何监控延迟的,如果你利用HAProxy指标进行其他有用的监控,或者你只是想188bet金宝搏官网打个招呼!