【方案】去哪兒網徐磊：如何利用開源技術構建日處理130億+的實時日誌平臺？

轉自：http://mp.weixin.qq.com/s?__biz=MzIzMzEzODYwOA==&mid=2665284466&idx=1&sn=2b06a529821734e36e26e642424f24fc&scene=2&srcid=0527p3qISp6dFqGg8iLIYgRF&from=timeline&isappinstalled=0#wechat_redirect

 

【本文系互聯網技術聯盟（ITA1024）原創首發，轉載或節選內容前需獲受權（受權後一週之後能夠轉載），且必須在正文前註明：本文轉自互聯網技術聯盟（ITA1024）技術分享實錄,微信公衆號：ita1024k】

 

徐磊

去哪兒網

高級運維開發工程師

互聯網技術聯盟

ITA1024講師團成員

本篇文章整理自徐磊5月19日在『ITA1024運維技術精英羣』裏的分享實錄：如何利用開源技術構建日處理130億+的實時日誌平臺？ 

正文以下

 

平臺創建的背景

隨着業務規模的不斷擴大，系統功能會變得愈來愈複雜，會天然演化爲運行再多臺服務器上的分佈式系統。

 

爲了應付業務的快速發展，下降開發難度，排除性能瓶頸，系統會不斷拆分，演化成包含多種子服務的分佈式系統，各子服務經過RPC相互調用，最後完成業務流程。

 

這個拆分和進化的過程是不可逆的，子系統越變越多，各類專用功能組件會不斷被引入，系統和機器規模迅速膨脹。

 

當業務發展到像Qunar同樣的規模時，系統會進化成爲包含幾千子服務，幾萬個服務器的龐大怪物，一個運維或者開發人員根本沒法全面的瞭解系統中的每一個邏輯，也沒法經過人肉登陸服務器grep日誌的方式找到系統問題的產生的緣由。

 

同時，隨着多人協做問題定位，溝通變多，效率下降，反而阻礙業務的發展。比較有表明性的現象有新版本發佈驗證時間變長，完成一次發佈要半天的時間，還有用戶投訴問題定位時間變長。

 

爲了解決這些問題，咱們急需一個系統，具有彙總，檢索，展現應用日誌，串接事件，快速定位問題的能力，更須要知足：

 

●     可靠性，不丟消息

●    應對跨機房網絡抖動或者故障

●    可以快速響應收集需求，並作相應的格式化

●    方便的查看實時數據

 

在這個需求的驅動下，2014年底開始着手建設實時日誌平臺。

平臺演進的過程

平臺目前已經經歷了兩個大版本的迭代，目前正在實施第三個版本。天天流經平臺的日誌數量在130億（去重），寫入ElasticSearch約10TB數據，分發給Spark Streaming大約3T左右數據，輻射140多個業務線。相關數據對接線上系統，作到實時反饋，如風控，推薦等功能。

 

技術選型

 

技術選型在咱們平臺演進的過程當中一直都會有，這是由於每一個階段，平臺功能的側重點是不一樣的，致使選擇相應的技術/框架時，除了要知足功能外，還要儘可能匹配已有的結構。

 

基於這點出發，咱們須要一個二次開發能力強，儘可能輕量級的底層平臺來統一管理資源和服務的接入，再此基礎上，逐步構建咱們的日誌平臺。

 

資源管理

 

對於日誌類的應用，計算工做量會偏大一些，同時容易與業務壓力成正比，好比access日誌，訂單日誌和rpc調用日誌等，同時又具有周期性，好比早8點至凌晨2點左右日誌產生較多，凌晨2點至早8點反而是系統最閒的時候，日誌基本沒多少。

 

基於以上的場景，咱們最早考慮的是選擇一個統一的資源管理程序/框架來支撐上層的日誌服務：

1.     輕量級：佔用儘可能小的資源；

2.     高效率：足夠支撐將來集羣規模的上漲；

3.     易維護：有API能夠獲取內部的運行狀態和監控指標；

4.     定製化：萬一沒法知足所有需求還能夠本身折騰折騰；

5.     社區好：用戶/場景多，出了問題容易找到答案。

 

當時備選的主要有三個：ApacheYARN，Apache Mesos和GoogleKubernetes。咱們簡單的作了一些比較：

 

	YARN	Mesos	Kubernetes
輕量級	每一個slave部署一個node manager	每一個slave上部署一個mesos-slave進程	每一個slave上部署一個kuberlet進程
高效率	能夠支撐萬臺規模	能夠支撐萬臺規模	當時支持的最大的集羣規模仍是百臺
易維護	Ambari能夠作到部署+監控	有http api獲取監控數據	cAdvisor+Heapster作監控
定製化	支持JVM語言二次開發	支持JVM語言/Python/C++二次開發	支持Go的插件
社區支持	使用最廣，社區活躍，案例多。幾乎是數據平臺的默認資源管理器/調度器。	在Docker熱潮以前相對較默默無聞，最成功的大規模應用也僅是Twitter一家。社區在當時主要是Apache，Twitter和Mesosphere在支撐。	比較新的框架，社區一樣火爆，發展速度很是快，當時除了GCE之外還未有知名案例。也考慮到Google的風格，比較懼怕幹一半跑了。

 

從三者的對比明顯看出，Kubernetes在當時的環境下還不能算是一個production ready的框架，只能從YARN和Mesos二者中作出選擇。另外咱們當時還有一個需求，就是但願能夠利用Docker實現快速擴容+日誌的ETL定製化，因此結合上面的表格，咱們選擇了一個較爲均衡的方案——Apache Mesos。

 

YARN和Mesos都屬於兩級調度，具備必定的類似性，從YARN移植數據分析類的應用在可控範圍內，並且Spark源生支持Mesos，數據分析這塊仍是有必定的功能保障的。

應用調度

 

單獨一個Mesos是沒任何做用的，必須搭配Framework才能達到申請資源，發佈應用的目的，咱們選擇了Marathon和Chronos分別做爲long-time-running service和crond job的調度層。同時在數據分析層面，Marathon和Chronos的覆蓋面比較廣（以下圖），也知足咱們日誌這塊的需求。

兩個底層結構定下來之後，就能夠考慮業務相關的技術選型了，到此爲止，咱們的基礎平臺結構就是這樣，上層服務能夠以container方式運行在任意節點上：

 

 

日誌收集

 

這塊的重要性僅次於底層平臺，不但要穩定，還不能過多佔用資源影響線上業務，同時又要保證吞吐量。

 

根據這幾個前提，咱們首先針對日誌的來源作了一個劃分：系統日誌和業務日誌：

 

	系統日誌	業務日誌
例子	sudo.log/messages/dmsg/cron等	access.log/dubbo/error.log等等
日誌量	小	巨大
日誌格式	固定	看開發心情
受衆	OPS團隊/安全團隊	業務線開發/QA
收集狀況	每臺機器都要收集	按需決定
結論	rsyslog	Qunar  Flume

 

多數的Linux發行版都配備了rsyslog，配置簡單，性能好，插件多，足以知足系統日誌的收集需求，上線進須要批量推送配置並重啓服務便可，運維成本最小化。

 

Qunar Flume是咱們的技術部針對業務日誌開發的一個agent，借鑑了Apache Flume的結構，同時與公司的應用中心，部署平臺整合到了一塊兒，支持日誌發現，日誌聚合，以及配置熱發等實用功能，知足業務線按需收集日誌的要求，隨時開啓/中止日誌收集。

 

同時，考慮到部分應用的併發量和請求量很是大，不適合開啓磁盤日誌的應用，咱們選擇elastic的packetbeats作爲補充方案，經過分流TCP數據包的方式收集相應的日誌，適合用在Nginx的access日誌，MySQL的請求等場景上。

 

日誌隊列

 

 

咱們直接選擇了Kafka，高吞吐量，高可用性，針對日誌類消息的完美搭配。更重要的是，low level api搭配offset能夠回放數據，盡最大可能保證消息不丟失和至少處理一次。

 

日誌清洗

 

 

又是一個髒活累活，選擇性較多，比較常見的如logstash，rsyslog，storm，spark等，前二者依靠配置，後二者則是靠編程，這裏主要把logstash/storm/spark三者作個對比：

 

	logstash	storm	spark（streamimg）
開發成本	寫配置文件	寫拓撲	寫job
學習成本	低，QA也能夠修改	高，非開發人員沒法使用	高，非開發人員沒法使用
部署成本	單進程	集羣模式	集羣模式
性能	低（1.x主要在ruby和java內存結構屢次轉換上）	高	高
可靠性	低，input自身的queue致使	高，ack保證	高，direct api + checkpoint
數據聚合，如TOP N	依賴filter，好比aggregate	拓撲方式能夠作到	時間窗
擴展性	相同配置啓動新實例	增長worker/命令行調整併發	增長executor
監控/指標	無（1.x）	有	有

 

比較下來發現logstash跟Storm/Spark相比，稍遜一籌，不過可取之處是開發和學習成本，畢竟針對日誌清洗這塊，人力成本佔大部分比重，時間主要耗費在與業務線覈對格式，類型，作數據關聯等等步驟上。

 

但是咱們就3我的，沒法支撐這麼多日誌格式的清洗工做，選擇的重心就傾向於logstash，並開發相應的debug工具，由業務線的開發或QA來完成數據清理工做，從編碼向配置過分，按需解析，這樣不但釋放了咱們的精力，解析結果還100%匹配業務線的需求。

 

日誌分析

 

 

這部分咱們選擇Logstash +Spark共同完成，針對單條（注意不是單行，日誌通過了Qunar Flume聚合後，已經涵蓋了部分上下文關係）日誌的處理，使用Logstash，針對須要分析上下文/時間窗口一類的場景則選用Spark。

 

除此以外，咱們還接管了一些Storm集羣，準備在有精力的時候替換成Flink。

 

日誌存儲

 

咱們針對日誌的存儲選擇了ElasticSearch，正好搭配Kibana能夠直接檢索日誌了，簡單好用，其餘的數據仍然存儲在HDFS上，有少部分數據會寫入Redis，MySQL對接業務。

 

日誌展現

 

ElasticSearch和Logstash都上了，Kibana就別閒着了，針對日誌的檢索，報表等事情，Kibana可以很好的完成，美中不足就是咱們使用的版本是4.1的，沒法本身調整Timezone，對於某些日誌的時間戳還要額外轉換成UTC來知足Kibana的展現。

 

除了Kibana外，咱們還缺乏針對SQL的展現組件，主要是對接Hive的數據，最開始的時候咱們使用Zeppelin自帶的圖表暫時支持下，後來利用Presto + Prestogres +Hue的方式升級了一版本，目前正在嘗試Airbnb開源的Caravel對接Presto/Prestogres，支持更自由的報表展現。

 

平臺1.0：解決日誌收集/存儲/展現

 

整個項目在2015年5月份開始啓動，首要目標就是解決一個由160臺KVM組成服務發佈時的無人值守功能，提供線上日誌的檢索和篩選，快速定位故障機器，再考慮接入更多的業務線日誌，提供檢索和統計的服務。

 

首先考慮的是解決機房間數據的可用性問題，要保證在機房間網絡故障時仍然能夠緩存必定時間的日誌，而且自帶冗餘數據，咱們採起的措施是在每一個機房內都放置一組Kafka（0.8.1）集羣，日誌採起就近原則發送到同機房的Kafka內，再由程序同步到中央Kafka。

其次是qflume的推廣和運維問題，咱們採起與應用中心綁定的策略。應用中心是技術部開發的一套服務治理系統，已經覆蓋了配置熱發，監控，報警等功能，搭配qflume正合適：

 

日誌收集相關的配置也在應用中心控制，隨時開啓/關閉收集，還能夠配置日誌合併的策略，無需OPS更新線上配置，監控和報警也一步到位，簡直是運維的好幫手：

 

收集端和日誌隊列都上線之後，咱們開始着手部署Mesos（0.22.0），Marathon（0.8.0），Chronos（2.3.2），Zookeeper和ElasticSearch，使用saltstack + ansible完成。接着就開始Docker化Logstash和Kibana，還有咱們提供的一些接入/發佈工具：

 

1.     咱們從新build了Logstash的鏡像，採起啓動後拉取配置的方式來應對日誌解析規則的變動，配置文件放在Gitlab裏，開放給業務線編輯，用tag區分不一樣release的版本。容器啓動後根據傳入的環境變量tag自動拉取對應配置，好比logstash.conf，自定義的pattern和elasticsearch模板，放到對應的路徑再啓動logstash。沒有考慮一次變動一個鏡像的緣由是每次的變更主要是logstash.conf這個文件，爲了一個文件從新build & pushimage顯得有些繁瑣了。

2.     Kibana咱們給每個業務線都部署了一個，經過環境變量傳入app code，每一個業務線的indexsettings/virtuals/dashboard都是獨立的，經過Chronos定時備份到swift上。

 

3.     利用Openrestry開發了一個簡單的七層服務發現，經過泛域名的形式將Kibana和app code關聯起來（如my_tomcat.kibana.corp.qunar.com），lua解析url拿到app code，請求MarathonREST API獲取task的hostname和port，直接proxy pass過去。後續又追加了針對Marathon任務的支持（如my_tts.marathon.corp.qunar.com）。

 

4.     四層的服務發現使用Bamboo + Haproxy，相比Marathon Eventbus + Etcd + Confd + Haproxy的方式，優點是工做量小，主要是配置工做，劣勢是細節控制沒有後者精確，沒法服用，例如信息同時彙總到報警系統。

 

5.     Kafka的管理使用Yahoo開源的Kafka-manager，監控數據收集使用kafka-http-metrics-reporter + kafka_metric_2_graphite.py，直接發送到graphite，包括了offset，topic的input/output統計，under replicate等等指標。

 

6.     針對日誌的接入開發了一個發佈系統，串接Jenkins和監控系統，調用Marathon的API發佈Logstash和Kibana，同時建立響應的報警，提交定時任務備份settings等工做。

 

這一階段的集羣的規模較小，大約用掉了30-40臺機器，隨後開始向業務線推廣使用，2015年9月，每日處理量超過了40億條。

 

平臺2.0：實時日誌分發

在1.0打下的基礎上，咱們把目標升級成了數據分發平臺，除了保證日誌收集存儲外，還要聯通線上日誌與各個業務線的數據組和分析系統，下降獨自獲取實時日誌的成本，同時擴大數據的複用程度，較少重複解析形成的資源浪費。

咱們工做的重心開始瞄準了Spark（1.6.2），以及開放Kafka/Logstash/ElasticSearch的訪問權限，同時調研了Presto/Zeppelin/Alluxio（原名Tachyon）三個數據框架，提供從測試，發佈，運行，緩存加速等一系列的功能。

 

在日誌收集方面，咱們引入了Heka和Packetbeats，針對容器日誌和Nginx一類的高QPS服務（ElasticSearch的HTTPREST API訪問監控也是經過Packetbeats完成）。也容許業務線向Kafka broker寫入數據，提升數據流通效率。

 

ETL層仍然首選Logstash，全部數據均通過Logstash的處理後寫入ElasticSearch或Kafka，留給Kibana和Spark使用。

 

實時處理從Storm遷移至Spark（Flink調研中），Block和Checkpoint默認存儲在Alluxio內，計算結果則經過編碼控制寫入HDFS/RBDMS/NoSQL等系統備用。

 

OLAP以Kianba/Zeppelin（須要編程）/Caravel爲主，輔以Presto/Prestoges/Hue完成簡單報表/聚合查詢等工做。

 

在Spark on Mesos的實施上遇到了很多的問題，主要是整合部分的代碼邏輯比較簡單，不能很好的匹配生產環境的調度策略，擴容也不方便（須要重發streaming），重寫了部分代碼後纔算是較爲方便的在Mesos集羣上調度driver和executor。咱們沒有使用Docker運行Spark任務，而是選擇了Mesos container（cgroup），經過tar包的方式發佈任務。

 

因爲增長了許多服務在Mesos（0.25.0）上，資源分配成了一個比較嚴重的問題，須要對cpu/mem調整超售比，適當提升下利用率，同時還要針對不一樣的Framework作靜態資源分配，好比Spark的cpu上限爲物理核的一半，儘可能散步在集羣的各個節點上，防止堆積到某個節點致使處理緩慢，如下是當時咱們採起的一個資源配比策略：

 

 

MESOS_resources="cpus(logstash):{{num_cpus}}"
MESOS_resources="${MESOS_resources};cpus(common):4"
MESOS_resources="${MESOS_resources};cpus(kibana):4"
MESOS_resources="${MESOS_resources};cpus(ops):4"
MESOS_resources="${MESOS_resources};cpus(spark):{{num_cpus/2}}"
MESOS_resources="${MESOS_resources};cpus(tachyon):4"
MESOS_resources="${MESOS_resources};cpus(others):{{num_cpus/2}}"
MESOS_resources="${MESOS_resources};cpus(test):8"
MESOS_resources="${MESOS_resources};ports(*):[8000-32000]"

 

 

同時Marathon在日益增加的應用面前也開始出現了效率問題，咱們不得不按照用途從新規劃應用，並拆分紅多個Marathon框架，控制不一樣任務的資源上限。

 

再優化了基礎平臺後，數據的日處理量增加到了每日100億的規模，大量的數據在平臺內流通，帶來了一個新的問題，一個沒接觸過系統的人如何能方便的獲取想要的數據，咱們整理了平臺內的數據流的信息，繪製了相應的數據拓撲，對外提供查詢。

 

平臺3.0：stateful service & cache

 

這個階段正在實施中，主要是針對ElasticSearch和Alluxio服務的平臺化，藉助Mesos的持久化卷和動態預留功能，提供stateful service的部署。

 

咱們最早要解決的是ElasticSearch服務化，目前許多業務線都開始使用ElasticSearch，申請資源和運維是都是獨自在作，造成不了統一的運維標準，經驗也不容易分享。對於咱們OPS也但願統一管理底層的資源，減小業務線的壓力。

 

咱們基於Mesos（0.28.0）+Marathon（1.1.1）從新構建了一套系統，部署相互隔離的ElasticSearch集羣，指定3個節點的node tag爲master（不一樣rack）,其他節點標記成data，並配合groupby rack保證物理資源的冗餘。Master和Datanode的發現經過Bamboo + Haproxy實現，ACL考慮search-guard。

 

不推薦使用ElasticSearchon Mesos這個項目，不支持持久化卷和動態預留，貢獻也不太活躍，可是測試系統的話能夠考慮下，用完就回收。

 

另一個要解決的問題是Alluxio的服務化，把計算節點的磁盤資源利用起來，做爲一個臨時文件的DFS，同時提供給其餘系統做爲block cache的一個備選方案。

 

平臺填坑指南

 

平臺演化到今天，經歷了很多的難題，從最初的幾臺機器到如今接近兩百臺的規模，坑沒少跳。除了能力暫時還達不到沒法修改（好比Mesos），基本還均可以搞定。藉着今天的機會分享下咱們填坑和優化的一些經驗。

 

Mesos

 

在maintenance接口出來之前，白名單就是運維的利器，升級/維護/人肉調度就靠它了，咱們利用saltstack+ etcd + confd + 白名單作了一個監控基礎服務擴容的daemon。新機器升級好內核後利用saltstack部署Mesos和預熱，並curl etcd的服務註冊自身，confd監控到變化後生成白名單，並調用Marathon的REST API擴容相應的服務。

 

監控則經過Logstash的http poller input請求Mesos的API獲取相應的數據，配合json filter篩選數據後存入監控系統內。

還遇到一個未解決的問題（0.25），就是Spark的framework有必定機率殘留在某些Slave上，消耗資源，每一個殘留進程0.1cpu/32mb內存，積累起來浪費仍是很可觀的，社區裏暫時沒有發現相應的解釋。

 

Docker

 

主要說一下daemon內存的問題，咱們的Docker使用1.7.1版本，以前對log-driver沒太關注，採起了默認的json-log配置，後來一次logstash的filter報錯打印了大量的日誌到stderr，致使daemon內存一直增加，最後啓動容器都申請不到內存，解決辦法就是log-driver=none，不在經過daemon中轉日誌數據，直接經過Mesos docker executor記錄到sandbox裏。

 

 

ElasticSearch

 

咱們存放日誌的ElasticSearch機器有50臺左右，最初是SAS盤+raid10，線上跑了一段時間發現IO並非瓶頸，就更換成了容量更大的SATA盤，單機容量40多T，足夠支撐存儲的須要。

 

首先遇到的問題是fielddatacache不釋放的問題，官方文檔是不建議設置fielddata的過時時間，主要是相應的數據結構從內存中移除代價較高，可是結合咱們實際的使用狀況，咱們將fielddata失效時間調整到5min。

 

而後是最頭疼的問題，datanode的fullgc，再調整了cache比例，失效時間後，仍然會發生fullgc，對比了監控後發現此時的fullgc主要和merge相關，仔細定位後發現是因爲shard分佈不均勻致使的，修改了total_shards_per_node=2後merge明顯引發的fullgc明顯降低了不少。

 

最後是寫入QPS不穩定的問題，這個問題在日誌處理量越多時越明顯，在data node的日誌上咱們發現了大量的「now throttlingindexing」提示，考慮到日誌的ElasticSearch並不是100%都須要寫入後當即能查詢到，咱們就調整了indices.store.throttle.type=none，防止由於merge限流致使的寫入變慢，同時又加大了indices.store.throttle.max_bytes_per_sec=100mb。

 

ElasticSearch的監控咱們選擇es2graphite.py這個腳本，配合公司的監控系統watcher，能夠知足平常的運維須要。

 

 

Logstash

 

最主要的是問題監控不足，吞吐量下降時不知道卡在哪一個環節，針對這個問題咱們修改了Logstash的部分代碼，針對input/filter/output埋點，統計每條日誌的處理時延，同時按期獲取兩個queue上的wait thread數量已肯定哪一個部分託慢了整個pipeline。

 

Spark on Mesos

 

遇到的問題很是多，小到臨時文件的存放，大到checkpoint失效，算是從頭至尾踩了一遍。1.6以前的Spark對於Mesos的支持並非很好，好比認證和調度約束都沒有作，須要本身寫patch。

 

經過mesosdispatcher提交的job，一些配置信息，環境變量帶不過去，看了代碼才發現環境變量是經過文件傳遞的，簡單的解決辦法就是把須要的信息寫到spark-env.sh內。

 

1.5以前的臨時文件不能放到Mesos的sandbox裏，沒法利用Mesos的GC機制釋放磁盤空間，1.5開始經過spark.local.dir和java.io.tmp配置寫入sandbox。

 

Spark on Mesos默認不支持多executor，須要本身patch對應代碼，或者利用Marathon啓動executor，咱們更推薦後者，針對Streaming任務擴容更方便。

 

Streaming的任務以Kafka做爲數據源使用時，推薦使用direct api，經過編碼方式控制offset的提交，同時每一個executor都有本身的consumer，consumer的併發粒度遠遠好於reciver的方式，消息可靠性也比reciver高，美中不足是沒有主動設置kafka partition的owner，須要本身編碼實現。

 

另外，checkpoint記錄在Alluxio（0.8.2）上會出現「fileis not complete」的狀況，這是client實現的問題，須要升級到1.0.0+版本解決，而HDFS無此問題。

 

最後一個問題是Streaming經過checkpoint恢復後丟失了一些依賴包（表現形式多爲ClassNotFound），這是由於在Spark on Mesos在啓動Driver後，相應的jar包放置在了對應的sandbox內，Driver恢復後路徑已經變化了，新的sandbox內沒有對應的jar包，較爲簡單的解決辦法以下：

sparkConf.setJars(Array(s"http://stor.corp.qunar.com/qae/spark/$dep-$appCode-jar-with-dependencies.jar"))

 

 

把Jar包放在FTP服務器上，每次Driver啓動都去FTP同步jar包恢復執行狀況。

 

以上就是今晚的分享，謝謝你們。

 

 

Q&A

問：將全部的服務運行在容器之上的初衷是什麼？

徐磊：混布+資源控制+方便部署，是優先考慮的。

 

追問： 這樣作了投入產出 以爲如何？

徐磊： 針對配置型的，好比logstash這些組件，之前用ansible或者saltstack去替換配置，重啓服務，如今這些的工做由docker的entrypoint和mesos slave來作。投入就是不須要開發針對ansible/saltstack的對接系統了，直接點鼠標就行了。

 

問：日誌的蒐集是實時仍是固定時間啊？

徐磊：實時時候，相似tail，qflume來作的。

 

問：日誌按什麼規則彙總的？   spark多久計算一次，從進入kafka到spark結果延時大概多少？

徐磊：這個默認是按照行(\n)收集，也能夠根據一些規則，好比java的stacktrace，能夠按照日誌時間的前綴收集，自動merge。 spark的batch時間最長有10min的，最短的是200ms，從收集開始算，到進入kafka的時間不超過150ms。

 

問：是否能夠將flume徹底替代logstash？

徐磊：收集端能夠，並且還有beats系列能夠用，不必用logstash收集。

 

追問：那就是能夠徹底替換樓？

徐磊：徹底能夠flume。

 

追問：有考慮過 solr 來作搜索嗎？

徐磊：沒，目前跟定了es。

 

問：logstash 的配置文檔我感受 很傻瓜化 ，裏面的核心的內部參數都沒有辦法配置，好比相似flume的channel 沒有辦法配置？

徐磊：對。。。這是配置類應用的劣勢，若是有精力開發的話，效果確定要比logstash好多了，好比咱們本身的qflume。

 

問：利用sprak 和storm在，在日誌實時監控上有什麼具體功能？

徐磊：好比search rank，商品推薦，風控等等，之前經過系統間埋點調用換成了消費日誌的方式。

 

問：這套結構是否嘗試過用過度析Nginx日誌用於流量控制，秒級日誌聚合統計效果如何？

徐磊：http server + packetbeats相對好一點，可是目前咱們沒有把access log直接對接流控這部分，日誌聚合依賴es的功能，咱們目前是經過Kibana+定時刷新來看，若是想更加靈敏，能夠用elasticsearch的一個特性（叫p什麼來着，忘記名字了），提早構建search，es會根據search的匹配程度自動推送數據出來，相似hook，這種的延時性要好於經過kibana來看。

 

問：opsdev  大家都用什麼語言？

徐磊：Python爲主，Java和Scala爲輔，少許的golang。

 

問：實時收集，會對生產系統產生影響嗎？

徐磊：會有影響，咱們許多應用都是運行在4core/4G的kvm上，收集agent若是資源佔用過大會影響到線上服務，這也是咱們的技術部從新開發qflume的一個目的，下降agent在資源的損耗，可是不能說100%避免極端狀況，好比咱們有個服務的日誌會把request/response的數據記錄下來，單行日誌有過誇張的5mb，這種狀況在producer queue的時候容易oom。

 

問：日誌不作匯聚和合並   對spark計算有影響吧，對hadoop也很差    請問這塊大家怎麼作的？

徐磊：給spark的日誌會根據要求提早把數據進行初步的處理，咱們通常會採用ruby代碼的方式來作這些事情，可是跑在logstash裏，至關因而數據經過logstash再作一次處理，寫回kafka，再交給spark作，能知足一部分的狀況。有些時候數據實在太散了咱們也很差用logstash作，只能依靠spark/storm來了。

 

問：當時1.0 - 3.0這些階段中，作這套系統的人員有多少人？這中間經歷了多少時間？

徐磊：1.0兩我的，主要是我和個人leader一塊兒作，2.0維持在3我的，如今3.0 4我的。

 

問：點擊流日誌，你們用什麼收集？

徐磊：收集方式不太同樣，若是是公共數據要用的，通常都是分析入口應用的日誌，缺點就是費時費力，格式一遍就歇菜了，咱們公司有一個更方便的東西，能夠直接把app的點擊流發送回來，比直接分析日誌的方式節省人力。

 

問：太散的話  貌似對spark和hadoop性能有影響    如今大家是經過spark處理麼，以作前期處理麼  flume收集的話，我沒找到方案，收集上作合併也有侷限性？

徐磊：若是是擔憂頻繁寫入HDFS的話，咱們使用了Alluxio，Spark數據直接寫入Alluxio裏面，異步寫到underfs，這種方式不會由於Spark上層的mirco batch太頻繁致使的請求過大，同時異步寫還能保證批量刷新。

 

問：關於application日誌和access日誌上下文聚合有什麼最佳實踐沒？

徐磊：單純的access日誌的話，咱們目前的方法是解析完直接寫入es了，經過es提供aggregate來作聚合，若是要關聯其餘日誌的話，咱們暫時還沒開始作，這個也是咱們3.0要乾的事情，因此咱們也是在摸索中。

 

 

◆  ◆  ◆

關於ITA1024

 

互聯網技術聯盟（ITA1024）是由京東、美團點評、小米、滴滴、攜程、網易、搜狐、樂視、噹噹、途牛、餓了麼、5八、獵豹等TOP100的互聯網服務和七牛、青雲、聽雲、DaoCloud、UCloud、有云等技術服務聯合發起的國內最大的企業間技術交流組織，專一於互聯網+技術與創新。

聯盟精心組織的1024系列技術峯會，由每週一期的線上萬人課堂和每個月一次的技術大會組成。每個月一個技術主題，由聯盟成員企業推薦的國內一流技術專家聯手打造，分享如何經過一線技術應用案例和最佳實踐，支撐和驅動業務成長。

聯盟還經過官方網站（www.ita1024.com），官方微信公衆（ita1024k），ITA1024技術月刊等多種形式，將精品技術內容精準推送給細分領域專業人羣。