日志实体类信息包括哪些内容?

Python025

日志实体类信息包括哪些内容?,第1张

日志实体类信息包括哪些内容?组件选择

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

组件对应的开源生态完整、活跃度高

对应的技术栈是我们所熟悉的,我们这边语言技术栈主要是Java、Go,如果组件语言是C、Ruby,应该就被排除了。

运维成本

易部署、性能好

1、Agent

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

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

2、Collector、MQ

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

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

3、ETL

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

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

架构合适的,就是最好的。

三、业务需求

我们这边收集日志应对的场景主要是:文本日志、docker日志、k8s日志,恰恰这些EFK全家桶都支持。

我们希望日志收集产品可以满足以下几个需求:

按照项目、应用、实例维度检索日志并支持搜索关键字高亮(因为大家检索日志的时候,肯定是检索某个应用、某个实例的日志)

支持检索出某条想要的日志后,可以查看上下文(查看该日志所在日志文件的前后多少条)

支持日志下载(目前支持两种场景:搜索结果下载、上下文下载;支持两种方式:在线下载、离线下载)

支持Elasticsearch Query String查询

支持自动化批量部署、卸载Filebeat,部署、卸载过程可视化

单实例支持多elasticsearch集群

支持文本日志、docker日志、k8s日志并能与将日志与其业务意义对应上。(即不管是哪种日志形式、来源,最终都需要与业务意义上的项目、应用、实例对应起来,因为对于日志的使用者来说,查询日志的出发点肯定是查询某个项目、某个应用(可以不选)、某个实例(可以不选)、某段时间的日志。)

四、具体实现

基于需求及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:log-search

https://github.com/jiankunking/log-search

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

五、监控、告警

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

基于日志做监控(Google Dapper)

基于日志做告警

基于日志做Machine Learning

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

前提:能要求使用方,按照某种规则打印日志。

监控发展:监控基本就是先打通链路trace,然后再在上报信息或者日志信息中,加强业务方面标识,即给监控添加业务维度方面的视角。

六、其它

1、DaemonSet

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

Running Filebeat on Kubernetes

2、Sidecar

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

莫名想起了istio。

Filebeat可以以sidecar模式来进行容器日志的收集,也就是filebeat和具体的服务容器部署在同一个pod内,指定收集日志的路径或文件,即可将日志发送到指定位置或Elasticsearch这类的搜索引擎。

每个pod内部署filebeat的模式,好处是和具体的应用服务低耦合,可扩展性强,不过需要在yaml进行额外配置。

3、业界案例分享

InfoQ运维大会日志处理专题演讲干货合集

曹林华-沪江网日志平台化之路

黎吾平-日志分析场景下的搜索引擎改进

林冰玉-QA 与Ops通力打造反脆弱的软件系统

周辉-新思路打造移动端个案综合日志分析系统

个人微信公众号:

作者:jiankunking 出处:http://blog.csdn.net/jiankunking

展开全文

APM:ELK 与 Prometheus

同为监控应用的两个平台,Prometheus和ELK的对比: ELK和Prometheus的对比 Prometheus ELK 轻量、部署相对简单 较重,组件较多,部署起来较麻烦 使用灵活,需要使用者会灵活运用 上手较为简单 适用于短期使用,比如SIT测试 适用于长久稳定地运行 ...

APP打开

Linux下常见的日志文件名

Linux常见的日志文件名: /var/log/cron 工作调度 /var/log/dmesg 内核检测过程中产生的信息 /var/log/lastlog 检测所有账号登陆信息 /var/log/maillog或/var/log/mail/* 邮件 /var/log/messages 记录系统发生的所有错误信息 /var/log/secure 涉及账号密码信息 /var/log/w...

APP打开

评论(23)

写评论

码工邢美玲码龄4年

哇啊1年前

刘佳欢--hannah码龄5年

谢谢分享1年前

衣舞晨风码龄10年

回复刘佳欢--hannah:愿能对你有所帮助

1年前

xudc码龄10年

学习了1年前

mortredly码龄1年

很优秀啊1年前

LaLaLa_OvO码龄10年

我现在每次去生产环境下载tomcat里的log文件分析,感觉好麻烦Ծ‸Ծ,感谢博主提供的思路,虽然一下子没太懂,但是研究下应该可以理解的1年前

码哥Think—Coder码龄3年

厉害1年前

fightsyj码龄4年

优秀1年前

叄拾叄画生码龄2年

不错1年前

qq_45010093码龄1年

我要下载码1年前

衣舞晨风码龄10年

回复qq_45010093:???

1年前

码农凉快-Eric码龄3年

日志很重要,在下需努力!1年前

去APP查看全部评论

SpringBoot控制台彩色输出

#控制台彩色输出 spring: output: ansi: enabled: ALWAYS SpringBoot控制台彩色输出

APP打开

分布式系统中的日志落地经验总结

@分布式系统中的日志落地经验总结 在过去的2年多的时间里,随着在公司推进容器云,陆陆续续的和日志打了不少交道,在这里做一个总结: 为什么需要日志 日志如何接收与存储 日志如何收集 日志收集客户端分析 日志的标准化 日志报警 日志归档 其他问题 为什么需要日志 日志的作用我觉得有三点: 故障排错 数据分析 业务审计 1,关于故障排错,当线上发生异常,查看应用的错误日志、堆栈信息、代理层的访问...

APP打开

关于日志的那些事儿 - 樱木天亥 - CSDN博客

写这篇文章是源于耗子叔在左耳听风专栏的群里发布了命题作文「关于日志的那些事儿」,正好可以去查阅资料,学习了解一下日志方面的知识。 什么是日志 首先,什么是...

关于日志的那些事儿_xiemanR的专栏-CSDN博客

关于日志的那些事儿 日志的作用 1.审计 商业分析:比如从日志中提取用户行为(比如,一个点击事件流)并结合用户的其他详情(比如,最终购买行为)来生成报告或者推荐相关...

如何打一手好Log

如果项目上过线的话,那你一定知道Log是多么重要。 为什么说Log重要呢?因为上线项目不允许你调试,你只能通过Log来分析问题。这时打一手好Log的重要性绝不亚于写一手好代码。项目出问题时,你要能拿出Log证明自己负责的部分没有问题,如果是自己的问题,要从Log里快速找出错误原因。如果没有从Log里找出错误原因,那一定是一件很悲催的事情,特别是在bug不容易重现的情况下。那简直...

APP打开

关于日志那些事

关于日志那些事 对于现在的应用程序来说,日志的重要性是不言而喻的。很难想象没有任何日志记录功能的应用程序运行在生产环境中。日志所能提供的功能是多种多样的,包括记录程序运行时产生的错误信息、状态信息、调试信息和执行时间信息等。在生产环境中,日志是查找问题来源的重要依据。本文从日志的定义、作用、分类、级别等角度介绍日志。 什么是日志 日志是用来保存系统发生的事件信息和各种对象执行的操作信息的管理对象...

APP打开

关于日志的那些事儿 - weixin_34416754的博客 - CSDN博客

写这篇文章是源于耗子叔在左耳听风专栏的群里发布了命题作文「关于日志的那些事儿」,正好可以去查阅资料,学习了解一下日志方面的知识。 什么是日志 首先,什么是...

Filebeat 收集日志的那些事儿_360技术-CSDN博客

点击蓝字关注我们最近因为云原生日志收集的需要,我们打算使用Filebeat作为容器日志收集工具,并对其进行二次开发,因此笔者将谈谈 Filebeat 收集日志的那些事儿。本文不...

一起来学 SpringBoot 2.x | 第三篇:SpringBoot 日志配置

点击上方“芋道源码”,选择“置顶公众号”技术文章第一时间送达!源码精品专栏 精尽 Dubbo 原理与源码专栏( 已经完成 69+ 篇,预计总共 75+ 篇 )中文详细注释...

APP打开

写日志的那些事儿

2019独角兽企业重金招聘Python工程师标准>>>...

APP打开

Filebeat 收集日志的那些事儿_weixin_48726650的博客-CSDN博客

Filebeat 收集日志的那些事儿 1前言 开源日志收集组件众多,之所以选择Filebeat,主要基于以下几点: 功能上能满足我们的需求:收集磁盘日志文件,发送到Kafka集群支持多行...

Filebeat 收集日志的那些事儿_HULK一线技术杂谈-CSDN博客

女主宣言最近因为云原生日志收集的需要,我们打算使用Filebeat作为容器日志收集工具,并对其进行二次开发,因此笔者将谈谈 Filebeat 收集日志的那些事儿。本文不涉及过...

日志记录的作用和方法 java

程序中记录日志一般有两个目的:Troubleshooting和显示程序运行状态。好的日志记录方式可以提供我们足够多定位问题的依据。日志记录大家都会认为简单,但如何通过日志可以高效定位问题并不是简单的事情。这里列举下面三个方面的内容,辅以代码示例,总结如何写好日志,希望对他人有所启发和帮助: 怎样记日志可以方便Troubleshooting程序运行状态可以记哪些应该避免怎样的日志方

APP打开

JB的ARTS之旅-关于日志的那些事

前言 很多小伙伴看到标题,可能会有疑问,什么叫ARTS?,这里答疑一下: 这是来自于左耳朵耗子专栏的一个活动,详情请来到某乎了解; 而ARTS实际意义是: 1.Algorithm:每周至少做一个 leetcode 的算法题 2.Review:阅读并点评至少一篇英文技术文章 3.Tip:学习至少一个技术技巧 4.Share:分享一篇有观点和思考的技术文章 复制代码 因精力有限,暂时只能挑一个完成,希...

APP打开

运维的那些事儿 - 狂生小白的博客 - CSDN博客

十二、应用系统日志 这里边可分析的东西就多了, 不过...人工智能那些事儿0.目录那些有意思的事儿那些数学的...关于思维导图的那些事 阅读数 529 前言:经过米老...

写评论

23

9

82

分享

APP内打

http://xiaorui.cc/2015/01/27/logstash%E4%BD%BF%E7%94%A8grok%E6%AD%A3%E5%88%99%E8%A7%A3%E6%9E%90%E6%97%A5%E5%BF%97%E9%81%87%E5%88%B0%E7%9A%84%E9%97%AE%E9%A2%98/

http://grokdebug.herokuapp.com/

demo:http://www.tuicool.com/articles/M7ryEv

Logstash 最佳实践:http://udn.yyuap.com/doc/logstash-best-practice-cn/filter/grok.html

logstash filter 语法:

Example

下面是日志的样子

55.3.244.1 GET /index.html 15824 0.043

正则的例子

%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}

配置文件里是怎么写得?

input {

file {

path =>“/var/log/http.log”

}

}

filter {

grok {

match =>[ "message", "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" ]

}

}

解析后,是个什么样子?

client: 55.3.244.1

method: GET

request: /index.html

bytes: 15824

duration: 0.043

自定义正则

(?<field_name>the pattern here)

(?<queue_id>[0-9A-F]{10,11})

当然你也可以把众多的正则,放在一个集中文件里面。

# in ./patterns/postfix

POSTFIX_QUEUEID [0-9A-F]{10,11}

filter {

grok {

patterns_dir =>“./patterns”

match =>[ "message", "%{SYSLOGBASE} %{POSTFIX_QUEUEID:queue_id}: %{GREEDYDATA:syslog_message}" ]

}

}

input {

file {

type =>"log"

#stat_interval =>"\t"

path

=>"/home/hadoop/xinwang_XW351464_2110.log"

}

}

filter {

if

[path] =~ "xinwang_XW351464_2110" {

mutate { replace =>{ "type" =>

"apache_access" } }

grok {

match =>{ "message" =>

"%{COMBINEDAPACHELOG}" }

}

}

date {

match =>[ "timestamp" ,

"dd/MMM/yyyy:HH:mm:ss Z" ]

}

}

output {

elasticsearch

{

#cluster =>"logstash_ela"

#node_name=>"es_master"

host =>

"192.168.1.152"

index =>"eslsg"

index_type =>"type"

protocol

=>"http"

port =>9200

workers =>1

}

}

执行 ./logstash agent -v -f txtTes.conf 的时候出现:

Grok loading patterns from file

{:path=>"/home/hadoop/logstash-1.4.2/patterns/postgresql",

:level=>:info}

Grok loading patterns from file

{:path=>"/home/hadoop/logstash-1.4.2/patterns/mongodb",

:level=>:info}

Grok loading patterns from file

{:path=>"/home/hadoop/logstash-1.4.2/patterns/mcollective",

:level=>:info}

Grok loading patterns from file

{:path=>"/home/hadoop/logstash-1.4.2/patterns/redis",

:level=>:info}

Grok loading patterns from file

{:path=>"/home/hadoop/logstash-1.4.2/patterns/java",

:level=>:info}

Grok loading patterns from file

{:path=>"/home/hadoop/logstash-1.4.2/patterns/ruby",

:level=>:info}

Grok loading patterns from file

{:path=>"/home/hadoop/logstash-1.4.2/patterns/junos",

:level=>:info}

Match data

{:match=>{"message"=>"%{COMBINEDAPACHELOG}"}, :level=>:info}

Grok

compile {:field=>"message", :patterns=>["%{COMBINEDAPACHELOG}"],

:level=>:info}

Pipeline started {:level=>:info}

New Elasticsearch

output {:cluster=>nil, :host=>"192.168.1.152", :port=>9200,

:embedded=>false, :protocol=>"http", :level=>:info}

Automatic

template management enabled {:manage_template=>"true",

:level=>:info}

Using mapping template {:template=>"{ \"template\" :

\"logstash-*\", \"settings\" : { \"index.refresh_interval\" : \"5s\" },

\"mappings\" : { \"_default_\" : { \"_all\" : {\"enabled\" : true},

\"dynamic_templates\" : [ { \"string_fields\" : { \"match\" : \"*\",

\"match_mapping_type\" : \"string\", \"mapping\" : { \"type\" : \"string\",

\"index\" : \"analyzed\", \"omit_norms\" : true, \"fields\" : { \"raw\" :

{\"type\": \"string\", \"index\" : \"not_analyzed\", \"ignore_above\" : 256} } }

} } ], \"properties\" : { \"@version\": { \"type\": \"string\", \"index\":

\"not_analyzed\" }, \"geoip\" : { \"type\" : \"object\", \"dynamic\": true,

\"path\": \"full\", \"properties\" : { \"location\" : { \"type\" : \"geo_point\"

} } } } } }}", :level=>:info}