摘要：本文通過對ETCD服務異常問題分析，代碼展示解決方案。
本文分享自華為雲社群《【執行個體狀态】GaussDB ETCD服務異常》，作者：酷哥。
首先确認是否是虛拟機、網絡故障
虛拟機故障導緻ETCD服務異常告警
問題現象
管控面上報etcd服務異常告警，虛拟機發生重新開機，熱遷移、冷遷移，HA等動作。
問題分析及界定
在告警資訊中找到執行個體ID、節點ID、虛拟機ID，在管控面檢視虛拟機狀态是否正常，能否正常登入，
如果虛拟機異常無法登入，聯系IaaS技術支援修複虛拟機。
檢查虛拟機是否發生過重新開機，熱遷移、冷遷移、HA等動作，例如記憶體、網卡等問題引起熱遷移。
處理步驟
聯系IaaS技術支援修複虛拟機，确認虛拟機故障原因，例如記憶體、網卡等問題引起熱遷移。
網絡故障導緻ETCD服務異常告警
問題現象
管控面上報etcd服務異常告警，虛拟機無法登入或ping通其他節點IP, 或者監控顯示網絡有異常。
問題分析及界定
在該節點上ping其他節點IP，測試是否ping通。
如果ping不通，執行步驟（1）（2），檢查該節點網絡、IP配置、防火牆配置等。
如果ping通，執行步驟（3）确認告警時間點網絡是否斷開。
（1）檢查IP是否正常：
ifconfig檢視etcd使用的IP是否存在，如果不存在，排查IP配置丢失原因，常見原因是虛拟機重新開機後IP沒有重新配置，導緻丢失。
（2）檢查防火牆是否正常
在Ruby使用者下檢視etcd的IP和端口： ps ux | grep etcd
在root使用者下iptables -L指令檢查防火牆是否限制了IP和端口，如果有限制，去掉防火牆限制。
(3) 檢視etcd日志
進入Ruby使用者
cd $GAUSSLOG/cm/etcd
檢視對應時間點的etcd_xxx.log日志，如果有如下日志，可能是etcd節點間網絡斷開, 或者對端的etcd程序down，導緻本端etcd連接配接斷開。
排查網絡原因或對端的etcd程序是否重新開機，網絡原因可能是網絡斷開，網卡故障，也有可能是虛拟機故障。
grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
rafthttp: lost the TCP streaming connection with peer c797ab3a61e2ea55 (stream MsgApp v2 reader)
etcdserver: failed to reach the peerURL(https:// X.X.X.X:X) of member c797ab3a61e2ea55 (Get "https://X.X.X.X:X/version": dial tcp X.X.X.X:X: i/o timeout)
rafthttp: health check for peer c797ab3a61e2ea55 could not connect: dial tcp X.X.X.X:X: i/o timeout (prober "ROUND_TRIPPER_RAFT_MESSAGE")
處理步驟
處理步驟同上，已說明。
負載過重導緻ETCD服務異常警告
問題現象
管控面上報etcd服務異常告警, 磁盤IO/CPU/記憶體 很高.
問題分析及界定
進入Ruby使用者
cd $GAUSSLOG/cm/etcd
檢視對應時間點的etcd_xxx.log日志，告警時間點有如下日志，說明etcd節點負載過重, 磁盤IO、CPU等壓力大。
2021-04-09 10:57:40.112936 W | wal: sync duration of 2.00201804s, expected less than 1s ===通常這個表示磁盤IO壓力大。
2021-04-09 10:57:40.112993 W | etcdserver: failed to send out heartbeat on time (exceeded the 1s timeout for 2.124414ms, to c8eccd97bed22939)
2021-04-09 10:57:40.112999 W | etcdserver: server is likely overloaded
2021-04-09 10:57:43.126444 W | etcdserver: read-only range request "key:\"/Ruby/ignoreNodeNumKey\" " with result "error:context canceled" took too long (1.999877971s) to execute
cd $GAUSSLOG/cm/cm_agent
搜尋對應時間點的cm_agent-xxx.log, 如果有如下日志，表示當時磁盤io比較高， io util 100 表示磁盤io 達到100%
2021-04-09 11:06:24.047 tid=15822 LOG: device vdb1, tot_ticks 889640579, cputime 1798651342, io util 100
處理步驟
1、在管控面檢視該節點當時磁盤IO、CPU、記憶體監控名額是否很高，
示例1：資料盤寫延時在16:00左右升高，影響etcd狀态。
示例2： etcd故障時刻，cpu、記憶體、磁盤寫延時都有增長，尤其是磁盤寫延時很明顯，需要分析磁盤寫延時升高的原因。
2、如果故障現場還在： iostat -mx 1 檢視磁盤IO狀态，top和free指令檢視cpu、記憶體使用情況, 分析磁盤IO高、CPU高，記憶體高的原因。
3、root使用者檢視該節點的系統日志, cd /var/log, 檢視該時間點message日志是否有異常記錄。例如：節點記憶體耗盡了，分析占用記憶體的原因，是否記憶體洩漏等。
如果仍無法确認原因，聯系華為工程師。
etcd程序故障導緻ETCD服務異常告警
問題現象
etcd程序down、重新開機，管控面上報etcd服務異常告警
問題分析及界定
登陸故障etcd節點， 進入Ruby使用者，執行指令ps ux | grep etcd， 檢視etcd程序是否在運作。
如果程序在，檢視etcd程序啟動時間，告警時是否重新開機過，聯系華為工程師确認重新開機原因。
如果程序不在，檢視etcd無法啟動原因：
（1）cd $GAUSSLOG/bin, 檢視目錄下是否有cluster_manual_start 和 etcd_manual_start 兩個檔案，
如果有表示叢集被停止，确認停止叢集的原因，之後啟動叢集，定位結束。
（2）cd $GAUSSHOME/bin 檢視目錄下是否存在etcd這個檔案，檔案權限是否正确，确認檔案不存在或權限不正确的原因。
（3）檢查etcd的資料目錄所在磁盤是否滿了或者故障，etcd目錄如下：cm_ctl query -Cvipd檢視
檢查etcd的資料目錄所在磁盤是否滿了或者目錄權限不正确（正确是700）或者故障，
如果磁盤滿，檢查占用磁盤的檔案并清除或者轉存到其他盤，如果是etcd本身的檔案占滿，聯系華為工程師分析原因。
如果目錄權限不正确，修改為正确的目錄權限。如果是磁盤故障，聯系IaaS技術支援分析定位。
處理步驟
參照上述處理，如果不是以上原因，請聯系華為工程師
OM接口無法正确傳回結果導緻ETCD服務異常告警
問題現象
管控面上報etcd服務異常告警， 管控無法擷取叢集狀态
問題分析及界定
檢視管控面是否擷取叢集狀态成功，是否擷取空消息，聯系華為工程師分析定位。
cd $GAUSSLOG/om/
檢視gs_om-xxx.log，是否有如下異常日志
例如： The status file does not exist. Path: /usr/local/temp/local_status_1611355718.58.dat.