智能日志管理平台

  • logkit-pro 常见问题

    最近更新时间:2018-07-30 10:55:16

    登录/鉴权问题

    问: logkit-pro 无法登录数据发送失败 ,显示 access_key 或 secret_key 不正确?

    答: 请确认您的机器时间是准确的,我们的接口鉴权会根据系统时间生成,需要保证您的系统时间和实际的时间误差在15分钟内。

    配置相关

    问:修改收集器配置是否需要重启logkit-pro?

    答:

    网页操作:无需重启。

    1. 对于本地的单机版本,如果在网页上修改配置,提交后立即生效,无需重启。
    2. 对于服务器的 agent,在服务端修改配置后,需要重新分发生效。

    控制台修改文件:分情况。

    无论是本地的单机版,还是服务器的agent,我们的配置中都有confs_path 监听的目录,在主配置文件中设置了的监听目录,修改配置无需重启。
    其他目录,如默认保存前端配置文件的目录.logkitconf 修改里面的收集器配置,需要重启 logkit 后生效。

    日志读取相关

    问: 希望读取的日志在不同路径下该如何配置?

    答:可以使用 file reader 中的 tailx 模式。

    问: 如何定位 logkit Pro 读取的日志来源?

    答:

    1. 在所有 parser 中都有一个 label 功能,这个功能可以用于填写机器编号,ip,服务名、团队名称等各种各样用于区别 logkit Pro 数据来源的标签,这些标签会附加在 logkit Pro 的日志中,便于在大的方向上定位日志来源。
    2. 如果是在 tailx 模式下,一个配置文件可以读多个路径,可以使用 datasource_tag 功能,将读取的日志路径作为一个字段记录在日志中。

    问: 读取的时候带上通配符*就报错read line timeout, no data received,单个文件读取是正常的?

    答: 带 * 读取的时候,为了不使打开的句柄过多,文件会有个过期时间,默认是24小时,如果文件的最后修改时间超过了24小时,就会读取不到。如果要解决这个问题,只要将读取的模式选择为tailx,然后把 expire 的配置设置更长即可。

    日志发送相关

    问: 如何不重不漏的高效发送日志数据 ?

    答:

    1. logkit-pro sender 的默认策略(fr_stategy) 是 数据不经过本地队列直接发送到下游(backup_only),一旦出现发送错误,则报错到本地队列等待重试。
    2. 如果想要加快发送速度,可以设置策略(fr_stategy) 为 并发发送(concurrent),此时会开启多线程发送,还可以设置策略(ft_stategy) 为 磁盘队列缓存发送(always_save),则所有数据会先发送到本地队列。两者的主要区别在于 concurrent 策略会直接并发发送,不经过队列。concurrentalways_save 都可配合 ft_procs 使用。
    3. 在配置了并发策略后,可以配置并发数量(ft_procs), 设置为 "2",就是开 2 个并发发送,速度就能大大提升。
    4. 如果还嫌不够快怎么办?可以用内存管道替换磁盘队列噢。但是需要说明,使用内存队列在 logkit-pro 异常退出时有丢失数据的风险。可以设置 ft_memory_channeltrue,使用 内存队列代替磁盘队列,使得发送和数据读取解析变为异步,在发送较慢的情况下数据可以缓存在内存队列里,不阻塞数据读取和解析的过程。但是使用内存队列数据不落磁盘,会有数据丢失的风险。该功能适合与并发数量(ft_procs)参数配合使用,利用内存队列,异步后,在发送端多并发加速。

    问: 如何发送一份数据到多个数据源?

    答:

    1. 我们推荐添加多个收集器分别发送。
    2. 也支持在一个收集器里面写多个sender,但是这样做的隐患是一个sender发送缓慢会阻塞所有的发送。

    问: 发送到 Pandora 的数据变化怎么处理?

    答:

    1. 在发送到 Pandora 的过程中,如果数据字段有增加,只要配置 sender 的 pandora_schema_free 为 true 即可,会自动识别并更新数据源的 schema。
    2. 发送到 Pandora 的数据,类型不能被 logkit Pro 自动判别怎么办? 此时在配置 pandora_schema_free 的情况下,再配置一下 pandora_auto_create, 只需要填写那些特殊的类型即可,比如 fieldx jsonstring,其他字段依旧可以通过 pandora_schema_free 自动更新。
    3. Pandora 不接受的字段名称如何处理呢? 在 ELK 中,常见的就是 @timestamp,但是 @ 符号,Pandora 是不支持的,此时只要使用 pandora_schema 字段配置一下 pandora 的别名即可,如:"@timestamp timestamp,..."。同样不支持的符号还包括中划线、竖线等,目前 Pandora 支持的符号是数字、字母以及下划线。
      注意最后要填写,... 表示其他字段都要。因为 pandora_schema 除了别名功能以外,还支持字段的选择,如果不加",..."则表示其他字段都不选。

    问: 发送出错的数据会被怎么处理?

    答: 默认情况下会放到 pandora_stash 字段。如果发送出错的数据大于 2M, 会进行切片发送,切片大小为 64KB, 如果在发送出错的数据的 key value 中找到 string 类型的 value 大于 2M,则对该 string 类型的 value 进行切片,尝试发送。否则对于该 value 进行 marshal 之后进行切片,放入 pandaora_stash 中。进行切片的数据会自动增加 pandora_separate_id 记录该切片的顺序,pandora_separate_id 的值为 separateId + "_" + separateDataKey + "_" + idx,其中 separateId 是随机生成的值,separateDataKey 为该切片 value 的 key, idx 为该切片在原始数据中的顺序。

    问: 使用logkit发送报错?
    Invalid args, argName: Schema, reason: invalid field key: @timestamp, RequestId=, failDatas size : 1

    答:目前智能日志管理平台的字段命名规则为: 长度在1-128个字符内,支持小写字母、数字、下划线;必须以小写字母开头。 其中@timestamp包含了@符号,不符合要求,所以无法创建。

    解析日志相关

    问: 解析出错的数据会被怎么处理?

    答:默认情况下,解析失败的数据会默认出现在 pandora_stash 字段, 除非在解析 parser 部分,配置 disable_record_errdatatrue,该选项可以禁止记录解析失败的数据。

    性能相关

    问: 如何限制/提高logkit-pro使用的CPU资源?

    答: 主配置文件中有 runtime.max_procs 一项,该项配置控制了logkit-pro整体使用的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"
      }
    }
    

    问: 读取、发送慢怎么提升?

    答: 读取、解析、发送跟实际的配置关系较为紧密,请参考各个模块的配置选项,可以关闭一些性能消耗大但您实际不使用的功能进行一些性能优化。
    除此之外,还要查看机器的资源是否已经达到瓶颈,主要查看: CPU内存磁盘IO网络带宽这四项。
    一般情况下,读取文件的速度不会成为性能瓶颈,而读取消息队列如kafka,则可以考虑通过多实例(多个runner)配置同一个consumergroup,来进行并发消费。
    解析(parser)转换(transformer)主要消耗CPU,如果CPU被打满,极有可能是配置的解析和转换较多,此时可以从解析方式或者转换方式上考虑优化,如能用csv的转换就不用grok,等等。
    发送(sender) 的优化方式较为多样,可以参考上文中日志发送常见问题里的如何不重不漏的高效发送日志数据 部分。

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