"每一个氏族和每一个埃奎拉的multa"[1]对CloudFlare的请求生命周期从边缘开始到结束。但是来世！与Catullus到Bithynia一样，由HTTP请求或DNS查询生成的日志还有很多很多要做。本文来自CloudFlare的数据团队。它报告了处理这些边缘日志的状态，包括哪些对我们很有效，以及自我们2015年4月的上一篇文章以来仍然存在的挑战。数字，感觉在边缘网络中，HTTP和DNS客户端连接到分布在世界各地的数千台服务器，关键在于将这些服务器分布在许多精心挑选的存在点上，并且有超过85个pop，没有任何网络比CloudFlare具有更好的表现力。然而，对于我们的网络日志来说，这种分布的相反情况必须发生。在anycast将请求（和查询）分散到边缘的数千个节点之后，数据团队的工作就是将生成的日志收集到少量的中心点，并将其合并以便于客户使用。上面的图表描述了昨天（7月11日）从边缘发送到这些中心点之一的总结构化日志（由于计数器重置而产生的一些伪影）。昨天我们看到：平均每秒360万个HTTP日志，峰值超过450万个日志/秒平均每秒750K个DNS日志，峰值超过1M日志/秒这是一个典型的、普通的一天，边缘在任何给定的一分钟内提供数百Gbps的服务，并且在任何给定的小时内传输超过1.28亿个不同的IP地址。这样的一天会产生将近360TB的原始Cap'n事件日志。代理这些数据需要两个Kafka集群，包括：1196芯，170个10G网卡，10.6TB内存，以及4.3PB磁盘。卡夫卡的下游拥有大致相同数量的硬件，有些在Mesos+Docker和HDFS之间共享，有些完全专用于CitusDB等服务。我们预计到2016年底，这些数字将大幅增加。有用的东西（不会坏的）在这个系统中什么工作得很好，为什么？还有更多，但空间只允许命名五个事物。日志转发器。上面的图使用了运行在边缘的日志转发服务的所有实例的度量。这个内部软件用go编写，在边缘（来自nginx和我们的DNS服务）和管道的数据中心端处理结构化日志。它的插件架构使得添加新的日志类型和Kafka端点变得非常容易，而且由于我们从它收集的关于入口、删除和缓冲区大小的指标，我们对它的操作有了很好的可见性。卡夫卡。CloudFlare运行着几个Kafka集群，其中一个集群只有不到80个代理。尽管有些故障模式仍然很难自动化，但市场上没有其他产品可以满足我们的需要，而且它每天都能做得非常好。持久性，并且在很大程度上改进了HTTP检索，用于日志共享。CloudFlare使用专用的Kafka消费者、HDFS和一些go服务为企业客户（称为log Share或ELS）提供日志存储和检索。多亏了更多的监控，提高了对多种网络故障的恢复能力，更好的运行手册，以及大量的艰苦工作，如今的日志共享比2015年底提供了更好的可用性。（团队中的每个人以及其他许多人都写了这篇文章，值得自己在文章中详述。）美国CITB。数据中心中没有什么东西比分片PostgreSQL更有魅力，但citudb作为一种性能卓越且易于管理的服务，可以持久化聚合数据。它的支持非常好，而且实际上它是"只是PostgreSQL"，这大大简化了citudb主版本的零停机升级和迁移到一个全新的集群。平台和SRE！如果没有Data的姊妹团队平台团队的辛勤工作，这些部分都无法正常工作。我们非常幸运地拥有一些最好的工具，包括用于度量的OpenTSDB+Grafana、用于警报的Prometheus、用于异常报告的Sentry、用于日志的ElasticSearch+Kibana、用于编排的Marathon+Mesos+Docker以及用于负载平衡的nginx+zoidberg。同样，我们也非常感谢CloudFlare出色的SRE，他们继续与我们合作，使数据中心成为一个可靠和高效的工作场所，尽管它与edge不同。还有什么要做的我们希望在不久的将来改进或期望增加什么？时间而不是空间限制了这些。粗略地说：为客户提供更可靠的服务。这项工作包括许多小事情，从更好的运行手册和自动化到容量规划和对现有架构的批量更新。它运行着一个连续统一体，从外部服务，如日志共享（logshare）到内部服务（内部服务完全是为了提高边缘的自动化和可视性）。新的分析。客户依赖CloudFlare了解边缘发生了什么。我们今天正致力于为CloudFlare的所有产品构建分析系统，并扩展我们现有的分析方法，以便它们能够告诉客户更多他们需要的东西。我们在这些新系统中使用的大部分技术仍然有待开发，尽管我们有一项技术（每秒处理100万个DNS事件日志）是Spark Streaming。新的数据管道。客户和CloudFlare本身都需要能够从一点到另一点获取请求和查询日志的系统。这种管道包括将原始日志推送到客户的外部管道，以及允许我们在数据中心之间推送日志以进行灾难恢复的内部管道等。更好地支持复杂分析。最后，总会有客户和内部用户需要更强大的工具来分析大规模的高维数据。让人们更容易地编写这样的分析，无论是从UI还是在作业运行于集群时，都是一个巨大的挑战，我们期待着证明这一点。对于所有这些服务，必须建立这样它们才能为所有人服务，一个关键的挑战是确保设计（1）对客户有效，以及（2）可以在经济数量的节点中实现。我们尽可能地构建在几十到几百个节点上性能良好的解决方案，而不是数千个节点。直到我们再次见面在这篇来自数据团队的帖子中，我们讨论了什么是有效的，以及我们希望下一步做什么。我们也想和你谈谈！如果你对这篇文章有什么想法，或者你希望数据团队接下来写些什么，请告诉我。另外：CloudFlare的数据是一个小团队，因此如果您对这些问题感兴趣，那么您将面临一些重大问题需要解决。查看系统软件工程师的数据和数据分析师角色，让我们知道你的想法。最后，如果您要去GopherCon，CloudFlare本周将有三个gopher参加，其中一个来自数据团队，Alan Braithwaite@Caust1c（许多很多数据服务，包括今天的所有生产服务，都是用go构建的。）快来看我们！"穿越许多民族，跨越许多海洋，"卡图勒斯101的开头。↩︎