Istio组件日志与请求日志采集方案_istio可以帮助采集业务日志吗

Istio日志方案

背景说明

为方便故障定位、问题溯源和运营分析，采集istio组件日志、请求日志和业务日志是服务网格落地的重要步骤之一。默认情况下，istio相关日志打在容器内，pod销毁重建后日志消失。此外，istio日志量没有预估和分级，很可能出现日志量过大而导致k8s集群不稳定等风险。

关键问题

Istio默认情况下，日志易丢失、难查找和未分级，很容易出现遗漏关键日志和占用磁盘空间过大等问题。在72h疲劳压测过程中，还发现istio组件磁盘读写过大、时区不一致和未限制资源等问题。

解决方案

实现思路

为了合理地分级采集istio日志，并控制日志磁盘利用率，该方案将istio日志输出路径重定向到宿主机的data数据盘，然后使用filebeat组件将日志录入ELK集群。具体实现过程如下：

1. 明确需要采集的日志类型，如关键组件日志、接口请求日志和业务输出日志；2. 采用istio方式部署bookinfo和testistio 2个测试项目，以观察isito日志状态；
2. 查看istio官方文档和登录容器，以确定组件、业务和请求日志的输出路径；
3. 调整istio组件日志配置并挂载本地卷，将组件日志落到/data/log/istio目录；
4. 修改istio stdio日志适配器配置，将请求日志落到/data/log/istio/stdio目录；
5. 挂载/data/web_log/<project_name>本地卷，将业务日志输出到该目录；
6. 用200或500并发持续压测服务，观察日志落盘情况和磁盘占用情况；
7. 根据压测结果，不断调整istio配置以控制网络IO、磁盘IO和容量压力。

调整范围

Istio组件较多且配置复杂，为减小配置修改难度，将原有25448行yaml文件按照功能划分为78个文件。本日志方案涉及的文件列表如下：

• 4istio-istio-sidecar-injectorConfigMap.yaml
• 4istio-prometheusConfigMap.yaml
• 6istio-grafana-service.yaml
• 6istio-prometheus-service.yaml
• 7istio-citadel-deployment.yaml
• 7istio-egressgateway-deployment.yaml
• 7istio-galley-deployment.yaml
• 7istio-ingressgateway-deployment.yaml
• 7istio-pilot-deployment.yaml
• 7istio-policy-deployment.yaml
• 7istio-telemetry-deployment.yaml
• 7istio-tracing-deployment.yaml

组件日志

istio官方文档已给出了istio-pilot、istio-egressgateway 、istio-ingressgateway、istio-telemetry和 istio-policy日志的统一配置，关键参数如下：

• 记录范围
  // 所有作用域的默认级别是 info ，为在正常情况下使用 Istio 提供大量的日志信息。

--log_output_level=default:info

• 控制输出
  // 选项可以定向输出到许多不同的位置，默认为日志信息通常发送到组件的标准输出

--log_target=/data/log/istio/$(ISTIO_META_WORKLOAD_NAME).$(INSTANCE_IP).log

• 日志轮转
  // 选项可以在日志文件被轮转前指定最大天数，默认为30

--log_rotate_max_age=1

// 选项可以指定文件轮转之前的最大size(以兆字节为单位), 默认为104857600MB

--log_rotate_max_size=1024

// 选项可以控制要保留的最大轮转文件数，较旧的文件将被删除, 默认为1000

--log_rotate_max_backups=30

以上参数设置参考了其它k8s集群的日志量，具体情况如下：

• region_prod k8s组件7天日志大小约8G，数量为20; nginx组件2天日志大小约为5G，数量为6；
• region_test istio在project少量流量测试的情况下，3天日志大小约为4.0K，数量为1；
• 根据日志量和需求，设置istio日志每天轮换，单个日志文件最大为1G，保留1个月的日志。

istio-tracing 组件采用了jaeger第三方组件来实现, 需要单独配置存储，关键配置如下：

          volumeMounts:
          - name: istio-log
            mountPath: /badger

请求日志

accessLog请求日志记录了服务之间的相互调用结果，该日志由envoy代理组件向telemetry组件上报。istio-telemetry 组件采用了stdio第三方组件来实现，需要单独修改11istio-stdio-adapter.yaml文件，关键配置如下：

spec:
  compiledAdapter: stdio
  params:
    logStream: ROTATED_FILE
    outputAsJson: false
    outputPath: /data/log/istio/stdio/access.log
    maxDaysBeforeRotation: 32
    maxMegabytesBeforeRotation: 128
    maxRotatedFiles: 512

测试流程

压测目标

在region_test 100集群部署了bookinfo和testistio 2个项目，部署yaml文件分别在在/opt/addons/istio/v1.4.10/samples/bookinfo和/opt/addons/istio/examples/testistio/ 3-callmepython目录下。

压测过程

使用hey压测工具72小时持续测试，hey命令如下：

nohup hey -z 72h -c 200 http://xxx.xxx.xxx.xxx/productpage  > /dev/null 2>&1 &
nohup hey -z 72h -c 500 -host caller.python.example.com http://xxx.xxx.xxx.xxx/user/helloworld > /dev/null 2>&1 &

压测结果

默认配置下，istio在日志方面遇到了磁盘占用过大、读写过大和时区不一致问题，具体表现如下：
a. istio-telemetry 500并发下，2h日志量50G以上；
b. istio-tracing 500并发下，2h日志量30G以上；
c. istio-tracing jager磁盘写速率，超过63M/s;
d. istio的官方镜像与北京相差8个时区。

优化方案

• 在时区层面，istio的官方镜像与北京相差8个时区。采用挂载/etc/localtime本地卷方式调整istio日志时区，实现了不修改官方镜像而调整时区的目的，减少了大量调整istio镜像的工作量。
• 在资源层间，默认情况istio组件只有请求值，没有上限值。根据72h istio组件压测结果，对istio关键组件设置了相应的上限值，以避免istio组件占用太多资源而影响k8s-worker节点的稳定性。
• 在磁盘层面，采用配置组件日志轮换、配置组件日志上限（含大小和个数），降低jaeger采样频率，和crontab定时任务清理日志等方式，将磁盘IO降到了5M/s以下和6h istio组件日志不超过5G。

5 执行计划
9月26号23:00, 部署region_test istio服务网格组件；
10月12号前，若video_api项目接入生产流量，则配置filebeat日志采集，将istio accessLog日志接入ELK集群。

附录

定时清除istio日志任务每6h执行一次，其中delete_istio_logs.sh脚本如下：

#/bin/bash

# 添加定时任务
# ansible k8s-all -m file -a "dest=/opt/addons/custome-tools/ state=directory"
# ansible k8s-all -m copy -a "src=/opt/addons/custome-tools/delete_istio_logs.sh dest=/opt/addons/custome-tools/"
# ansible k8s-all -m cron -a "name='delete istio log cron' job='/usr/bin/sh /opt/addons/custome-tools/delete_istio_logs.sh > /dev/null 2>&1 ;' hour=*/6"

# 若要删除该cron 只需要加一个字段 state=absent
# ansible k8s-all -m cron -a "name='delete istio log cron' state=absent"

# 删除1天前istio日志
/usr/bin/find /data/log/istio/ -name "*.log.*" -type f -mtime +1 | xargs rm -f
/usr/bin/find /data/log/istio/ -name "*.log" -type f -mtime +1 | xargs rm -f

# jaeger-data保留最近的12个文件
cd /data/log/istio/jaeger-data
ls -lt /data/log/istio/jaeger-data | awk '{if(NR>12){print "rm -rf "$9}}'| sh

# jaeger-key保留最近的12个文件
cd /data/log/istio/jaeger-key
ls -lt /data/log/istio/jaeger-key | awk '{if(NR>12){print "rm -rf "$9}}'| sh
# stdio-adapter保留最近的12个文件
cd /data/log/istio/stdio
ls -lt /data/log/istio/stdio | awk '{if(NR>12){print "rm -rf "$9}}'| sh

#du -d1 -h /data/docker/runtime/containers | sort -h
echo "======== start clean docker containers logs ========"

 查找大于2G的json-log
logs=$(find /data/docker/runtime/containers -type f -name *-json.log -size +2G  | xargs grep "stream" -l)

# 清空大于2G的docker日志
for log in $logs

        do
                echo "clean logs : $log"
                cat /dev/null > $log
        done

echo "======== end clean docker containers logs ========"

参考资料

[1] 第二十三部分 Istio 收集指标和日志
(https://blog.csdn.net/u013538795/article/details/90264387?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-4.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-4.channel_param)
[2] 在Kubernetes生产环境中运行Istio
https://cloud.tencent.com/developer/article/1590076
[3] Istio流量管理实现机制深度解析.
https://zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro/
[4] istio-1：部署与体验istio-1.4.2.
https://cloud.tencent.com/developer/article/1560766
[5] ISTIO telemetry V2 介绍.
https://developer.aliyun.com/article/756018
[6] 深度解析Istio系列之流量控制篇.
https://mp.weixin.qq.com/s?__biz=Mzg3OTA4NDgzOQ==&mid=2247483716&idx=1&sn=132e22c81fe32825358a8babdef0746a&chksm=cf08950cf87f1c1af48e4876ea2be0eb4ebe970aef7441c9082eebb71542cb09d8daad7c9d2c&scene=21#wechat_redirect
[7] 深度解析Istio系列之策略与遥测篇.
https://blog.csdn.net/squirrelanimal0922/article/details/88573395
[8] 微服务链路追踪之Jaeger.
https://www.imooc.com/article/details/id/296732