基于Docker的日志分析平台(四)平台整合

原文链接:https://segmentfault.com/a/1190000012400830

在上一篇中我们基本上完成了 ELK 和 Kafka 环境的安装,并且也通过几个简单的例子入门。现在我们就把搭建好的架构中加入 Kakfa 作为缓冲区。再来说一下,首先 Logstash 从日志源读取日志并且存储到 Kafka,然后 Logstash 再从 Kafka 中读取日志存储到 Elasticsearch。所以我们需要两步骤。

Logstash -> Kafka

Logstash 会直接把日志发送给 Elasticsearch,再由 Kibana 进行展示。因为因为 Logstash 会同步把日志传输到 Elasticsearch ,一旦 ElasticSearch 挂掉数据就有可能会丢失。于是,我们考虑利用 Kafka 作为缓冲区,让 Logstash 不受 Elasticsearch 的影响,第一步就是让 Logstash 把日志发送到 Kafka,这里 Logstash 相当于 Producer。直接来看看 Logstash 的配置文件:

input {
    file {
        path => ["/var/log/laravel/storage/logs/*.log"]
    }
}
filter {
   grok {
        match => {
            "message" => "\[%{TIMESTAMP_ISO8601:logtime}\] %{WORD:env}\.%{LOGLEVEL:level}\: %{GREEDYDATA:msg}"
        }
    }
}
output {
    kafka {
        bootstrap_servers => "kafka:9092"
        topic_id => "laravellog"
    }
}

这里是用来读取 Laravel 项目的日志文件,我们在 input 和 output 中间加入了一个 filter,这是 Logstash的插件,用户格式化读取进来的数据。一般情况下,Laravel的日志文件大概是这样:

[2017-12-05 17:45:07] production.ERROR: 报错接口 {"api":"/admin/sales"}

分为几个部分,分别是日志的记录时间,产生日志的环境,日志的级别,日志的信息以及额外数据。所以我们进行了一个格式化,最后可以让他以 JSON 的形式存储到 Elasticsearch,默认没有 filter 的情况是直接一行存储进去。格式化后的数据就是这样的(部分):

{
    "msg": "接口参数 {\"params\":[]} ",
    "path": "/var/log/fenyong/storage/logs/laravel-2017-12-05.log",
    "level": "ERROR",
    "env": "local",
    "logtime": "2017-12-05 17:54:50"
  }

Kafka -> Elasticsearch

利用 Logstash 从 Kafka 读取数据然后存储到 Elasticsearch,这里 Logstash 作为 Consumer,唯一需要注意的地方是要保证 Topic 的名称一致。

input {
    kafka {
        bootstrap_servers => "kafka:9092"
        topics => ["laravellog"]
    }
}

output {
    elasticsearch {
        hosts => "elasticsearch:9200"
        index => "laravellog"
        user => "elastic"
        password => "changeme"
    }
}

这样我们就完成了从 Logstash 到 Kafka 再到 Elasticsearch 的日志存储,接下来就可以用 Kibana 来展示数据了。
深度截图_选择区域_20171205180030.jpg

至此,我们就成功把 Kafka 加入到日志分析平台的架构中。

展开阅读全文

基于 jenkins 和 docker 的持续集成平台

09-17

软件开发过程中,开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次。如果项目较小,对外部的依赖较小,那么软件集成可能不会是什么问题。但是目前很多软件项目特别是互联网项目面临着需求不明确,系统架构复杂,任务分配混乱等一系列问题,从而给持续集成带来许多麻烦。也给整个项目带来不必要的风险。因此一个有效的持续集成系统越来越重要。rnrn[img=https://img-bbs.csdn.net/upload/201509/17/1442457399_559829.jpg][/img]rnrn个推平台是一个极其复杂的分布式系统,整个系统包含了 RPC 调用,高速缓存,集群同步等各种复杂的场景。整个团队只有二十来个人却维护了近百个模块的开发和测试工作,如果没有一套有效的机制,很难想象如何完成这些任务。持续集成在其中扮演了非常重要的角色,借助于 Git、Docker、Jenkins 以及 Nexus 等工具,我们搭建了自己的持续集成环境,并一步一步的摸索出了自己的最佳实践,这篇文章将会和大家一起分享我们是如何利用这些技术提高团队的生产力的。rnrn个推持续集成系统的组成rnrn使用git作为版本控制库rn相比于同类项目版本系统,git有一项非常显著的优势,就是版本分支(branch)的合并(merge)十分方便。rn使用docker搭建测试环境rn作为一种新型的虚拟化方式,相对于传统的虚拟化方式有着众多的优势。例如,docker虚拟容器的启动可以在秒级实现,并且对系统资源的利用率很高。另外,docker的管理,迁移和扩展也更轻松有效。rn使用jenkins作为持续集成服务器rnJenkins为开发人员提供了非常有效的持续集管理。其强大的插件系统和明确的构建逻辑,使得构建流程的创建非常简便。rnrnDocker在持续集成系统中的作用rnrn测试作为软件项目重要的一环,一般都需要开发团队搭建一套独立的测试系统。但作为持续集成的一个环节,此测试系统又异于一般的测试系统。主要原因为,持续集成测试系统主要用来做回归测试,而且需要支持快速大量的代码升级。基于docker的特性,以及持续集成的需求,个推采用docker为持续集成搭建了一整套测试系统。rnrn镜像准备:docker 的运行基于镜像文件,而每个项目所需的镜像文件又不同。因此需要独立分析每个项目的需求以及未来扩展需要,创建出不同版本的镜像文件。目前,个推主要有4大类镜像,分别支持前端,后端,工具类等项目。以前端为例,个推采用了前后端分离的开发模式,因此此镜像主要用来支持web 前端的服务运行。rnrn服务包准备:为了能在docker里运行所需要的服务,需要docker实例中安装相应的服务包(service package)。 一般有两种方法,一种是将相应的服务包在镜像文件中安装,另一种以docker 卷的形式动态映射到docker实例。 两种方式有其优劣,第一种方式使得每次docker 容器的启动非常迅捷,而第二种方式则更为灵活。这个需要根据不同的需求选择合适的方式。rn下图为docker 在整个持续集成系统中的作用。Jenkins 作为主服务器将代码和docker 统一的管理起来。rnrn[img=https://img-bbs.csdn.net/upload/201509/17/1442457450_326463.png][/img]rnrn个推持续集成流程rnrn下面以user模块为例,对持续集成的流程进行阐述,如下图所示:rnrn[img=https://img-bbs.csdn.net/upload/201509/17/1442457506_60081.png][/img]rnrn从图中可以看出,我们系统的git分支包括dev,master两个分支:rnrndev:开发分支,开发人员维护,开发人员将最新代码提交到这个分支,Jekins监视这个分支,任何代码改变都会触发自动化测试rnmaster:发布分支,这个分支上的版本是自动化测试通过后的版本,且自动化打包监控这个分支rnrn图中的每个长方形代表一个Jenkins Job。下面将对每个Job进行说明:rn• user: 监控user代码库的dev分支,当每次有新的代码提交时,就会自动触发构建任务。编译代码,同时生成code style,测试覆盖率等关于代码质量的报表。成功后将触发user-docker任务。rn• user-docker: 打包user工程,重启user的docker实例以便于使用全新的user包。成功后将触发testcase任务rn• testcase: 验收测试,检测改变是否满足业务需求所定义的验收条件。成功后将触发marge任务rn• merge:将user的dev分支merge到master分支rn• user-pkg: 监控user代码库的master分支,当有代码改变时,执行mvn package打包操作rn经过上面的几个步骤,从代码提交到打包的整个过程就自动化起来了。rnrn总结rnrn目前越来越多的公司开始重视持续集成系统,但是缺乏定制化的系统真的能满足复杂的需求吗?当模块之间的联系越来越复杂,集成的频率越来越大,运行环境的不断升级 等等,缺乏定制的持续集成系统是否能达到预期,个推在docker 上找到了解决方案。 虽然仍然有许多挑战,但随着技术的升级和完善,我们终会越做越好。rn 论坛

没有更多推荐了,返回首页