0

我现在已经尝试了一些日志收集服务，比如 logspout/papertrail 和 fluentd/elasticsearch，但结果并不总是以正确的顺序显示，这可能会使调试变得困难。一个示例是 Node.js 应用程序、console.log导致多行的命令或其堆栈跟踪错误。这些行都以相同的时间戳显示，我猜日志收集服务无法知道显示这些的顺序。有没有办法增加毫秒精度？或者以其他方式确保它们以与我docker logs执行命令相同的顺序显示？

更新：我还没有研究过，但是我看到了一些关于 fluent 或 elasticsearch 的东西，默认情况下在较新的版本中支持毫秒+精度

4

2 回答 2

1

据我了解，您有两种选择：

  • 提高时间戳精度（就像你做的那样）；或者
  • 使用可以维护数据顺序的日志存储。例如MongoDB。日志收集概念在另一篇 stackoverflow帖子中进行了描述。
于 2015-05-27T10:29:24.223 回答
0

我在这个答案中找到了 fluentd 的解决方法，但我仍然想要一个真正的解决方案

这是我修改后的 td-agent.conf，用于fluentd-es-image。它添加了time_nano可以排序的字段

<source>
  type tail
  format json
  time_key time
  path /varlog/containers/*.log
  pos_file /varlog/es-containers.log.pos
  time_format %Y-%m-%dT%H:%M:%S.%L%Z
  tag cleanup.reform.*
  read_from_head true
</source>

<match cleanup.**>
   type record_reformer
   time_nano ${t = Time.now; ((t.to_i * 1000000000) + t.nsec).to_s}
   tag ${tag_suffix[1]}
</match>


<match reform.**>
  type record_reformer
  enable_ruby true
  tag kubernetes.${tag_suffix[3].split('-')[0..-2].join('-')}
</match>

<match kubernetes.**>
   type elasticsearch
   log_level info
   include_tag_key true
   host elasticsearch-logging.default
   port 9200
   logstash_format true
   flush_interval 5s
   # Never wait longer than 5 minutes between retries.
   max_retry_wait 300
   # Disable the limit on the number of retries (retry forever).
   disable_retry_limit
</match>

<source>
  type tail
  format none
  path /varlog/kubelet.log
  pos_file /varlog/es-kubelet.log.pos
  tag kubelet
</source>

<match kubelet>
   type elasticsearch
   log_level info
   include_tag_key true
   host elasticsearch-logging.default
   port 9200
   logstash_format true
   flush_interval 5s
   # Never wait longer than 5 minutes between retries.
   max_retry_wait 300
   # Disable the limit on the number of retries (retry forever).
   disable_retry_limit
</match>
于 2015-05-27T04:15:38.810 回答