详情
本书专门介绍Elastic Stack中的一个可视化组件Kibana。全书共9章，主要包括如何安装和配置Kibana、如何用Kibana进行业务分析、如何用Kibana进行日志分析、如何用Kibana和Metricbeat进行指标分析、如何在Kibana中进行Graph探索、如何定制Kibana的Timelion、如何用Kibana进行异常检测、如何为Kibana开发定制插件等内容。
书名：Kibana数据可视化
ISBN：978-7-115-49312-5
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [法] 巴阿尔丁•阿扎米（Bahaaldine Azarmi）
译 谢人强 方延风
责任编辑 杨海玲
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright ©2017 Packt Publishing. First published in the English language under the title Learning Kibana 5.0, ISBN 978-1-78646-300-5. All rights reserved.
本书中文简体字版由Packt Publishing公司授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。
版权所有，侵权必究。
Kibana是广泛地应用在数据检索和数据可视化领域的ELK中的一员。本书专门介绍Kibana，通过不同的用例场景，带领读者全面体验Kibana的可视化功能。全书共9章，主要包括数据驱动架构简介、安装和配置Kibana 5.0、用Kibana进行业务分析、用Kibana进行日志分析、用Kibana和Metricbeat进行指标分析、探索Kibana中的Graph、定制Kibana的Timelion、用Kibana进行异常检测、为Kibana开发自定义插件等内容。书中包括丰富的示例，可以帮助读者解决各种常见的数据可视化问题。
本书适合想要学习如何用Elastic Stack部署数据驱动架构，特别是如何用Kibana对那些Elasticsearch索引的数据进行可视化的开发人员、运维团队、业务分析师和数据架构师阅读。
当前，数据可视化是一个极为活跃而又关键的技术领域，它通过计算机图形化技术，清晰有效地表达信息，让人直观地识别出特征，从而实现对数据集的深入洞察，就是所谓“好的图表自己会说话”。而Kibana就是一款优秀的数据可视化工具软件。
Kibana是Elastic公司的Elastic Stack中的一个组件，是该公司大名鼎鼎的ELK中的一员，在Elastic的网站页面上是这样介绍Kibana的：“Kibana给你自由塑造数据的选择，你甚至都不一定要预判你在找什么。通过它的交互可视化，从一个问题开始，看看它能引导你到哪里。”
ELK被广泛地应用在数据检索和数据可视化领域，但是介绍ELK特别是专门介绍Kibana的中文书籍极少。本书是一部专门介绍Kibana的著作，它并不局限于讲解如何绘制各种酷炫的可视化图形，更重要的是，本书让我们了解在不同的用户场景下，如何用正确的图形实现数据的可视化。本书包括了许多图的介绍以及丰富的示例，相信读者会从本书中获益良多，能够应对各种常见的数据可视化问题。
在这里，要特别感谢福州外语外贸学院，因为本书获福州外语外贸学院学术著作出版基金资助，还要感谢人民邮电出版社杨海玲编辑专业细心的审核，与她的合作很轻松、很开心。
此外，由于译者水平有限，书中错误和失误在所难免，如有任何意见和建议，请不吝指正，我们将感激不尽。我们的邮箱分别是vhope@163.com和afang@fjinfo.org.cn。
谢人强，副教授，现任福州外语外贸学院电子商务系主任。美国西俄勒冈（Western Oregon Univerisity）访问学者，发表学术论文20余篇，目前的研究方向是信息生态、电子商务等。他主要翻译了第1章至第5章的内容，并对全书内容进行了校译。
方延风，高级工程师，现在福建省科学技术信息研究所任职。毕业于清华大学，获得计算机技术工程硕士学位，美国俄勒冈大学访问学者，曾出版过多本计算机图书，目前的研究方向是文本数据挖掘、自然语言处理（NLP）、信息检索技术等。他主要翻译了第6章至第9章的内容。
Bahaaldine Azarmi是Elastic公司的解决方案架构师。在此之前，他与人联合创立了Reachfive公司—— 一家专注于构建用户行为和社会分析的营销数据平台公司。他还曾就职于不同的软件公司，如Talend和Oracle等，分别担任解决方案架构师和架构师等职位。在本书之前，他在Apress出版社出版了Scalable Big Data Architecture，在Packt Publishing出版社出版了Talend for Big Data等书。他现居于巴黎，拥有巴黎理工大学（Polytech’Paris）计算机科学硕士学位。
这里作者想感谢一些人，因为本书不单由作者一个人写就，还有Elastic公司的许多人参与。
Alan Hardy在软件行业已经浸淫20多年，具有不同行业和环境的丰富经验，从跨国公司，到软件初创公司，到金融机构，包括全球性的贸易公司和交易所。他出道时，是实时、监控和警报系统的开发人员，后来转向C、C++和Java环境下的分组交换技术和金融数据处理等领域。Alan现在在Elastic工作，在这里，他得以充分发挥在数据探索方面的激情，领导着EMEA解决方案架构。
Bharvi Dixit是一位IT专家，也是一位在搜索服务器、NoSQL数据库和云服务方面有着丰富经验的工程师。他拥有计算机科学硕士学位，目前就职于Sentieo——一个美国支持的金融数据和股权研究平台，他领导公司的整个平台和架构，掌控数以百计的服务器。他在Sentieo的搜索和数据团队中也扮演着关键的角色。
他也是Delhi的Elasticsearch Meepup小组的组织者，他常常做关于Elasticsearch和Lucene的演讲，长期致力于这些技术社区的构建。
Bharvi还担任Elasticsearch的自由撰稿顾问，他帮助许多组织在不同的用例中采用Elasticsearch解决复杂的搜索问题，例如，为反恐和风险管理领域以及其他领域（如招聘、电子商务、金融、社会搜索和日志监控等）大数据自动化智能平台创建搜索解决方案。
他对创建可扩展的后端平台有着浓厚的兴趣。他感兴趣的领域还有搜索工程、数据分析和分布式计算。他写代码时喜欢用的主要语言是Java和Python，他还为咨询公司开发产权软件。
2013年，他开始研究Lucene和Elasticsearch，并撰写了两本关于Elasticsearch的书Elasticsearch Essentials和Mastering Elasticsearch 5.0均由Packt Publishing出版。
你可以通过领英（LinkedIn）与他联系，或者在Twitter上关注他的账号@d_bharv。
如今，想要理解数据，无论它的性质如何，都越来越难。这有多方面的原因，比如容量、数据的多样性、数据的来源以及将异源数据关联起来而带来的复杂性等。
所有人都很难应对这种不断增加的挑战，这就是为什么越来越多的应用被开发出来以便于数据管理，它们涵盖了不同的层面：采集数据，处理数据，存储数据，最终为了帮助理解而对数据进行可视化。
上述这些层面的问题汇总起来，构成了一个数据驱动架构所需的基础层，这种架构必须具备可扩展的能力，以满足用户日益增长的需求和期望。
当前有无数的软件和应用可以响应这些挑战，但你很难找到一个全栈方案能超越所有类型的用例，完全满足所有的需求。
幸而，Elastic Stack就是这样的一个全栈方案，它为用户提供了一种敏捷的、可扩展的访问数据方式。Kibana是这个栈的一个组成部分，它属于可视化层，为在Elasticsearch存储层上被索引的数据提供可视化。
在本书中，我们将全面体验Kibana带来的可视化功能，通过不同的用例场景，如用事故数据创建可视化仪表板，或者对最重要的系统数据进行统计，又或者在数据中检测异常点，等等。
本书不会采用一个一个进行罗列的方式，而是在实践的基础上，基于具体的例子和动手实验来进行学习。
第1章给出数据驱动架构简介，讲述构建一个数据驱动架构的基础层，以及Elastic Stack是如何实现这一点的。
第2章介绍如何安装和设置Kibana 5.0，内容涵盖Elasticsearch和Kibana的安装，并对Kibana进行全面的剖析。
第3章介绍如何用Kibana 5.0进行业务分析，本书处理的第一个用例，即业务分析，采用的数据是巴黎的事故数据。
第4章介绍如何用Kibana 5.0进行日志分析，主要以Apache日志数据为例，讲解技术日志的用例。
第5章介绍如何用Metricbeat和Kibana 5.0进行指标分析，利用从Metricbeat获取的系统数据，和读者一起了解Kibana 5.0指标分析的全新功能。
第6章探索Kibana中的Graph，讲解Elastic Stack中图的概念，介绍基于Stack Overflow数据的取证图分析。
第7章介绍如何定制Kibana 5.0的Timelion，讲解如何扩展Timelion的功能以及如何从Google Analytics中抓取数据进行扩展。
第8章介绍如何用Kibana 5.0进行异常检测，介绍Elastic Stack的机器学习特性以及用Kibana可视化系统数据中的异常。
第9章介绍如何为Kibana 5.0开发自定义插件，讲解如何开发一个插件来可视化Elasticsearch的集群拓扑。
为配合本书，读者必须下载并安装Elastic Stack，特别是Elasticsearch、Kibana、Metricbeat、Logstash和X-pack。这些软件都可以从http://www.elastic.co/download下载。
Elastic Stack可以在多种环境多种机型上运行，https://www.elastic.co/support/matrix列出了其支持的各类平台。
本书适合想要学习如何用Elastic Stack 5.0部署一个数据驱动架构，特别是如何用Kibana 5.0对那些Elasticsearch索引的数据进行可视化的开发人员、运维团队、业务分析师和数据架构师阅读。
在本书中，读者会发现一些文本样式被用来区别不同种类的信息，下面是一些样式例子及其各自的含义。
在文本、数据库表名、目录名、文件名、文件扩展名、路径名、虚拟URL、用户输入、Twitter条目等中出现的代码关键词用这样的方式展示：“我们可以通过include指令包含其他上下文。”
代码块的格式设置如下：
PUT /_snapshot/basic_logstash_repository
{
"type": "fs",
"settings": {
"location":
"/Users/bahaaldine/Dropbox/Packt/sources/chapter3/basic_logstash_repository",
"compress": true
}
}命令行输入或输出的格式如下：
GET _cat/indices/basic*
新词和重要的关键词用黑体显示，在屏幕上看到的词，例如，在菜单或对话框中显示的类似文本会加粗显示：“点击Next按钮进入下一屏。”
这里出现的是警告或者重要的注意点。
这里出现的是提示和技巧。
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
本书提供如下资源：
要获得以上配套资源，请在异步社区本书页面中点击
，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
如果您是教师，希望获得教学配套资源，请在社区本书页面中直接联系本书的责任编辑。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，点击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您是学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
这时，你应该已经装好Elastic Stack，并可以创建仪表板和可视化了。本章将重点讨论日志分析用例，深入探讨两个示例，即挖掘巴黎交通事故数据和挖掘Apache服务器的流量日志。
本章中我们关注下面几个主题。
为了引出本章内容，我们先研究一下什么是日志。
日志由包含着时间戳的事件和对事件本身的描述构成。它按顺序将事件追加到日志或日志文件中，所有行的顺序都是基于时间戳的。下面是一个Apache服务日志的示例：
83.149.9.216 - - [28/May/2014:16:13:42 -0500] "GET /presentations/logstash-
monitorama-2013/images/kibana-search.png HTTP/1.1" 200 203023
"http://semicomplete.com/presentations/logstash-monitorama-2013/"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/33.0.1700.77 Safari/537.36" 我们可以猜到某些信息的含义，如IP地址（83.149.9.216）、时间戳（28/May/ 2014:16:13:42 -0500）、HTTP动词（GET）、请求的资源（/presentations/ logstash-monitorama-2013/images/kibanasearch.png）。所有这些信息对于不同目的都是必不可少的，例如，分析服务器上的流量，检测可疑行为，或者调整数据以增强网站的用户体验。
在可视化应用程序开始作为分析日志的实际解决方案之前，IT运营团队通常使用大量的GREP命令对数据进行提取，以提取出要点。但在数据大规模增长的环境下，人工使用GREP已经无法应对这样的数据规模，这种方法不再实用了。
Kibana提供了简化日志管理的能力，首先是通过对观察进行可视化，其次是探索神奇的时刻，也就是说——意外的数据。
你也许会奇怪为什么要采用巴黎事故数据集数据来作为日志分析用例。我只是想打破那些采用Kibana进行可视化时产生的偏见——有时会顽固地存在于人的脑海里。Kibana是一个可视化应用，它不仅仅是被IT运维团队用来监控应用的健康状况。
我们讨论的这个用例的名称只是个摘要，它定义了数据的使用简介。你可以进行日志分析并真正处理健康保健方面的数据，也可以基于同样的日志进行应用监控。这仅取决于数据的性质和内容，同时也取决于你的可视化使用配置。如果准备好了，我就要开始对采集的日志进行安全分析了。
Kibana提供了很多可视化功能和特性用来进行日志分析，巴黎事故数据集用例会让我们对其中的大部分内容有所了解。
Elastic Stack的每个产品都给数据建模带来了最佳实践，Kibana渲染的数据来自Elasticsearch的聚合结果。Elasticsearch在同一个索引中进行数据聚合，索引包含了许多文档，文档包含许多字段。可以推论，文档的一致性越高，可用来数据聚合的范围越大。我所指的文档的一致性的含义是用尽可能多的字段来描述事件，即实体。这就是所谓以实体为中心的文档。
在我们的示例中，原始数据按如下方式结构化：
20/04/2012 16:05,20/04/2012,16:05,75,111,"172, RUE DE LA
ROQUETTE",,1_75111_10314,,"172, RUE DE LA ROQUETTE, 75011 Paris",RUE
MERLIN,Motor Scooter,RESPONSIBLE,Car,RUN
AWAY,,,Cond,Injured,RESPONSIBLE,,,,,,,,,,"172, RUE DE LA ROQUETTE, 75011
Paris",48.8591106,2.3862735,spring,2,afternoon 日志的每一行之间以逗号分隔，描述了发生在巴黎的事故。它包含事故的时间戳、地点信息、涉及车辆的说明和涉及人员的说明等。如果我们把这行内容转为Elasticsearch所期待的JSON文档格式，它看起来应是如下形式：
{
"Address": "172, RUE DE LA ROQUETTE",
"Zip code": null,
"Dept": "75",
"Person 2 Tag": null,
"Segment": null,
"Corner": "1_75111_10314",
"Person 1 Category": "Cond",
"involvedCount": "2",
"Person 4 Cat": null,
"season": "spring",
"periodOfDay": "afternoon",
"Person 3 Tag": null,
"timestamp": "20/04/2012 16:05",
"Com": "111",
"Person 2 Category": null,
"Person Tag": "RESPONSIBLE",
"Vehicle 2 Description": "Car",
"Hour": "16:05",
"Vehicle 3 Description": null,
"Person 3 Cat": null,
"Address2": "RUE MERLIN",
"Address1": "172, RUE DE LA ROQUETTE, 75011 Paris",
"Person 4 Tag": null,
"Date": "20/04/2012",
"Vehicle 2": "RUN AWAY",
"Vehicle 3": null,
"Vehicle 1": "RESPONSIBLE",
"Vehicle 1 description": "Motor Scooter",
"fullAddress": "172, RUE DE LA ROQUETTE, 75011 Paris",
"Person 2 Status": null,
"location": {
"lon": "2.3862735",
"lat": "48.8591106"
},
"Person 4 Status": null,
"Person 1 Status": "Injured",
"Person 3 Status": null
}这些内容易于阅读，为了在聚合形式上有更多可能性，这也是在Elasticsearch里我们想要的。这让我们可以从数据中获取特定的信息，例如，巴黎最危险的街道是哪里，在那里要怎么做才能增强骑行体验。我们将采用Logstash来导入CSV日志。
Logstash是Elastic Stack中的传输组件，部署在服务器端，用来收集、转换和发送数据到Elasticsearch。
使用Logstash时，要先构建一个配置文件，设置不同层（文件输入、过滤器和输出）的配置。本书研究的是使用Kibana 5，我已经在GitHub仓库里准备了相应的配置文件，这样在你开始的时候就不需要学习不同版本的Logstash配置了。
我会对配置文件的每个部分进行详细讲解，先从输入部分开始。
（1）配置输入——文件。这里我们采用文件作为输入源（https://www.elastic.co/ guide/en/logstash/5.0/plugins-inputs-file.html），从本地文件系统中逐行采集数据：
input {
file {
path => "/path/to/accidents/files/directory/accident*"
type => "accident"
start_position => "beginning"
}
}上面的配置首先指定了要采集的文件的路径，这里我使用了通配符，因为这里有多个源文件，并且它们有相同的命名模式。
我还设置了一个accident类型，它会被Elasticsearch当作文档类型，最后的start_position参数告诉Logstash从文件的开头开始读取。
（2）设置过滤器。设置完输入部分，就该是Logstash的过滤器部分了，它在Elasticsearch对数据进行索引之前先对数据进行预处理。
下面是我们将使用的过滤器：
filter {
csv {
separator => ","
columns => ["timestamp","Date","Hour","Dept","Com","Address","Zip
code","Corner","Segment","Address1","Address2","Vehicle 1
description","Vehicle 1","Vehicle 2 Description","Vehicle 2","Vehicle 3
Description","Vehicle 3","Person 1 Category","Person 1 Status","Person
Tag","Person 2 Category","Person 2 Status","Person 2 Tag","Person 3
Cat","Person 3 Status","Person 3 Tag","Person 4 Cat","Person 4
Status","Person 4
Tag","fullAddress","latitude","longitude","season","involvedCount","periodOfDay"]
}
if ([Corner] == "Corner") {
drop { }
}
date {
match => [ "timestamp", "dd/MM/YYYY HH:mm" ]
target => "@timestamp"
locale => "fr"
timezone => "Europe/Paris"
}
mutate {
convert => [ "latitude", "float" ]
convert => [ "longitude","float" ]
rename => [ "longitude", "[location][lon]", "latitude", "[location][lat]" ]
}
}第一个过滤器是一个csv过滤器，它把事件当作逗号分隔的值进行分析。这里的列名将被当成Elasticsearch的JSON文档中的字段名。就源文件的第一行来说，它表示自身头部信息，我不想保留它们，因此用了个小标记来减少列的数量。Corner是真实的街角名（头部名称）。
接下来我用日期过滤器将数据格式化成期望的模式，并设置地点和时区。
最后，源文件里包含的经度和纬度字段将被用来创建geopoint字段（https://www. elastic.co/guide/en/elasticsearch/reference/master/geo-point.html），以便在地图上渲染出事故地点。
（3）配置输出——Elasticsearch。最后是输出部分，用来在Elasticsearch中对数据进行索引，其配置直截了当：
output {
elasticsearch {
action => "index"
hosts => "localhost:9200"
index => "accidents-%{+YYYY}"
user => "elastic"
password => "changeme"
template => "/path_to_template/template.json"
template_overwrite => true
}
}配置正确的话，我们就能连接到Elasticsearch，另一部分是设置正确的模板路径，template指向一个文件，描述了索引应用的映射（https://www.elastic.co/guide/en/ elasticsearch/reference/master/mapping.html）。索引里也包含了可以进行配置的类型，例如，可以对字段格式进行设置。比起让Elasticsearch创建默认模板，我们最好还是让Logstash使用自定义模板。这样才能确保数据被正确地格式化，便于Kibana可视化使用。例如，大多数文本数据，像address字段，必须被作为文本进行索引，但还得有一个关键词类型字段，这样才能在Kibana中进行聚合。
到目前为止，你已经能够运行Logstash，并采集数据了。在第3章的源文件目录下，有个paris_accidentology目录，进入conf/logstash目录，执行如下命令：
MacBook-Pro-de-Bahaaldine:logstash bahaaldine$ ls
csv_to_es.conf template.json 就能看到上面两个文件，即Logstash配置文件和索引模板。
可以执行如下命令来采集数据：
MacBook-Pro-de-Bahaaldine:logstash bahaaldine$
/elastic/logstash-5.0.0/bin/logstash -f csv_to_es.conf 采集结束后，打开Kibana的Console，执行如下命令：
GET accident*/_count 采集进来的数据集里有13 628个文档，数据的可视化已经准备就绪，如图3-1所示。
图3-1 在accident索引中的文档计数
在创建仪表板之前，有必要先了解一下在Kibana里创建一个可视化时，从查询层面来看，到底后台发生了什么。此外，还要探究一下通过查询把多个可视化组合成仪表板时，发生了些什么。
我们用线图（line chart）作为示例，它表示沿时间线发生的事故数量。幸运的是，不同可视化类型的创建过程是一致的。我们会详细讲解这个创建过程，不过更值得注意的是后者的差异。首先，进入Kibana的Visualize部分，选择创建一个线图，如图3-2所示。
图3-2 创建线图
选择要处理的索引模式，本例中应该选择accident*，如图3-3所示。
图3-3 选择accident*索引模式
呈现在我们面前的是线图可视化设置的选项部分，如图3-4所示。
图3-4 线图选项
这些选项分为以下两个部分。
在本示例中，我们把事故数量画在y轴，时间画在x轴上。选出Count作为y轴，设置一个自定义的标记Accidents count，并选择x轴进行统计量的配置，如图3-5所示。
图3-5 线图配置
可以看到，为了在x轴上表示时间，我们选择了Date Histogram（日期直方图）将每个事故文档中的@timestamp字段进行聚合。对于Interval（间隔）配置，我们采用Kibana默认的Auto（自动）选项，它会依据统计量的数量自动在聚合中计算出最佳的时间间隔。实质上，如果创建的统计量过多，指定时间范围里的数据展示效果会难以看清。点击选项顶部区域的Run按钮，就能看到图3-6所示的线图。
图3-6 事故线图
点击Options（选项）还能看到各种图表类型的附加选项，如图3-7所示。
图3-7 线图的选项
对于线图，Smooth Lines（平滑线形）选项的渲染效果比默认的要好些，默认效果看起来有点儿太锋利。图3-8的左边部分是默认的锋利线形，右边是平滑线形。
图3-8 锋利线形与平滑线形
这样我们就能看出线图设置不同选项的效果。接下来，我们看看在Elasticsearch查询的底层发生了些什么。解答这个问题并不费劲，只需点击线图左下角那个小的向上箭头，如图3-9所示。
图3-9 可视化的详细视图
此时，会出现图3-10所示的表格。
图3-10 可视化的详细信息
可视化的详细视图包括以下内容。
回到请求部分，以下代码展示了如何产生线图：
{
"size": 0,
"query": {
"bool": {
"must": [
{
"query_string": {
"analyze_wildcard": true,
"query": "*"
}
},
{
"range": {
"@timestamp": {
"gte": 1337279849612,
"lte": 1339020555494,
"format": "epoch_millis"
}
}
}
],
"must_not": []
}
},
"aggs": {
"2": {
"date_histogram": {
"field": "@timestamp",
"interval": "12h",
"time_zone": "Europe/Berlin",
"min_doc_count": 1
}
}
}
}提交一个查询之后，query_string部分用来进行全文搜索，如图3-11所示。
图3-11 使用全文搜索栏
通过选择日期范围，产生一个用来渲染数据的时间窗口，这样聚合部分就能使用日期直方图，在指定的时间间隔上创建计数统计量。在本例中，每12小时进行一次数据统计。响应中包含了这个时间段里全部的文档。这里展示一下：点击Response标签，就能看到完整的响应信息。
"aggregations": {
"2":{
"buckets": [
{
"key_as_string": "2012-05-17T12:00:00.000+02:00",
"key": 1337248800000,
"doc_count": 1
},
{
"key_as_string": "2012-05-18T00:00:00.000+02:00",
"key": 1337292000000,
"doc_count": 5
},
{
"key_as_string": "2012-05-18T12:00:00.000+02:00",
"key": 1337335200000,
"doc_count": 7
},
{
"key_as_string": "2012-05-19T00:00:00.000+02:00",
"key": 1337378400000,
"doc_count": 3
},可以看出，每12小时就会创建一个统计量，其中包含doc_count，它在本例中代表事故的数量。
可能你已经发现，所有聚合的神奇效果都是在Elasticsearch层面上完成的，Kibana获取相应的响应信息，然后进行渲染。现在你该明白后台的架构了，我们可以继续给事故数据集仪表板创建新的图表。在后续的例子中，我只重点讲述不同的地方，不再重复那些不同可视化类型间大同小异的创建过程。
我们准备用条形图（bar chart）可视化方式来展示那些事故最高发的街道。先按可视化创建的流程执行，然后选择Vertical bar chart（垂直条形图）类型。
接着，选择x轴，简要配置一下统计量来显示条目聚合，从选择框里选择Terms（条目）类型即可，如图3-12所示。
图3-12 条形图设置
可以看到，在图3-12中，我选择了不可解析的Address.keyword来进行聚合。不这样的话，选择一个可解析的字段来做条目聚合，就会发现字段里包含的每个条目都会被单独进行聚合。
我选择的大小值为10，这样就能按降序展示出最危险的10条街道。最后看到的效果如图3-13所示。
图3-13 事故高发街道
我们还可以更进一步添加其他统计量，只需在buckets部分点击Add sub-bucket（添加分统计量）按钮即可。我们也可以添加其他级别的聚合，例如，基于Vehicle 1 description.keyword字段增加一个条目聚合。这样，就能看到最危险的街道上不同车辆类型引发的事故分量，如图3-14所示。
图3-14 带车型分量的十大事故高发街道
为了展示事故中涉及的车辆类型情况，我们确实会使用不同级别的聚合。
接下来要介绍的是饼图（pie chart）。创建一个新的饼图可视化，并在x轴上选择Vehicle 1 description.keyword进行条目聚合，然后添加Vehicle 2 description.keyword字段作为分统计量，再添加Vehicle 3 description.keyword字段作为分统计量，如图3-15所示。
图3-15 多级聚合饼图
生成的效果如图3-16所示。
图3-16 涉事车辆细分
这样，用户可以对第一类车型进行分析，同样对涉事的第二类、第三类车型也可以进行分析，如图3-17所示。
图3-17 小汽车事故中的涉事车辆
接下来的图表类型是面积图（area chart），它按小车事故中的受害者状态对事故进行划分。类似之前的图表，使用以下信息来创建面积图。
图3-18 按人员状态划分的事故面积图
最终渲染出来的图是堆叠面积图，如图3-19所示。
图3-19 堆叠面积图
在我看来，图3-19的比例不是很适合，因为图表的上部是一片无用的空白。幸而在选项标签里还有个更好用的设置，让我们能用百分比值换掉默认的堆叠选项，这让可视化体验完全不一样了，如图3-20所示。
图3-20 事故之后人员状态图
采用百分比值后，用户可以一眼就了解受害者的状态，例如，事故造成的死亡人数很少。
最后介绍的图表类型是切片地图（tile map）。在切片地图上，我们可以展示出巴黎的事故密度。要实现这个目标，先创建一个切片地图，点击Geo Coordinates（地理坐标），选择Geohash聚合时会自动选中location字段，这也是文档中仅有的地理位置字段，如图3-21所示。
图3-21 切片地图配置
渲染可视化之后，就能看到图3-22所示的缩略的巴黎事故地图。
图3-22中仍有一些比例不太合适，因此，在选项标签里，我们可以将默认的圆圈标记比例换成Heatmap（热图）。热图可以在地图上展示出事故的集中度。为了获得更易于接受的渲染效果，需要对设置进行多种尝试，我采用的设置值如图3-23所示。
图3-22 事故地图
图3-23 热图配置
Radius（半径）是点的大小，Blur（模糊）是对热量的饱和度进行增减。Maximum zoom（最大变焦）依赖于地图的可缩放程度，进行放大时，饱和度不断降低直到Maximum zoom设置。Minimum opacity（最小不透明度）调节饱和度直到Maximum zoom设置。图3-24展示了热图的渲染效果。
图3-24 事故热图
至此，我们把用来创建仪表板的可视化都进行了尝试。现在进入仪表板区域，在上面的菜单条上点击new（新建）按钮，在这里，再点击add（添加）按钮就可以添加各种可视化到仪表板中。你可以随心所欲地清除、缩放各个可视化实体。图3-25是我完成的仪表板效果。
图3-25 巴黎事故数据集仪表板
现在仪表板已经创建好了，我们可以对数据进行分析、过滤、创建关联性，还能发现之前没想到或没想过的模式。我们可以向数据提问。
虽然骑行在巴黎已经普及十多年了，但是Velib网络特别指出，巴黎的骑行体验是相当危险的。通过仪表板，我们来试试能否提高巴黎的骑行体验。首先，可以使用饼图仪表板，在图例中点击Bicycle条目及带加号的那个放大镜图标，如图3-26所示。
图3-26 巴黎事故数据集仪表板
点击图3-27所示的全局过滤器，将会应用到整个仪表板并刷新数据。
图3-27 自行车过滤器
查看面积图，我们会发现绝大多数自行车事故中涉及的人员都是“受伤”，出人意料的是，很少人需要送医或者死亡，这和一贯的巴黎骑行印象并不一致，如图3-28所示。
图3-28 自行车事故受害者状态
查看地图，我们会发现绝大多数事故发生在从北到南贯穿巴黎的纵轴上，如图3-29所示。
图3-29 自行车事故关联显示贯穿巴黎的线路
因为穿过城市的中心，这条轴上的车流量极大。查看饼图我们会注意到，除了小汽车，事故中还涉及了各种类型的车辆，如图3-30所示。
图3-30 自行车事故涉及的车辆类型
我们可以假定自行车和其他车型在这条轴上共享道路（在本项研究期间）。因此，添加自行车专用道有一定提高骑行体验的可能性。由于缺乏空间，要在巴黎建设自行车专用道也很困难，这也是我们只有“逻辑”专用道，只在路面上进行标识的原因。这样甚至会让道路更加狭窄，如图3-31所示（图片来源于https://en.wikipedia.org/wiki/Bicycle- sharing_system）。
图3-31 自行车专用道
这是我们在Kibana之旅中给出的第一个结论。现在可以尝试其他的特性，如全文搜索特性。如果再看一下热图，我们就会发现，总体来说，自行车事故的密度分布和背景数据差别并不大，如图3-32所示。
图3-32 高层级自行车事故热图
在全文搜索栏里输入morning关键词，试着分析一下早晨通勤的情况，如图3-33所示。
图3-33 对时段进行过滤：早晨
这样我们获得的热图如图3-34所示。
图3-34 早晨通勤时段自行车事故的密度
如果熟悉巴黎，你对巴黎南部事故的高密度不会感到意外，不过，图3-34用黑线围出的区域值得注意。
在这个区域里有许多学校和大学，因此，如果在这里划出或建设专用的自行车道，相信有机会可以提高骑行体验。
怎么鉴别出巴黎最危险的街道，并了解为什么，这个问题很有意思，也是本例要说明的。
为了探索这个问题，我们使用条形图，根据事故数量大致上给出最危险的街道，如图3-35所示。
图3-35 巴黎最危险的4条街道
如果熟悉巴黎，你对结果中的协和广场（Place de la Concorde）和香榭丽舍大道（Avenue des Champs Elysees）不会感到意外，它们分别构成了巴黎拥挤的街道的巨大迂回。
第三条街道更有意思，玛格丽特大道（Allée de la Reine Marguerite）几乎已经不在巴黎，它位于西部边界上，如图3-36所示。
图3-36 玛格丽特大道附近的事故
从图3-37所示的饼图中，你会发现绝大多数事故是由小汽车引发的，同时有些让人感到意外的是厢式货车，同时，事故涉及的附带车型为自行车、摩托车、小摩托等。
图3-37 玛格丽特大道附近的事故涉及的车型
人人皆知，两轮车事故总是发生在司机没有查看他们的视线盲区时。因此，这是否意味着在这个区域，小汽车和厢式货车很少经过？为什么呢？
据说是因为红灯区。实际上，巴黎的东部和西部的一些地方以红灯区闻名。
本章对巴黎事故数据集的业务分析到此结束，读者应该对如何在Logstash里创建一个管道用来从CSV文件或者其他源里导入数据有了深入的了解。此外，我们还了解了如何用不同的可视化实体组合成仪表板，目的是将业务分析问题应用到我们的数据中。
下一章将关注一个更偏技术的主题，也就是Apache服务器日志分析。所用的方法是一致的，不过我们将使用不同的途径导入数据，显然也会提出不同的问题。
在前两章中，我们已经看到了在业务和技术用例的上下文中如何使用Kibana对日志数据进行可视化，现在我们将把重点转到指标分析，它在数据结构方面与前者有着根本性的不同。
因此，在开始本章之前，我想对什么是指标说上几句。
所谓指标，就是包含时间戳和一个或多个数值的事件，它们被顺序地追加到一个指标文件里，所有的指标线都基于时间戳。下面给出了一些系统指标的例子：
02:30:00 AM all 2.58 0.00 0.70 1.12 0.05 95.55
02:40:00 AM all 2.56 0.00 0.69 1.05 0.04 95.66
02:50:00 AM all 2.64 0.00 0.65 1.15 0.05 95.50与日志不同，指标是周期性地发送的，例如每10分钟发送一次（如上面例子所示），而日志通常是在发生某些事件的情况下追加到日志文件中的。
指标常常被用在软件或硬件健康监控的语境中，如资源利用监控、数据库执行指标监控等。
从5.0版以来，Elastic已经在所有层面的解决方案上拥有了新的相关特性，从而增强指标管理和分析的用户体验。Metricbeat是Kibana 5.0的一个新特性，它允许用户传送指标数据到Elasticsearch，不论其是来自服务器的数据还是来自应用程序的数据，还配有开箱即用的Kibana仪表板。Kibana还将Timelion与其核心集成在一起，Timelion是一个被设计来处理各类指标数值数据的插件。
在本章中，我们将开始使用Metricbeat，然后采用X-Pack组件中的alerting（警报），以此来介绍Timelion，不过我们要等到第6章再讨论它的更多细节。
Metricbeat可不只是一个系统指标的传送者，它还拥有可扩展模块架构，可以和一些开箱即用的模块搭配使用，如图5-1所示。
图5-1 Metricbeat架构
如图5-1所示，Metricbeat拥有能从Web服务器（Apache或Nginx）、数据库（MongoDB、MySQL或PostgreSQL），甚至Redis或Zookeeper那里传送指标的能力。此外，Elastic为开发人员提供了在线文档，让他们可以创建自己的Metricbeat，所以可以很容易地扩展出开箱即用的功能。
在本书中，我们将使用系统模块作为Metricbeat的默认配置。用户可以监视计算机或笔记本电脑，并在Kibana 5.0中对数据进行可视化。这只是Metricbeat处理能力的一个例子，如果想要在更大的规模上进行操作，可以设想在数据中心中采用分布式的Metricbeat进行传送，而采用集中式的Kibana实例来监控所有节点。
本李我们将介绍Metricbeat的安装，然后开始用它传送数据到Elasticsearch。
先从https://www.elastic.co/downloads/beats/Metricbeat下载压缩文件，如图5-2所示，安装很简单，只需解压文件即可。
图5-2 下载Metricbeat
本书中我们下载的是给Mac系统使用的5.0.0-alpha版本（本书写作期间发布的版本），然后对TAR文件进行解压：
tar -zxvf metricbeat-5.0.0-darwin-x86_64.tar.gz解压出来的目录结构如下：
MacBook-Pro-de-Bahaaldine:metricbeat-5.0.0 bahaaldine$ pwd
/elastic/metricbeat-5.0.0
MacBook-Pro-de-Bahaaldine:metricbeat-5.0.0 bahaaldine$ ls
total 23528
scripts
metricbeat.yml
metricbeat.template.json
metricbeat.template-es2x.json
metricbeat.full.yml
metricbeat至此，Metricbeat的安装就完成了，接着需要对其进行配置以适合你的环境设置。
Metricbeat的配置存储在metricbeat.yml文件中，它由以下部分组成。
这里我们将批量对所有配置采用默认值，把重点放在输出部分。因为我们要的效果是把指标数据发送到Elasticsearch实例上去，所以转到配置的output部分，并修改设置以适合你的配置：
#====================== Outputs ==================================
# Configure what outputs to use when sending the data collected by
the beat.
# Multiple outputs may be used.
#-------------------------- Elasticsearch output ------------------
------------
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["localhost:9200"]
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme" }在本例中，要是采用Kibana 5.0版本中安装X-Pack带来的默认安全设置，必须传递用户名和密码。如果不使用默认值，就要创建一个专用于Metricbeat的新用户。为了实现这个目标，需要打开Kibana，进入Management（管理）部分，如图5-3所示。
图5-3 Kibana管理面板
在这里，点击Roles（角色）链接，进入图5-4所示的页面。
图5-4 角色管理页面
点击New Role（新角色）按钮创建一个新角色，角色配置仪表板允许创建不同粒度级别的角色，限定从集群到字段级别的安全。在本例中，我们将采取快捷方式创建一个具有创建索引和存储指标权限的角色，如图5-5所示。
图5-5 创建metricbeat_user角色
正如所见，这个角色将能够按照metricbeat-*模式创建指标，这是Metricbeat采用的默认索引模式。此外，我们要将所有权限赋予这些索引。
保存好角色，然后转到用户部分，点击New User（新用户）按钮，创建一个叫metricbeat_user的新用户，如图5-6所示。
图5-6 创建metricbeat_user用户
现在调整一下metricbeat.yml里的内容，加入刚创建的用户及其密码凭证：
# Optional protocol and basic auth credentials.
#protocol: "https"
username: "metricbeat"
password: "secret" 现在运行Metricbeat并将数据传送到Elasticsearch的准备已经就绪，在Metricbeat安装目录下执行如下命令：
mac:metricbeat-5.0.0 bahaaldine$ ./metricbeat 返回Kibana，进入Discover标签，选择metricbeat-*索引模式，将在Elasticsearch中看到图5-7所示的数据。
图5-7 进入Elasticsearch的Metricbeat数据
接下来我们就可以导入Metricbeat的Kibana仪表板了。
在本节中，我们将关注Kibana中Metricbeat带来的几种开箱即用的可视化。
导入仪表板之前，我们先看看Metricbeat传送的真实指标数据，本章写作的时候我使用的是Chrome浏览器，因此，我准备按进程名（这里是chrome）从数据中过滤出与Chrome相关的内容，如图5-8所示。
图5-8 按进程名过滤后的“探索”标签
下面是一个文档内容的范例：
{
"_index": "metricbeat-2016.09.06",
"_type": "metricsets",
"_id": "AVcBFstEVDHwfzZYZHB8",
"_score": 4.29527,
"_source": {
"@timestamp": "2016-09-06T20:00:53.545Z",
"beat": {
"hostname": "MacBook-Pro-de-Bahaaldine.local",
"name": "MacBook-Pro-de-Bahaaldine.local"
},
"metricset": {
"module": "system",
"name": "process",
"rtt": 5916
},
"system": {
"process": {
"cmdline": "/Applications/Google
Chrome.app/Contents/Versions/52.0.2743.116/Google Chrome
Helper.app/Contents/MacOS/Google Chrome Helper --type=ppapi -
-channel=55142.2188.1032368744 --ppapi-flash-args --lang=fr",
"cpu": {
"start_time": "09:52",
"total": {
"pct": 0.0035
}
},
"memory": {
"rss": {
"bytes": 67813376,
"pct": 0.0039
},
"share": 0,
"size": 3355303936
},
"name": "Google Chrome H",
"pid": 76273,
"ppid": 55142,
"state": "running",
"username": "bahaaldine"
}
},
"type": "metricsets"
},
"fields": {
"@timestamp": [
1473192053545
]
}
}上面的文档将chrome进程的资源利用率分解了出来。例如，我们可以看到CPU和内存的使用情况和进程的整体状态。现在，考虑到真正的仪表板里对数据进行可视化。要做到这一点，需要进入Metricbeat安装目录下的scripts文件夹，查看相关脚本文件：
MacBook-Pro-de-Bahaaldine:scripts bahaaldine$ pwd
/elastic/metricbeat-5.0.0/scripts
MacBook-Pro-de-Bahaaldine:kibana bahaaldine$ ls
import_dashboards.shimport_dashboards.sh就是我们用于在Kibana里导入仪表板的脚本文件，执行这个脚本：
./import_dashboards.sh –h上面的命令将打印出帮助信息，基本上是一些传给脚本的参数列表。这里需要指定用户名和密码，因为我们正在使用X-Pack安全插件，这样才能保证集群的安全性：
./import_dashboards.sh -u elastic:changeme正常情况下，应该会看到一些日志，表明仪表板已经被导入：
Import visualization Servers-overview:
{"_index":".kibana","_type":"visualization","_id":"Serversoverview","_version":4,"forced_refresh":false,"_shards":
{"total":2,"successful":1,"failed":0},"created":false}至此，我们已经在Elasticsearch中导入了指标数据，并且在Kibana中创建了仪表板，现在可以对数据进行可视化了。
如果回到Kibana的仪表板部分，试着打开Metricbeat system overview（Metricbeat系统概览）仪表板，看到的内容类似于图5-9。
图5-9 Kibana的Metricbeat仪表板
你会在仪表板里看到在自己的计算机上运行的进程的各种指标值。本例中，这样的指标有很多，单击Load/CPU部分，我们可以用可视化展现出CPU使用率和系统负载，如图5-10所示。
图5-10 CPU使用率和系统负载
作为一个示例，这里有一点很重要，必须搞清楚：Metricbeat在整个系统的CPU或RAM里的使用痕迹很少，如图5-11所示。
图5-11 Metricbeat资源的利用率
从图5-11中可以看到，在我的MacBook Pro上，Metricbeat只使用了大约0.4%的CPU和不到0.1%的内存。但是，如果想找出最消耗资源的进程，可以查看Top processes（最消耗资源进程）数据表，它会给出图5-12所示的信息。
图5-12 最消耗资源进程
除了Chrome H使用了大量的CPU，会议应用zoom.us看起来也给我的笔记本电脑带来了很大的压力。
为了更好地处理指标数据，我们不准备使用Kibana的标准可视化，而是使用Timelion，重点关注那些消耗大量CPU的用例。
Timelion是一个奇妙的可视化工具，常用来处理时间序列数据。这里，我们通过对Metricbeat数据的处理来演示如何应用它。
本书前面曾提到，Timelion是Kibana的新核心插件，它允许用户对数值型字段进行数学运算，并将它们图形可视化。在本节中，我们还使用前面的例子来介绍Timelion——分析最消耗资源的进程。
登录Kibana，并点击侧边栏的Timelion图标，如图5-13所示。
图5-13 Kibana的侧边菜单条
首先，你会注意到的是欢迎内容条，它对Timelion的基础特性进行了简介，和一般的Kibana仪表板的风格有很大差别，如图5-14所示。
图5-14 Timelion欢迎内容条
除了在本书中能学到的内容，我强烈建议你浏览一下这个入门教程。
你还会注意的是工作区，它由一个表达式栏和一个或多个图表组成，如图5-15所示。
图5-15 Timelion工作区
上面的菜单栏可以完成以下功能：
在表达式栏里，可以创建一个Timelion表达式以指向一个或多个数据源，而不仅限于Elasticsearch。Kibana仪表板唯一可能的数据源就是Elasticsearch，这是两者之间的一个主要区别。这里，你可以用Quandl、Worldbank和Graphite，甚至可以开发自己的数据源。
数据源表达式主要用来发出请求以获取数值数据列表。在Elasticsearch案例中，返回的结果是聚合的统计量，这和用Kibana仪表板发现的没有什么不同。
然后，在Timelion里，可以通过数学表达式对结果集进行计算、近似、外推等操作。因此，Timelion基本上代表了对底层数据源技术（如Elasticsearch）的高承载能力，并可以在浏览器端对指标进行转换。
它的不足之处在于结果集不能超过2000个指标统计区间，如图5-16所示。
图5-16 最大统计区间错误提示
这也保证了基于浏览器计算的数据量不会太大。你可以通过表达式栏右侧的时间间隔选择器对时间间隔进行配置，如图5-17所示。
图5-17 Timelion时间间隔选择器
默认选择是auto，足以满足大多数用例，本节我们会介绍一个示例。现在检查一下表达式栏，你看到的应该是默认表达式.es(*)。
这个表达式指向Elasticsearch集群，并在时间间隔选器中选定的时间周期内统计所有的文件数量。然后将其呈现在目前为止唯一的图表上，每个图表对应一个表达式。现在我们使用.es(index=metricbeat)表达式来引用这个数据源，指向metricbeat索引模式。其中的index参数让你可以指定索引模式，生成的图表如图5-18所示。
图5-18 metricbeat*文档计数
该怎么对图表里的文档进行过滤，让其只显示CPU总使用率大于100%的项目呢？代码如下：
.es(index=metricbeat*, q=system.process.cpu.total.pct:>1.0)效果如图5-19所示。
图5-19 CPU使用率超过100%的进程
q或者query参数让你可以设置一个过滤器，本例中，是给出CPU使用率超过100%的进程数量的视图。在图5-19中将其基于时间逐个显示。
对于这个用例，我们还可以从不同的视角来进行观察：通过metirc参数，按时间显示出最大的CPU使用率。
这次，我们准备在可视化里添加更复杂的东西，这里介绍一种方法：设置一个阈值，将CPU变化用线型可视化展示出来，并对超过阈值的所有数据点进行标记。
首先，展示出基于时间的最大CPU使用率：
.es(index=metricbeat*,
metric=max:system.process.cpu.total.pct:>1.0).color(#2196F3).label("Max CPU
over time")效果如图5-20所示。
图5-20 基于时间的最大CPU使用率
我们用metric参数和max运算来算出序列中的最大值，正如你所看到的，图表中有一些空白之处（基本上是由于某种原因，笔记本电脑没有在运行或者被关闭了）。这里，我们可以猜测，我休息了一段时间去吃午饭，下午3:30左右可能出去溜达了一会儿。
这里有一些数据点缺失了，这种情况在大量的用例中是很常见的，例如可能是由网络故障引起的。我们可以采用另一个叫作fit的函数，以特定的模式对数据进行插值，这样就能把数据点连接起来，如图5-21所示。
图5-21 基于carry模式修补缺失部分
我故意在fit函数中使用了carry模式，因为它在本例中为max运算提供了最好的结果。别犹豫，还可以尝试其他方法，我们应该了解一些，比如scale法，不过它不太适合计算max的情况，你可以从本书源代码文件中的server/fit_functions的代码注释里直接找到每个模式的文档。
接下来的操作是在图表中打印输出两个阈值，换句话说，一条静态的直线表示警戒值，另一条线代表若被超过则问题严重，必须采取及时措施。我们就定义CPU使用超过75%作为警戒值，100%作为严重阈值，此时的表达式如下：
.static(0.75).color(#FF9800).label(Warning),
.static(1.0).color(#F44336).label(Error)效果如图5-22所示。
图5-22 带阈值的图表
color和label表达式给图表带来了可定制的特性，每条线可以有指定的颜色和图例标签。
如果加上一个movingaverage函数，我们就可以把CPU最大使用率的图优化得更平滑一些，代码如下：
.es(index=metricbeat*,
metric=max:system.process.cpu.total.pct:>1.0).color(#2196F3).label("Max CPU
over time").fit(mode=carry).movingaverage(2)效果如图5-23所示。
图5-23 用movingaverage函数平滑线型
现在我们可以使用point函数来标记到达阈值的数据点，并且将所有内容乘以100，这样就能在可视化中以百分比值的形式展示，代码如下：
(.static(0.75).color(#FF9800).label(Warning),
.static(1.0).color(#F44336).label(Error),
.es(index=metricbeat*,
metric=max:system.process.cpu.total.pct:>1.0).color(#2196F3).label("Max CPU
over time").fit(mode=carry).movingaverage(2), .es(index=metricbeat*,
metric=max:system.process.cpu.total.pct:>1.0).color(#2196F3).fit(mode=carry
).movingaverage(2).condition(lt, 0.75).condition(gt,
1.0).points(symbol=diamond, radius=4).color(#EF6C00).label("1st level
alert"),
.es(index=metricbeat*,
metric=max:system.process.cpu.total.pct:>1.0).color(#2196F3).fit(mode=carry
).movingaverage(2).condition(lt, 1.0).points(symbol=diamond,
radius=4).color(#FF1744).label("2nd level alert")).multiply(100)效果如图5-24所示。
图5-24 标记数值
上面这些表达式也没有想的那么复杂，我只是重复使用了绘制最大CPU使用率折线的表达式，其中显示橙色菱形条件是.condition(lt, 0.75).condition(gt, 1.0)，显示红色菱形条件是.condition(lt, 1.0)。
现在，我们已经拥有了一个完整的图表，它显示了一个平滑的基于指标的最大CPU使用率折线，能够实时显示异常跟踪点。我们可以轻松地在同一图表上看到哪些值超过了阈值。点击Save（保存）按钮，就可以将图表存入Kibana的面板，然后把当前表达式存为Kibana仪表板条目，如图5-25所示。
图5-25 保存表达式
接着进入仪表板部分，点击Add（新增）按钮，把它添加到Metricbeat系统统计（Metricbeat System Statistic）仪表板里，如图5-26所示。
图5-26 添加到仪表板中
通过不断组合各种可视化特性，Kibana 5.0给用户带来了完整的可视化体验，
下面，我们将在可视化中增加警报功能来使其更强大，当警报真的被触发时进行可视化展示。
首先我们需要创建一个警报，它基本上由以下特性组成。
如果需要了解关于警报的更多信息，推荐浏览在线文档https://www.elastic.co/ guide/en/x-pack/current/xpack-alerting.html。
在本例中，我们希望在系统CPU消耗最大值超过40%时触发警报，这意味着要和system.process.cpu.total.pct配合工作，由它为我们提供这个值。警报的配置如下：
{
"trigger": {
"schedule": {
"interval": "10s"
}
},
"input": {
"search": {
"request": {
"indices": [
"metricbeat*"
],
"body": {
"size": 0,
"aggs": {
"max_cpu": {
"max": {
"field": "system.process.cpu.total.pct"
}
}
},
"query": {
"bool": {
"must": [
{
"range": {
"@timestamp": {
"gte": "now-10s"
}
}
}
]
}
}
}
}
}
},
"condition" : {
"script" : {
"lang": "painless",
"inline" : "if (ctx.payload.aggregations.max_cpu.value > 0.40) {
return true; } return false;"
}
},
"actions": {
"log": {
"transform": {},
"logging": {
"text": "Max CPU alert executed : {{ctx}}"
}
},
"index_payload" : {
"transform": {
"script": {
"lang": "painless",
"inline": "Map result = new HashMap(); result['@timestamp'] =
ctx.trigger.triggered_time; result['cpu'] =
ctx.payload.aggregations.max_cpu.value; return result;"
}
},
"index" : {
"index" : "cpu-anomaly-alerts",
"doc_type" : "alert"
}
}
}
}正如所见，警报每10秒触发一次；它执行输入的请求，其中主要是对数据进行聚合，并根据Metricbeat最近10秒传送过来的数据计算出最大的系统值。
然后根据判断条件进行校验，验证其值是否高于0.4（40%），如果是，则执行警报的动作。
ctx变量将包含了所有上下文数据的信息记录下来，输出的示例如下：[2016-09-12 22:16:40,159][INFO ][xpack.watcher.actions.logging]
[Jaguar] Max CPU alert executed : {metadata=null,
watch_id=cpu_watch, payload={_shards={total=35, failed=0,
successful=35}, hits={hits=[], total=225, max_score=0.0},
took=2, timed_out=false, aggregations={max_cpu=
{value=0.7656000256538391}}}, id=cpu_watch_53-2016-09-
12T20:16:40.155Z, trigger={triggered_time=2016-09-
12T20:16:40.155Z, scheduled_time=2016-09-12T20:16:39.958Z},
vars={}, execution_time=2016-09-12T20:16:40.155Z}{
"_index": "cpu-anomaly-alerts",
"_type": "alert",
"_id": "AVcgA-viVDHwfzZYssj_",
"_score": 1,
"_source": {
"@timestamp": "2016-09-12T20:08:30.430Z",
"cpu": 0.5546000003814697
}
}为了启用这个警报，我们必须进入Kibana的Console插件，将其添加到警报索引里，X-Pack为此设计了一个专门的API，如图5-27所示。
图5-27 在Kibana控制台里创建警报
完成上述步骤之后，我们回到Kibana的Timelion，调试表达式以绘制CPU最大值折线，以及警报被触发的数据点。下面是使用的表达式：
(
.static(0.4).color(#FF9800).label(Warning),
.es(index=metricbeat*, metric=max:system.process.cpu.total.pct)
.color(#2196F3)
.label("Max CPU over time")
.fit(mode=carry).movingaverage(2),
.es(index=cpu-anomaly-alerts)
.condition(operator=lt,1)
.points(symbol=cross)
.color(#FF1744)
.divide(
.es(index=cpu-anomaly-alerts)
.condition(operator=lt,1)
)
.multiply(
.es(index=metricbeat*, etric=max:system.process.cpu.total.pct)
.fit(mode=carry)
.movingaverage(2)
)
).multiply(100)表达式首先创建了一个表示40%的阈值的静态直线，然后绘制出动态的最大系统CPU使用率的平均值。接着使用CPU异常警报索引，让它保存所有的警报输出，每次警报被触发时就绘制一个交叉点。
注意，我使用的一个条件是从可视化中删除所有值为0的点，因为Timelion会把它们绘制出来，这将导致图表显得既繁复又杂乱。
把同样的数据集按它的值分开，每个值为1时，就会出现一个交叉，将其与用于求最大系统CPU使用率相同的表达式相乘。这样，要平滑展示图表上的所有值，只需要一个y轴，交叉线应该与CPU折线重叠。最后，把所有的东西都乘以100，使之以百分比的形式可视化，如图5-28所示。
图5-28 带警报点的最大系统CPU使用率折线
正如所见，我们现在可以清楚地看到所有那些有疑问的值，并且可以确定警报已经被触发，并采取了主动措施。
在本章中，我们已经看到如何在技术指标分析的环境中使用Kibana。我们依靠Metricbeat从服务器传送来的数据，在Kibana的仪表板和Kibana的Timelion里对结果进行可视化。在下一章中，我们仍将研究指标分析，但采用的是一个业务用例——美国国内航班用例。
