我们刚刚开始接触 ELK Stack 一个月左右的时间，希望利用传说中 Elasticsearch 的快速搜索能力和 Kibana 的图形展示能够更快的提供公司业务系统分析的支撑。所以就没有先纠结于自己搭建 ELK Stack，而是在网上选择 SaaS 服务。
目前最流行的应该是 AWS 上面提供的 Elasticsearch Service，和 Elastic 公司自己提供的 Elastic Cloud 服务。这里记录点我们初步使用他们的一些经验。
AWS ES
我们最开始接触时并不知道 Elastic 自己有一个云服务，所以直接上了 AWS ES 的系统。
上手情况
所有的操作都是图形界面展示，有非常丰富的中文介绍说明。非常方便了解整个系统的工作情况。
数据流采用了 Kinesis Agent 在设备端采集文件信息，然后通过 Kinesis Stream 接受数据，经过 Kinesis Analytics 进行初步数据过滤后，发送给 Firehose 作为一个通道进行数据分流，一部分直接发送给 AWS ES 系统，一部分直接发送到 S3 进行原始数据备份。AWS ES 中内部集成了 Kinaba 功能，可以在给定的 endpoint 中直接使用。
整个工作流跑起来，如果稍微熟悉一些也就一天的时间就可以搭建完成。整体用下来非常的顺畅。没有花钱的不是 😝
Kinesis Agent
这东西是 Kinesis 组件里面的一个数据采集器，没有什么特殊的功能，就是监听指定的文件，将变化的 Log 文件内容回传到 Kinesis 服务端。
在配置中，可以简单的进行 Log 文件行内容的匹配。匹配就是一个正则表达式的方式进行处理。
我们用这个部分的时间不长，没有对他的稳定性，和提供其他内容的适应性做考量。基本的印象就是能用，没有啥特点。
Kinesis Stream
这个东西号称是用于对标 Kafka 的，用户流数据的接收。使用中觉得作用实在有限，跟 Firehose 的区别也就是一个是实时数据流（Kinesis Stream) 一个是近实时的数据流。而最大的问题是 Kinesis Stream 的出口只能有一个，当然也可能是我们不会用。
最大的问题是，这东西实在是贵，我们很快就放弃了。他的好处也没有太多的体验。并且使用中我们突然发现 Kinesis Agent 的数据可以直接发送给 Firehose，就把他跳过去了。
Kinesis Analytics
这是一个类似于 KSQL 的流处理内容，有 SQL 基础的人学习这个内容还是比较容易上手的。主要是一些概念会不同，在 Kinesis Analytics 中 SQL 处理的内容是一个流数据，而以前在数据库中 SQL 处理的是一个相对静态的块内容。需要熟悉一下。
这个东西我们也很快废弃了，原因一样的简单，实在太贵了。能够对数据的处理有限，并且流 SQL 的处理实在使用不习惯。我们后来采用了 ES 内的 Script 来完成数据的处理操作。
如果有什么实时性要求非常高的流处理需求，可以考虑使用这个东西对一些特定的数据进行处理。废弃后，才想明白为何 AWS 官方的视频一直在强调安全方面的处理，觉得除了实时安全防护方面的需求，还真不知道这东西还能干吗。
Firehose
他是 AWS Kinesis 中的一个比较新的成员。感觉上应该是 AWS 准备用这个东西替换 Kinesis Stream。
他比 Stream 好在可以有多个数据出口，至于流数据的缓冲等方面我们并没有过多的探究。用起来没有发现有数据丢失和压力问题。在 Kinesis Stream 中读取的数据基本上是实时拿到的，而在 Firehose 中拿到的数据是有一个时间周期的。
Kinesis Agent 的数据可以直接发送给 Firehose，经过其中转可以发送给 Kinesis Analytics、AWS ES、S3 等各种地方。但是如果发送给 Kinesis Analytics 后就不能发送给其他的出口了。而 Kinesis Analytics 处理完成后，需要将数据发送给另一个 Firehose 后，才能转发给 AWS ES 服务。但是这时，可以有多个选择，AWS 系统中的图形化配置已经把逻辑结果说得很清楚了。
Firehose 的定位很清楚，就是一个消息队列的作用。在 Kinesis 家族中，这个东西应该是跟 Kafka 对标最相似的。但是他的限制比 Kafka 多太多了，完全没有一个消息队列的灵活性。不过费用来说还算相对便宜一些，不想自己搭建 Kafka 又想有类似的能力，可以考虑选择这个。
Elasticsearch Service
方便跟后面 Elastic 的区别，这个我就叫 AWS ES 了。
在使用上没觉得有什么不方便的，配置、启动都很顺畅，从 Firehose 接收数据也很简单。
但是最无力吐糟的就是他的 Access Control 部分，实在是搞得人晕头转向的，我们最后由于是实验系统，干脆给完全开放了。后来看到有人谈到可以在本机启动一个 Proxy 来限制对于 AWS ES 的使用，我们因为到目前为止依然拿他当实验系统，所以没有使用，有兴趣的同学可以参考这个连接 ，Github aws-es-proxy 。我们目前使用的是 Elastic X-Pack Security 组件。
初步的数据分析、简单地图形化展示在 AWS ES 上都没有问题，我们在这个系统中完成了对 Elasticsearch & Kibana 的初步熟悉。但是当稍微有点想法想做点事情的时候，就被 AWS ES 的各种限制给挡住了。AWS ES 只支持 Kibana 这一个插件，而且还不让你安装其他的，实在是很难用下去。当然如果只是拿他当一个简单的日志处理器，没有任何关联性分析的想法，应该用起来是没有问题的。
这里一定要提一句，我们用了一个新的 AWS 账户做实验，一年体验期中，我们使用 t2.small 的设备运行这个服务。整个实验期间 AWS ES 系统一分钱没花，并且也没觉得几百个 GB 的数据测试有啥太大的压力问题。大家要是只是初步熟悉了解 Elasticsearch 系统，或者做一些生产实验，完全可以注册个新的 AWS 账户，成本完全就是 0。🙄
使用感受
AWS 提供了完善的流数据处理能力，从 Agent --> 消息队列 --> 预处理 --> 分析 --> 备份，整个处理过程可以全程 SaaS 化。业务启动速度非常的快。
Kinesis 家族中的东西都能用，就是各种限制和不完善，每个用起来都像个半成品的样子，而且限制太多，灵活程度不够。作为初期的消息队列组件使用没有问题，感觉我们要真的用了 Kinesis 后面早晚会换。不过好在所有东西都是模块化的，切割更换还是很简单的。
AWS ES 系统限制实在是太多了，不仅仅 Plugin 方面不能安装。而且在 RESTful API 的使用上也做了限制，具体能够使用的 API 请参考 《支持的 Elasticsearch 操作》。写到这里回想一下，其实 AWS ES 作为分析系统使用应该也没有啥太多的限制，主要我们就是因为少了 X-Pack 的支持而废弃了他。
在 AWS 的社区中，官方无视了大量的人请愿的要求增加 X-Pack 的支持，不过估计因为授权方面的问题，这个是没有啥希望了。AWS
社区实在可怜，除了功能方面的增加要求外，实在没啥有用的。还不如 AWS Blog 中的几篇涉及到 Elasticsearch 的博文有用。
不过好在，看到 Elasticsearch 5.5 支持后，对于相关的 RESTful API 的支持应该都在不断地打开。
使用中感觉就是，主要谁的功能跟 AWS 自己的冲突，他就砍掉这些功能，然后让你能够使用他们的自家服务。但是问题是 AWS 也不是每个服务都好用。真是大厂的毛病。
写了太多，稍后再总结我们使用 Elastic Cloud 的情况，他最大的好处就是原厂的支持多。
