【本文系互聯網技術聯盟（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）是由京東、美團點評、小米、滴滴、攜程、網易、搜狐、樂視、當當、途牛、餓了么、58、獵豹等TOP100的互聯網服務和七牛、青雲、聽雲、DaoCloud、UCloud、有雲等技術服務聯合發起的國內最大的企業間技術交流組織，專注於互聯網+技術與創新。
聯盟精心組織的1024系列技術峰會，由每周一期的線上萬人課堂和每月一次的技術大會組成。每月一個技術主題，由聯盟成員企業推薦的國內一流技術專家聯手打造，分享如何通過一線技術應用案例和最佳實踐，支撐和驅動業務成長。
聯盟還通過官方網站（www.ita1024.com），官方微信公眾（ita1024k），ITA1024技術月刊等多種形式，將精品技術內容精准推送給細分領域專業人群。
