<!-- toc -->

<!-- tocstop -->

此次对ELKstack的LogStash预研的目的

  1. 了解LogStash是什么？
  2. LogStash能做什么？
  3. 怎样在我们的业务场景中使用起来，是否能很好的契合我们的业务需求？

ELK stack 是什么？

ELK Stack 是 Elasticsearch、Logstash、Kibana 三个开源软件的组合。在实时数据检索和分析场合，三者通常是配合使用，而且又都先后归于 Elastic.co 公司名下，故有此简称。 ELK Stack 在最近两年迅速崛起，成为机器数据分析，或者说实时日志处理领域，开源界的第一选择。和传统的日志处理方案相比，ELK Stack 具有如下几个优点：

  • 处理方式灵活。Elasticsearch 是实时全文索引，不需要像 storm 那样预先编程才能使用；
  • 配置简易上手。Elasticsearch 全部采用 JSON 接口，Logstash 是 Ruby DSL 设计，都是目前业界最通用的配置语法设计；
  • 检索性能高效。虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到全天数据查询的秒级响应；
  • 集群线性扩展。不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的；
  • 前端操作炫丽。Kibana 界面上，只需要点击鼠标，就可以完成搜索、聚合功能，生成炫丽的仪表板

目前阶段，我们主要针对LogStash做相应的预研。

1. LogStash是什么？

LogStash是开源的具有实时管道能力的数据收集引擎。

2. LogStash能做什么？

  • 可以动态地统一不同来源的数据(dynamically unify data from disparate sources)
  • 规整数据到您选择的输出(normalize the data into destinations of your choice)
  • 为多元的下游分析和可视化方案提供 整洁和无差异 的数据(Cleanse and democratize all your data for diverse advanced downstream analytics and visualization use cases)

所有类型的事件都可以被丰富和改造，在经过一系列的<管道链>input,filter和output插件的处理，以及许多的本地编解码器进一步简化吸收过程。

具体数据处理：

  • 处理各种类型的日志和指标 [logs and metrics]
  • 解锁万维网数据 [Transform HTTP requests into events ]
  • 挖掘出已有数据的更多更大的价值[Data Stores and Streams ]
  • 探索其它数据的广度[传感器和物联网]

3.怎样集成，使我们的运维平台兼具实时日志分析的能力

ELK Stack 组合是一套已经很成熟与完整的从数据采集分析LogStash->存储检索Elasticsearch->前端展示Kibana的解决方案，基于我们目前平台来说，直接部署使用即可。当然，我们也可以制作自己的前端展示框架来替换Kibana，以更加契合我们目前运维平台的风格和特性，但以目前Kibana目前的功能来说，足以满足我们日志分析前端展示的要求，以及在开发前端展示所需要付出的时间与精力来说，并不划算。这一现成的解决方案已经很契合我们的业务要求并可直接使用。只需要在部署完成，考虑在我们的平台界面添加相关跳转链接过去即可。

至于ELK的部署方案，则是需要我们更多去考量的地方。

ELK的部署方案

一个最小的部署方案是：

需要一个Logstash实例和Elasticsearch实例，Logstash直连ElasticSearch。

使用Filters

还是最小的部署方案，只是增加了filters配置，但需要注意的时越来越来多的数据和越来越来多的过滤器会直接影响性能。

扩展到一个更大的Elasticsearch集群

Typically, Logstash does not communicate with a single Elasticsearch node, but with a cluster that comprises several nodes. By default, Logstash uses the HTTP protocol to move data into the cluster.

使用消息队列管理吞吐的峰值

When the data coming into a Logstash pipeline exceeds the Elasticsearch cluster’s ability to ingest the data, you can use a message queue as a buffer. By default, Logstash throttles incoming events when indexer consumption rates fall below incoming data rates. Since this throttling can lead to events being buffered at the data source, preventing backpressure with message queues becomes an important part of managing your deployment.
When your Logstash deployment has a message queue configured, Logstash functionally exists in two phases: shipping instances, which handles data ingestion and storage in the message queue, and indexing instances, which retrieve the data from the message queue, apply any configured filtering, and write the filtered data to an Elasticsearch index.

LogStash多连接的高可用——logStash 集群

To make your Logstash deployment more resilient to individual instance failures, you can set up a load balancer between your data source machines and the Logstash cluster. The load balancer handles the individual connections to the Logstash instances to ensure continuity of data ingestion and processing even when an individual instance is unavailable.

最后，可伸缩的Logstash应该具备的一些特性

A mature Logstash deployment typically has the following pipeline:

  • The input tier consumes data from the source, and consists of Logstash instances with the proper input plugins.
  • The message queue serves as a buffer to hold ingested data and serve as failover protection.
  • The filter tier applies parsing and other processing to the data consumed from the message queue.
  • The indexing tier moves the processed data into Elasticsearch. Any of these layers can be scaled by adding computing resources. Examine the performance of these components regularly as your use case evolves and add resources as needed. When Logstash routinely throttles incoming events, consider adding storage for your message queue. Alternately, increase the Elasticsearch cluster’s rate of data consumption by adding more Logstash indexing instances.