该日志记录了系统的行为，该行为在理解系统，诊断问题，辅助审核等方面具有极为重要的作用。通常，最近时期内的日志访问频率是最高的。我们通过聚合日志分析日志并汇总数据，以帮助开发，操作和维护，并且DBA了解业务的状态和行为。此实践是基于MySQL的包装日志。当前的系统不足以支持新的需求，并且需要重建日志分析系统。
现有的包装系统将抓取和分析MySQL请求向ClickHouse请求的所有SQL语句，并且数据可用于分析数据库操作。可以回收资源，并且可以回收辅助审核。
嗅探器捕获软件包后，将数据写入Kafka，然后Clickhouse直接在Kafka队列中消耗数据，然后将数据合并到ClickHouse中。服务器程序根据天空级别定期在Clickhouse中读取数据，分析，分析，分析，总结数据，并分析与请求IP相对应的服务信息。最后，结果写入MySQL。
当前数据是日志数据，它允许损失或重复的一小部分。KAFKA队列中的数据约为133W/s（单个队列为33W），而在MySQL中存储的结果约为4.6T。
AppCode：服务的名称是服务的基本属性
Clickhouse：用于在线分析的列数据库（OLAP）
KAFKA：高性能分布式队列服务
动物园管理员：分布式开源协调服务
扩展：当业务量增加时，该服务可以通过较低的价格满足对业务量增长的需求
塑料比率：基于相同的纬度，n个数据汇总为m，在聚集之前，m必须小于或等于n.data编号
消耗能力不足会导致Clickhouse消费kafka队列中缺乏数据，并且延迟很高，而Kafka中的数据仅保留3小时。KAFKA队列中四个节点的四个节点的四个节点所消耗的数据消耗，大约80％的数据丢失，导致数据不完整。
不准确的服务信息计算是天堂 - 级计算要求的服务信息。由于服务已在云中部署在云中，因此单个服务的IP更改非常频繁，导致服务信息的服务信息延迟（向上）到24小时），即使是许多计算的结果也是错误的。在某些情况下，这导致了分析的数据完全令人难以置信。
摘要数据很小。目前，总结了请求数据的四个维度，只有一天级别的数据，大粒径，无法钻取特定信息，显示的维度和详细信息较少。
服务监视和可用性服务器节点目前只有一个，并且由于缺乏可用性，没有详细的监视信息。
对于当前服务的缺点，设计一组服务需要当前的日志计算性能和业务需求，并且具有良好的可扩展性。
高性能，高可扩展性和高可用服务需要以下特征：
在资源有限的情况下，高性能尽可能提高数据消耗和聚合功能，减少数据丢失的可能性，并减少数据库的延迟。
当单个或多个节点存在问题时，高可用性不会影响整个服务的可用性；
当将来的业务日志数量进一步增加时，只有通过增加部署节点或修改配置，就可以满足增长需求，而无需额外工作，就可以将其数量进一步增加。
将计算请求业务信息的延迟从请求IP减少到1分钟内获取服务信息的延迟，以确保准确性为99.9％
摘要数据和较低钻头查询的更多尺寸支持更多信息查询的维度，并在某些情况下查询中的支持。
监视提供了各种监视数据，这很方便显示服务。它可以根据监视促进定位问题。
当前的Clickhouse的消耗能力不足以通过扩展节点和调整参数进一步解决它，但是Clickhouse无法完成服务信息计算，并且OLAP类型数据库不太友好，无法更新数据，尤其是大型scale更新。您想求解[计算延迟的计算请求业务信息]，此问题可以具有两个解决方案：
如果我们采用解决方案，它将增加嗅探器方面的不可控制性，这与在我们先前设计的设计之前，尽可能多地与嗅探器消费的最初意图相反，因此我们选择第二个解决方案。
1.总体过程设计如下：
2.模块部门
所有模块的目标：高性能，高可用，高扩展
Dubaimeta描述
因为基本服务无法提供高性能IP映射映射接口，因此需要自行实现此功能。基本服务的IP-AppCode映射信息提供的接口，获取从IP应用程序映射信息的信息流来kafka-ops队列实时合并到当前数据，并为IP贴印信息提供接口；
设计
由于Dubaimeta是一个提供基本信息的接口，因此访问的数量相对较大，并且需要提供高性能，高可用性和高可扩展性。因此，Dubaimeta需要尽可能地设计为无国籍服务。
将所有IP贴码映射数据存储在MySQL中，并映射到最新版本中。所有IP贴码更改也将存储在mysql.continue中，通过版本信息，在最新版本中，IP-AppCode信息在当前的总体卷中，IP应用程序数据不大，它可以在不使用其他缓存的情况下在服务内部缓存。这不仅可以减少网络和缓存请求，减少时间耗尽的请求，还可以避免缓存依赖性的性能和可用性。这样，Dubaimeta可能会成为接近无国籍服务的服务。
如果单个请求无法达到缓存，则基本服务的IP插件接口将请求基本服务，并将数据合并为缓存。但是，但是如何与单个dubaimeta节点数据与所有节点数据保持一致与其他Dubaimeta节点的交流结束？
有两种解决方案：
尽可能确保单个节点的高性能，并检测单个节点的数据一致性延迟，及时删除了问题防护服务。通过这种方法，您可以最大程度地减少数据的不一致性引起的问题。因此，选择[更改通知]的方法；
开始过程
当服务启动时，信息流将从kafka-ops持续订阅，所有更改信息合并了内部的缓存，然后连续订阅从self-kafka-ops.data信息的变更信息流，结合所有数据合并全部数据。等待直到所有数据合并完成，并且两个Kafka队列未累积。
绩效分析
目前，基本信息的数据量不大，可以在不使用其他缓存的情况下将其在服务中缓存。它可以降低网络的时间消耗和访问缓存，从而大大降低请求的时间消耗，也可以避免由于对缓存的依赖而导致的性能和可用性。
单节点IP映射映射更改将启动更改通知。其他节点的异步通知，没有其他节点需要感知，因此可以保证性能。
可用性分析
Dubaimeta当前拥有所有存储在本地缓存的数据，并在MySQL中存储一个副本和更改信息流。
因为Dubaimeta靠近州，部署多个节点，并通过负载平衡服务发送不同的节点，以确保整体服务的可用性。
MySQL通过平台的现有HA，以确保可用性；
扩展分析
由于dubaimeta接近没有状态，因此可以水平扩展，不会影响其他节点。它只需要在负载平衡器中添加节点。
Snifferserver描述
从kafka-sniffer队列中获取日志数据，补充日志中的各种业务信息，并汇总数据。最后，将聚合后的结果分批写入Clickhouse。
由于队列中的数据量相对较大，因此所有数据不能全部存储，并且根据一定维度需要聚集数据。通过减少聚合比（聚合之前的数据数/数据编号的数量）在聚集之前，可以减少总体数据量，并且在确保性能的前提下，应尽可能缩短进入仓库的时间。
由于Clichouse是OLAP分析类型的列数据库，因此建议在批处理中提高数据库的写作性能（不少于1,000）。
设计
对于单个队列，多个SniferServer可以使用相同的消费组消费数据来确保消费者的性能和可用性。同时，Sniferserver也具有一定的可扩展性。
SniferServer是用于内存消耗和CPU消耗的服务。为了减少GC和内存消耗，通过重复使用对象，单个服务中的内部对象数量不会波动，这可以大大减少GC和内存的数量，并改善表现。
根据该功能，SniferServer分为三个模块：消费者模块，聚合器模块和作者模块。
消费者模块消费者队列中的数据将数据传递给聚合器模块。聚合器模块填充业务信息并汇总数据，并且聚合数据将传递给作者模块。作者模块将数据分批写入Clickhouse。
功能：从Kafka-Sniffer队列获取数据，然后在数据组合后将数据传输到聚合器模块
分析：对于单个Kafka队列，消费速度是：
测试后，在当前场景配置下，通过33W/s（两个SniferServer）的消耗速度可以达到20W/s+。可以通过消费者的调整完全满足业务需求。
功能：接受来自消费者的数据并获取IP映射映射信息和业务信息，补充信息记录数据。在一定量的数据或加班后，根据指定的维度汇总了此批次数据汇总作者模块
分析：
1.如果每个数据需要通过界面获取IP映射映射和业务信息，则将大大降低聚合的效率。因此，有必要在本地缓存IP应用程序和业务信息。聚合器模块还需要订阅Kafka-ops和self-kafka-ops更改，并将IP-pappCode合并为本地缓存。
2.通过增加聚合螺纹的数量，它可以有效提高聚合的效率。但是，线程数的数量越多地增加了聚合比（与业务行为有关）的程度在不同程度上。通过增加单批次的数量，可以减少聚合比。需要根据需要对两个指标进行测试；
测试：对于同一队列中的数据，单个SniferServer的聚集比约为10％-20％，两个SniferServer的平均聚合比约为15％-30％，而三个Sniferserver的平均聚合比大约大约约15％-30％。超过30％，因此在同一配置中添加SniferServer将增加聚合比率，并且存储端将增加数据量。
功能：在内存中接受来自聚合器模块的数据和缓存。当缓存数据超过n件或缓存时间超过m秒时，缓存数据以批量写入Clickhouse；
分析：每批都应在编写数据之前尽可能多地缓存数据量，提高写作效率，减少写作次数的次数，并预设单个批次为1W（最小值，配置）数据；
分析
每个模块都可以设置线程和并行线程的数量，并且可以改进缓存和并行线程的线程数。出乎意料地终止，丢失的数据将变得更多，并且需要考虑适当的每个参数的配置。
每个模块的开始和闭合顺序需要额外关注。
首先启动Writer模块，初始化作者模块的缓存和线程，然后启动聚合器模块，初始化聚合器的缓存和线程，最后启动消费者模块以初始化消费者模块的线程和缓存。
为了减少数据丢失，当服务正常关闭时，需要按以下顺序关闭该模块
扩展分析
由于SniferServer是一种部分计算类型，从Kafka到Sniferserver到ClickHouse，因此大量数据传输需要更好的CPU和网卡，以使Sniferserver的性能充分发挥作用。
Sniferserver的内部可扩展性：嗅探器的每个模块都可以通过设置线程数和高速缓存大小来提高性能；
SniferServer -Level可扩展性：对于单个队列，由Kafka限制的分区数量最多是同时运行的嗅探器数量。当分区数超过分区数时，节点不再参与队列消耗；
Kafka的分区：单个Kafka群集的分区在理论上没有限制。它仅限于服务器资源，动物园管理器以及操作和维护的便利性。需要上限；
整个服务：您可以将日志数据计划为不同的IDC的不同KAFKA，以便对日志数据进行分区；
可用性分析
Sniferserver通过消费组在Kafka队列中消耗数据。通过冗余Sniferserver，即使单个Sniferserver挂断电话，也不会影响整体服务。
snifferanalyze描述
根据天堂级定期从Clickhouse获取汇总数据，分析，总结，存储分析结果并提供界面和页面显示结果。
设计
分析摘要后的结果分为两种类型的数据。第一类是初步聚合的粗大尺寸数据，数据量相对较大。一旦生成数据，它将不会被修改，只有大尺度删除，通常是可追溯性，分析和钻探询问和使用和使用，使用频率不是很高；第二类是摘要报告数据。一些数据将进行大规模修改，更加并发查询。总体数据量比第一类数据相对较小。通常，结果和接口查询更多。
Clickhouse的单表查询和大型存储中的写作效率很高，压缩效率很高，但不擅长进行并发查询和频繁的修改数据。官方网站建议它查询每秒100次。比较，MySQL适合存储小体积数据，以及数据添加，删除和调查，并且擅长于高和查询。
全面考虑可节省存储成本和各种存储的特性。第一类数据适用于单击室中存储，第二种类型的数据适用于存储在MySQL中。设置原始日志数据的适当到期时间，超过指定时间的数据已删除，并摘要与原始数据量相比，数据已大大减少，该数据量可以保留更长的到期时间。
依靠陈词滥价的分析能力，第一种数据分析千篇一律的数据直接进入Clickhouse以避免中间储层。写入mysql。
您需要在执行每个任务之前获得锁定。只有成功获得的任务才能执行任务。Sniferranalyze多个节点将通过在执行任务之前抓取任务来获得任务锁。只有当成功获得的节点才能执行任务，以确保执行不影响分析任务的单个节点。但是，如果任务是在终端的中间执行的，那么当前需要进行中间的介入。
扩展分析
目前，分析类型类型的扩展能力有限。
可用性分析
由于分析类型的任务扩展能力有限，只能在节点之间保证它。一旦任务执行中断需要人为干预处理。
ClickHouse描述
Clickhouse架构图
例如，图标Clickhouse有两个碎片（A和B），每件都有两个副本（[A1，A2]，[B1，B2]）。
Clickhouse群集复制引擎的副本由Zookeeper实现，数据块的元数据信息由Zookeeper.FILM A存储。FILMA有两个节点：A1和A2，A1和A2共同监视节点中的数据中的数据。Zookeeper的目录。当A1节点写入数据块时，A1变为Zookeeper上的更多元数据信息。A2收到Zookeeper的元数据更改后，它发起了通知，将指定的数据块拾取到A1。A1将指定的数据块发送到A2以完成数据传输。以相同的方式，A2还可以编写数据以告知Zookeeper更改数据并将数据传输到A1。数据同步是异步的，并且在传输时会很重有关数据块。有关副本相关的更多信息，请参阅官方网站说明。
碎片由分布引擎实现。分布引擎不存储任何数据，Clickhouse具有数据分布，可以根据指定的规则（随机，哈希，范围，自定义）将数据分配给每个碎片。
当数据写入分布引擎中时，数据完成后立即返回数据。Clickhouse将根据规则定期将数据分配给其他节点。
当通过分布引擎查询时，无论碎片规则是什么样的，分布都会将SQL分配到所有碎片询问，总结当前节点，最后返回客户端。如果您查询复制引擎表，则仅此而已查询本地数据。
可用性分析
Clickhouse的复制引擎和Zookeeper实施数据副本，以确保可以在每件中允许副本。可以在Clickhouse的所有节点上编写和阅读分布引擎。
但是数据同步是异步的。如果节点是成功编写的，并且数据在数据未完成之前是停机时间，并且无法恢复，则尚未同步的数据块将丢失。
扩展分析
因为在查询时，分布式查询将在查询时将SQL分发到所有碎片，而不管数据的数据状态如何，因此可以将新节点直接添加到ClickHouse群集中，而不必担心旧数据迁移的问题。需要考虑数据倾斜。通过增加新节点重量的重量，您可以将新书面数据发送到新片段。
将数据写入分布引擎时，分布引擎将首先编写局部区域，然后将其转发到其他节点，这可能会导致额外CPU和IO使用的问题，当本地网络流量增加时，额外的CPU可能会导致其他节点。并在服务合并数据块时使用。您只能在不编写Distribute表的情况下仅编写本地表来解决此问题。数据倾斜问题。
监视说明
当前的监视仅用于查看每个节点的状态并显示性能问题，而无需提供高级别的功能。对公司现有监视系统的监视警报访问。
Snifferserver：
所有SniferServer节点的平均内存占用约为12G，最大GC平均值约为21ms，平均GC 75点约为0.6ms。
两个节点Sniferserver的总CPU（32核）利用率约为70％，网卡的峰值约为330mb/s下降400MB/s。
单队列数据生成速度的峰值约为30W/s，平均积累约为20K，消费者比生产者快。
聚合的平均聚合每秒1.2次，数据聚合比约为40％。作家每秒写大约6次。业务信息和AppCode HIT率几乎为100％。
页面显示：
显示某个业务的平均响应时间和查询数量
显示缓慢查询的平均响应时间和查询数
Sniferserver在队列中完成日志数据，以完成业务信息，汇总数据并将结果写入ClickHouse。snifferanalyze定期分析数据并将结果写入ClickHouse和MySQL。整个系统具有高性能，高可用性和高可伸缩性的优势，并且使用内存和CPU的使用相对稳定。日志分析提供的结果系统可以帮助您更好地了解业务行为，发现潜在的问题并评估数据库中业务风险。BARINGSBINGING SLEW查询风险指数系统可以更准确地评估慢速查询的风险。
https://clickhouse.com/docs/zh/
https://clickhouse.com/docs/zh/eble-engines/mergetree-family/replication/
https://mp.weixin.qq.com/s/kfbw5k7txdijlovkyls40a
原始：https：//juejin.cn/post/7094917968915595300