智能日志管理平台

  • logkit-pro性能对比与优化说明

    最近更新时间:2018-09-10 16:46:15

    logkit作为一款agent,我们非常关注其性能,在功能性能方面我们都与同类产品做了深入的对比。在功能上,我们也给了用户大量选择,一方面可以限制其使用的资源,另一方面可以对其进行性能调优,在需要的时候尽最大可能提升对资源的利用率。

    开源收集组件之间的功能性能对比

    该场景我们主要针对是是三个收集工具都支持的从文件读取,进行数据解析,再发送到文件的过程,读取的文件为1GB的文本文件,总体的对比结论见下表。

    logkit-pro logstash fluentd filebeat
    可视化配置 人性化的可视化配置,使用体验流畅 文件配置 文件配置 文件配置
    使用难度 可视化配置,上手简单 文件配置,上手一般 上手困难,文档匮乏 文档详细,demo较多
    数据流处理 支持 支持 支持 不支持
    可收集的数据源 丰富 丰富 一般 丰富
    中文文档 丰富
    运行时CPU占用情况 可控,默认一核以内 不可控,至少二核~三核 可控,一核以内 可控,正常二核左右
    运行时内存占用情况 100M以内 600~700M 600~700M 50M左右
    系统监控 支持 支持 不支持 不支持
    发送消息添加系统信息 支持且可按需添加 支持,强制添加 仅支持timestamp 支持,强制添加
    集群管理 支持 不支持 不支持 不支持
    售后支持 完善 一般 一般 一般
    定制化开发 支持 不支持 不支持 不支持
    开发语言 Golang Java Ruby Golang

    针对场景的功能性能对比

    在场景功能的对比测试中,我们主要针对logkit-pro发送到pandora,logtail发送到阿里云日志平台,logstash发送到Elasticsearch集群进行测试。对比结果如下。

    logkit-pro logtail logstash
    原始文件大小 1.3G(7000000条记录) 1.3G(7000000条记录) 1.3G(7000000条记录)
    运行时占用资源情况 80~90% CPU, 100M 以内 MEM 70~80% CPU, 100M 以内 MEM 80~90% CPU, 900M MEM
    耗时 5分钟内 5分钟内 50~60分钟
    历史数据收集 支持 不支持 支持
    数据处理出错解决方案 持续发送,错误日志按原始格式发送,显示错误 阻塞,报错(报错信息无法理解) 阻塞,控制台打印错误日志
    使用门槛 极低,初、高级功能均具备可视化配置 较低,高阶功能可视化支持不佳 较高,需要自建es集群
    运行时内存占用情况 100M以内 50M左右 600~700M
    输出支持 支持多种输出方案 仅支持发送到阿里云 支持多种输出方案
    数据源多重收集 支持 不支持 支持
    开发语言 Golang C/C++ Java
    注意 - logtail收集方式对于阿里云的ECS支持较好,而对于线下机器的支持并不友好 -

    测试环境信息:

    
    CPU型号 : Intel(R) Xeon(R) CPU E5-2403 0 @ 1.80GHz\*8
    CPU核心数 : 4 * 8
    CPU线程数 : 1 * 8
    Memory信息 : 94GB
    Medium Type : Physical
    
    

    以下是表格一中结果的详细实验数据。

    注:由于filebeat仅支持数据收集,对于数据流的处理需要和logstash配合使用。

    按原始文本逐行解析:

    logkit-pro logstash fluentd filebeat
    用时 70s 68s 206s 143s
    原文件大小 1.3G 1.3G 1.3G 1.3G
    生成文件大小 2.2G 2.2G 1.6G 3.8G
    运行占用资源 51.0%CPU,83M+ MEM 247.0%CPU,646M+ MEM 98.0%CPU,54M- MEM 211.5%CPU,13M MEM
    启动占用资源 同运行时 304.0%CPU,702M+ MEM 同运行时 同运行时
    注意 - - - 默认会添加许多系统字段

    按固定分隔符(csv)解析

    logkit-pro logstash fluentd filebeat
    用时 62s 226s 794s 301s
    原文件大小 913M 913M 913M 913M
    生成文件大小 1.5G 2.5G 1.3G 3.6G
    运行占用资源 85.9%CPU,79M MEM 247.0%CPU,581M- MEM 98.0%CPU,48M- MEM 205.9%CPU,685M MEM(total)
    启动占用资源 同运行时 301.0%CPU,505M+ MEM 同运行时 同运行时
    注意 - 默认添加额外系统信息,不可配置 - filebeat不支持对数据的parser 和transform操作,需要配合logstash使用

    按正则表达式(grok)方式解析

    logkit-pro logstash fluentd filebeat
    用时 173s 150s 187s 210s
    原文件大小 913M 913M 913M 913M
    生成文件大小 1.5G 2.6G 1.3G 3.5G
    运行占用资源 96.5%CPU,78M+ MEM 119.1%CPU,520M+ MEM 95.3%CPU,62M- MEM 219.2%CPU,716M+ MEM(total)
    启动占用资源 同运行时 305.5%CPU,534M+ MEM 同运行时 同运行时

    logkit-pro 资源限制与性能调优

    logkit-pro 与社区版 logkit 在资源限制和性能调优方式上基本一致,以下描述统一使用 logkit。

    计算机上的主要资源大体可以分为四类,CPU、内存、磁盘以及带宽,分别对应了程序的计算量、分配和使用的内存、磁盘IO读写速率以及网络传输量。

    CPU: 在logkit的使用场景下,通常CPU是最先达到瓶颈的,比如日志的解析规则非常复杂,或者配置了较多的转换,此时这类操作对运算量要求较高,就会耗费较多的CPU。

    内存: 其次到达平均的可能是内存资源,如开启了文件读取,并且命中了非常多的小文件,此时就会打开较多的句柄,并且每个文件读取时都会在内存中对数据进行一些缓存;
    也有可能读取的文件数据量非常大,读取速率很高,此时由于程序存在数据交换,内存中会分配很多小的对象,虽然随着GC(垃圾回收机制)不断运转,会形成一个动态平衡,但是若数据量大,总量会占用的比较高。

    带宽: 带宽有可能很难达到瓶颈,但也有可能最先达到瓶颈。查看带宽是否达到瓶颈的方法非常简单,只要粗略的计算单位时间内数据传输的总量,然后和带宽总大小对比就知道了。如果是公网带宽,相对来说比较容易达到瓶颈,成本也较高,此时一般都采用GZIP之类的压缩传输节省带宽。

    磁盘: 这里的磁盘通常指磁盘IO, 一般情况下磁盘IO不会成为瓶颈,但是对于某些特殊情况,如机器上积攒了大量的历史日志,若一下子把这些历史数据全部读取发送就有可能导致磁盘IO过高,这方面,logkit默认开启了 20MB/s 的资源限制,防止此类极端情况发生。

    资源限制

    CPU: 对于 CPU 的限制,我们在 logkit 的主配置文件 logkit.conf 中给了全局的开关, 该配置为 logkit 占用系统 CPU 资源的上限。

    主配置文件中有 runtime -> max_procs 一项,该项配置控制了 logkit 整体使用的 CPU 数量,默认为1,当您希望限制使用的核数时,配置为您希望限制的数量即可,当您希望提高使用量时也是相应修改。

    {
      "version": 1,
      "service": {
        "bind_host": ":3000",
        "static_dir": "public",
        "upload_dir": "data/upload"
      },
      "service_url": {
        "smart_elf": "https://logkit-pro.qiniu.com/"
      },
      "runtime": {
        "max_procs": 1
      },
      "security": {
        "disable_auths": false,
        "auths_file": "auths.conf"
      }
    }
    

    内存: logkit 对内存没有特殊的限制配置,但是本身对内存的使用做了一定程度的优化,正常情况下,没有任何收集任务的话,占用内存在 50MB 以内,仅配置了一个收集任务的情况下,内存资源使用量应该也在 100MB 以内。

    磁盘: logkit 为文件读取设置了磁盘IO的限制功能,默认情况下为 20MB/s, 你可以在文件读取中配置 读取速度限制(readio_limit) 参数进行修改。
    若某些功能使用了 logkit 的磁盘队列,写入磁盘队列的 IO 也可以通过 磁盘写入限速(ft_write_limit) 限制, 默认的写入速度限制为 10MB/s

    带宽: 带宽的限制主要在各个发送端,logkit在几乎所有发送都设置了发送的压缩方式,如七牛智能日志管理平台的 压缩发送(pandora_gzip) 功能, http发送的 是否启用gzip(http_sender_gzip) 功能等。
    同时在发送到 七牛日志管理平台 时,我们还增加了 流量限制(flow_rate_limit) 和 请求限制(request_rate_limit) 功能,允许用户限制每秒发送的流量和请求数,logkit采用令牌桶算法进行限流。

    性能调优

    从本质上讲,性能调优是使得程序可以充分利用系统资源的过程。所以他涉及到系统的各个方面,是一项系统性的工作,需要对机器上各个部分的资源有相对清晰的了解。

    与资源限制相反,性能调优需要逐一将资源限制项放开,或者说调高其限制。让我们按瓶颈出现的可能性逐一讲解功能配置方法。

    查看程序对CPU用量的常见命令如: tophtopps aux
    查看程序内存用量的常见命令如: tophtopps aux
    查看磁盘IO的常用命令如: iostat -x 10iotop
    查看网络带宽的常用命令如: iftopnetstat

    CPU

    如资源限制一节中所述,首先要调高 logkit 的主配置文件 logkit.conf 中针对 CPU 使用核数的整体开关,mac_procs 该参数理论上限为机器的逻辑核数,可以根据机器的配置调整,若不确定机器具体核数,写大了也没有关系。

    注意,主配置文件调整后,要重启 logkit 才能生效。

    调整了 logkit 整体可以使用的核数以后,就要想办法让程序利用上多核,在主配置的多核开启后,解析和转换会自动利用上多核能力,除此之外,还可以进行一下优化。

    1. 多线程发送, 发送端的多线程功能,可以充分利用CPU多核的能力,提升发送效率。这一点我们设计三种多线程发送方式。
      • 纯并发发送,不经过任何队列,纯开启多线程并发发送。对于发送的CPU是性能瓶颈的情况下尤为有效。设置策略(ft_stategy) 为 并发发送(concurrent),配置并发数量(ft_procs), 设置为 "2",就是开 2 个并发发送,速度就能大大提升。
      • 磁盘队列并发,先保存到磁盘队列,再并发发送,使用磁盘队列主要便于读取和发送异步化,有利于发送需要大批量发,读取快的情况,发送可以攒一批数据发送。该功能适合接受数据的服务端能承受的单次请求数据量较大,而单次请求响应较慢的情况。设置策略(ft_stategy) 为 磁盘队列缓存发送(always_save),则所有数据会先发送到本地队列, 同样需要配置并发数量(ft_procs), 设置为 "2",就是开 2 个线程在磁盘队列后并发发送。
      • 内存队列,原理类似磁盘队列,但是在程序被强行中断时存在数据丢失风险,性能上比磁盘队列更优。配置上与磁盘队列相同,额外配置 ft_memory_channeltrue 即可。
      • 默认策略(ft_stategy) 是 backup_only, 数据不经过本地队列直接发送到下游,一旦出现发送错误,则报错到本地队列等待重试。
    2. 多线程读取,一般情况下,读取文件时CPU不会成为性能瓶颈,而读取消息队列如kafka,则可能因为单个线程读取导致平均,可以考虑通过配置多实例(即多个收集任务,每个收集任务配置同一个consumergroup就可以保证数据不重复收集),来进行并发消费。
    3. 上述针对CPU的配置调整完成后需要重新分发到对应的agent执行,若观察一段时间后,发现使用的CPU已经占满,并且发送速率依然较慢,极有可能是配置的解析和转换较多或者性能较低,此时可以从解析方式或者转换方式上考虑优化,如能用csv的转换就不用grok等等。当然,数据量大的情况下发送时使用压缩功能发送也极有可能消耗较多CPU,但是一般情况下不建议关掉压缩功能,因为带宽资源通常比CPU资源更珍贵。

    内存

    一般情况下,内存不会成为性能瓶颈,但是内存如果超过系统限制,程序会直接OOM重启,所以有时也需要对内存进行一些调优。

    通常情况下程序内存占用高往往由于以下几个原因导致:

    1. 使用了如 tailxdirx模式收集日志,并且命中的日志文件/文件夹过多。此时可以考虑设置短一点过期时间(忽略文件的最大过期时间expire),只关注最近有数据追加的文件即可。
    2. 程序开启的收集任务过多或单个收集任务收集的数据量极大,因为收集任务多会导致程序中缓存的数据量变大,这种情况下可以适当多给程序一些内存。

    磁盘

    对应磁盘IO的限制,把相应的限制调大即可。你可以在文件读取中配置 读取速度限制(readio_limit) 参数进行修改。
    若某些功能使用了 logkit 的磁盘队列,写入磁盘队列的 IO 也可以通过 磁盘写入限速(ft_write_limit) 调整, 默认的写入速度限制为 10MB/s
    若查看发现磁盘IO的使用率已经相当高了,那可能机器本来就运行了重IO的应用,此时应该关闭一些使用磁盘的功能,如磁盘队列等。

    带宽

    带宽基本上没有什么调优空间,把相应资源限制中的限制去掉即可。如果带宽使用率达到了您带宽大小的上线,那么就需要调整带宽了,或者看看能否采用压缩发送等功能。

    以上内容是否对您有帮助?
  • Icon free helper
    Close