实时收集Storm日志到ELK集群

背景

我们的storm实时流计算项目已经上线几个月了,由于各种原因迟迟没有进行监控,每次出现问题都要登录好几台机器,然后使用sed,shell,awk,vi等各种命令来查询原因,效率非常低下,而且有些统计是没法做的,所以很有必要对storm本身相关的日志以及我们运行在storm上面的任务的日志做一个统一的日志收集,分析,查询,统计平台。

技术选型

对于这个选择,其实不用考虑那么多,借用一句名言 Life is short , You need elk ! 关于elk相关的安装这里不再介绍,可参考散仙的博客:http://qindongliang.iteye.com/category/330375

需求分析

序号 讨论 内容
1 storm需要收集的日志 (1)本身的相关的日志 (2)提交任务的日志
2 日志过滤 排除gc的log和部分不相干业务的log
3 索引如何切分 考虑量不是很大,按每月生成一份索引
4 索引模板定制 默认的动态mapping比较简答,所以我们采用自定义动态索引模板
5 日志的定期删除 使用es官网插件curator管理

核心配置

(1)es的模板定义 注意date类型的动态类型是开启docvalue的,便于快速聚合和排序

{
  "order": 0,
  "template": "jstorm*",
  "settings": {
    "index": {
      "number_of_replicas": "0",
      "number_of_shards": "3"
    }
  },
  "mappings": {
    "_default_": {
      "dynamic_templates": [
        {
          "level": {
            "mapping": {
              "index": "not_analyzed",
              "type": "string"
            },
            "match": "level",
            "match_mapping_type": "string"
          }
        },
        {
          "message": {
            "mapping": {
              "index": "analyzed",
              "type": "string"
            },
            "match": "message",
            "match_mapping_type": "string"
          }
        },
        {
          "date_fields": {
            "mapping": {
              "doc_values": true,
              "type": "date"
            },
            "match_mapping_type": "date"
          }
        },
        {
          "string_fields": {
            "mapping": {
              "index": "not_analyzed",
              "type": "string"
            },
            "match": "*",
            "match_mapping_type": "string"
          }
        }
      ],
      "_all": {
        "enabled": false
      }
    }
  },
  "aliases": {}
}

(2)logstash的conf定义

input{
    file{
            #初始化全量导入
            start_position => "beginning"
            #统一的storm的日志目录
            path=> ["/data/logs/jstorm/**/*.log"]
            #排除的路径
            exclude =>["*gc*","*log_monitor*"]
            #指定文件偏移量存储的文件
            sincedb_path => "./sincedb"
            #配置多行数据收集(针对异常)
            codec => multiline {
                          #类似两个info之间的所有数据是一行数据
                          pattern => "^\[%{LOGLEVEL:loglevel}"
                          #true代表是两个loglevel之间的数据
                          #false代表两个异常之间的数据,跟上面的相反
                          negate=> true
                          #后一条的数据前面所有的,都属于这整条数据
                          what => "previous"
                        }
        }
} 

filter {
        #使用gork直接获取日志级别和时间
        grok {
                match =>{"message"=>"%{LOGLEVEL:loglevel}\s*%{TIMESTAMP_ISO8601:time} "}
        }

    #  转化日志时间为收集的时间,并移除无用的字段
    date{
            match => ["time","yyyy-MM-dd HH:mm:ss.SSS","yyyy-MM-dd HH:mm:ss","ISO8601"]
            remove_field => [ "time","@version" ]   

   } 

# 这个地方可以对一些数据做过滤
#  if [loglevel] == "DEBUG" {
#   drop { }
#  }

}

#输出到es的配置
output{

  elasticsearch{
   #设置索引名
   index => "jstorm_pro%{+YYYY-MM}"
   hosts=> ["192.168.8.5:9200","192.168.8.6:9200","192.168.8.7:9200"]
   #关闭logstash自动管理模块
   manage_template => false
   #指定模板名为jstrom
   template_name => "jstorm"
   #设置flush的数量
   flush_size => 3000
   }
 # 调试控制台输出
 # stdout { codec => rubydebug  }
}

辅助脚本

放在logstash的根目录下面

启动脚本:start_jstorm.sh
nohup bin/logstash -f config/jstorm.conf  &> jstorm_logstash.log & echo $! >jstorm_logstash_pid& 

关闭脚本:stop_jstorm.sh
kill -9 `cat jstorm_logstash_pid`

收集检索效果

一切完成后,启动logstash收集进程后,我们就可以实时在kibana里面分析数据了,非常nice!

然后,我们就可以非常快速的定位异常数据了。

时间: 2024-10-09 08:12:59

实时收集Storm日志到ELK集群的相关文章

配置三台服务器组成的ELK集群(二)

上一篇里主要是介绍了ES和ES-Head的安装过程,这一篇继续介绍ELK集群的其他核心组件安装过程. 五.安装Logstash: 本案的Logstash安装在10.113.130.117上:燃鹅,Logstash也可以利用多台组成集群,如果未来单台处理不过来,可以把Logstash扩展到其他服务器上. 将logstash.tar.gz解压到指定目录: # tar -zxvf logstash-5.4.1.tar.gz -C /opt/ # mv /opt/logstash-5.4.1/ /opt

亿级PV的ELK集群实践之路

前言 笔者多年前便维护过ELK,但是由于站点日志流量及服务器数量并不是很多基本都是单机搞定. 然而光Web服务器就400+,Nginx日志大小每天50G+,加上其他业务系统日志,之前单机ELK显然不足以支撑现有的业务场景. 规划篇 目前的业务采用阿里云+自建机房的模式,阿里云做为线上业务,自建机房做为灾备中心,尽可能的将线上日志实时传输到自建机房进行数据分析. 架构图 简述 1.日志集中处理 笔者一开始是在每台机器通过filebeat+logstash的方式将日志进行收集和处理后发送到elast

STORM在线业务实践-集群空闲CPU飙高问题排查(转)

最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并到了storm新版本中,在这篇文章里会介绍这个问题出现的场景.分析思路.解决的方式和一些个人的收获. 背景 首先简单介绍一下Storm,熟悉的同学可以直接跳过这段. Storm是Twitter开源的一个大数据处理框架,专注于流式数据的处理.Storm通过创建拓扑结构(Topolog

STORM在线业务实践-集群空闲CPU飙高问题排查

源:http://daiwa.ninja/index.php/2015/07/18/storm-cpu-overload/ 2015-07-18AUTHORDAIWA STORM在线业务实践-集群空闲CPU飙高问题排查有2条评论 STORM在线业务实践-集群空闲CPU飙高问题排查 最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并

通过docker搭建ELK集群

单机ELK,另外两台服务器分别有一个elasticsearch节点,这样形成一个3节点的ES集群. 可以先尝试单独搭建es集群或单机ELK https://www.cnblogs.com/lz0925/p/12018209.html // 单机ELK https://www.cnblogs.com/lz0925/p/12011026.html // 三节点es集群 注意点 服务器内存:要求不低于8G,如果4G,没有跑其他程序的话,应该也可以,低于4G基本不用考虑. 我的系统:阿里云centOS7

ELK集群部署及收集nginx日志

一.ELK说明 二.架构图 三.规划说明 四.安装部署nginx+logstash 五.安装部署redis 六.安装部署logstash server 七.安装部署elasticsearch集群 八.安装kibana 一.ELK说明 ELK Stack 是 Elasticsearch.Logstash.Kibana 三个开源软件的组合.在实时数据检索和分析场合,三者通常是配合共用,而且又都先后归于 Elastic.co 公司名下,故有此简称. ELK Stack 在最近两年迅速崛起,成为机器数据

CentOS7.3下ELK日志分析系统集群搭建

Elasticsearch是个基于Lucene实现的开源.分布式.restful的全文本搜索引擎,此外他还是一个分布式实时文档存储,其中每个文档的每个filed均是可被索引的数据,且可被搜索,也是一个带实时分析功能的搜索引擎,能够扩展至数以百计的节点实时处理PB级别的数据.它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等.Elasticsearch集群采用主从模式,通过获取Logstash客户端收集来的日志信息同步到Elastic

实时计算平台中的弹性集群资源管理

本文系微博运维数据平台(DIP)在实时计算平台的研发过程中集群资源管理方面的一些经验总结和运用,主要关注以下几个问题: 异构资源如何整合? 实时计算应用之间的物理资源如何隔离? 集群资源利用率如何提高? 集群运维成本如何降低? 1. 背景 这是我们初期的一个实时计算架构,大致划分为三个部分: (1)日志收集: 使用Rsynlog.Flume.Scribe汇聚各个业务方发送过来的日志数据:如果条件允许,业务方也可以直接将数据写入Kafka. (2)日志传输: 使用Kafka作为日志收集组件与实时应

elk集群安装配置详解

#  一:简介 ``` Elasticsearch作为日志的存储和索引平台: Kibana 用来从 Elasticsearch获取数据,进行数据可视化,定制数据报表: Logstash 依靠强大繁多的插件作为日志加工平台: Filebeat 用来放到各个主机中收集指定位置的日志,将收集到日志发送到 Logstash: Log4j 直接与 Logstash 连接,将日志直接 Logstash(当然此处也可以用 Filebeat 收集 tomcat 的日志). ``` ####  port ```