我對開源版本openfalcon的變更

ps 基於openfalcon做監控現在有點落伍了，目前我這裏有更好的方案，感興趣的+qq 907974064或者github issue留言

地址 https://github.com/ning1875/falcon-plus

###新增proxy模塊支持api查詢多機房

###我重寫了聚合器,重寫聚合器目的 poly_metric VS aggregator

• 解決endpoint多的聚合斷點問題
• 解決聚合器單點問題，使得橫向擴展得以實現
• 解耦聚合器各個單元，可以方便的增加新的聚合入口和聚合策略

###.falcon agent自升級
過程說明：
http-req —>hbs —>開啓升級開關—>檢查agent心跳信息中版本號，並檢查當前hbs升級隊列—>發送升級指令給agent —> agent通過 升級命令中的url地址和目標版本號下載新的二進制（會有備份和回滾邏輯）—>agent check沒有問題後獲取自身的pid向自己發送kill信號 —>agent退出然後會被systemd拉起打到升級的目的—>新的心跳信息中版本checkok不會繼續升級
升級舉例說明:
1. falcon-agent新加了採集指標，測試OK後在代碼中打上新的版本號比如7.1（現有是7.0）
2. 然後將7.1版 放到下載服務器的路徑下 目前是 10.3.21.225 /data00/tgz/open-falcon/bin_7.1，並確保下載ok ,wget http://10.3.21.225/file/open-falcon/bin_7.1
3. 然後向hbs 發送升級的http請求（這裏有個保護機制:只能在hbs本機發起）
4. 然後通過hbs 的http接口查詢當前心跳上來的agent的版本查看升級進度 ，curl -s http://localhost:6031/agentversions |python -m “json.tool”
5. 同時需要連接的redis集羣觀察 agent_upgrade_set 這個set的值，redis-cli -h ip -p port -c smembers agent_upgrade_set & scard agent_upgrade_set
6. 目前看併發2000可以把一臺下載的nginx萬兆網卡流量打滿。1.24GB/s

## falcon-agent 自升級
curl -X POST   http://127.0.0.1:6031/agent/upgrade -d '{"wgeturl":"http://10.3.21.225/file/open-falcon","version":"6.0.1","binfile_md5":"35ac8534c0b31237e844ef8ee2bb9b9e"}'

curl -X GET  http://127.0.0.1:6031/agent/upgrade/nowargs
{"msg":"success","data":{"type":0,"wgeturl":"http://10.3.21.225/file/open-falcon","version":"6.0.1","binfile_md5":"35ac8534c0b31237e844ef8ee2bb9b9e","cfgfile_md5":""}}

curl http://127.0.0.1:6031/agentversions
{"msg":"success","data":{"n3-021-225":"6.0.1"}}

curl -X DELETE  http://127.0.0.1:6031/agent/upgrade
{"msg":"success","data":"取消升級成功"}

  uri:
	url: http://127.0.0.1:6031/agent/upgrade
	method: POST
	body: {"wgeturl":"http://10.3.21.225/file/open-falcon","version":"6.0.2","binfile_md5":"f5c597f15e379a77d1e2ceeec7bd99a8"}
	status_code: 200
	body_format: json

報警優化：

1.alarm添加電話報警,lark報警	
2.報警發送優化pop速度,避免報警堆積在redis中
3.dashboard:配置頁面增加說明,alarm頁面只展示自己組的報警,新增報警記錄搜索功能
4.改造發送lark邏輯， 主備兩個機器人發送失敗就停止發送變爲:第一輪主備兩個機器人嘗試發送4次,如果本輪失敗的話推入失敗隊列 10分鐘後再發送,依然是兩個機器人嘗試發送4次如果最終失敗的話推入失敗隊列,後面會對最終失敗隊列做監控

報警屏蔽:

1.im通道也就是頭條的lark發送的報警藉助lark card功能，能把報警接收人,要屏蔽的endpoint+counter，屏蔽接口地址等信息發送給接收人。
2.接收人通過點擊屏蔽1小時等按鈕將屏蔽信息發往alarm的api接口
3.alarm收到屏蔽信息，根據user+counter+rediskey前綴作爲redis-key ，SETEX到redis中，value和ttl都是屏蔽的時長，並sadd到redis一個記錄所有屏蔽記錄的set中，然後更新到到自身的內存map中
4.啓動一個定時任務，定時同步redis中的屏蔽信息到alarm的內存中：smemebers redis屏蔽的set 然後get 這個key如果不存在說明屏蔽已失效，從alarm的map中刪除，如果存在更新到內存中(解決alarm重啓後重建屏蔽信息)
5.alarm消費報警事件時分高低優先級 check 屏蔽map如果cache hit則取消發送報警：比如報警事件是同樣的，只是接受人是一個列表，這裏屏蔽的體現就是從發送人列表中將屏蔽人剔除
6.取消屏蔽也需要發送一個請求到alarm，alarm更新redis和自己map即可

修復聚合器機器數量1k+聚合失敗斷點問題,聚合器加cache減輕db壓力

1.聚合器在獲取機器數量多的組時調用的api原版的問題是 獲取了host的其他信息，而agg需要的是根據group_name獲取機器列表
也就是獲取一個host後還要關聯查詢很多信息導致1k+機器光調用這個接口就花費20s，新增了值獲取機器列表的接口

解決graph和hbs代碼中duplicate更新db引發的db插入失敗問題:

1.表有不止一個唯一鍵時 insert on duplit key update  可能會有問題 
2.When the table has more than one unique or primary key, this statement is sensitive to the order in which the storage engines checks the keys. Depending on this order, the storage engine may determine different rows to mysql, and hence mysql can update different rows. 
3.問題鏈接 https://bugs.mysql.com/bug.php?id=58637
4.現象就是在mysql slow_querylog中能看到一條insert lock了100多秒 最後的row_affected是0就是插入失敗了。導致db整體響應慢
5.修復過程：變insert on duplicate 爲先插入報錯後再更新

所有組件中需要http調用其他接口失敗加重試，加cache減少調用次數 使用這個包"github.com/patrickmn/go-cache"

雙擊房改造：

1.服務組件廊坊懷來雙機房部署，agent採集流量按機房分開：transfer和hbs的域名做dns view，
2.引入新組件falcon-apiproxy替換原有api，使用戶查詢時無需關心數據機房屬性。通過nginx 控制請求的path既：所有需要請求雙機房數據的查詢都pass到apiproxy，apiproxy拿到請求的數據，解析成分機房的endpoint列表
。判斷endpoint屬於哪個機房是apiproxy通過配置文件中配置的各個機房hbs地址然後定時遍歷請求hbs rpc 獲取每個hbs連接過來的endpoint信息存儲到apiproxy中以 機房名稱爲key的map中，每次查詢請求過來時在cache中查詢這個endpoint應該屬於哪個機房
3.獲取到endpoint列表對應機房的信息然後發起請求到各個api查詢數據後拼接在一起回覆給用戶
4.python falcon-dashboard雙寫廊坊懷來db模式，使用戶變更配置時操作一次即可

國內海外容量規劃和agent採集間隔變化:

1.agent默認採集間隔由30秒變爲按採集項目的重要程度分爲10，30，60，120四個檔位。
2.原有的默認採集cpu單核監控變爲可配置

HBS多實例全表查詢mysql導致mysql壓力大

1.利用redis實現分佈式鎖
2.搶到鎖的hbs實例負責查詢mysql更新到redis
3.搶鎖失敗的hbs到redis中查詢
4.具體說明：setnx 鎖的key  value是 unix_time.now + timeout ，setnx成功說明搶到鎖，並把鎖的ttl設置爲timeout
setnx失敗檢查鎖的值是否已經超時(防止有expire命令沒執行成功也就是通過value判斷鎖是否超時)，搶鎖成功的實例查詢mysql並更新的redis中，並且把這次更新的key 放到一個名字不會變的key，讓所有hbs查詢這個key 類似服務發現

falcon-agent 新增監控項

1.TcpExt.TCPFastRetransRate- #用來表示重傳率這是一個放大1w倍的值 一般網絡上認爲百分之一的重傳數爲臨界值,所以TcpExt.TCPFastRetransRate 超過100認爲異常
2.mem.shmem #用來表示共享內存的值,如果機器上有用到/dev/shm做讀寫的話,算內存使用率的時候  /dev/shm 的用量 +  普通的 mem used = 真實內存用量
3.mem.memavailable（單位字節） & mem.memavailable.percent（百分比)
4.percore.busy/core=core01每個邏輯cpu的使用量 ，監控每個邏輯cpu新增開關配置
5.sys.ntp.offset
代表本機和ntpserver之間的ntp偏移 ，單位是毫秒
正的值代表是超前，負值代表是滯後
6.sys.uptime
代表機器啓動時間 單位是秒

python-dashboard

1.雙寫廊坊懷來db模式，使用戶變更配置時操作一次即可
2.dashboard機器組添加tag: 新增首頁服務樹,group頁面組拉取自己的tag組
3.dashboard: 重寫screen搜索邏輯,優化速度,優化cas認證完跳轉問題,給部分api提供跳過機制

falcon-alarm 支持羣組報警

聚合器gauge 和counter 問題

原始聚合器在處理counter類型的聚合時做法是 例如query查出來的數據轉化成gauge類型的再聚合計算。這樣算sum和avg就可以擺脫每次聚合數量不一致導致的
混入特別大的原始點 ，帶來數據的混亂
具體比如 網卡速率在30k左右，但是/proc/net/dev 中的數據遠大於這個值
###我重寫了聚合器,重寫聚合器目的 poly_metric VS aggregator

• 解決endpoint多的聚合斷點問題
• 解決聚合器單點問題，使得橫向擴展得以實現
• 解耦聚合器各個單元，可以方便的增加新的聚合入口和聚合策略