資訊專欄INFORMATION COLUMN
PaaS平臺緩存組件采用電信集體自研分布式緩存ctg-cache產品，部署在“天翼云”資源池，為多個能力中心提供服務，如外部客戶統一認證平臺（UAM）、CPCP增量（CPC1）、CPCP工作臺（CPC1WEB）、綜合資源（RM）、銷售門戶，計費等，目前支撐大約為每分鐘10萬的業務訪問緩存請求。CRM集群部署了10組Redis實例節點，以及4個“接入機”節點，如表一、圖一所示。
表格 1 CRM集群節點信息
圖表 1 分布式緩存部署拓撲圖
IT運維與安全體系的落地關鍵在于解決問題的快慢，歸根結底是客戶感知,巡檢是必要手段之一。通過巡檢，一方面可檢查服務可用性，保障服務的平穩運行，另一方面可發現潛在的隱患，及時做出對應的整改措施。我們對于巡檢的不斷優化和改善，就是為了更快地修復、杜絕和預防故障，達成客戶能夠獲得良好的感知的最終目的。
目前PaaS平臺組主要通過監控告警和定期巡檢來保障分布式緩存的服務健康性。分布式緩存實行每日巡檢制，巡檢主要分為3個時間段，第一個時間段是早上7點到7點半，進行PaaS平臺所有組件的統一晨檢，保障營業廳營業前服務的健康性；第二個時間段是上班時間由平臺組每隔2小時巡檢一次，在保障組件正常運行的同時，還要關注監控曲線的波動幅度是否正常、CPU/內存使用率是否偏高、應用執行緩存操作的報錯率等，便于及時發現隱患；第三個時間段是晚上9點到9點半，進行PaaS平臺所有組件的統一巡檢。
此前PaaS平臺組對于分布式緩存的巡檢主要是檢查管理頁面組件的運行狀態，但在分布式緩存一次故障處理過程中，運維人員在收到告警后立刻著手進行處理，當時管理頁面組件運行狀態正常，運維人員在問題定位上耗費了較長時間，因此沒有快速解決故障。
故障現象
（1）運維人員收到緩存的各類告警郵件，包括宕機告警、服務告警等告警郵件。
（2）平臺測試程序和應用調用緩存報錯：READONLYyou can’t write against a read only salve，大量寫入操作失敗。
圖表 2 分布式緩存“READONLY”報錯
故障分析
（1）在10.145.***.7、10.145.***.11接入機上出現網絡狀態波動，使得監控端口探測失效、應用連接失敗、應用報錯。
（2）10.145.***.7、10.145.***.11 機器網絡恢復后，期間發生的Redis主從切換沒有寫入zookeeper，zookeeper判斷主從錯誤，同時，10.145.***.11的“接入機”出現故障，表象為正在運行但實際卻不可用，導致應用繼續報錯，延長了故障發生時間。
圖表 3 分布式緩存故障過程示意圖
故障處理
（1）在機器網絡恢復后，運維人員檢查管理頁面，發現Redis節點和“接入機”的運行狀態全部正常，但執行平臺測試程序，報“READONLY”錯，原因是網絡波動期間發生的Redis主從切換沒有寫入zookeeper，于是進行了Redis主從切換。
（2）整個CRM集群的所有Redis節點主從切換完畢后，驗證測試程序依然在報錯，而此時zookeeper中Redis主從信息與實際信息已經全部一致。運維人員查看客戶端監控發現有一臺“接入機”的報錯顯著地高于其他接入機，于是重啟了該接入機，之后測試程序不再報錯。
圖表 4 服務恢復后的可用性測試
為了更快定位問題并解決，我們優化了巡檢方案。巡檢的優化方案主要為增加緩存組件的巡檢項目，包括Redis主從切換狀態檢測和服務可用性探測，從而能夠快速判斷問題產生的環節，加快故障修復的操作流程。
方案實現通過Ansible腳本完成，腳本分為兩個部分，第一部分通過對比zookeeper節點信息與Redis實際主從信息是否一致來檢查主從切換是否正常；第二部分為執行探測程序，使用4份不同的環境配置信息，每份配置信息對應一臺接入機，保持其它不變，只改變“接入機”的地址，既可以檢查服務可用性，又可以確保通過每臺“接入機”連接Redis進行讀寫都不會報錯。
主從切換狀態檢測
Redis主從切換狀態是否正常的判別標準是，登入zookeeper，進入到/apps/cache/redisSets/CRM_REDIS_001目錄，檢查每一個master節點前的IP地址是否與實際的主節點一致。
舉例：
實際為10.145.***.5:**00為主，10.145.***.4:**00為從
/app/ctgcache/cache_apps/redisEntites/redis/src/redis-cli-h 10.145.***.5 -p **00 -a VI9IAMzX info replication
圖表 5 Redis主從信息
那么master{$seq} 前的connUrl就應該是10.145.***.5:**00，如果不是，則判斷為異常。
圖表 6 Zookeeper中Redis的主從信息
可用性探測
一、探測邏輯設計
a）連續探測60次讀、寫，記錄成功失敗次數；
b） 讀操作連續失敗10次或者寫操作連續失敗10次，則停止退出探測。
二、程序配置說明
a）env變量配置環境標識；result_path變量配置結果文件目錄；
b）不同的環境添加對應的配置信息，實際情況是4個環境，對應4個接入機；
c）啟動時依次加載不同環境配置，并行探測，探測結束，探測程序自動退出。
圖表 7 不同環境的配置文件
圖表 8 探測程序配置信息
結果文件說明
每個環境都會生成對應的探測結果文件（文件名：環境標識），結果包含讀操作成功數/失敗數、寫操作成功數/失敗數
圖表 9 不同環境生成結果文件
圖表 10 結果信息
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/130188.html
摘要：需要監控的維度有登錄總數成功數失敗分類用戶地區版本號瀏覽器類型登錄來源服務所在機房等等。 引言在任何一家互聯網公司，不管其主營業務是什么，都會有一套自己的賬號體系。賬號既是公司所有業務發展留下的最寶貴資產，它可以用來衡量業務指標，例如日活、月活、留存等，同時也給不同業務線提供了大量潛在用戶，業務可以基于賬號來做用戶畫像，制定各自的發展路徑。因此，賬號服務的重要性不言而喻，同時美團業務飛速發展...
摘要：優雅的服務降級微服務架構最大的優點之一就是當組件出現故障時，能隔離這些故障并且能做到優雅地服務降級。 本文首先介紹微服務架構存在的風險，然后針對如何避免微服務架構的故障，提出了多種有效的微服務架構中的方法和技術，其中例如服務降級、變更管理、健康檢查和修復、斷路器、限流器等。 目錄 1、微服務架構的風險 2、優雅的服務降級 3、變更管理 4、健康檢查和負載均衡 5、自我修復 6、故障轉移...
摘要：優雅的服務降級微服務架構最大的優點之一就是當組件出現故障時，能隔離這些故障并且能做到優雅地服務降級。 本文首先介紹微服務架構存在的風險，然后針對如何避免微服務架構的故障，提出了多種有效的微服務架構中的方法和技術，其中例如服務降級、變更管理、健康檢查和修復、斷路器、限流器等。 目錄 1、微服務架構的風險 2、優雅的服務降級 3、變更管理 4、健康檢查和負載均衡 5、自我修復 6、故障轉移...
摘要：阿里云上領域各個產品最終目標是為了對以上各個組件進行有效監控。阿里云的解決方案地圖基于今天的云上的應用架構，阿里云的解決方案地圖如下所示。其他阿里云服務包括緩存，等。阿里云解決方案地圖以下表格對阿里云解決方案進行總結。 摘要： PM是近5年來伴隨著云技術、微服務架構發展起來的一個新興監控領域。在國內外，無論是云廠商(如AWS, Azure，等)還是獨立的公司(Dynatrace, Ap...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1901·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2743·2023-01-11 13:20
閱讀 1394·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20
