使用ELK处理Docker日志(二)



昨天小数分享的使用ELK处理Docker日志(一)很受欢迎,今天迫不及待的带来第二篇,侧重于分析和可视化,期待给您带来帮助:)


嘘,听说数人云工程师们在奥斯汀DockerCON2017买了DockerT恤,小数要抢来送给大家,具体规则请关注明日微信~
【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述和架构、部署和核心机制分析、进阶篇——Kubernetes调工作原理及源码分析等。
image

上篇文章介绍了如何将容器日志收集到ELK (Elasticsearch,Logstash和Kibana)的基本步骤。不管最终使用哪种方法来收集Docker日志--使用日志驱动程序或专用日志驱动均可行,接下来要解决的问题是如何在Elasticsearch中编入索引并在Kibana展现时处理日志。

本文将进一步分析使用ELK记录Docker的过程 - 分析和可视化日志。

Dockerized环境要求:

  • 由ELK,Prometheus和Grafana容器组成

  • 使用Docker日志收集器将Docker日志发送到Logz.io ELK。


若使用自己的ELK部署,分析和可视化日志的概念保持不变。

分析之前的准备工作...解析

分析容器生成日志的难度级别取决于如何解析--将消息分解成有效字段的效率越高,可视化起来也就越容易,这正是 Kibana 知名的原因。

由于Dockerized环境存在差异,提供详细的解析说明是很困难的,以下是同一主机上两个不同容器的日志。首先是Grafana容器:

t=2017-03-22T13:04:47+0000 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/logout status=302 remote_addr=109.67.183.188 time_ms=1ns size=29

然后是Elasticsearch容器:

[2017-03-22T13:05:01,974][INFO ][o.e.c.r.a.DiskThresholdMonitor] [0EUzBd2] rerouting shards: [high disk watermark exceeded on one or more nodes]

日志解析小技巧:

  1. 时间戳 尝试规范不同类型容器日志的时间戳字段,有助于以后日志的分析,不用修改每个新镜像的时间格式。

  2. 服务ID /标签 为了区分不同的容器日志,给每个日志类型添加标签至关重要,这样可以在Kibana中以不同的流来区分日志,若想在日志中获取容器名称和ID,也可以添加更多的数据注释,以便将来分析。

  3. 丢掉不必要的数据 如果有不必要的数据字符串,可以使用Logstash过滤器删除,经常清理后续分析会变得容易一些,另外,请不要将日志写入STDOUT / STDERR。


当然,自己完成所有这些操作并不简单,可以借助logspout和Logz.io日志收集器等工具。

日志查询

上篇文章已经介绍如何将Docker日志存入Elasticsearch,基于这个条件我们开始新的操作。

image

分析数据之前,最好将一些字段添加到主日志显示区域(“Discover”选项),有助于了解数据。

如上所述,这个字段列表以及是否可以用于分析,完全取决于如何配置解析。示例中保留了一些有用的字段,可以看到诸如“image”(容器镜像名称),“id”(容器ID)和“name” (容器名称)。

image.

接下来就是查询日志,这里需要熟悉Kibana基本查询语法,简单介绍下使用Kibana搜索Docker日志上下文,更多Kibana语法查询方法可关注Kibana教程。

用 "free-text"在日志中进行搜索是比较常用的方式,更精确的搜索例如"Field-level"可锁定特定容器或主机的日志:

id: 84379bdbe8e0

image

还可以在逻辑语句中组合两个"field-level"搜索,以查找特定容器和重要日志:

id: 6c05ea5efd6d AND loglevel:INFO

image

记住,这些字段需要在解析中进行映射,以便执行基于字段的搜索。

查看特定容器的日志的另一种方法是使用"_exists_"查询,可根据日志消息中存在的特定字段过滤。

例如:

_exists_:loglevel
完成数据查询后,不要忘记保存查询语句,这将会在接下来的可视化环节提供帮助,虽然可以在创建可视化的同时进行搜索,但是过滤后的数据范围缩小了查找更容易。

Docker日志可视化

Kibana以索引数据为基础创建丰富的可视化和仪表板的能力而闻名,事实上,得到这些数据并不容易。需要再次强调的是-如何映射和解析消息至关重要。下面来看一些简单的例子。

单个容器日志

根据每个容器或主机生成的日志量创建可视化饼图,使用容器“name”字段的聚合,得到以下结果:

image

当然也可以使用 "image" 或 "host" 进行聚合。

单个容器事件

另一个例子是监控特定容器的事件数量,为此,将基于保存的事件日志搜索创建可视化折线图,示例中有生成日志事件(错误和警告日志)的特殊容器,需要做的是将X轴配置为使用日期直方图:

image

条形图可以更全面地查看每个容器日志:

image

镜像/容器/主机的数量

用独特的可视化聚合方式,在环境中显示Docker容器,镜像和主机的数量:

image

这些只是在Kibana中可视化Docker容器日志的简单示例,Kibana包含更多可用的可视化类型 --平铺地图可视化可以创建IP字段(映射为地理位置字段),条形图,数据表等的地理图表。

如果使用Logz.io ELK来记录Docker日志,则可以在ELK APPS 中使用预制的仪表板--一个免费的Kibana可视化和仪表板库:
image.

结束语

尽管在Docker1.12中引入了Docker驱动程序,容器日志记录仍然是一个很大的挑战,日志收集没有捷径,解决方案各有优缺点,然而文中未提及的Docker生成其他类型的数据(例如 container stats 和 daemon events)也应当被记录下来。

尽管从Docker主机到ELK的设置并创建良好的日志解析通道并不简单,但最终的结果是值得的,可视化全方位日志将能更有效地关联事件并监控Dockerized环境。

原文链接:https://logz.io/blog/docker-lo ... -two/

0 个评论

要回复文章请先登录注册