cloudflaredns解析解析域名工具


cloudflaredns解析解析域名工具

Cloudflare已经有一个用于HTTP日志的数据管道。我们希望DNS分析工具可以利用该功能。每当边缘服务处理一个HTTP请求时,它就会以CapnProto格式生成一个结构化的日志消息,并将其发国际快递本地多路复用服务。考虑到数据量,我们只记录部分DNS消息数据,只包含我们感兴趣的数据,例如响应码,大小或queryname,这使得我们每个消息平均只保留约150字节数据。然后将其与元数据处理(例如在查询处理期间触发的定时信息和异常)融合。在边缘融合数据和元数据的好处是,我们可以将计算成本分散到成千上万的边缘服务器,并且只记录我们需要的信息。

多路复用服务(称为“日志转发器”)正在每个边缘节点上运行,从多个服务组装日志消息并将其传输到我们的仓库,以便通过TLS安全通道进行处理。运行在仓库中的对应服务将日志接收并解分解到几个ApacheKafka集群中。ApacheKafka用于生产者和下游消费者之间做缓冲,防止消费者故障或需要维护时的数据丢失。自0.10版本以来,Kafka允许通过机架感知分配副本,从而提高对机架或站点故障的恢复能力,为我们提供容错的未处理消息存储。

拥有结构化日志队列使我们能够追溯性地查问题,而不需要访问生产节点。在项目的早期阶段,我们会跳过队列并找到我们所需的粗略时间段的偏移量,然后将数据以Parquet格式提取到HDFS中,以供离线分析。

HTTP分析服务是围绕生成聚合的流处理器构建的,因此我们计划利用ApacheSpark将日志自动传输到HDFS。由于Parquet本身不支持索引以避免全表扫描,因此在线分析或通过API提供报告是不切实际的。虽然有像parquetindex这样的扩展可以在数据上创建索引,但也不能实时运行。鉴于此,最初的设计是仅向客户显示汇总报告,并保留原始数据用以内部故障排除。

汇总摘要的问题在于,它们只能处理基数较低(大量唯一值)的列。通过聚合,给定时间范围内的每个列都会扩展到很大的行数(与唯一条目个数相等),因此可以将响应码(例如只有12个可能的值,但不包含查询名称)进行聚合。如果域名受欢迎,假设每分钟被查询次,那么可以预期每分钟做聚合可以减少倍的数据,然而实际上并不是这样。

由于DNS缓存的存在,解析器在TTL期间不会进行DNS查询。TTL往往超过一分钟。因此,服务器多次看到相同的请求,而我们的数据则偏向于不可缓存的查询,如拼写错误或随机前缀子域名攻击。在实践中,当用域名进行聚合时,我们可以看到最多可以减少为原来的1/60的行数,而多个分辨率存储聚合几乎可以抵消行减少。使用多个分辨率和键组合也可以完成聚合,因此聚合在高基数列上甚至可以产生比原始数据更多的行。

由于这些原因,我们首先在zone层次上汇总日志,这对于趋势分析来说已经足够,但是对于具体原因分析来说则太过粗糙。例如,我们正在调查其中一个数据中心的流量短暂爆发。具有未聚合的数据使我们能够将问题缩小到特定DNS查询,然后将查询与错误配置的防火墙规则相关联。像这样的情况下,只有汇总日志就有问题,因为它只聚合一小部分请求。

所以我们开始研究几个OLAP系统。我们研究的第一个系统是Druid。我们对前端(Pivot和以前的Caravel)是如何切分数据的能力印象很深刻,他使我们能够生成具有任意维度的报告。Druid已经被部署在类似的环境中,每天超过亿事件,所以我们对它可以工作很有信心,但是在对抽样数据进行测试之后,我们无法证明数百个节点的硬件成本。几乎在同一时间,Yandex开源了他们的OLAP系统ClickHouse。

ClickHouse的系统设计更加简单,集群中的所有节点具有相同的功能,使用ZooKeeper进行协调。我们建立了一个由几个节点组成的集群,发现性能相当可观,所以我们继续构建了一个概念验证。我们遇到的第一个障碍是缺少工具和社区规模的规模太小,所以我们钻研了ClickHouse设计,以了解它是如何工作的。

ClickHouse不直接支持Kafka,因为它只是一个数据库,所以我们使用Go写了一个适配器服务。它读取来自Kafka的使用CapnProto编码的消息,将它们转换为TSV,并通过HTTP接口分批插入ClickHouse。后来,我们讲ClickHouse的HTTP接口替换为GOSQL驱动,以提高性能。从那以后,我们就开始为该项目提供了性能改进。我们在性能评估过程中学到的一件事是,ClickHouse写入性能很大程度上取决于批量的大小,即一次插入的行数。为了理解为什么,我们需要进一步了解了ClickHouse如何存储数据。

ClickHouse用于存储的最常见的表引擎是MergeTree系列。它在概念上类似于Google的BigTable或ApacheCassandra中使用的LSM算法,但它避免了中间内存表,并直接写入磁盘。这使得写入吞吐量非常出色,因为每个插入的批次只能通过“主键”进行排序,压缩并写入磁盘以形成一个段。没有内存表也意味着他仅仅追加数据,并且不支持数据修改或删除。当前删除数据的唯一方法是按日历月份删除数据,因为段不会与月份边界重叠。ClickHouse团队正在积极致力于使这个功能可配置。另一方面,这使得写入和段合并无冲突,因此吞吐量与并行插入的数量成线性比例关系,直到I/O跑满。但是,这也意味着它不适合小批量生产,这就是为什么我们依靠Kafka和插入器服务进行缓冲的原因。ClickHouse在后台不断合并,所以很多段将被合并和写多次(从而增加写放大),太多未合并的段将触发写入限流,直到合并完成。我们发现,每秒钟每张表的插入一次效果最好。

表读性能的关键是索引和数据在磁盘上的排列。无论处理速度有多快,当引擎需要从磁盘扫描太多数据时,这都需要大量时间。ClickHouse是一个列式存储,因此每个段都包含每个列的文件,每行都有排序值。通过这种方式,可以跳过查询中不存在的列,然后可以通过向量化执行并行处理多个单元。为了避免完整的扫描,每个段也有一个稀疏的索引文件。鉴于所有列都按“主键”排序,索引文件仅包含每第N行的标记(捕获行),以便即使对于非常大的表也可以将其保留在内存中。例如,默认设置是每隔行做一个标记。这种方式只需要122,070个标记来具有1万亿行的表格进行索引。在这里可以查看ClickHouse中的主键,深入了解它的工作原理。

使用主键列查询时,索引返回考虑行的大致范围。理想情况下,范围应该是宽而连续的。例如,当典型用法是为单个区域生成报告时,将区域放在主键的第一个位置将导致按每个区域进行排序,使得磁盘读取单个区域连续,而如果按主要时间戳排序则在生成报告是无法保证连续。行只能以一种方式排序,因此必须仔细选择主键,并考虑典型的查询负载。在我们的例子中,我们优化了单个区域的读取查询,并为探索性查询提供了一个带有采样数据的独立表格。从中吸取的教训是,我们不是试图为了各种目的而优化索引,而是分解差异并多加一些表。

这样专有化设计的结果就是在区域上聚合的表格。由于没有办法过滤数据,因此扫描所有行的查询都要昂贵得多。这使得分析师在长时间计算基本聚合时不那么实际,所以我们决定使用物化视图来增量计算预定义聚合,例如计数器,唯一键和分位数。物化视图利用批量插入的排序阶段来执行生产性工作计算聚合。因此,在新插入的段被排序之后,它也会生成一个表格,其中的行代表维度,而列代表聚合函数状态。聚合状态和最终结果之间的区别在于,我们可以使用任意时间分辨率生成报告,而无需实际存储多个分辨率的预计算数据。在某些情况下,状态和结果可能是相同的例如基本计数器,每小时计数可以通过累计每分钟计数来产生,但是对独特的访问者或延迟分位数求和是没有意义的。这是聚合状态更有用的时候,因为它允许有意义地合并更复杂的状态,如HyperLogLog(HLL)位图,以便每小时聚合生成每小时独立访问者估计值。缺点是存储状态可能比存储最终值要昂贵的多上述HLL状态在压缩时大概有字节/行,而计数器只有8字节(平均压缩1个字节)。使用这些表可以快速地将整个区域或站点的总体趋势形象化,并且我们的API服务也使用它们做简单查询。在同一位置同时使用增量聚合和没有聚合的数据,我们可以通过流处理完全简化体系结构。

我们使用12个6TB磁盘做RAID10,但在一次磁盘故障之后重新进行了评估。在第二次迭代中,我们迁移到了RAID0,原因有两个。首先,不能热插拔有故障的磁盘,其次阵列重建花费了数十个小时,这降低了I/O性能。更换故障节点并使用内部复制通过网络(2x10GbE)填充数据比等待阵列完成重建要快得多。为了弥补节点故障的可能性较高,我们切换到3路复制,并将每个分片的副本分配到不同的机架,并开始规划复制到单独的数据仓库。

另一个磁盘故障突出了我们使用的文件系统的问题。最初我们使用XFS,但它在复制过程中开始在同一时间从2个对等点进行锁定,从而在完成之前中断了段复制。这个问题表现为大量I/O活动,由于损坏的部分被删除,磁盘使用量增加很少,所以我们逐渐迁移到了ext4,该文件系统就没有这个问题。

当时我们只依靠Pandas和ClickHouse的HTTP接口进行临时分析,但是我们希望使分析和监控更容易。因为我们知道Caravel(现在更名为Superset),我们就把它和ClickHouse进行了整合。

Superset是一个直观的数据可视化平台,它允许分析人员在不写一行SQL的情况下交互地切片和切分数据。它最初是由AirBnB为Druid构建和开源的,但是随着时间的推移,它已经通过使用SQLAlchemy(一种抽象和ORM)为数十种不同的数据库方言提供了基于SQL的后端的支持。所以我们编写并开源了一个ClickHouse方言,并集成到Superset。

Superset为我们提供了特别的可视化服务,但是对于我们的监控用例来说,它仍然不够完善。在Cloudflare,我们大量使用Grafana来可视化所有指标,所以我们将它与Grafana集成并进行开源。

它使我们能够用新的分析数据无缝地扩展我们现有的监测仪表板。我们非常喜欢这个功能,因此我们希望能够为用户提供同样的能力来查看分析数据。因此,我们构建了一个Grafana应用程序,以便可视化来自CloudflareDNSAnalytics的数据。最后,我们在您的Cloudflare仪表板分析中提供了它。随着时间的推移,我们将添加新的数据源,维度和其他有用的方法来显示Cloudflare中的数据。

本文链接:/weixin_/article/details/