原创 消息隊列選型:rocketmq or rabbitmq

1.目前我們用的activemq,面臨一些問題 activemq高可用基於leveldb的複製,但activemq從5.*開始,leveldb已經不再有任何更新 The LevelDB store has been deprecated

原创 mysql sql語句digest收集與展示

1.前言 mysql慢查詢,已經有現成的成熟的方案收集展示了:pt-query-digest結合box公司的anemometer,沒用過的移步:《mysql慢查詢可視化》(本章內容需要提前瞭解anemometer)。 但DBA們一定還遇到

原创 基於spark實時分析nginx請求日誌,自動封禁IP之二:日誌實時分析

上一章講了WEB功能設計,本章繼續講下日誌實時分析設計。 《基於spark實時分析nginx請求日誌,自動封禁IP之一:web功能設計》 整體思路:從kafka集羣讀取請求日誌流,經過spark structured streaming(

原创 基於spark實時分析nginx請求日誌,自動封禁IP之一:web功能設計

用過阿里高防的都知道,高防有個很牛X的防CC功能配置:基於域名,基於某URL(精確匹配或後模糊匹配),限制某個時間跨度的請求頻率,超過該頻率會拉黑n分鐘。廢話少說,直接上圖: 然而: 高防不是所有公司都用得起的(月費用1萬以上), 高防

原创 mysql高可用自動切換方案(半同步複製+keepalived+第三方數據邏輯判斷)

1.前言 自從踏進互聯網運維這個行當,就無時不刻不在爲高可用費神。nginx、tomcat、緩存、隊列、數據庫,每個環節高可用的最基本要求是避免單點故障,能夠自動failover。mysql的高可用方案說起來很多,但真正想在你家的生產環境

原创 k8s支持大量商戶自定義域名的配置

基於nginx -> traefik -> k8s的架構,某個應用需要支持商戶的大量任意自定義域名,咋整呢?咱公司k8s上的應用遇到這個場景,因此研究了下,有以下兩種方案: 方案1, 最直接粗暴但很lowB的方案,ingress中列出每個

原创 k8s過期鏡像清理

隨着應用程序版本的發佈,k8s環境會留下大量過期的鏡像佔用空間,因此需要通過任務自動清理。 crontab任務調用以下腳本即可: 1.節點鏡像清理 刪除dangling鏡像 docker image prune -f 刪除無容器使用的鏡

原创 通過linux跳板ssh訪問容器

容器的IP是不固定的,因此無法像傳統服務器在ssh工具中配置清單; 最佳的方式是在瀏覽器上通過webterminal方案點擊鏈接直接打開ssh終端,要求開發像樣的容器管理平臺(我們的平臺還在設計階段。。。),另外webterminal訪問

原创 web terminal工具gateone使用

稍微牛B的運維團隊,沒有運維平臺是不行的,web termin是運維平臺的重要組成部分,這裏吐血推薦gateone,github上5K顆星,遺憾的是作者不更新了,但瑕不掩瑜,它依然是我心目中web terminal no.1。 web上直

原创 隊列選型:rocketmq or rabbitmq

1.目前我們用的activemq,面臨一些問題 activemq高可用基於leveldb的複製,但activemq從5.*開始,leveldb已經不再有任何更新 The LevelDB store has been deprecated

原创 ELK的監控工具Elastalert的報警功能擴展

Nginx請求日誌輸出到ELK,同時通過Elastalert監控ELK日誌中的關鍵信息(如http狀態500+錯誤,耗時較長的請求數達到閾值等等),這幾乎是中小型互聯網公司的標配。 Elastalert自帶的報警方式雖然多種多樣,但是不能

原创 mysql歷史數據自動歸檔

數據庫跑一段時間後,因爲查詢性能、磁盤容量,運維管理等方面的原因,需要將在線數據挪到歷史庫(不同的服務器)。如我們的在線訂單隻留3個月數據,3個月以前的就需要到歷史庫查了。 自動歸檔常見的方式有pt-archiver,但我還是覺得自己寫存

原创 nginx ip黑名單動態封禁

網站被惡意請求,拉黑IP是重要的手段,如果每次拉黑都要到nginx上配置,未免太low了;我們需要更方便的控制nginx IP黑名單。 1.方案 黑名單持久化到mysql (常見的方案是redis,但不利於控制,如:不同的IP設置不同的有

原创 calico的iptables規則

學習了下calico的iptables規則,挺複雜的,沒想到iptables能這麼用。。。 iptables中的鏈涉及到不少簡寫: hep: host endpoint wl: workload endpoint fw: from wor

原创 memcache集羣方案

1.方案選型 緩存方案的基本要求:避免單點故障;較好的性能和穩定性;便於運維管理。 常見方案如下: A. 客戶端直接訪問多個memcache 實例 優點:簡單,未引入新的節點; 缺點:維護不方便,未實現集中管理;性能不滿足,實例宕機後不能