亿级日志平台实践

本篇主要讲工作中的真实经历，我们怎么打造亿级日志平台，同时手把手教大家建立起这样一套亿级 ELK 系统。日志平台具体发展历程可以参考上篇 「从 ELK 到 EFK 演进」

废话不多说，老司机们座好了，我们准备发车了~~~

整体架构

整体架构主要分为 4 个模块，分别提供不同的功能

Filebeat：轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说：Filebeat就是新版的 Logstash-fowarder，也会是 ELK Stack 在 Agent 的第一选择。

Kafka: 数据缓存队列。作为消息队列解耦了处理过程，同时提高了可扩展性。具有峰值处理能力，使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

Logstash ：数据收集处理引擎。支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储以供后续使用。

Elasticsearch ：分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析，并能将这三者结合起来。Elasticsearch 基于 Lucene 开发，现在使用最广的开源搜索引擎之一，Wikipedia 、StackOverflow、Github 等都基于它来构建自己的搜索引擎。

Kibana ：可视化化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。

版本说明

Filebeat: 6.2.4
Kafka: 2.11-1
Logstash: 6.2.4
Elasticsearch: 6.2.4
Kibana: 6.2.4

相应的版本最好下载对应的插件

具体实践

我们就以比较常见的 Nginx 日志来举例说明下，日志内容是 JSON 格式

{"@timestamp":"2017-12-27T16:38:17+08:00","host":"192.168.56.11","clientip":"192.168.56.11","size":26,"responsetime":0.000,"upstreamtime":"-","upstreamhost":"-","http_host":"192.168.56.11","url":"/nginxweb/index.html","domain":"192.168.56.11","xff":"-","referer":"-","status":"200"}
{"@timestamp":"2017-12-27T16:38:17+08:00","host":"192.168.56.11","clientip":"192.168.56.11","size":26,"responsetime":0.000,"upstreamtime":"-","upstreamhost":"-","http_host":"192.168.56.11","url":"/nginxweb/index.html","domain":"192.168.56.11","xff":"-","referer":"-","status":"200"}
{"@timestamp":"2017-12-27T16:38:17+08:00","host":"192.168.56.11","clientip":"192.168.56.11","size":26,"responsetime":0.000,"upstreamtime":"-","upstreamhost":"-","http_host":"192.168.56.11","url":"/nginxweb/index.html","domain":"192.168.56.11","xff":"-","referer":"-","status":"200"}
{"@timestamp":"2017-12-27T16:38:17+08:00","host":"192.168.56.11","clientip":"192.168.56.11","size":26,"responsetime":0.000,"upstreamtime":"-","upstreamhost":"-","http_host":"192.168.56.11","url":"/nginxweb/index.html","domain":"192.168.56.11","xff":"-","referer":"-","status":"200"}
{"@timestamp":"2017-12-27T16:38:17+08:00","host":"192.168.56.11","clientip":"192.168.56.11","size":26,"responsetime":0.000,"upstreamtime":"-","upstreamhost":"-","http_host":"192.168.56.11","url":"/nginxweb/index.html","domain":"192.168.56.11","xff":"-","referer":"-","status":"200"}

Filebeat

为什么用 Filebeat ，而不用原来的 Logstash 呢？

原因很简单，资源消耗比较大。

由于 Logstash 是跑在 JVM 上面，资源消耗比较大，后来作者用 GO 写了一个功能较少但是资源消耗也小的轻量级的 Agent 叫 Logstash-forwarder。

后来作者加入 elastic.co 公司， Logstash-forwarder 的开发工作给公司内部 GO 团队来搞，最后命名为 Filebeat。

Filebeat 需要部署在每台应用服务器上，可以通过 Salt 来推送并安装配置。

下载

$ wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.2.4-darwin-x86_64.tar.gz

解压

tar -zxvf filebeat-6.2.4-darwin-x86_64.tar.gz
mv filebeat-6.2.4-darwin-x86_64 filebeat
cd filebeat

修改配置

修改 Filebeat 配置，支持收集本地目录日志，并输出日志到 Kafka 集群中

$ vim fileat.yml
filebeat.prospectors:
- input_type: log
  paths:
    -  /opt/logs/server/nginx.log
  json.keys_under_root: true
  json.add_error_key: true
  json.message_key: log

output.kafka:
  hosts: ["192.168.0.1:9092，192.168.0.2:9092，192.168.0.3:9092"]
  topic: ‘nginx‘

Filebeat 6.0 之后一些配置参数变动比较大，比如 document_type 就不支持，需要用 fields 来代替等等。

启动

$ ./filebeat -e -c filebeat.yml

Kafka

生产环境中 Kafka 集群中节点数量建议为（2N + 1 ）个，这边就以 3 个节点举例

下载

直接到官网下载 Kafka

$ wget http://mirror.bit.edu.cn/apache/kafka/1.0.0/kafka_2.11-1.0.0.tgz

解压

tar -zxvf kafka_2.11-1.0.0.tgz
mv kafka_2.11-1.0.0 kafka
cd kafka

修改 Zookeeper 配置

修改 Zookeeper 配置，搭建 Zookeeper 集群，数量 ( 2N + 1 ) 个

ZK 集群建议采用 Kafka 自带，减少网络相关的因素干扰

$ vim zookeeper.properties

tickTime=2000
dataDir=/opt/zookeeper
clientPort=2181
maxClientCnxns=50
initLimit=10
syncLimit=5

server.1=192.168.0.1:2888:3888
server.2=192.168.0.2:2888:3888
server.3=192.168.0.3:2888:3888

Zookeeper data 目录下面添加 myid 文件，内容为代表 Zooekeeper 节点 id （1，2，3），并保证不重复

$ vim /opt/zookeeper/myid
1

启动 Zookeeper 节点

分别启动 3 台 Zookeeper 节点，保证集群的高可用

$ ./zookeeper-server-start.sh -daemon ./config/zookeeper.properties

修改 Kafka 配置

kafka 集群这边搭建为 3 台，可以逐个修改 Kafka 配置，需要注意其中 broker.id 分别 （1，2，3）

$ vim ./config/server.properties
broker.id=1
port=9092
host.name=192.168.0.1
num.replica.fetchers=1
log.dirs=/opt/kafka_logs
num.partitions=3
zookeeper.connect=192.168.0.1: 192.168.0.2: 192.168.0.3:2181
zookeeper.connection.timeout.ms=6000
zookeeper.sync.time.ms=2000
num.io.threads=8
num.network.threads=8
queued.max.requests=16
fetch.purgatory.purge.interval.requests=100
producer.purgatory.purge.interval.requests=100
delete.topic.enable=true

启动 Kafka 集群

分别启动 3 台 Kafka 节点，保证集群的高可用

$ ./bin/kafka-server-start.sh -daemon ./config/server.properties

查看 topic 是否创建成功

$ bin/kafka-topics.sh --list --zookeeper localhost:2181

nginx

监控 Kafka Manager

Kafka-manager 是 Yahoo 公司开源的集群管理工具。

可以在 Github 上下载安装：https://github.com/yahoo/kafka-manager

如果遇到 Kafka 消费不及时的话，可以通过到具体 cluster 页面上，增加 partition。Kafka 通过 partition 分区来提高并发消费速度

Logstash

Logstash 提供三大功能

  • INPUT 进入
  • FILTER 过滤功能
  • OUTPUT 出去

如果使用 Filter 功能的话，强烈推荐大家使用 Grok debugger 来预先解析日志格式。

下载

$ wget https://artifacts.elastic.co/downloads/logstash/logstash-6.2.4.tar.gz

解压重命名

$ tar -zxvf logstash-6.2.4.tar.gz
$ mv logstash-6.2.4 logstash

修改 Logstash 配置

修改 Logstash 配置，使之提供 indexer 的功能，将数据插入到 Elasticsearch 集群中

$ vim nginx.conf

input {
  kafka {
    type => "kafka"
    bootstrap_servers => "192.168.0.1:2181,192.168.0.2:2181,192.168.0.3:2181"
    topics => "nginx"
    group_id => "logstash"
    consumer_threads => 2
  }
}

output {
  elasticsearch {
    host => ["192.168.0.1","192.168.0.2"，"192.168.0.3"]
    port => "9300"
    index => "nginx-%{+YYYY.MM.dd}"
  }
}

启动 Logstash

$ ./bin/logstash -f nginx.conf

Elasticsearch

下载

$ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.2.4.tar.gz

解压

$ tar -zxvf elasticsearch-6.2.4.tar.gz
$ mv elasticsearch-6.2.4.tar.gz elasticsearch

修改配置

$ vim config/elasticsearch.yml

cluster.name: es
node.name: es-node1
network.host: 192.168.0.1
discovery.zen.ping.unicast.hosts: ["192.168.0.1"]
discovery.zen.minimum_master_nodes: 1

启动

通过 -d 来后台启动

$ ./bin/elasticsearch -d

打开网页 http://192.168.0.1:9200/, 如果出现下面信息说明配置成功

{
    name: "es-node1",
    cluster_name: "es",
    cluster_uuid: "XvoyA_NYTSSV8pJg0Xb23A",
    version: {
        number: "6.2.4",
        build_hash: "ccec39f",
        build_date: "2018-04-12T20:37:28.497551Z",
        build_snapshot: false,
        lucene_version: "7.2.1",
        minimum_wire_compatibility_version: "5.6.0",
        minimum_index_compatibility_version: "5.0.0"
    },
    tagline: "You Know, for Search"
}

控制台

Cerebro 这个名字大家可能觉得很陌生，其实过去它的名字叫 kopf ！因为 Elasticsearch 5.0 不再支持 site plugin，所以 kopf 作者放弃了原项目，另起炉灶搞了 cerebro，以独立的单页应用形式，继续支持新版本下 Elasticsearch 的管理工作。

注意点

  1. Master 与 Data 节点分离，当 Data 节点大于 3 个的时候，建议责任分离，减轻压力
  2. Data Node 内存不超过 32G ，建议设置成 31 G ，具体原因可以看上一篇文章
  3. discovery.zen.minimum_master_nodes 设置成 （ total / 2 + 1 ），避免脑裂情况
  4. 最重要的一点，不要将 ES 暴露在公网中，建议都安装 X-PACK ，来加强其安全性

kibana

下载

$ wget https://artifacts.elastic.co/downloads/kibana/kibana-6.2.4-darwin-x86_64.tar.gz

解压

$ tar -zxvf kibana-6.2.4-darwin-x86_64.tar.gz
$ mv kibana-6.2.4-darwin-x86_64.tar.gz kibana

修改配置

$ vim config/kibana.yml

server.port: 5601
server.host: "192.168.0.1"
elasticsearch.url: "http://192.168.0.1:9200"

启动 Kibana

$ nohup ./bin/kibana &

界面展示

创建索引页面需要到 Management -> Index Patterns 中通过前缀来指定

最终效果展示

总结

综上，通过上面部署命令来实现 ELK 的整套组件，包含了日志收集、过滤、索引和可视化的全部流程，基于这套系统实现分析日志功能。同时，通过水平扩展 Kafka、Elasticsearch 集群，可以实现日均亿级的日志实时处理。


所有好的架构设计首要的原则并不是追求先进，而是合理性，要与公司的业务规模和发展趋势相匹配，任何一个公司，哪怕是现在看来规模非常大的公司，比如 BAT 之类，在一开始，其系统架构也应简单和清晰的。

但随着业务范围不断扩充，业务规模不断扩大，系统渐进复杂和庞大，让所有系统都遇到高可用的问题。那我们该如何避免类似的问题，构建高可用系统呢？

为此我特意写了一个专栏《带你玩转高可用》，将多年来在百度和沪江的架构设计实战经验，集结成这个专栏。

本专栏总共包含 15 篇文章，分成三大模块详细解释高可用架构的相关知识：

概念篇：介绍高可用架构理论与演进，这块比较偏理论。不过对于我们理解整套体系还是有必须的。
工程篇：介绍常见互联网分层中每一层高可用是怎么做的，包含 DNS、服务层、缓存层、数据层等
问题篇：介绍怎么排查线上常用的故障，包括机器、应用层等维度故障定位
专栏每周都会更新，持续 64 天。在这将近 2 个月内，我会带着大家去全面了解高可用架构的方方面面，同时会将遇到的这些问题和对应的解决方案抛出来，希望大家不要重复我遇到过的坑。同时也期待大家提出有意思的问题。

专栏地址：带你玩转高可用

原文地址：http://blog.51cto.com/13527416/2117141

时间： 2024-10-31 18:05:02

亿级日志平台实践的相关文章

支撑微博亿级社交平台，小白也能玩转Redis集群(原理篇)

Redis作为一款性能优异的内存数据库,支撑着微博亿级社交平台,也成为很多互联网公司的标配.这里将以Redis Cluster集群为核心,基于最新的Redis5版本,从原理再到实战,玩转Redis集群 常见Redis集群方案 在介绍Redis Cluster集群方案之前,为了方便对比,先简单了解一下业界常见的Redis集群方案: 1 基于客户端分片 Redis Sharding是Redis Cluster出来之前,业界普遍使用的多Redis实例集群方法.其主要思想是基于哈希算法,根据Redis数

万亿级日志与行为数据存储查询技术剖析（续）——Tindex是改造的lucene和druid

五.Tindex 数果智能根据开源的方案自研了一套数据存储的解决方案,该方案的索引层通过改造Lucene实现,数据查询和索引写入框架通过扩展Druid实现.既保证了数据的实时性和指标自由定义的问题,又能满足大数据量秒级查询的需求,系统架构如下图,基本实现了文章开头提出的几个目标. (点击放大图像) Tindex主要涉及的几个组件 Tindex-Segment,负责文件存储格式,包括数据的索引和存储,查询优化,以及段内数据搜索与实时聚合等.Tindex是基于Lucene的思想重构实现的,由于Luc

万亿级日志与行为数据存储查询技术剖析——Hbase系预聚合方案、Dremel系parquet列存储、预聚合系、Lucene系

转自:http://www.infoq.com/cn/articles/trillion-log-and-data-storage-query-techniques?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage 目前大数据存储查询方案大概可以分为:Hbase系.Dremel系.预聚合系.Lucene系,笔者就自身的使用经验说说这几个系

构建类微博的亿级社交平台高性能Redis技术精讲

课程目标本课程将为读者讲解Redis数据库的安装与使用,其核心目的是为了集群开发进行铺垫. 适用人群系统架构人员 集群开发工程师 WEB工程师 课程简介     Redis是现在最流行的缓存数据库,利用Redis可以实现10W/秒的数据操作,利用Redis可以解决高并发的数据访问问题,同时Redis又可以与许多的集群架构进行整合处理.     在本课程之中,将为读者完整的讲解Redis的编译.部署操作,同时会详细的讲解在Redis之中支持的各种数据类型操作,同时在本课程之中为了更好的与后续的集群

PPT下载 | 亿级用户万台服务器背后，vivo云服务容器化如何破茧化蝶？

2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期.本次技术沙龙vivo.中兴通讯.华为.数人云共同派出技术大咖,为开发者们带来有关微服务.容器化.配置中心.服务网格等领域的实战与干货分享. 数人云Meetup每月一期,欢迎大家来面基.学习.本文为vivo云计算架构师袁乐林分享的"vivo云服务容器化实践"现场演讲实录. 今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架

亿级用户万台服务器背后，vivo云服务容器化如何破茧化蝶？

2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期.本次技术沙龙vivo.中兴通讯.华为.数人云共同派出技术大咖,为开发者们带来有关微服务.容器化.配置中心.服务网格等领域的实战与干货分享. 数人云Meetup每月一期,欢迎大家来面基.学习.本文为vivo云计算架构师袁乐林分享的"vivo云服务容器化实践"现场演讲实录. 今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架

【方案】去哪儿网徐磊：如何利用开源技术构建日处理130亿+的实时日志平台？

转自:http://mp.weixin.qq.com/s?__biz=MzIzMzEzODYwOA==&mid=2665284466&idx=1&sn=2b06a529821734e36e26e642424f24fc&scene=2&srcid=0527p3qISp6dFqGg8iLIYgRF&from=timeline&isappinstalled=0#wechat_redirect [本文系互联网技术联盟(ITA1024)原创首发,转载或节选内容

千亿级数量下日志分析系统的技术架构选型

?? 随着数据已经逐步成为一个公司宝贵的财富,大数据团队在公司往往会承担更加重要的角色.大数据团队往往要承担数据平台维护.数据产品开发.从数据产品中挖掘业务价值等重要的职责.所以对于很多大数据工程师,如何根据业务需求去选择合适的大数据组件,做合适的大数据架构工作就是日常工作中最常遇到的问题.在这里根据七牛云在日增千亿级的日志分析工作,和大家分享一下大数据技术架构选型的一些经验.? 大数据架构师在关注什么 ?在一个大数据团队中,大数据架构师主要关注的核心问题就是技术架构选型问题.架构选型问题一般会

亿级日PV的魅族云同步的核心协议与架构实践(转)

云同步的业务场景 这是魅族云同步的演进,第一张是M8.M9,然后到后面的是MX系统,M9再往后发展,我们的界面可以看到基本上是没有什么变化的,但本质发生了很大的变化,我们经过了一些协议优化,发展到今天的魅族云同步. 这是云服务对应的网页端,界面非常简洁,可以看到正中间我们有4个模块,提供一些传统数据的讨论,不得不提一下这边的查手机,我们通过它帮一些客户找到了他的手机,它的功能是很强大的,可以定位位置,还可以进行一些拍照. 我们的业务发展了这么多年,一个是手机端,一个是网页端,都说搞技术的是非常寂