2019-10

10.5

1. 全部的告警信息進入一個redis的隊列，對其中的告警進行主機組的檢查，在觸發器中有tag的，使用後臺配置中定義的tag取定義的用戶組，而後該條消息就會發送到這個組的成員中。若是沒有tag的就使用該消息所屬組對應的用戶。
2. send_msg使用supervisor啓動的，配置信息中有定義的日誌路徑，打開日誌會發現不少東西
3. 消息平臺主機的時間比monitor主機慢三分鐘，有必定的延時性。

10.8

1. 會議彙總了之前的問題，以及以後須要作的內容，
2. zy的邁普設備依賴的是snmpget方式獲取的值，在頁面有個配置snmp的測試，武勝烈面的告警沒發出來就是由於這個配置沒配通，使得數據沒有載入數據庫，而後監控系統傳不到，故沒有爆出警告。
3. 對於maipu設備的sql語句仍是有不少的問題，sql查出來269條，實際上有328條村行信息
4. bps 每秒傳輸位數，除以8就是1字節，除1024就是1k，再除1024就是1m
5. f5設備是一個vs，也就是一個pool底下開的有4個以上的節點（每一個節點就是一臺主機），由底下的節點去分發請求。通常f5都是作的主備，正常狀況是由主來負載均衡，主掛掉，備上位。鏈接數，節點名稱，ip都是經過oid取的值。

10.9

1. sdata_update 32位的包新建目錄的功能在64位上很差用。
2. paramiko的SSHClient能夠鏈接遠程主機執行命令，SFTPClient能夠完成下載上傳文件的功能
3. 偶然的想一下就能解決之前的一個頭疼問題，例如solarwinds的告警發送邏輯
4. 頭一次提交變動單，好菜，表述不清晰
5. 說明文檔得靠本身了，給培訓依靠不了別人

10.10

1. 光纖交換機8510B的主機名稱沒改，使得接受的snmptrap信息通過處理給主機發送的時候發不過來
   snmptrap的工做流程是網絡設備自發生錯誤，經過oid的形式會發出告警，經過snmptrap的方式打通162端口，是日誌數據由zabbix server上的snmpd服務接管，通過必定的格式處理，在snmptt的配置文件中指定處理信息的腳本，日誌信息流入腳本，腳本中實現了zabbix sender的協議，經過指定主機名，鍵，值，就能夠發送到監控系統中對應的主機監控項上，見天沒有看sender的代碼，被sender後的日誌信息給誤導了，日誌信息中寫的是 （IP：xxx,msg:xxx）錯誤的一位ip是一個主機的ip，實際上經過觀察sender的代碼就能夠知道這個ip其實是指定的host。
   同時在每一個執行腳本中都有日誌記錄的，在 /var/log/snmptt/下的各日誌能夠查看發送的日誌信息，
2. 增長了oracle的日誌告警，只要保證zabbix用戶進入文件目錄有這rx權限，而且對文件有r權限，就能夠取到日誌信息，從而進行正則匹配從而觸發告警，不然會發生權限被拒的後果，
   zy有兩臺oracle數據庫運行在 aix的機器上，而且該機器上的客戶端是2.4.4的，不支持log監控項，總是提示too many parameters，跟zabbix版本有關係。
   zy的oracle日誌路徑並不是徹底格式統一，須要按需找到日誌路徑。aix主機上不支持命令補全，不支持上下翻滾估計是爲了安全吧。
3. netapp模板中修改了監控項原型，在原型中可計算類型的監控項別不會跟着修改，還須要手動修改其監控項，zy在這個上面有觸發器，因爲觸發器的條件之一一直取不到值，致使空間佔滿也沒報出來警
   netapp中的aggragate自動發現中爲啥8040A可以發現了8040B的聚合空間？？？？？
4. 客戶端修更名字重啓對當前服務有什麼影響
5. solarwind中的邁普設備增長166 170 的過濾
6. zabbix server端上安裝agent，使用rpm包的方式安裝，會與原來安裝的server 衝突 /var/log/zabbix 這個目錄，使用 rpm -ivh xxxx.rpm --force 強制忽略衝突進行安裝。安裝完成以後，須要確認./var/log/zabbix這個目錄的屬組 屬主 及其權限。同時zabbix agent 的配置文件中修改主機名，配置server的ip，同時將配置文件的屬主屬組也修改。再啓動zabbix agent服務，

10.11

1. aix機器上的oracle10帶，使用zabbix2.4.4客戶端監控日誌很詭異。
2. 對於日誌告警，當匹配到一條告警信息，會告警，當後一條信息出來沒有知足觸發條件的時候，告警就被恢復了？
3. 使用web.page.xxx的監控項監控頁面的時候，若是url中含有zabbix不容許的特殊字符，那麼監控項就不能建立，這就須要使用web場景了，web場景不存在這些問題，
4. 要養成好的習慣，出去就要關閉當前的shell連接，網頁連接等等

10.12

1. linux模板磁盤空間使用量觸發器刪除對剩餘量的判斷，跟大屏同步，自動發現清單是1H的更新週期。因爲netapp的卷是被多個機器共享，告警沒開，一開的話可能出現多條重複的告警
2. fintel t+1 已經下線，全部Linux的觸發器關閉，
3. solarwinds告警發送添加，用戶沒有sms信息，因此關閉sms發送
4. ups netups的報告添加，定到每個月1號8點，是否須要放到dev/null下
5. oracle的日誌告警基本添加完畢，觸發器還需優化，一個告警觸發後，下一條若是還觸發告警，告警信息將會被替代。

10.14

1. 新上的客戶端，須要開放10050端口，方便之後的更新腳本的使用，同時要可以訪問repo的4507端口，這樣才能去repo裏面下載東西。對於oracle的監控，還須要配置oracle的環境變量，這樣才能使用sqlplus等工具，同時還要保持sql帳號密碼的正確性
   repo就是一個nginx服務啓動一個url，開放給外界，外界訪問這個端口就能夠訪問到對應的目錄中的內容。
2. awk真是個神奇，能夠切割字符串，能夠拼接字符串。
3. ping對應主機的解決方法是使用zabbix sender 完成自動發現規則中的監控項原型的建立，使用外部檢查使用原型中獲得的監控項參數去執行fping命令，而後對返回值進行alive的字符串查詢，查詢到說明正常，不然down，
   zabbix sender的自動發現規則沒有周期時間，就是後臺sender一次數據，刷新一次原型，不過監控項圓形能夠週期性執行，跟普通的監控項差很少
4. oracle的安裝，

10.15

1. oracle機器的poc操做，執行完更新腳本後，環境變量就配置好了，問題？爲何任意的sid均可以進行數據獲取了
2. 關於新上的oracle的機器，須要對dbquetry用戶進行受權 grant select any dictionary to dbquery; 不然在使用dbquery用戶進行查詢數據庫的時候會提示權限無效。
3. 老的zabbix_config.tar.gz 包缺乏tb_total的sql文件，須要從新上傳到repo，使用sdata update進行手動更新，
4. 中間件的監控添加，globalrequest中有發送接收的字節數， connect中有最大線程鏈接數的配置，使用當前活躍線程數和這個最大數能夠作一個觸發器。
5. 數據庫報表，。都使用歷史數據，不適用趨勢數據了，歷史數據會全一點。

10.16

1. jmx的監控大都布在py2.6的環境中，有兩臺機的py版本是2.4的，2.6的py語法不適用，須要從新編寫腳本再更新到客戶端進行取值，
2. 原來覺得的jmx腳本執行超時，實則不是，是由於server端到客戶端的10050端口就沒通，因此顯示的執行超時，開通端口就能夠了。
3. 中間件的日誌大多格式不一樣意，作成多種監控項，其中配置宏變量，而後組成不一樣的日誌路徑，
4. 十點40 zabbix server的內存忽然佔滿，一個httpd進程佔滿了，重啓httpd才解決，緣由是我用了api.history.get()取得數據量太大了，沒有加過濾條件，差點把服務器幹廢了。一個進程佔了12G

10.17

1. 修改zabbix的php源碼，放開{ITEM.LASTVALUE}中對於20個字符的長度限制，
2. k8s準備
3. tomcat的日誌監控
4. 可計算型的監控項建立要注意語法

10.18

1. oracle實例重啓時對於oracle表空間和ASM磁盤組的自動發現規則會把錯誤返回信息進行遍歷返回，生成一對錯誤的監控項，而後top10的數據對於錯誤信息沒過濾，默認錯誤的值是100，就把整個top數據給爆紅了。刪除原來的錯誤監控項，在自動發現規則清單中添加過濾器，過濾器中可使用正則，正則長度有限制。
2. jsoncole中還有一堆有用的信息，能夠繼續深挖。tomcat就只是個殼子，裏面能夠放web服務，放上資源實時的在jconsole中就能夠獲取信息
3. tomcat跟weblogic有共有部分，有些也是不同的，要區別對待。
4. zy的tomcat服務凌晨斷了，主機的日誌中一個打jmx腳本執行的信息，而後jmx的監控項在那個時間段內獲取不到數據，可使用這個作一個判斷tomcat是否正常運行的監控項

10.19

1. 對於低版本的py2.4，執行jmx監控的腳本還須要指定java的路徑，直接寫死在一個機器上行，在另外一個上不行，
2. 對於中間件的監控，能夠分紅多個模板來組合監控，一個模板控制一部份內容。可使用模板來打開關閉監控項，以及觸發器的建立
3. 使用zabbix get來獲取鍵對應的值，在zabbix server上獲取不到值，在監控設備上手動執行腳本卻能夠獲得數據，很懵逼，通過奇哥指點應該是用戶的權限方面的問題，先查看了腳本及配置文件的讀寫權限，沒有什麼區別，而後查看sdata用戶的環境變量和weblogic用戶的環境變量區別，sdata缺乏java的執行路徑，在代碼中添加上，使用zabbix get能夠獲取到值。
4. gj的交換機使用的是snmp監控，在升級完ios鏡像以後，監控系統中最新數據顯示接口是down的狀態，可是到了設備上查詢是都啓動的。過了一會設備的全部監控項都消失了，而後自動發現規則又生成出了新的監控項，原來的歷史數據都丟失了，可是最新數據顯示正常了，很奇怪，應該是在十點多的時候snmp服務才啓動，升級了ios。監控項鍵值生成新的，把舊的給代替了。

10.21

1. 文件上傳的邏輯直接放到show機器上，不用ssh 的sftp去引導了
2. nfs文件系統的掛載及監控發現，過濾
3. LLD自動發現的json格式及snmp自動發現的格式
4. proxy的使用。

10.22

1. 新加完的主機，在加完模板後，記得分組添加分組，否則影響告警發送到童虎
2. nfs文件掛載狀態的添加，的用腳本，自動發現出來的只能監控nfs盤的資源使用狀況，沒法監控nfs的掛載與否
3. 日誌監控在觸發器中指定了過濾的字段ORA，爲啥仍是能匹配出來abort與ora共存的狀況
4. show server是兩臺機器，頁面配置linux的代碼得修改，使用server去ping受控主機的10050端口

10.23

1. 日誌輔助監控是依賴於es的聚合來的，對es聚合結果的斷定，加上zabbix觸發器函數的判斷，生成新的告警。
2. 對於zabbix中的日誌監控中關鍵字段的匹配， . 是要用\來轉義的
3. sed中添加空格 sed -i 's\aaaa/ / / / bbbb\g' xxx.txt ,就將文本中的aaaa轉換爲 ' bbbb' 加了四個空格。
4. fabric中的run方法能夠添加env參數，是一個字典類型，env中的參數能夠傳值到sh腳本中。

10.24

1. 註釋掉solarwinds中短信的接受信息，記得收尾要作好，每次改完起碼在shell中導入一次，看看有無語法報錯，由於把短信接收者給住了，短信模板中沒註釋，形成一個變量未定義，致使告警沒發出去。》》》solarwinds告警轉發正常，solarwinds時區增長八小時,datetime對象增長8小時
2. 萬德基金，內控管理中腳本的91行爲 set -A ，自動發現表空間跟asm有問題，提示必須爲json對象，linux中的json全靠echo一個一個拼出來，將A改成a，表空間發現正常，asm爲空？回去確認，自動發現週期修改成60s沒動靜，手動測試監控項正常，搞不懂
3. 數據庫巡檢報告中增長ccvs新驗印的判斷，ccvs匹配有兩條，開放對萬德的過濾。待會記得把發郵件功能打開
4. 新的波利特的UPS設備的告警信息在APC進行了轉化，現行的告警過濾OID是正確的的，須要把腳本改改，使信息能正常發送，在設備管理界面添加上snmp可讀的設備，使用snmp v1協議就能夠獲取到值。

10.25

1. celert任務重啓的時候必須刪除掉原來的celery scheduler文件，防止停redis的時候把原來的老任務也繼續載入，形成同一個任務執行了屢次，
2. 在model 中更改class meta中的信息，在admin中更改admin中顯示的信息，不須要遷移對象,ordering字段指定按照什麼字段進行排序顯示（在admin站點中），支持-，表示反向
3. 批量更新腳本還須要添加對不支持監控項的判斷，對用戶增長提示信息
4. 消息平臺對於郵件的發送結果判斷有誤，有個郵件發出去了，可是記錄中顯示的失敗。

10.26

1. 修改snmptt中的ups執行腳本，增長對16進制信息的轉化判斷，一開始想多了，老想經過空格的數量來判斷字符串是否爲16進制對象，可是這樣會有一個弊端，可能使用空格進行切割，獲得的列表對象也符合斷定條件，可是這個值並不是16進制，那就出錯了，還想了想斷定空格數量，嘗試去尋找16進制對象斷定的方式，這些都是無用的, 其實根本就是怕他出錯，那麼久讓他錯，使用 try except來處理，讓全部的有空格的都去嘗試解碼一下，出了錯在except中指定默認值，這就就完美解決。
2. apc轉化後的snmptt信息並不是都是通用的，在ups的溫度告警項中，對於施耐德的告警信息其中不會添加最新的溫度值，可是波利特的會，全部在用告警信息判斷是否告警的時候就須要把二者公共部分結合起來，
3. ups設備添加的時候須要拖到附屬行，配置支行信息，配置位置信息，配置告警接收人，告警閾值等等，經過閾值的調整能夠達到告警的觸發。
4. ups告警在監控系統中的添加用到了組的概念去定組發送，首先建立一個用戶組，將接受告警的人員添加到這個組中，在相應的告警觸發器上配上tag，而後在後臺添加配置項tag:增長的用戶組。

10.28

1. oracle腳本，由ksh換成sh，其中有一個生命數組的操做，在ksh中是 set -A 數組名 數組體，在sh中是直接使用 數組名=（數組體）來申明的，因爲只改了腳本頭的解釋器聲明，致使oracle表空間自動發現出來的數據沒有構成json數據，每一個字段後面沒有加逗號，解決就是將聲明數組的方式也改爲sh中的。
2. go中的time.Duration對象聽蛋疼的，不過也挺好用的，直接從納秒級提供，而後就是須要主題 time.second * 8 ,這樣是可使用過的，可是若是從外部接受入參，而後將傳入的字符串轉成數字再乘以 time,second是不能直接使用的，還須要將 轉成的數字使用 time.Duration(int)再與time.duration相乘
3. 用goping達成的linux包，在linux下執行，須要的是root權限，每次執行ping都須要一個xxx.so文件，須要root權限才行，折中辦法是chmod 4755 go-ping，讓普通用戶也有跟root同樣的權限去執行這個包，並且在zabbix自帶的簡單檢查中也有 相似的說明，須要給予4755權限。

10.29

1.3個oracle腳本更改爲功，
2.imm的自動發現爲什麼不起做用了。更換硬盤重啓服務以後將無效的刪去，又恢復正常。
3.ups的snmptrapd方式就是使用的apc轉換後的oid信息來判斷是告警仍是恢復，判斷標誌就是起始時間和恢復時間，分別是6 鍵跟7鍵，只有6起始就是告警狀態，二者都有就是恢復，能夠手動的拼接一條告警16位進制信息，而後交給腳本執行，而後ups的告警機制是若是10分鐘再也不受到數據並且最新值是1，那麼將告警，若要手動恢復的話，須要7鍵配置上恢復時間，將0改成有數便可，同時消息體也更改。
4.修改資產記錄收集出問題的bug

10.30

1.IMM是IBM服務器的管理卡，能夠獲得服務器的硬件信息，走的是snmp形式，一段時間後imm會死掉，可是上面運行的os服務沒問題，須要手動重啓服務器imm纔能有效
2.靈活調度的事件間隔在api建立監控項的時候是一個分號分隔的字符串
3.文件系統的掛載判斷可使用首層的文件夾大小值進行判斷

10.31

1.imm的監控不能用預期的給任意監控項加nodata觸發器，由於有的機器上對於同一類的監控項，有的有效有的無效，仍是使用對主機的監控項狀態進行判斷，例如當全部的磁盤監控項狀態都不支持的時候就發封郵件
2.對於oracle的asm自動發現，aix主機不能反回正常數據，可是其餘linux機器能夠。
3.更新了用戶，告警代碼。
4.博利特的ups信息被apc轉義以後30鍵對應的信息跟原來的施耐德信息不同的，須要在腳本中添加。