9 生产环境的ELK技术栈

当我们说到生产级别实施ELK技术栈时，有一些隐含的前提条件

1. 防止数据丢失
2. 数据保护
3. 可扩展性的解决方案
4. 数据保留

防止数据丢失

• Logstash的索引器之前引入一层消息中间件可以防止数据丢失。消息中间件（如redis）在处理大型数据流时被证明是非常有效的，因为Logstash将数据索引到es时可能会变得很慢。在Logstash忙于将数据索引到es的情况下，redis可以很好地帮助缓冲数据。如果索引失败，它还提供一层保护，事件会保存在消息队列中而不会丢失

数据保护

• es的索引必须防止未经授权的访问，Kibana仪表盘也应该保护起来。我们也可以设置一个nginx的反向代理来访问Kibana实例，这样就可以通过用户免得密码来访问Kibana控制台
• Kibana支持对请求做SSL加密，包括客户端到Kibana服务端的请求，以及Kibana服务端到es的请求
• 为了对浏览器和Kibana服务之间的通信进行加密，可以在kibana.yml中配置ssl_key_file和ssl_cert_file两个参数
• 以下是对从Kibana服务器发出的请求进行加密的SSL（PEM格式）

ssl_key_file: /path/to/your/server.key
ssl_cert_file: /path/to/your/server.crt

• Elasticsearch shield可以用来为Elasticsearch中的数据提供索引级别的访问控制。我们可以在shield中为Kibana创建一个角色，并确定赋予Kibana用户某些访问权限，配置如下
• 我们也给予Kibana服务器级别的角色，允许其访问.kibana索引，配置如下

shield不是免费的，而是Elastic提供的收费服务的一部分。Search Guard是另外一个免费工具，也能很好地保护Elasticsearch的安全。更多细节 https://search-guard.com/

系统可扩展性

随着应用程序数据量的增长，日志分析系统要有良好的可扩展性。此外，有时系统的负载会突然升高，更需要日志分析系统来分析应用的具体情况。ELK技术栈提供了按照需要简单扩展每个组件的能力

• 可以随时在集群增加更多的es节点（主节点和数据节点）。对于大集群，建议有三个主节点（一主两备）。此外，对于大数据量的搜索和索引需求，可以增加负载均衡或路由节点。此外，可以增加更多的Logstash和Redis实例，也可以添加多个Kibana实例。一个典型可扩展的架构如下

数据保留

由于es不可能保存所有的数据，所以在构建日志分析系统时，制定数据保留策略是非常重要的，否则可能导致数据丢失。因此需要有一个能自动删除超过一定时间的旧索引的程序 Elasticsearch Curator可用来帮助管理索引数据。可以使用Curator定时删除不需要的旧索引。例如，下面的命令可以在指定的时间删除超过10天以上的索引文件，可以用crontab设置每天运行 https://github.com/elastic/curator

curator --host 10.0.0.7 delete indices --older-than 10 --time-unit days --timestring '%Y.%m.%d'

ELK技术栈实施案例（LinkedIn）

https://www.slideshare.net/tinle1/elk-atlinked-in

问题描述

• LinkedIn拥有多个数据中心、数以万计的服务器，以及数百亿条日志记录。每天记录、索引、搜索、存储、可视化并分析所有的日志，这是一个巨大挑战。同时必须维护访问控制、存储和传输方面的安全性。随着数据量的增长，系统将扩大到更多的数据中心、更多的服务器，并产生更多的日志。所以LinkedIn需要一个可以处理大规模数据的高效的日志分析管道

对解决方案的要求

• LinkedIn需要的日志分析解决方案必须满足以下要求

1. 要能水平扩展，这样可以在需要时添加更多的节点
2. 处理速度要快，尽可能接近实时
3. 成本要低
4. 具备灵活性
5. 有一个庞大的社区支持
6. 开源

解决方案

• ELK技术栈符合以上所有的标准。目前LinkedIn的许多团队都在使用ELK。当前LinkedIn内部ELK技术栈的使用状况如下

1. ELK集群数量超过100个，分布在6个数据中心，有20多个团队在使用
2. 一些大的集群超过320亿个文档（超过30TB）、平均每天索引30亿个文档（约3TB）

目前LinkedIn在ELK技术栈的架构中使用了es、logstash、kibana和kafka

LinkedIn的Kafka

• 在LinkedIn中，kafka是一个常见的数据传输层。每天要处理约1.1万亿条消息、200TB的输入和700TB的输出。其架构已经扩展到50多个集群。有1100个消息代理，包括约3.2万个主题（Topic）和35万个分区

运维的挑战

• LinkedIn产生了大量数据，因此，可靠的传输、队列、存储和索引都是很重要的。还需要从不同来源采集数据，如Java、Scala、Python、Node.js、Go等。显然这些数据源的格式都是不同的，所以还需要进行转换

LinkedIn使用Kafka记录日志

• LinkedIn在每个数据中心为日志使用了专用集群。每个应用使用不同的Kafka主题，为所有服务、不同语言和框架提供了一个通用的日志传输服务。Logstash从Kafka获取日志，最初用自己的Kafka input插件；后来采用KCC（Kafka Console Consumer）的管道输入插件

• 使用KCC Logstash管道插件样例配置如下

SCA使用ELK的案例

https://www.elastic.co/cn/blog/improving-user-intelligence-with-the-elk-stack-at-sca

• 爱生雅（SCA）是一家全球领先的卫生用品与林业公司。集团研发并生产具有可持续性的个人护理用品、纸巾和林业产品。在SCA，使用elk记录用户在内部网站和外部网站中的搜索、对结果文档的点击行为及用户反馈。另外，我们还会收集一些定性指标

SCA如何使用ELK

• 每个搜索事件都记录了所有搜索参数和结果信息，如查询字符串、分页、排序、维度、命中数、搜索响应时间、搜索日期和时间等。点击结果文档时也记录了大量的信息
• Logstash会实时监控写入日志文件的每个事件，为每个事件生成一个文档，并推送到es，最后在kibana展示

如何帮助分析

• 因为大量信息都已经索引到elk技术栈中，所以通过简单的查询就能做各种分析，如“在过去一周里，10个最常见的搜索是什么”、“点击X文档的用户都在查找什么”，还有更复杂的，如“每周三来源于S的被点击文档的最后修改时间的分布是怎样的”
• 类似这样的分析可以帮助对搜索进行优化，以满足用户需求，并提供更大的价值。通过分析，可以调整相关性模型，可以增加新的维度或删除旧的维度，或者更改搜索页和搜索结果页的布局

SCA使用ELK做监控

• ELK不仅可以设置用于记录用户行为的信息，还可以用来监控服务器的健康状况。在监控场景中，elk可以当作时序数据库来使用。每隔几秒，服务器的CPU、内存和磁盘使用数据（都是时序数据）将被索引。这可以用来查询历史数据并找出系统的趋势

Cliffhanger Solutions使用ELK的案例

Cliffhanger Solutions是公用事业和电信行业的应用服务提供商。它主要为客户和公用事业公司提供有计划的预防性维护，以帮助减少故障恢复时间。使用elk对各种数据源的数据做实时索引。数据源包括维修车的GPS定位数据，或运行在平板电脑上的app，以及智能仪表的读数和GIS（地理信息系统）设备数据

现在运维人员可以很快得到问题的答案，如“我是否可以安全地关闭这个开关，向1500个客户恢复电力供应”或“一场风暴正在从南方袭来，从风暴袭击的地方拿回我的吊半车需要多久”。“制造商X的变压器的MTBF（平均故障间隔时间）高于平均值 。找到所有这样的变压器，并以安装日期进行排序，然后将它们发送到工单系统进行检查或更换” https://www.elastic.co/cn/blog/using-elk-to-keep-the-lights-on

Kibana示例——Packetbeat仪表盘

https://demo.elastic.co/。elk自带了一个很好的kibana仪表盘示例，展示了技术栈的各方面 Packetbeat提供了实时的网络数据包分析能力，是一个开源的数据采集器，可以与Kibana和es集成，为web网络、数据库及其他网络协议提供实时分析

• 这个示例基于Packetbeat实现了多个仪表盘，如已经有mysql、mongodb、web事务、thrift-rpc等仪表盘

• mysql性能仪表盘

• web事务仪表盘

• mongodb性能仪表盘

• geo ip可视化