skywalking集群优化

• 背景

某天接到告警skywalking没有采集调用链信息，于是展开分析并进行优化

 

• 优化点

1. 日志配置优化

 根据磁盘容量调整文件保持个数，修改log4j2.xml文件<DefaultRolloverStrategy max="10"/>

 

    2.调整skywalking存储elasticsearch配置，修改application.yml文件

storage:

  elasticsearch:

    nameSpace: ${SW_NAMESPACE:"CollectorRdpCluster"}

    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:IP1:9200,IP2:9200,IP3:9200}

    protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"}

    indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:2}

    indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:1}

    bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:4000} # Execute the bulk every 1000 requests

    flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:30} # flush the bulk every 10 seconds whatever the number of requests

    concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:4} # the number of concurrent requests

    metadataQueryMaxSize: ${SW_STORAGE_ES_QUERY_MAX_SIZE:8000}

 

各个修改值介绍：

clusterNodes:  根据实际情况调整es集群配置(后续可以调整顺序)

indexReplicasNumber：存储副本数量，该值在一定程度上会影响存储效率，打开关闭索引速度；但目前我们的elasticsearch集群不是很稳定，为了能高可用而修改该值

bulkActions： 批量提交的大小，通过增加该值，减少skwalking服务端和es之间交互，增加吞吐量

flushInterval： 每间隔多久提交请求，不管现有多少个请求，目的也是减少交互，增加吞吐量

concurrentRequests:  增加现有请求数量

metadataQueryMaxSize：查询最大数量，默认5000，调整为8000

 

    3.对ES中现有的 索引进行优化

修改所有collectrdpcluster打头索引的setting配置，主要目的也是增强IO；修改后同时也会带来丢失部分日志的风险，具体操作步骤如下

（1）关闭索引

http://IP1:9200/collectorrdpcluster*/_close   

POST

 

（2）调整索引配置

http://IP1:9200/collectorrdpcluster*/_settings?preserve_existing=true

PUT

{

    "index.merge.scheduler.max_thread_count" : "1",

    "index.refresh_interval" : "30s",

    "index.translog.durability" : "async",

    "index.translog.sync_interval" : "120s"

}

 

说明:

<1>  preserve_existing=true， 是否覆盖已有的配置项，需要根据实际情况调整

<2>index.merge.scheduler.max_thread_count, 调整索引merge的线程数， 默认会根据cpu核数进行计算，但对于机械硬盘来讲，默认值反而影响效率

<3>index.refresh_interval 刷新间隔时间, 默认是1s，对于日志类数据，及时性没必要这么高

<4>index.translog.durability 持久化方式，异步；异步会存在丢失部分数据风险

<5>index.translog.sync_interval 同步间隔，越长的间隔会让io更平稳

 

（3）打开索引

http://IP1:9200/collectorrdpcluster*/_open

POST

 

（4）创建索引模版

http://IP1:9200/_template/collectorrdpcluster_temp

PUT

{

  "index_patterns": ["collectorrdpcluster*"],

  "settings": {

      "index.merge.scheduler.max_thread_count" : "1",

      "index.refresh_interval" : "30s",

      "index.translog.durability" : "async",

      "index.translog.sync_interval" : "120s"

  }

}

 

• 回溯及思考

1. 调整日志回收大小原因

在发现skywalking采集不到微服务调用链信息后，查看磁盘，发现该日志所在磁盘空间已满；

    后续可以从两个方面进行改进

(1)增加对应磁盘的监控及时告警

(2)及时清理日志信息，可以增强log4j2.xml配置，也可以通过shell脚本定时清理

 

      2. 调整skwalking中es存储配置原因

由于线上pod数量过多，快1000+，因此任务很重，通过优化配置让其能通过更少的交互存储更多的信息

 

      3.调整现有日志索引设置的原因

因为是对线上环境进行优化，已经存在了一些索引数据，通过优化已存在索引的异步落盘等参数，让其更高效

 

      4.设置模版原因

随着skwalking的运行，它会按月、天等生成一些以 nameSpace: ${SW_NAMESPACE:"CollectorRdpCluster"}打头的一些索引，通过创建模版，能让其后续创建的索引使用我们预期的配置

 

     5.后续需要继续关注磁盘占用情况，及时调整skywalking保存数据时间，清理过期数据