續上篇,這篇我們來進一步探索 Tye 更多的使用方法。本篇我們來了解一下如何在 Tye 中如何進行日誌的統一管理。
Newbe.Claptrap 是一個用於輕鬆應對並發問題的分散式開發框架。如果您是首次閱讀本系列文章。建議可以先從本文末尾的入門文章開始了解。
必不可少的日誌管理
對應用進行日誌記錄和分析是診斷排查線上問題的重要手段。而簡單基於控制台或者文件的直接記錄既不利於開發者直接讀取也不利於大規模分析。
因此,開發者往往會選擇一些諸如 Exceptionless
或者 ELK
之類的日誌管理方案,來實現線上環境的日誌管理。
但是,我們仍然缺少一個在開發環境小巧可用、部署簡易、最小資源佔用、可視化良好的日誌管理方案。
故而,本案例,讓我們來使用 Tye
中已經擴展可用的 Seq
工具,來作為開發環境的日誌管理和可視化工具。
創建測試應用
create-tye-seq-test.sh
dotnet new sln -n TyeTest
|
通過以上命令,我們創建了一個測試的 API 項目,並且創建出了 tye.yml 文件。
直接使用 tye run
命令啟動應用,我們其實可以在 tye dashboard 中查看到查看到以控制台方式輸出的日誌:
缺陷也非常明顯,這種方式非常不利於閱讀和分析。
啟用 Seq 記錄和查看日誌
打開 tye.yml ,加入 seq 的擴展配置:
tye.yml
name: tyetest
|
從上面的配置可以看出:
- 只是增加了一個 extensions 節點。在其中設置了一個 seq 的子節點並配置了日誌存儲的位置。
使用 tye run
啟動後,可以在 dashboard 中查看到啟動好的 seq 服務。
打開 seq 便可以看到 seq 的查詢介面:
使用瀏覽器調用一下 swagger 介面中的 API。便可以在 seq 中查看到最新的日誌。
這便是使用 seq 最簡單的一種方式。
seq 的搜索方式是非常類似於 SQL 的流式查詢語句,開發者可以通過以下鏈接學習如何使用 UI 進行查詢:
//docs.datalust.co/docs/the-seq-query-language
我不想每次都重新部署 Seq
我們都知道, Tye 在停止運行時會嘗試停止此次所有部署的容器,Seq 也是以容器的方式運行,因此,每次停止 Tye 時,容器都會被自動移除。這其實有點浪費時間。
因此,此處在進一步介紹如何在本地長久部署一個 Seq 實現重複利用。
實際上,根據 Tye 中的程式碼,如果服務中已經存在一個名稱為 seq
的服務,那麼就會自動使用該服務,而跳過創建步驟。
故此,我們只要本地部署一個 seq 服務,然後在 tye.yml
添加這個服務即可。
Seq 可以使用 Windows 安裝包或者使用 docker 的方式進行安裝。本示例將使用 docker 進行安裝:
docker-compose.yml
version: '3.3'
|
使用 docker-compose up -d
方式長久啟動 seq。那麼就可以在 //localhost:5380 查看到 seq dashboard。
然後,我們修改 tye.yml
:
tye.yml
name: tyetest
|
這裡,主要的改動有:
- 不再需要在 extensions 中指定日誌存儲此位置,因為這個時候時候的是外部的 seq 服務,指定這個參數已經沒有意義了。
- 添加了一個名為
seq
的服務,其中external: true
指定了其為一個外部服務。故而啟動時不會嘗試去創建這個服務。
這樣使用 tye run
啟動後得到的結果和先前效果是一致的。但是,不會在每次都重新啟動一個新的 seq 實例。而是使用我們手動部署的 seq 實例。極大加快的啟動速度。
tye 源碼關於 seq 創建方式的判斷位置:
//github.com/dotnet/tye/blob/master/src/Microsoft.Tye.Extensions/Seq/SeqExtensions.cs#L15
docker 方式安裝 seq:
//docs.datalust.co/docs/getting-started-with-docker
Windows 直接安裝 seq:
//docs.datalust.co/docs/getting-started
最後,發到 K8S 裡面試一下
注意,和前面的 mongo 一樣。 seq 並不會在使用 tye deploy
時主動創建。而是會嘗試使用服務發現機制去尋找名為 seq
的服務。這其實和上節中手動創建 Seq 實例有點類似。
因此,如果要部署 extensions
包含 seq 的 tye.yml。請確保 k8s 集群中存在名稱為 seq 的服務,這樣日誌才能正常輸出。
小結
本篇,我們已經順利完成了使用 Tye 中的 seq 擴展來實現日誌的統一管理。同時也順便練習了如何在 tye 中將為外部服務添加綁定。
實際上,Tye 不僅僅提供了 seq 擴展日誌擴展,其也提供了更加廣為人知的 Elasticsearch
+Kibana
方案。
開發者可以通過以下鏈接查看相關的操作方法:
//github.com/dotnet/tye/blob/master/docs/recipes/logging_elastic.md
下一篇,我們將進一步研究在 Tye 中實現對分散式鏈路追蹤的實現。
最後但是最重要!
如果讀者對該內容感興趣,歡迎轉發、評論、收藏文章以及項目。
最近作者正在構建以 Actor 模式 和 事件溯源 為理論基礎的一套服務端開發框架。希望為開發者提供能夠便於開發出 「分散式」、「可水平擴展」、「可測試性高」 的應用系統 ——Newbe.Claptrap
本篇文章是該框架的一篇技術選文,屬於技術構成的一部分。
項目文檔庫:claptrap.newbe.pro
聯繫方式: QQ 群 610394020
您還可以查閱本系列的其他選文:
理論入門篇
術語介紹篇
- Actor 模式
- 事件溯源(Event Sourcing)
- Claptrap
- Minion
- 事件 (Event)
- 狀態 (State)
- 狀態快照 (State Snapshot)
- Claptrap 設計圖 (Claptrap Design)
- Claptrap 工廠 (Claptrap Factory)
- Claptrap Identity
- Claptrap Box
- Claptrap 生命周期(Claptrap Lifetime Scope)
- 序列化(Serialization)
- 最小競爭資源 (Minimal Competing Resources)
樣例實踐篇
開發工具篇
- 使用 Tye 輔助開發 k8s 應用竟如此簡單(一)
- 使用 Tye 輔助開發 k8s 應用竟如此簡單(二)
- 使用 Tye 輔助開發 k8s 應用竟如此簡單(三)
- 使用 Tye 輔助開發 k8s 應用竟如此簡單(四)
- 使用 Tye 輔助開發 k8s 應用竟如此簡單(五)
- 使用 Tye 輔助開發 k8s 應用竟如此簡單(六)
其他番外篇
- 談反應式編程在服務端中的應用,資料庫操作優化,從 20 秒到 0.5 秒
- 談反應式編程在服務端中的應用,資料庫操作優化,提速 Upsert
- 十萬同時在線用戶,需要多少記憶體?——Newbe.Claptrap 框架水平擴展實驗
- docker-mcr 助您全速下載 dotnet 鏡像
- 十多位全球技術專家,為你獻上近十個小時的.Net 微服務介紹
- 年輕的樵夫喲,你掉的是這個免費 8 核 4G 公網伺服器,還是這個隨時可用的 Docker 實驗平台?
- 如何使用 dotTrace 來診斷 netcore 應用的性能問題
- 只要十步,你就可以應用表達式樹來優化動態調用
GitHub 項目地址://github.com/newbe36524/Newbe.Claptrap
Gitee 項目地址://gitee.com/yks/Newbe.Claptrap
您當前查看的是先行發佈於 www.newbe.pro 上的部落格文章,實際開發文檔隨版本而迭代。若要查看最新的開發文檔,需要移步 claptrap.newbe.pro。