ELK全量日志查询浅析

ELK全量日志查询浅析

ELK 全量日志查询项目

需求由来

1. 开发人员不能登录线上服务器查看详细日志,经过运维周转费时费力
2. 日志散落在多个系统上,难以查找和整合。
3. 日志数量巨大,查询速度太慢,难以满足需求。
4. 无法全局掌握项目运行情况
5. 日志数据查询不够实时
6. 数据分析人员不会写代码,无法分析统计数据。
7. .......

ELK全量日志查询

  • Logstash+ElasticSearch+Kibana(分布式日志系统)

    • Logstash:监控,过滤,收集日志
    • Elasticsearch:存储日志,提供查询功能。
    • Kibana: 提供web界面,支持查询统计和图表展现。
    • filebeat: 轻量级的日志收集工具。

架构设计

  • 使用filebeat
    • filebeat(1.3)–> logstash(parse) –> es –>kibana –ngix
      • 如果logstash出现问题会导致filebeat收集的数据丢失
    • filebeat(1.3) –> logstash(parse)[loadbalance] –> es –>kibana–mgix
      • filebeat和logstash耦合性太高
    • filebeat(1.3) –> redis –> logstash(parse)–>es–>kibana–ngix
      • 里面redis是一个单线程的实例,redis单线程每秒处理能力一般是10W次左右,相对于kafka来说不值得一提,遇到数据量特别巨大情况可能会发生问题。
    • filebeat –>kafka –>logstash(parse)–es–>kibana –ngix
      • kafka可以水平扩展,使用多分区,支持多线程并行执行。
      • 在应用端收集日志的话,logstash比较重量级,性能消耗比filebeat大。
    • filebeat用于日志收集和传输,相比Logstash更加轻量级和易部署,对系统资源开销更小。
    • logstash与filebeat来说,支持的数据源更多,且可以对数据进行过滤。

安装部署

其他问题

  1. logstash的时区问题,logstash中的@timestamp时间比我们当前时间相差8个小时

    • 原因,默认情况下logstash生成的时间是使用UTC时间,我们是在UTC+8时区。
    • 解决方案:kibana,在kibana显示的时候会读取浏览器的当前时区,然后在页面上转换时间内容的显示。
  2. multiline异常信息整合

    • 原因: 使用filebeat收集日志会出现一个问题,filebeat默认按行进行日志收集,如果出现一条异常信息占多行,就会把异常信息按行存储。

    • 解决方案: 修改filebeat.yml文件

      • 1
        2
        3
        4
        5
        mutiline:
        # 匹配以20开头以后的信息
        parttern: ^20
        negate: true
        match: after

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×