我們剛剛開始接觸 ELK Stack 一個(gè)月左右的時(shí)間筋帖，希望利用傳說中 Elasticsearch 的快速搜索能力和 Kibana 的圖形展示能夠更快的提供公司業(yè)務(wù)系統(tǒng)分析的支撐溜哮。所以就沒有先糾結(jié)于自己搭建 ELK Stack该面，而是在網(wǎng)上選擇 SaaS 服務(wù)。
目前最流行的應(yīng)該是 AWS 上面提供的 Elasticsearch Service郑藏，和 Elastic 公司自己提供的 Elastic Cloud 服務(wù)。這里記錄點(diǎn)我們初步使用他們的一些經(jīng)驗(yàn)。
AWS ES
我們最開始接觸時(shí)并不知道 Elastic 自己有一個(gè)云服務(wù)兆旬，所以直接上了 AWS ES 的系統(tǒng)。
上手情況
所有的操作都是圖形界面展示怎栽，有非常豐富的中文介紹說明丽猬。非常方便了解整個(gè)系統(tǒng)的工作情況。
數(shù)據(jù)流采用了 Kinesis Agent 在設(shè)備端采集文件信息熏瞄，然后通過 Kinesis Stream 接受數(shù)據(jù)脚祟，經(jīng)過 Kinesis Analytics 進(jìn)行初步數(shù)據(jù)過濾后，發(fā)送給 Firehose 作為一個(gè)通道進(jìn)行數(shù)據(jù)分流强饮，一部分直接發(fā)送給 AWS ES 系統(tǒng)由桌，一部分直接發(fā)送到 S3 進(jìn)行原始數(shù)據(jù)備份。AWS ES 中內(nèi)部集成了 Kinaba 功能邮丰，可以在給定的 endpoint 中直接使用行您。
整個(gè)工作流跑起來，如果稍微熟悉一些也就一天的時(shí)間就可以搭建完成剪廉。整體用下來非常的順暢娃循。沒有花錢的不是 ??
Kinesis Agent
這東西是 Kinesis 組件里面的一個(gè)數(shù)據(jù)采集器，沒有什么特殊的功能斗蒋，就是監(jiān)聽指定的文件捌斧，將變化的 Log 文件內(nèi)容回傳到 Kinesis 服務(wù)端。
在配置中泉沾，可以簡單的進(jìn)行 Log 文件行內(nèi)容的匹配捞蚂。匹配就是一個(gè)正則表達(dá)式的方式進(jìn)行處理。
我們用這個(gè)部分的時(shí)間不長跷究，沒有對他的穩(wěn)定性姓迅，和提供其他內(nèi)容的適應(yīng)性做考量〗页基本的印象就是能用队贱，沒有啥特點(diǎn)。
Kinesis Stream
這個(gè)東西號稱是用于對標(biāo) Kafka 的潭袱，用戶流數(shù)據(jù)的接收柱嫌。使用中覺得作用實(shí)在有限，跟 Firehose 的區(qū)別也就是一個(gè)是實(shí)時(shí)數(shù)據(jù)流（Kinesis Stream) 一個(gè)是近實(shí)時(shí)的數(shù)據(jù)流屯换。而最大的問題是 Kinesis Stream 的出口只能有一個(gè)编丘，當(dāng)然也可能是我們不會用与学。
最大的問題是，這東西實(shí)在是貴嘉抓，我們很快就放棄了索守。他的好處也沒有太多的體驗(yàn)。并且使用中我們突然發(fā)現(xiàn) Kinesis Agent 的數(shù)據(jù)可以直接發(fā)送給 Firehose抑片，就把他跳過去了卵佛。
Kinesis Analytics
這是一個(gè)類似于 KSQL 的流處理內(nèi)容，有 SQL 基礎(chǔ)的人學(xué)習(xí)這個(gè)內(nèi)容還是比較容易上手的敞斋。主要是一些概念會不同截汪，在 Kinesis Analytics 中 SQL 處理的內(nèi)容是一個(gè)流數(shù)據(jù)，而以前在數(shù)據(jù)庫中 SQL 處理的是一個(gè)相對靜態(tài)的塊內(nèi)容植捎。需要熟悉一下衙解。
這個(gè)東西我們也很快廢棄了，原因一樣的簡單焰枢，實(shí)在太貴了蚓峦。能夠?qū)?shù)據(jù)的處理有限，并且流 SQL 的處理實(shí)在使用不習(xí)慣济锄。我們后來采用了 ES 內(nèi)的 Script 來完成數(shù)據(jù)的處理操作暑椰。
如果有什么實(shí)時(shí)性要求非常高的流處理需求，可以考慮使用這個(gè)東西對一些特定的數(shù)據(jù)進(jìn)行處理拟淮。廢棄后干茉，才想明白為何 AWS 官方的視頻一直在強(qiáng)調(diào)安全方面的處理，覺得除了實(shí)時(shí)安全防護(hù)方面的需求很泊，還真不知道這東西還能干嗎。
Firehose
他是 AWS Kinesis 中的一個(gè)比較新的成員沾谓。感覺上應(yīng)該是 AWS 準(zhǔn)備用這個(gè)東西替換 Kinesis Stream委造。
他比 Stream 好在可以有多個(gè)數(shù)據(jù)出口，至于流數(shù)據(jù)的緩沖等方面我們并沒有過多的探究均驶。用起來沒有發(fā)現(xiàn)有數(shù)據(jù)丟失和壓力問題昏兆。在 Kinesis Stream 中讀取的數(shù)據(jù)基本上是實(shí)時(shí)拿到的，而在 Firehose 中拿到的數(shù)據(jù)是有一個(gè)時(shí)間周期的妇穴。
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ā)送給另一個(gè) Firehose 后曲梗，才能轉(zhuǎn)發(fā)給 AWS ES 服務(wù)赞警。但是這時(shí)，可以有多個(gè)選擇虏两，AWS 系統(tǒng)中的圖形化配置已經(jīng)把邏輯結(jié)果說得很清楚了愧旦。
Firehose 的定位很清楚，就是一個(gè)消息隊(duì)列的作用定罢。在 Kinesis 家族中笤虫，這個(gè)東西應(yīng)該是跟 Kafka 對標(biāo)最相似的。但是他的限制比 Kafka 多太多了祖凫，完全沒有一個(gè)消息隊(duì)列的靈活性琼蚯。不過費(fèi)用來說還算相對便宜一些，不想自己搭建 Kafka 又想有類似的能力蝙场，可以考慮選擇這個(gè)凌停。
Elasticsearch Service
方便跟后面 Elastic 的區(qū)別，這個(gè)我就叫 AWS ES 了售滤。
在使用上沒覺得有什么不方便的罚拟，配置、啟動都很順暢完箩，從 Firehose 接收數(shù)據(jù)也很簡單赐俗。
但是最無力吐糟的就是他的 Access Control 部分，實(shí)在是搞得人暈頭轉(zhuǎn)向的弊知，我們最后由于是實(shí)驗(yàn)系統(tǒng)阻逮，干脆給完全開放了。后來看到有人談到可以在本機(jī)啟動一個(gè) Proxy 來限制對于 AWS ES 的使用秩彤，我們因?yàn)榈侥壳盀橹挂廊荒盟?dāng)實(shí)驗(yàn)系統(tǒng)叔扼，所以沒有使用，有興趣的同學(xué)可以參考這個(gè)連接 漫雷，Github aws-es-proxy 瓜富。我們目前使用的是 Elastic X-Pack Security 組件。
初步的數(shù)據(jù)分析降盹、簡單地圖形化展示在 AWS ES 上都沒有問題与柑，我們在這個(gè)系統(tǒng)中完成了對 Elasticsearch & Kibana 的初步熟悉。但是當(dāng)稍微有點(diǎn)想法想做點(diǎn)事情的時(shí)候蓄坏，就被 AWS ES 的各種限制給擋住了价捧。AWS ES 只支持 Kibana 這一個(gè)插件，而且還不讓你安裝其他的涡戳，實(shí)在是很難用下去结蟋。當(dāng)然如果只是拿他當(dāng)一個(gè)簡單的日志處理器，沒有任何關(guān)聯(lián)性分析的想法妹蔽，應(yīng)該用起來是沒有問題的椎眯。
這里一定要提一句挠将，我們用了一個(gè)新的 AWS 賬戶做實(shí)驗(yàn)，一年體驗(yàn)期中编整，我們使用 t2.small 的設(shè)備運(yùn)行這個(gè)服務(wù)舔稀。整個(gè)實(shí)驗(yàn)期間 AWS ES 系統(tǒng)一分錢沒花，并且也沒覺得幾百個(gè) GB 的數(shù)據(jù)測試有啥太大的壓力問題掌测。大家要是只是初步熟悉了解 Elasticsearch 系統(tǒng)内贮，或者做一些生產(chǎn)實(shí)驗(yàn)，完全可以注冊個(gè)新的 AWS 賬戶汞斧，成本完全就是 0夜郁。??
使用感受
AWS 提供了完善的流數(shù)據(jù)處理能力，從 Agent --> 消息隊(duì)列 --> 預(yù)處理 --> 分析 --> 備份粘勒，整個(gè)處理過程可以全程 SaaS 化竞端。業(yè)務(wù)啟動速度非常的快。
Kinesis 家族中的東西都能用庙睡，就是各種限制和不完善事富，每個(gè)用起來都像個(gè)半成品的樣子，而且限制太多乘陪，靈活程度不夠统台。作為初期的消息隊(duì)列組件使用沒有問題，感覺我們要真的用了 Kinesis 后面早晚會換啡邑。不過好在所有東西都是模塊化的贱勃，切割更換還是很簡單的。
AWS ES 系統(tǒng)限制實(shí)在是太多了谤逼，不僅僅 Plugin 方面不能安裝贵扰。而且在 RESTful API 的使用上也做了限制，具體能夠使用的 API 請參考 《支持的 Elasticsearch 操作》流部。寫到這里回想一下拔鹰，其實(shí) AWS ES 作為分析系統(tǒng)使用應(yīng)該也沒有啥太多的限制，主要我們就是因?yàn)樯倭?X-Pack 的支持而廢棄了他贵涵。
在 AWS 的社區(qū)中，官方無視了大量的人請?jiān)傅囊笤黾?X-Pack 的支持恰画，不過估計(jì)因?yàn)槭跈?quán)方面的問題宾茂，這個(gè)是沒有啥希望了。AWS
社區(qū)實(shí)在可憐拴还，除了功能方面的增加要求外跨晴，實(shí)在沒啥有用的。還不如 AWS Blog 中的幾篇涉及到 Elasticsearch 的博文有用片林。
不過好在端盆，看到 Elasticsearch 5.5 支持后怀骤，對于相關(guān)的 RESTful API 的支持應(yīng)該都在不斷地打開。
使用中感覺就是焕妙，主要誰的功能跟 AWS 自己的沖突蒋伦，他就砍掉這些功能，然后讓你能夠使用他們的自家服務(wù)焚鹊。但是問題是 AWS 也不是每個(gè)服務(wù)都好用痕届。真是大廠的毛病。
寫了太多末患，稍后再總結(jié)我們使用 Elastic Cloud 的情況研叫，他最大的好處就是原廠的支持多。
