引言：
眾所周知，對於乙個雲原生 paas 平台而言，在頁面上檢視日誌與指標是最為基礎的功能。無論是日誌、指標還是鏈路追蹤，基本都分為採集、儲存和展示 3 個模組。
這裡筆者將介紹雲原生下的常見的指標 & 日誌的採集方案，以及 erda 作為乙個雲原生 paas 平台是如何實將其現的。
採集端 agent 通過 daemonset 的方式部署在每個節點上。該模式下，通常是由 agent 主動採集的方式來獲取指標，常見的 agent 有 telegraf、metricbeat、cadvisor 等。
應用場景：
當我們需要採集程式的內部指標時，通常採用 agent 主動拉取指標或客戶端主動推送指標的方式。
應用場景：
那麼，到底是採用推還是拉的方式呢？
我認為這取決於實際應用場景。例如：短時任務，由於 agent 可能還沒開始採集它就已經結束了，因此我們採用推的方式；而對於 web 服務則不存在這個問題，採用拉的方式還能減少使用者側的負擔。
prometheus 作為 cncf 的 2 號畢業選手，一出生就基本成為雲原生尤其是 kubernetes 的官配監控方案了。
它實際是一套完整的解決方案，這裡我們主要介紹它的採集功能。
其與推&拉方案基本相同，不過由於其即為豐富的 exporter 體系，基本可以採集包括節點級別的各種指標。
在 erda 中，當前的方案是通過二開了 telegraf, 利用其豐富的採集外掛程式，合併了 daemonset 和推拉方案。
容器內應用的日誌若輸出到 stdout 中，容器執行時會通過 logging-driver 模組輸出到其他媒介上，通常是本機的磁碟上，例如 docker 通常會通過 json-driver 輸出日誌到 /var/log/docker/containers//*.log 檔案中。
對於這種場景，我們一般採用 daemonset 的方案，即在每個節點上部署乙個採集器，通過讀取機器上的日誌檔案來採集日誌。
daemonset 方案也有一些侷限性，例如，當應用日誌是輸出到日誌檔案時，或者想對日誌配置一些處理規則（例如，多行規則、日誌提取規則）時。
此時可採用 sidecar 的方案，通過 logging-agent 與應用容器通過共享日誌目錄、主動上報等方式來採集。
當然，還可以主動（一般通過**商提供的 sdk）上報日誌。
常見應用場景有：
業界中，比較有名的就是使用 elk 來作為日誌方案，當然也是整套解決方案。採集模組主要是 beats 作為採集端，logstash 作為日誌收集總入口，elasticsearch 作為儲存，kibana 作為展示層。
在 erda 中，我們使用了 fluent-bit 作為日誌採集器：
不難看出，無論是指標還是日誌，其資料採集方案還是比較簡單清晰的，我們可以根據實際場景隨意搭配。
然而隨著集群規模的增長以及使用者自定義需求的增加，往往會出現如下難點：
對於這些問題，我們也在不斷探索實踐中，並會在後續的文章中進行分享。
文中部分源自網路，侵刪
雲原生思想 雲原生的微服務架構
不同微服務之間可能存在一些異構，為了讓每乙個團隊在微服務體系下發揮最大效能，我們允許不同團隊採用不同的程式語言，甚至不同的執行環境來去執行這些微服務。因此，我們在運維和管理微服務時，最初其實並沒有一套統一的標準去處理的異構環境，這也是為什麼後來容器技術變得流行起來，它的乙個重要作用就是通過一層標準的...
雲原生的開發理念
雲原生的開發理念體現在敏捷開發和雲原生的價值上 01.敏捷開發 敏捷開發體現的內容 互動,交付,協作,變化.個體與互動,勝過於過程和工具.可以工作的軟體,勝過於面面俱到的文件.客戶協作,勝過於合同談判.響應變化,勝過於遵循計畫.小步快跑,快速迭代,我們怎麼才能實現該目標呢?02.雲原生的價值 交付軟...
雲計算的下半場 雲原生
是否上雲已經很少被提及，如何它已經成為乙個熱門話題，因為它已經滲透到各行各業，和後半雲計算時代，它的未來發展將走向，雲計算市場發生了哪些變化值得考慮。接下來，雲容科技將帶你們一起分析 雲計算的下半場 雲原生 近年來，在政策的大力支援下，雲計算在全國各地蓬勃發展，像雨後春筍般湧現出私有雲，完成了傳統i...