我们可以做些调优，skywalking写入ES的操作是使用了ES的批量写入接口。我们可以调整这些批量的维度。尽量降低ES索引的写入频率，如：
bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:4000} # Execute the bulk every 2000 requests
bulkSize: ${SW_STORAGE_ES_BULK_SIZE:40} # flush the bulk every 20mb
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}
调整bulkActions默认2000次请求批量写入一次改到4000次；bulkSize批量刷新从20M一次到40M一次；flushInterval每10秒刷新一次堆改为每30秒刷新；concurrentRequests查询的最大数量由5000改为8000。这种配置调优确实生效了，重启服务后两三天了都没有出现过ES写入阻塞的问题。不过这种设置只是暂时的，你只能期望流量不突发，或者应用不增加。一旦遇到突发流量和应用的增加，ES写入瓶颈还是会凸显出来。而且参数设置过大带来了一个新的问题，就是数据写入延时会比较大，一次服务交互发生的trace隔好久才能在skywalking页面上查询到。所以最终解决方案是优化ES的写入性能，具体优化可以参考别人的文章：https://www.easyice.cn/archives/207
另外作为开源化的平台，扩展性也是其中的优势，本身ES就是分布式全文检索框架，可以部署成高可用的集群，另外Skyawalking也是分布式链路跟踪系统，分布式既然是它应用的特性，那么怎么去构建集群化的监控平台，就完全靠你自己的想象和发挥了。
最后放一张我的Skywalking监控平台的监控效果图（压测过程中的应用监控），我可是斗胆把人家的Logo都换了，但我可不会用在商用领域，只是部门内部使用，方便其他人一眼认出这是个APM监控平台：