我們剛剛開始接觸 ELK Stack 一個月左右的時間，希望利用傳說中 Elasticsearch 的快速搜索能力和 Kibana 的圖形展示能夠更快的提供公司業(yè)務系統(tǒng)分析的支撐。所以就沒有先糾結(jié)于自己搭建 ELK Stack，而是在網(wǎng)上選擇 SaaS 服務。

目前最流行的應該是 AWS 上面提供的 Elasticsearch Service，和 Elastic 公司自己提供的 Elastic Cloud 服務。這里記錄點我們初步使用他們的一些經(jīng)驗。

AWS ES

我們最開始接觸時并不知道 Elastic 自己有一個云服務，所以直接上了 AWS ES 的系統(tǒng)。

上手情況

所有的操作都是圖形界面展示，有非常豐富的中文介紹說明。非常方便了解整個系統(tǒng)的工作情況。

數(shù)據(jù)流采用了 Kinesis Agent 在設(shè)備端采集文件信息，然后通過 Kinesis Stream 接受數(shù)據(jù)，經(jīng)過 Kinesis Analytics 進行初步數(shù)據(jù)過濾后，發(fā)送給 Firehose 作為一個通道進行數(shù)據(jù)分流，一部分直接發(fā)送給 AWS ES 系統(tǒng)，一部分直接發(fā)送到 S3 進行原始數(shù)據(jù)備份。AWS ES 中內(nèi)部集成了 Kinaba 功能，可以在給定的 endpoint 中直接使用。

整個工作流跑起來，如果稍微熟悉一些也就一天的時間就可以搭建完成。整體用下來非常的順暢。沒有花錢的不是 ??

Kinesis Agent

這東西是 Kinesis 組件里面的一個數(shù)據(jù)采集器，沒有什么特殊的功能，就是監(jiān)聽指定的文件，將變化的 Log 文件內(nèi)容回傳到 Kinesis 服務端。

在配置中，可以簡單的進行 Log 文件行內(nèi)容的匹配。匹配就是一個正則表達式的方式進行處理。

我們用這個部分的時間不長，沒有對他的穩(wěn)定性，和提供其他內(nèi)容的適應性做考量?；镜挠∠缶褪悄苡茫瑳]有啥特點。

Kinesis Stream

這個東西號稱是用于對標 Kafka 的，用戶流數(shù)據(jù)的接收。使用中覺得作用實在有限，跟 Firehose 的區(qū)別也就是一個是實時數(shù)據(jù)流（Kinesis Stream) 一個是近實時的數(shù)據(jù)流。而最大的問題是 Kinesis Stream 的出口只能有一個，當然也可能是我們不會用。

最大的問題是，這東西實在是貴，我們很快就放棄了。他的好處也沒有太多的體驗。并且使用中我們突然發(fā)現(xiàn) Kinesis Agent 的數(shù)據(jù)可以直接發(fā)送給 Firehose，就把他跳過去了。

Kinesis Analytics

這是一個類似于 KSQL 的流處理內(nèi)容，有 SQL 基礎(chǔ)的人學習這個內(nèi)容還是比較容易上手的。主要是一些概念會不同，在 Kinesis Analytics 中 SQL 處理的內(nèi)容是一個流數(shù)據(jù)，而以前在數(shù)據(jù)庫中 SQL 處理的是一個相對靜態(tài)的塊內(nèi)容。需要熟悉一下。

這個東西我們也很快廢棄了，原因一樣的簡單，實在太貴了。能夠?qū)?shù)據(jù)的處理有限，并且流 SQL 的處理實在使用不習慣。我們后來采用了 ES 內(nèi)的 Script 來完成數(shù)據(jù)的處理操作。

如果有什么實時性要求非常高的流處理需求，可以考慮使用這個東西對一些特定的數(shù)據(jù)進行處理。廢棄后，才想明白為何 AWS 官方的視頻一直在強調(diào)安全方面的處理，覺得除了實時安全防護方面的需求，還真不知道這東西還能干嗎。

Firehose

他是 AWS Kinesis 中的一個比較新的成員。感覺上應該是 AWS 準備用這個東西替換 Kinesis Stream。

他比 Stream 好在可以有多個數(shù)據(jù)出口，至于流數(shù)據(jù)的緩沖等方面我們并沒有過多的探究。用起來沒有發(fā)現(xiàn)有數(shù)據(jù)丟失和壓力問題。在 Kinesis Stream 中讀取的數(shù)據(jù)基本上是實時拿到的，而在 Firehose 中拿到的數(shù)據(jù)是有一個時間周期的。

Kinesis Agent 的數(shù)據(jù)可以直接發(fā)送給 Firehose，經(jīng)過其中轉(zhuǎn)可以發(fā)送給 Kinesis Analytics、AWS ES、S3 等各種地方。但是如果發(fā)送給 Kinesis Analytics 后就不能發(fā)送給其他的出口了。而 Kinesis Analytics 處理完成后，需要將數(shù)據(jù)發(fā)送給另一個 Firehose 后，才能轉(zhuǎn)發(fā)給 AWS ES 服務。但是這時，可以有多個選擇，AWS 系統(tǒng)中的圖形化配置已經(jīng)把邏輯結(jié)果說得很清楚了。

Firehose 的定位很清楚，就是一個消息隊列的作用。在 Kinesis 家族中，這個東西應該是跟 Kafka 對標最相似的。但是他的限制比 Kafka 多太多了，完全沒有一個消息隊列的靈活性。不過費用來說還算相對便宜一些，不想自己搭建 Kafka 又想有類似的能力，可以考慮選擇這個。

Elasticsearch Service

方便跟后面 Elastic 的區(qū)別，這個我就叫 AWS ES 了。

在使用上沒覺得有什么不方便的，配置、啟動都很順暢，從 Firehose 接收數(shù)據(jù)也很簡單。

但是最無力吐糟的就是他的 Access Control 部分，實在是搞得人暈頭轉(zhuǎn)向的，我們最后由于是實驗系統(tǒng)，干脆給完全開放了。后來看到有人談到可以在本機啟動一個 Proxy 來限制對于 AWS ES 的使用，我們因為到目前為止依然拿他當實驗系統(tǒng)，所以沒有使用，有興趣的同學可以參考這個連接 ，Github aws-es-proxy 。我們目前使用的是 Elastic X-Pack Security 組件。

初步的數(shù)據(jù)分析、簡單地圖形化展示在 AWS ES 上都沒有問題，我們在這個系統(tǒng)中完成了對 Elasticsearch & Kibana 的初步熟悉。但是當稍微有點想法想做點事情的時候，就被 AWS ES 的各種限制給擋住了。AWS ES 只支持 Kibana 這一個插件，而且還不讓你安裝其他的，實在是很難用下去。當然如果只是拿他當一個簡單的日志處理器，沒有任何關(guān)聯(lián)性分析的想法，應該用起來是沒有問題的。

這里一定要提一句，我們用了一個新的 AWS 賬戶做實驗，一年體驗期中，我們使用 t2.small 的設(shè)備運行這個服務。整個實驗期間 AWS ES 系統(tǒng)一分錢沒花，并且也沒覺得幾百個 GB 的數(shù)據(jù)測試有啥太大的壓力問題。大家要是只是初步熟悉了解 Elasticsearch 系統(tǒng)，或者做一些生產(chǎn)實驗，完全可以注冊個新的 AWS 賬戶，成本完全就是 0。??

使用感受

AWS 提供了完善的流數(shù)據(jù)處理能力，從 Agent --> 消息隊列 --> 預處理 --> 分析 --> 備份，整個處理過程可以全程 SaaS 化。業(yè)務啟動速度非常的快。

Kinesis 家族中的東西都能用，就是各種限制和不完善，每個用起來都像個半成品的樣子，而且限制太多，靈活程度不夠。作為初期的消息隊列組件使用沒有問題，感覺我們要真的用了 Kinesis 后面早晚會換。不過好在所有東西都是模塊化的，切割更換還是很簡單的。

AWS ES 系統(tǒng)限制實在是太多了，不僅僅 Plugin 方面不能安裝。而且在 RESTful API 的使用上也做了限制，具體能夠使用的 API 請參考 《支持的 Elasticsearch 操作》。寫到這里回想一下，其實 AWS ES 作為分析系統(tǒng)使用應該也沒有啥太多的限制，主要我們就是因為少了 X-Pack 的支持而廢棄了他。

在 AWS 的社區(qū)中，官方無視了大量的人請愿的要求增加 X-Pack 的支持，不過估計因為授權(quán)方面的問題，這個是沒有啥希望了。AWS
社區(qū)實在可憐，除了功能方面的增加要求外，實在沒啥有用的。還不如 AWS Blog 中的幾篇涉及到 Elasticsearch 的博文有用。

不過好在，看到 Elasticsearch 5.5 支持后，對于相關(guān)的 RESTful API 的支持應該都在不斷地打開。

使用中感覺就是，主要誰的功能跟 AWS 自己的沖突，他就砍掉這些功能，然后讓你能夠使用他們的自家服務。但是問題是 AWS 也不是每個服務都好用。真是大廠的毛病。

寫了太多，稍后再總結(jié)我們使用 Elastic Cloud 的情況，他最大的好處就是原廠的支持多。