原创 ELK之ES2.4.1雙實例平滑升級調優至5.2.1踩坑並supervisor管理記

  ES老集羣用的2.4.1版本,跑的比較好就一直沒動,最近看資料ES5.X已經穩定,並且性能有較大提升,心裏就發癢了,但由於業務要保持高可用的屬性,就得想一個平滑升級的方案,最後想到了多實例過度的辦法,5.X版本網上介紹配置變化較大,也做

原创 WebService之nginx+(php-fpm)結構模型剖析及優化

  隨着php腳本語言使用的普及,目前webserice服務大部分都在用nginx+(php-fpm)的結構,瞭解了其工作過程後纔可以在各個方面想辦法做調整優化和故障排查,從以下幾點總結一下這種模型。一、nginx和php-fpm的關係和分

原创 玩兒透ELK日誌分析集羣搭建.調優.管理(rsyslog->kafka->logstash->ES->kibana)

   實時日誌分析作爲掌握業務情況、故障分析排查的一個重要手段,目前使用最多最成熟的莫過於ELK方案,整體方案也有各種架構組合,像rsyslog->ES->kibana、rsyslog->Redis->Logstash->ES->kib

原创 巧用rsyslog收集多套日誌並做單套日誌的過濾分離

  日誌是supervisor打出來的python日誌,且把不同格式的日誌打印到了同一批文件裏,需求是把帶post和ERROR關鍵字的日誌分離,並進入兩個不同kafka的topic隊列,目前的情況是rsyslog已經收集了nginx的訪問日

原创 Nginx/tengine做cache時緩存機制—存不存、存多久、用不用方法論

    Nginx/tengine(後面名稱只寫nginx了)單純做cache性能比不過ats,特別是在磁盤處理方面,不過論綜合能力nginx就是大拿了,他集web服務器、負載均衡、cache三種能力於一身,可以說是非常綜合性的選手。比如說

原创 在互聯網你的請求是如何被引導、劫持的?

   大多數的引導和劫持都是到cache設備上的,做cache有諸多好處,比如對於運營商而言可以節省網間流量(省錢)、提高用戶體驗(靜態內容、視頻等加速),對於網站主通過CDN做了cache後可以提高用戶體驗(加速),當然也有非法獲利者通過

原创 nginx多條件if判斷後rewrite,減輕後端php工作壓力(隨筆)

先說下我對nginx配置文件的認識:      nginx的配置文件可以看成是一個程序,一個按照程序員思維習慣進行語法設置的nginx配置程序,編寫簡單便於理解,而且配合着各種變量和if判斷等指令可以靈活的做各種策略設置。      工作中

原创 Nginx/tengine裏的那些timeout時間

   老早用nginx時就零零散散的接觸這些時間,一直沒靜下心繫統的梳理一遍,其實理解了這些時間的作用和設置,對配置tengine(nginx)線上業務的優化有不可小覷的作用,對nginx的工作流程也會有更深的理解,目前我線上配置是服務ht

原创 十幾萬連接幾M的流量,嚇死“寶寶”了

    某局點升級(nginx變ats,同時去掉前端的nginx負載層),升級之後服務就不正常,硬生生的看着十幾萬連接,沒有流量,各種排錯,可謂是把心提到嗓子眼驚心動魄的半小時,雖然做了很好的業務機制,服務不正常用戶可以直接回源,不過對於我

原创 理解TIME_WAIT,徹底弄清解決TCP: time wait bucket table overflow

    一直對這個問題知其然而不知其所以然,這些日子再次碰到,看了很多的資料,徹底解決一下,呵呵,先上個圖,所有理解圍繞着此圖來看,此圖描述了四次揮手的整個過程:通過此圖先說明幾個概念:TIME_WAIT的產生條件:主動關閉方在發送四次揮手

原创 大型互聯網應用如何進行流量削峯,應對瞬間請求?

      大型互聯網應用經常要處理流量高峯問題,這也是我所負責業務經常要面對的事情,比如遇到一個熱點事件、策劃一個活動或者push一個頁面,訪問的驟增帶來讀寫流量的驟增,對應每個模塊都面臨考驗,那麼有哪些方法可以做到流量削峯或者說流量削峯

原创 Nginx/Tengine服務啓動管理腳本(未使用系統funtions函數)

    tengine是淘寶對於nginx1.6.2的一個二次開發,性能比原生態nginx更好,這幾天在做測試,想應用到現有的架構裏。源碼包安裝後就牽涉到一個添加到系統服務方便管理問題,到網上搜nginx啓動腳本一大堆,但不是自己寫的總歸不