項目經驗

項目經驗

要點

1. Kubernetes 生產應用
2. 雲主機彈性伸縮
3. 日誌收集平臺 ELK
4. 監控平臺 從 zabbix 到 prometheus
5. 代碼發佈平臺 Jenkins
6. 堡壘機 jumpserver
7. 打點服務應用 prometheus

---

<a id = "ks"> Kubernetes 生產應用 </a>

關鍵點 :

• 服務彈性伸縮, deployment 利用Horizontal Pod Autoscaling 實現對 pod 的彈性伸縮
• 對內對外提供服務, 利用 ingress 和 service 實現
• 權限管理, 利用 namespace 和 rdac實現
• helm 軟件包管理工具
• node 節點的彈性伸縮, 利用對雲主機的彈性伸縮實現

監控

• kube-prometheus

日誌收集

節點上運行一個 agent 來收集日誌,但 DaemonSet 模式下

• 阿里雲日誌服務
• FELK

pod 中包含一個 sidecar 容器來收集應用日誌

• 在每個 pod 中添加一個 fluentd 或 filebeat 容器收集日誌傳輸到外部ELK 中

直接在應用程序中將日誌信息推送到採集後端

代碼發佈

• jenkins shell（目前比較low）
• 可用 drone 或 jenkins-pipeline 。
• 自己寫一個。已經有大概思路。

<a id = "ecs"> 雲主機彈性伸縮。</a>

對主機的彈性伸縮服務，這個是雲服務商提供的服務。\
彈性伸縮主要是根據設置的伸縮規則，在業務需求增長時自動爲您增加 ECS 實例以保證計算能力，在業務需求下降時自動減少 ECS 實例以節約成本。\
產品主要通過在SLB後面掛載 ECS 。實現對cpu或內存使用率的監控，當內存或cpu超過一定的閾值，利用之前定義的伸縮策略，利用之前製作好到鏡像進行伸縮 ECS 。\
帶來下面問題

問題

新發布代碼無法在老鏡像中。如果彈性伸縮的話，新增的 ECS 中的代碼就和線上代碼不一致了。

解決

個人覺得比 low，這樣也使發佈比較重。但在 Kubernetes 中就不存在這樣的問題了。

在發佈代碼後，調用雲服務商的API，給新 ECS 打鏡像、修改項目的彈性伸縮策略、把新鏡像id替換老鏡像id。

<a id = "elk"> 日誌收集 </a>

elk+kafka

• a. filebeat 收集 nginx 的日誌並把日誌發給 logstash
• b. logstash 對日誌進行字段拆分並寫到 elasticicsearch 。如果利用到kafka ，就在寫到 elasticicsearch 之前，先寫到 kafka ，之後elasticicsearch 從kafka 中獲取數據。
• c. 利用 kibana 進行展示。
• d. 在 kibana 根據不同的業務，提前配置好對 request_time、upstream_time、status_code 等等的 dashboard, 方便定位問題。
• e. 告警：

  • 寫好腳本，定期檢查不同業務的 request_time、upstream_time、status_code 。如果超時或 status_code 爲 5XX 就釘釘告警

程序部分日誌收集和告警

要求：

網關 nginx 服務產生 request_id ,這個請求後面的一系列請求都帶上這個request_id 寫日誌.
目地
方便定位問題。

當nginx 中出現 5xx 等錯誤時，根據這個請求的 request_id，可以找到程序中對應的一系列請求，從而快速定位具體問題在哪裏。
資源：
考慮到資源問題，目前僅僅收集 warn/ error / fatal 三個等級的程序日誌，導入到 elk 中。根據 request_id 快速定位程序問題。

告警：

定時任務，統計最近1分鐘，如果某個項目出現10個 error 或者出現過 fatal 就告警。
每天統計項目出現的 warn 次數。發郵件。
項目 warn 較多的（500條warn），額外會釘釘發告警，讓開發處理一下

<a id = "prometheus"> 監控 </a>

從 mysql+zabbix+grafana+微信/釘釘 到 prometheus+grafana+alertmanager + 釘釘

主要監控點

• cpu 使用率
• 內存使用量/使用率
• 服務器負載
• 磁盤容量/io
• 網絡流量
• tcp連接數
• 來源IP連接數
• 訪問IP連接數

對服務的監控：''

• redis : cpu，內存使用量、hit、miss 、get 、 set、ops ...
• elasticsearch: cpu、jvm、內存、gc、indics、健康狀態、 ops ...
• mongodb: cpu、mem、ops ...

之所以遷移到 prometheus

1. prometheus 對資源的要求非常低。就一個二進制問題，運行起來就可以了。
2. 當 zabbix 監控超過100臺服務器之後，查看監控的時候就明顯慢了。
3. prometheus 添加告警更加清晰方便。

<a id = "jenkins"> jenkins 代碼發佈 </a>

對開發要求：

規定所有開發，所有編譯過程，都寫一個 `makefile` 。我這邊僅僅需要 `make build` 即可

大致流程：

1. 先從 git 倉庫獲取根據對應的 tag 或 branch 獲取代碼。
2. 利用 jenkins 的 shell 功能，進行 make build
3. 獲取 build 後的代碼， rsync 到服務器。
4. 重啓 supervisor 服務。
5. 健康檢查；sleep 3s，查看端口和進程是否正常。同時請求健康檢查接口，查看服務是否正常。
6. 到這裏這個發佈完成。但同時會觸發下面步驟。後臺運行。

   • 利用 api 對新發布的項目中的某一個 ecs 進行打鏡像. 一般10分鐘左右
   • 修改彈性伸縮策略的的鏡像 ID 爲a步驟產生的鏡像 ID 。
   • 發釘釘和郵件提醒。主要包括項目名稱、修改前後的鏡像名稱。

<a id = "jumpserver"> 堡壘機 jumpserver </a>

目的：

• 目前還沒有把所有的程序日誌收集，偶爾開發到服務器查看相應的debug日誌。
• 開發需要到服務器，就帶來權限管理問題了。用它主要就是爲了解決這個問題。

優點：

• 不同的開發，給不同的訪問服務器的權限
• 資源統一管理。
• 操作審計等等

  <a id = "point"> 打點服務，定位資源使用情況 </a>

  prometheus+pushgateway+grafana+alertmanager+釘釘

  目的

  經常會遇到如下問題， 某個服務、資源的 cpu 或者內存飆高。爲了清楚瞭解。這些資源爲飆高，是什麼服務導致，我們就加入了打點服務。

  方案：

• 程序在調用其依賴的資源時，往時序數據庫打一個點。
• prometheus 作爲時序數據庫。
• pushgateway 作爲 prometheus時序數據庫的網關。
• grafana 做展示
• alertmanager + 釘釘，實現告警

---

作者: lvnian