- 背景
公司有一套大数据的处理平台,涉及到Hadoop,Spark,Hive,Presto等框架,当数据出现异常时,往往要通过多个环节的排查才能定位到问题,大致排成流程如下 插件日志-->采集日志-->Spark日志-->Hive日志--->Hadoop日志。。。。。。,只看这个流程已经醉了,为了便于问题的准确定位,计划采用ELK的方案对日志进行采集,存储以及查询。
处于技术原型阶段,采用最简单的ELK架构,没有引入Kafka等中间数据层,也暂不涉及优化方案 - 模型说明
环境的搭建过程,请参考 “ELK实践系列-测试环境环境安装”内容。
由于涉及到多套环境,且每个环境都有多种类型的日志,为了便于对数据的维护,Elasticsearch采用根据环境分索引,根据数据类型分type的策略。数据的采集,存储,展示模型如下
- 配置
配置的主要内容就是Logstash如何把数据传到Elasticsearch.本例采用tail日志文件的方式来采集数据,完整的logstash配置如下
input {file {type => "hadoop.logs"path => ["/opt/distribute/logs/hadoop/hadoop-root-namenode.log"]}file {type => "hive.logs"path => ["/opt/distribute/logs/hive/hive.log"]}file {type => "streaming_stor.logs"path => ["/opt/distribute/logs/streaming/streaming_stor.log"]}file {type => "spark.logs"path => ["/opt/distribute/logs/spark/spark-master.log"]}
}output {stdout {codec => rubydebug}elasticsearch {hosts => [" http://10.5.25.18:9200"]index => "cluster-10-5"}} - 验证
如果上面的一切都OK了,接下来就可以登录Kibana,通过Discover模块来查询日志了
- 可以改进的地方
- 字段提取问题:目前查询的方式比较暴力,如果想查询日志Level为ERROR的日志,也只能通过搜索message 的方式来实现,如果数据量较大,可能出现性能问题,可以通过在logstash中添加groke,把Level字段单独提出来,这样查询会更方便
- 定时数据清理问题:一个环境跑了半天,在ES中产生了大概2G的数据,需要一个脚本可以定时删除过期的数据
- HA问题:目前Elasticsearch是单机,为了保证服务的稳定性,需要扩展节点
- 目前采用数据的方式是通过Logstash将数据推到ES的方式,如果Logstash数据较多,可能会对ES的正常运行造成一定的影响,为了保证数据平稳的传送,如果需要可以将结构改成 各集群Logstash--->Kafka集群---->Lostash--->ES 的方式
- 集群监控:添加Marvel插件对ES进行监控
- ES的JVM优化
ELK实践系列-系统日志监控
最新推荐文章于 2024-08-08 08:14:30 发布