Elasticsearch写入瓶颈导致skywalking大盘空白

目录
  • 前言
  • 问题定位
    • THREAD-B,找出当前阻塞其他线程的线程
  • 解决方案
    • 临时方案,SKYWALKING参数调优
  • 最终方案-优化ES的写入性能
  • 结语

前言

继上次skywalking出故障《解析Arthas协助排查线上skywalking不可用问题》不到一个月,线上skywalking又出毛病了。又是大盘空白,trace列表最近的数据都查询不出来,但是时间稍久的数据就能查询出来,如一天前的数据有,一个小时前的数据就没有,这个只是表象,最终查明症结是ES的服务写入瓶颈,导致写入写入数据的线程阻塞导致的。下面是排错过程以及解决方案说明。

问题定位

工具还是那个工具Arthas,不了解的可以翻阅我之前的博文,这里不多说明Arthas。不过这次我们应用了一个新的进阶指令thread,它可以查看当前线程信息,查看线程的堆栈。当skywalking大盘没有数据时,使用如下指令:

thread -b

THREAD -B, 找出当前阻塞其他线程的线程

有时候我们发现应用卡住了, 通常是由于某个线程拿住了某个锁, 并且其他线程都在等待这把锁造成的。 为了排查这类问题, arthas提供了thread -b, 一键找出那个罪魁祸首。最后得到如下的结果:

如上图,相信大家已经看到问题所在了,重点在红色字体箭头指向的部分,不得不说Arthas做的太棒了。症结就是ES的批量写入失败线程阻塞了。后从社区了解到是因为ES写入瓶颈,导致skywalking在批量写入索引的时候线程阻塞了。导致阻塞的那段时间的数据都没有写到ES,然后查询是没有问题的,表象就是skywalking的大盘空白也查询不到近期的数据了。

解决方案

临时方案,SKYWALKING参数调优

skywalking写入ES的操作是使用了ES的批量写入接口。我们可以调整这些批量的维度。尽量降低ES索引的写入频率,如:

elasticsearch:
    clusterNodes: 192.168.20.221:9200 indexShardsNumber: 2 indexReplicasNumber: 0 # Batch process setting, refer to https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html bulkActions: 4000 # Execute the bulk every 2000 requests bulkSize: 40 # flush the bulk every 20mb flushInterval: 30 # flush the bulk every 10 seconds whatever the number of requests concurrentRequests: 2 # the number of concurrent requests receiver-register: default:
receiver-trace: default:
    bufferPath: ../trace-buffer/ # Path to trace buffer files, suggest to use absolute path bufferOffsetMaxFileSize: 500 # Unit is MB bufferDataMaxFileSize: 1000 # Unit is MB bufferFileCleanWhenRestart: false

调整bulkActions默认2000次请求批量写入一次改到4000次。批量刷新从20M一次到40M一次。这种配置调优确实生效了,重启服务后两三天了都没有出现过ES写入阻塞的问题。不过这种设置只是暂时的,你只能期望流量不突发,或者应用不增加。一旦遇到突发流量和应用的增加,ES写入瓶颈还是会凸显出来。而且参数设置过大带来了一个新的问题,就是数据写入延时会比较大,一次服务交互发生的trace隔好久才能在skywalking页面上查询到。所以最终解决方案是优化ES的写入性能。

最终方案-优化ES的写入性能

如果是自建Elasticsearch服务,在基础大数据团队负责搜索引擎 Elasticsearch 优化和开发,博文里分享了很多可调优配置的参数。不过我们这边综合运维人力和支出方面的考虑,决定采用阿里云提供的Elasticsearch,不过这带来了一个新的问题,阿里云的ES服务不论内外网都需要Http Basic认证,但是目前的skywalking并没有提供这种支持。

结语

skywalking是一款非常不错的开源apm产品,很多功能特性甚至可以和商业的apm产品一争高下,比如trace查询等功能。我们线上的skywalking没有全面铺开去接入应用,但是问题还是发生了不少,希望这些线上的踩坑排坑经验能带来更多的参考价值。关于Elasticsearch 带Http Basic 认证skywalking不支持的问题,将在下文详描述去解决

以上就是Elasticsearch写入瓶颈导致skywalking大盘空白的详细内容,更多关于Elasticsearch写入skywalking空白的资料请关注我们其它相关文章!

(0)

相关推荐

  • 解析Arthas协助排查线上skywalking不可用问题

    目录 前言 使用到的工具arthas 先定位问题一 问题一: 问题解决: 功能说明 参数说明 定位问题二 问题二: 问题解决: 结语 前言 首先描述下问题的背景,博主有个习惯,每天上下班的时候看下skywalking的trace页面的error情况.但是某天突然发现生产环境skywalking页面没有任何数据了,页面也没有显示任何的异常,有点慌,我们线上虽然没有全面铺开对接skywalking,但是也有十多个应用.看了应用agent端日志后,其实也不用太担心,对应用毫无影响.大概情况就是这样,但

  • python实现skywalking的trace模块过滤和报警(实例代码)

      skywalking本身的报警功能,用起来视乎不是特别好用,目前想实现对skywalking的trace中的错误接口进行过滤并报警通知管理员和开发.所以自己就用python对skywalking做了二次数据清洗实现.项目方在了自己了github(https://github.com/shygit-dev/skywalking-cli-python)上了,有兴趣的同学可以做二次改造,共同学习.下面简单列出了代码内容: sw-trace.py #!/usr/bin/env python # _*

  • Skywalking改成适配阿里云等带Http Basic的Elasticsearch服务

    目录 前言 skywalking项目结构 定位代码改动 注意事项 结语 前言 最近公司skywalking服务经常出现大盘空白的情况,经查明,是由于ES的写入瓶颈造成线程阻塞,数据没有落地到ES造成.后综合运维成本等方面考虑,准备使用阿里云提供的Elasticsearch服务,阿里云的ES无论内外网都加上了Http Basic认证,但是skywalking6.x提供的RestHighLevelClient客户端并没有适配带Http Basic基础认证的ES服务,所以需要稍加改动下skywalki

  • net core下链路追踪skywalking安装和简单使用教程

    当我们用很多服务时,各个服务间的调用关系是怎么样的?各个服务单调用的顺序\时间性能怎么样?服务出错了,到底是哪个服务引起的?这些问题我们用什么方案解决呢,以前的方式是各个系统自己单独做日志,出了问题从暴出问题的服务开始一个一个服务的排查,耗时耗力,有些日志不全的,还不一定查得出来.好在现在有Skywalking链路追踪系统,可以不用写任何代码,就追踪到各个服务间的调用关系和性能状态等. 本文将从0开始搭建两个webapi项目,使用Skywalking来追踪他们之间的调用关系及响应时间.开发环境为

  • Elasticsearch写入瓶颈导致skywalking大盘空白

    目录 前言 问题定位 THREAD-B,找出当前阻塞其他线程的线程 解决方案 临时方案,SKYWALKING参数调优 最终方案-优化ES的写入性能 结语 前言 继上次skywalking出故障<解析Arthas协助排查线上skywalking不可用问题>不到一个月,线上skywalking又出毛病了.又是大盘空白,trace列表最近的数据都查询不出来,但是时间稍久的数据就能查询出来,如一天前的数据有,一个小时前的数据就没有,这个只是表象,最终查明症结是ES的服务写入瓶颈,导致写入写入数据的线程

  • ElasticSearch写入流程实例解析

    目录 一.前言 二.lucence写 2.1 增删改 2.2. 并发模型 2.2.1. 基本操作 2.2.2 更新 2.2.3 删除 2.2.4 flush和commit 2.2.5 merge 小结 三. ElasticSearch的写 3.1. 宏观看ElasticSearch请求 3.2. 详细流程 3.2.1 协调节点内部流程 3.2.2 主分片节点流程* 3.2.3 副本分片节点流程8 四.总结 一.前言 介绍我们在前面已经知道ElasticSearch底层的写入是基于lucence依

  • php从memcache读取数据再批量写入mysql的方法

    本文实例讲述了php从memcache读取数据再批量写入mysql的方法.分享给大家供大家参考.具体分析如下: 用 Memcache 可以缓解 php和数据库压力下面代码是解决高负载下数据库写入瓶颈问题,遇到最实用的:写入ip pv uv的时候,用户达到每分钟几万访问量,要记录这些数据,实时写入数据库必定奔溃. 用以下技术就能解决,还有如用户注册,同一时间断内,大量用户注册,可以缓存后一次性写入到数据库,代码如下: 复制代码 代码如下: public function cldata(){ $me

  • 解析导致局域网网速变慢的五大真凶

    对于网管来说,局域网网速变慢是最麻烦的事之一了.如果是网络不通,反而能够快速地找到原因,但如果网络是通的,但网速变慢,这就最令人头痛.初次面对这类"软"故障时,往往有的人会束手无策.本文为大家介绍引起此类"软"故障常见的原因及排除方法,以提高大家对实际问题的处理能力. 一.网线问题导致网速变慢 我们知道,双绞线是由四对线按严格的规定紧密地绞和在一起的,用来减少串扰和背景噪音的影响.同时,在T568A标准和T568B标准中仅使用了双绞线的1.2和3.6四条线,其中,1

  • Python日志无延迟实时写入的示例

    我在用python生成日志时,发现无论怎么flush(),文件内容总是不能实时写入,导致程序意外中断时一无所获. 以下是查到的解决方案(亲测可行): open 函数中有一个bufferin的参数,默认是-1,如果设置为0是,就是无缓冲模式. 但是用二进制模式打开这个文件,并且把要写入的信息转换byte -like如下. with open("test.txt",'wb',buffering=0) as f: #wb是写模式加二进制模式 f.write(b"hello!&quo

  • MySQL服务器 IO 100%的分析与优化方案

    前言 压力测试过程中,如果因为资源使用瓶颈等问题引发最直接性能问题是业务交易响应时间偏大,TPS逐渐降低等.而问题定位分析通常情况下,最优先排查的是监控服务器资源利用率,例如先用TOP 或者nmon等查看CPU.内存使用情况,然后在排查IO问题,例如网络IO.磁盘IO的问题. 如果是磁盘IO问题,一般问题是SQL语法问题.MYSQL参数配置问题.服务器自身硬件瓶颈导致IOPS吞吐率问题. 本文主要给大家介绍的是关于MySQL服务器 IO 100%的分析与优化方案,下面话不多说了,来一起看看详细的

  • 一文学会Hadoop与Spark等大数据框架知识

    目录 一个实际的需求场景:日志分析 Hadoop Hadoop的生态坏境 Spark Spark整体架构 Spark核心概念 Spark的核心组件 海量数据的存储问题很早就已经出现了,一些行业或者部门因为历史的积累,数据量也达到了一定的级别.很早以前,当一台电脑无法存储这么庞大的数据时,采用的解决方案是使用NFS(网络文件系统)将数据分开存储.但是这种方法无法充分利用多台计算机同时进行分析数据. 一个实际的需求场景:日志分析 日志分析是对日志中的每一个用户的流量进行汇总求和.对于一个日志文件,如

  • Vue打包路径配置过程

    目录 Vue打包路径配置 1. 配置文件 2. 打包示例(npm/cnpm run build) 解决打包路径配置的问题 问题 原因 解决 Vue打包路径配置 1. 配置文件 module.exports = { // ...... // 相对路径都是相对于index.js所在的目录config开始的 build: { // index,assetsRoot两个路径基本不用改动,只是用于文件打包存放的路径 // index.html的路径 index: path.resolve(__dirnam

随机推荐