日志收集有延迟

xdai

我是在现有的kubernetes集群上部署的2.1，部署完状态显示都正常

现在集群里服务的日志都是落盘的，然后我开启了落盘日志，部署了文档中心里的test-log容器，看日志的话收集的很少，而且会延迟2个小时左右，test-log还是昨天收集，最新的收集不到,不知道该从哪里排查问题。

huanggze

xdai 现在还有日志滚动刷出吗？还是说采集已经停了？

xdai

这是最近的另外fluent-bit有下面的报错
[2019/11/20 03:36:10] [error] [out_es] could not pack/validate JSON response
{“took”:23440,“errors”:true,“items”:[{“index”:{“index”:“ks-logstash-log-2019.08.31”,“type”:“flb_type”,“id”:“Amjhhm4BYm92d9lXXhZ7”,“status”:429,“error”:{“type”:“es_rejected_execution_exception”,“reason”:“rejected execution of processing of [1221794][indices:data/write/bulk[p]]: request: BulkShardRequest [[ks-logstash-log-2019.08.31][4]] containing [30] requests, target allocation id: pneqd10bS9OHDbGIt10PeA, primary term: 1 on EsThreadPoolExecutor[name = elasticsearch-logging-data-0/write, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@778891ba[Running, pool size = 4, active threads = 4, queued tasks = 200, completed tasks = 632026]]”}}},{“index”:{“index”:“ks-logstash-log-2019.08.31″,“type”:“flb_type”,“id”:“A2jhhm4BYm92d9lXXhZ7″,“status”:429,“error”:{“type”:“es_rejected_execution_exception”,“reason”:"rejected execution of processing of [1221792][indices:data/write/bulk[p]]: re

xdai

huanggze

xdai 这个报错显示的是 queued tasks 堆积。看看 es 的 CPU/Mem 使用量，可以适当提高 limit 试试

xdai

huanggze
我把es的limit给去掉了，重启了fluent-bit,还是有报错。

huanggze

xdai 重启 fluent-bit 刚开始是会有这样的异常（原因是当前 KubeSphere 版本的 Fluent Bit 还没有把记录文件读取 position 的 database 持久化），因为要从头拉取日志，等待拉完即可。

你的问题应该只需要调整 es，fluent-bit 尽量不要碰。去了 limit 后的 es 让它跑一会看看

SeesawLiu

xdai 你的问题解决了吗，我也遇到这样的错，fluent报了错，日志也一直停留在这个时间了

brosoul

huanggze 我在 kubesphere 2.1.1 版本中也将 es 的 limit 去掉，但是 fluent-bit 仍然处于，已经跑了6个小时左右，日志查询结果还是不够完整，这是还没拉取完日志吗，是否可以通过其他手段（除了取消 limit）提高处理日志的性能？

[2020/02/28 10:44:58] [error] [out_es] could not pack/validate JSON response

{"took":0,"errors":true,"items":[{"index":{"_index":"ks-logstash-log-2019.12.20","_type":"flb_type","_id":"GRVmi3ABLtm74sQyPGEb","status":403,"error":{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}}},{"index":{"_index":"ks-logstash-log-2019.12.20","_type":"flb_type","_id":"GhVmi3ABLtm74sQyPGEb","status":403,"error":{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}}},{"index":{"_index":"ks-logstash-log-2019.12.20","_type":"flb_type","_id":"GxVmi3ABLtm74sQyPGEb","status":403,"error":{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}}},{"index":{"_index":"ks-logstash-log-2019.12.20","_type":"flb_type","_id":"HBVmi3ABLtm74sQyPGEb","status":403,"error":{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow de

huanggze

SeesawLiu 那是对的呀，没问题

huanggze

brosoul 提高处理日志性能的方法可以扩容 elasticsearch-logging-data POD 的副本数

huanggze

brosoul 需要看你的日志量有多大，比如每天 1亿条以上的日志，可以扩容到 5个副本（默认两个）

brosoul

huanggze 好的，谢谢。我现在看来还是有些日志没有收集到（原来 3个副本），我尝试一下scale elasticsearch-logging-data ，稍晚反馈

huanggze

brosoul 哦，看你的报错是es read-only 了，不是性能不够。是存储满了

brosoul

huanggze
确实我 scale 了pod，每个的cpu在0.6 左右，但是存储方面

[elasticsearch@elasticsearch-logging-data-0 ~]$ df -Th
Filesystem     Type     Size  Used Avail Use% Mounted on
overlay        overlay  447G  286G  162G  64% /
tmpfs          tmpfs     64M     0   64M   0% /dev
tmpfs          tmpfs    126G     0  126G   0% /sys/fs/cgroup
/dev/sda1      xfs      223G   17G  206G   8% /etc/hosts
shm            tmpfs     64M     0   64M   0% /dev/shm
/dev/sdb1      xfs      447G  286G  162G  64% /etc/hostname
/dev/rbd12     ext4     197G   12G  186G   6% /usr/share/elasticsearch/data
tmpfs          tmpfs    126G   12K  126G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs          tmpfs    126G     0  126G   0% /proc/acpi
tmpfs          tmpfs    126G     0  126G   0% /proc/scsi
tmpfs          tmpfs    126G     0  126G   0% /sys/firmware

我到 elasticsearch-logging-data 其中一个pod 中，存储采用了 6%。