您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

日志服务架构设计

时间:2019-09-19 08:40:46  来源:  作者:

最近想把之前做过的日志项目及个人的思考梳理一下,于是有了本文。

背景

我们这边应用部署的环境比较复杂,主要有以下几种:

  • 机器直接部署
  • 通过原生Docker部署
  • 通过kubernates集群部署

部署环境不统一,导致查看应用日志很不方便。

业务需求

与部署环境对应,对于日志收集需求分为以下几类:

  • 机器上的文本日志(直接运行在物理机或者虚拟机中的应用日志)
  • 运行在docker容器中的应用日志
  • 运行在kubernates集群中的应用日志

具体业务需求可以拆分为:

  • 按照项目、应用、实例维度检索日志并支持搜索关键字高亮(因为大家检索日志的时候,肯定是检索某个项目、某个应用、某个实例的日志)
  • 支持检索出某条想要的日志后,可以查看上下文(查看该日志所在日志文件的日志上下文)
  • 支持日志下载(目前支持两种场景:搜索结果下载、上下文下载;支持两种方式:在线下载、离线下载)
  • 支持自动化批量部署、卸载Agent,部署、卸载过程可视化
  • 单实例支持多elasticsearch集群
  • 支持文本日志、docker日志、k8s日志并能与将日志与其业务意义对应上。(即不管是哪种日志形式、来源,最终都需要与业务意义上的项目、应用、实例对应起来,因为对于日志的使用者来说,查询日志的出发点肯定是查询某个项目、某个应用(可以不选)、某个实例(可以不选)、某段时间的日志。)
  • 支持部署到业务自己的集群中

需求已经明确了,下面看一下业界方案。

业界日志系统架构

日志服务架构设计

 

  • Collector的作用是:
  • 清洗、汇聚数据,减少对于后端集群的压力。
  • 安全,不允许Agent直连kafka等内部集群,保证一定的安全性,即使后端发生调整也能保证对于Agent连接、认证方式的稳定。
  • MQ的作用是削峰填谷、解耦、多次消费。

上图的架构是业界比较通用的一种架构,对于各种场景都考虑的比较全。

既然业界的架构已经这么完备,那么我们是否就直接采用呢?

对于我们而言,有以下几个问题:

  • 涉及的组件比较多,链路比较长,运维比较麻烦
  • 这一整套架构,不利于单独部署(比如某个业务应用部署机房网络是隔离的,而且项目又不大,只能提供有限的几台机器,这时候如果需要部署业界这套架构的话,资源就会比较受限,如果想做到即支持业界架构组件的可插拔(比如可灵活的决定是否需要Collector、MQ),那么就需要运维几套配置或代码)
  • 最关键的就是其中组件提供的功能,我们目前用不到。比如MQ的削峰填谷、多次消费。

组件选择

选择组件,我们这边主要是从以下几个方面进行考量的:

  1. 组件对应的开源生态完整、活跃度高
  2. 对应的技术栈是我们所熟悉的,我们这边语言技术栈主要是JAVA、Go,如果组件语言是C、Ruby,应该就被排除了。
  3. 运维成本
  4. 易部署、性能好

Agent

一提到日志收集方案,大家第一个想到的肯定是ELK(Elasticsearch、Logstash、Kibana ),但Logstash依赖于JVM不管是性能还是简洁性,都不是日志收集agent的首选。

个人感觉一个好的agent应该是资源占用少,性能好,不依赖别的组件,可以独立部署。而Logstash明显不符合这几点要求,也许正是基于这些考虑elastic推出了Filebeat。

Collector、MQ

Elasticsearch集群在部署的时候,一般都是提前估计好容量、机器、shard等信息,因为Elasticsearch集群运行后,再水平拓展,比较麻烦,而我们这边由于业务及成本限制无法很好的预估容量,所以就结合公司实际要求:使用日志服务的业务方自带机器,也就是业务方会有独立的Elasticsearch集群。

每个业务方都使用自己的Elasticsearch集群,所以集群压力不会很大,从而Collector、MQ这两个组件对于我们的作用也就很小了。

ETL

因为Elasticsearch Ingest Node完全可以满足我们的解析需求,所以就没有必要再引入Logstash等相关组件了。

到这里,基本可以看出我们的架构如下:

日志服务架构设计

 

架构设计的几个原则:

  • 合适优于业界领先
  • 简单优于复杂
  • 演化优于一步到位

具体实现

基于需求及EFK套件,梳理我们场景中特有的东西:

  • docker日志的场景比较单一,都是通过之前一个产品A发布部署的,其docker命名规则比较统一,可以通过截取docker.container.name来获取应用名字;同时在部署的时候,可以知道部署目标机器的ip,这样就可以通过应用+ip来作为实例名称。
  • k8s场景也比较统一,都是通过之前一个产品B发布部署的,其pod命名规则比较统一,可以通过截取kubernetes.pod.name来获取应用名字(但需要通过namespaces关联到tenant,再通过tenant与项目一一对应);k8s中的pod.name就是唯一的,以此来作为实例名称即可。
  • 文本日志:因为文本日志主要的场景是已经裸机部署的应用,这种场景下,不存在应用自动迁移的情况,所以文本日志的应用名称、实例名称可以在部署的时候打上标签即可。

具体规则及解析见下图(实例部分处理暂未标注):

日志服务架构设计

 

推荐写日志到文本文件中,使用标准输出就好。

到这里可以发现我们选择Filebeat来作为日志的收集端,Elasticsearch来存储日志并提供检索能力。

那么,日志的清洗在哪里做呢?

日志的清洗一般有两种方式:

  • 先把日志收集到kafka,再通过Logstash消费kafka的数据,来清洗数据
  • 直接通过Elasticsearch的[Ingest Node]来清洗数据,因为Ingest Node也支持Grok表达式

对于,我们的场景而言,我们需要清洗数据的要求比较简单,主要是应用、实例名称的截取还有文本日志中日志时间的处理(@timestamp重置,时区处理),所以我们选择了方案2。

在我们的方案中,并没有提供Kibana 的界面直接给用户用,而是我们自己根据公司业务独立开发的。

前端界面为什么不采用Kibana,而需要自己开发?

  1. kibana对于业务开发人员有一定的学习成本
  2. kibana界面没有很好的将日志内容与业务意义关联起来(界面选择总比一次次的输入要好,这也是我们将日志的项目、应用、实例等业务信息解析出来的原因)
  3. log-search支持Query String,因此对于熟悉kibana的开发人员来说,在我们自己开发的前端界面检索效果是一样的。

log-search提供的功能可以参见github:github.com/jiankunking…

如果日志需要清洗的比较多,可以采用方案1,或者先不清洗,先把数据落到Elasticsearch,然后在查询的时候,进行处理。比如在我们的场景中,可以先把日志落到Elasticsearch中,然后在需要检索应用名称的时候,通过代码来处理并获取App名字。

监控、告警

其实基于日志可以做很多事情,比如:

  • 基于日志做监控(google Dapper)
  • 基于日志做告警
  • 基于日志做machine Learning

具体思路,可以参见下图:

日志服务架构设计

 

前提:能要求使用方,按照某种规则打印日志。 监控发展:监控基本就是先打通链路trace,然后再在上报信息或者日志信息中,加强业务方面标识,即给监控添加业务维度方面的视角。

其它

DaemonSet

以DaemonSet方式部署Filebeat来收集日志,其实收集也是宿主机/var/lib/docker/containers目录下的日志。 Running Filebeat on Kubernetes

Sidecar

一个POD中运行一个sidecar的日志agent容器,用于采集该POD主容器产生的日志。

莫名想起了istio。

Filebeat可以以sidecar模式来进行容器日志的收集,也就是filebeat和具体的服务容器部署在同一个pod内,指定收集日志的路径或文件,> 即可将日志发送到指定位置或Elasticsearch这类的搜索引擎。 每个pod内部署filebeat的模式,好处是和具体的应用服务低耦合,可扩展性强,不过需要在yaml进行额外配置。



Tags:架构设计   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
背景在日常工作中,我们通常需要存储一些日志,譬如用户请求的出入参、系统运行时打印的一些info、error之类的日志,从而对系统在运行时出现的问题有排查的依据。日志存储和检索...【详细内容】
2021-11-23  Tags: 架构设计  点击:(22)  评论:(0)  加入收藏
如何设计一个好的软件架构,如何提高软件的扩展性,移植性,复用性和可读性?很多做嵌入式开发的朋友经常会遇到这种情况:一个项目软件设计完成了,客户提出了一些新的功能需求。这时侯...【详细内容】
2021-11-08  Tags: 架构设计  点击:(35)  评论:(0)  加入收藏
1、网络架构总体说明为了方便网络管理,园区网络通常按照功能或业务进行分层分区设计,园区内部网络包括终端层、接入层、汇聚层、核心层、出口区,园区外部的其他园区、分支、出...【详细内容】
2021-08-17  Tags: 架构设计  点击:(89)  评论:(0)  加入收藏
一:业务背景优惠券是电商常见的营销手段,具有灵活的特点,既可以作为促销活动的载体,也是重要的引流入口。优惠券系统是vivo商城营销模块中一个重要组成部分,早在15年vivo商城还是...【详细内容】
2021-08-06  Tags: 架构设计  点击:(74)  评论:(0)  加入收藏
组织结构是企业的骨架,是实现战略目标的载体,是企业运营的支撑,是岗位设置的依据,是企业信息流的渠道。如果企业缺乏合理的组织结构,就会造成分工不明确、权责不清楚、沟通渠道不...【详细内容】
2021-06-08  Tags: 架构设计  点击:(120)  评论:(0)  加入收藏
1. 前言嵌入式是软件设计领域的一个分支,它自身的诸多特点决定了系统架构师的选择,同时它的一些问题又具有相当的通用性,可以推广到其他的领域。提起嵌入式软件设计,传统的印象...【详细内容】
2021-04-15  Tags: 架构设计  点击:(250)  评论:(0)  加入收藏
背景考拉安全部技术这块目前主要负责两块业务:一个是内审,主要是通过敏感日志管理平台搜集考拉所有后台系统的操作日志,数据导入到es后,结合storm进行实时计算,主要有行为查询、...【详细内容】
2021-04-01  Tags: 架构设计  点击:(260)  评论:(0)  加入收藏
简介: 作为一名Java程序员,相信同学们都听说过微内核架构设计,也有自己的理解。那么微内核是如何被提出来的?微内核在操作系统内核的设计中又有什么作用?本文从插件化(Plug-in)架...【详细内容】
2021-02-24  Tags: 架构设计  点击:(158)  评论:(0)  加入收藏
由于多年前开发了一款聊天软件,今天朋友给我打电话,说他们公司准备开发一款内部使用的沟通交流工具,找我咨询关于即时聊天软件一些经验,于是跟他聊了一些关于这方面的东西,所以在...【详细内容】
2020-12-22  Tags: 架构设计  点击:(284)  评论:(0)  加入收藏
Nginx+Redis+MQ+DB下秒杀实现原理 Nginx+Redis+MQ+DB下限购实现原理 Nginx+Redis+MQ+DB下亿级流量实现原理 Redis在架构中的意义 分布式微服务是快了还是慢了 高可用和可用...【详细内容】
2020-12-22  Tags: 架构设计  点击:(365)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(5)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(9)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(21)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(17)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(17)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条