設想今天是個愉快的週末，天氣很好，你帶著孩子在公園閒逛，這時候，一條簡訊來了：
瞬間整個人都不好了，到底怎麼回事，上面的業務有沒有預警，趕緊把相關人召集一下，最好趕緊去下公司吧！也許這時候你會想：能不能有些智慧型監控手段，給我看到我最想要的資訊，這種模稜兩可的資訊，只會讓人心情變差。
回到主題，現在只要說微服務，必須先說單塊應用了，那單塊應用架構下，監控都怎麼做呢？這是乙個非0即1的問題，如果宿主伺服器指標一切正常，那就是單塊應用出問題了。對於宿主伺服器的監控技術也算蠻成熟，比如nagios、zabbix；而對於應用的監控，主要通過應用伺服器的管理平台，或者直接上去拿應用日誌就可以了。
隨著微服務越來越多的被採用，以前是單個伺服器+單個服務，現在轉變成是多個伺服器+多個服務的模式了，出現乙個異常，如何快速找出問題根源，顯然對監控能力的要求更高了：
分散在各處的日誌怎麼辦？
· 是某個宿主伺服器的問題？還是某個服務的問題？
· 無論是服務還是伺服器問題，影響鏈有哪些？
當然，前面一直在拿故障定位舉例，但監控可不是只為了故障定位，一般監控目標無非下面幾種：
· 事故預警：比如基於閥值對比的實時的事件告警等
· 故障定位：比如靜態點的異常日誌收集等
· 優化決策：比如使用者行為資料分析，發現瓶頸等
無論是上述的哪個目標，又或是微服務帶來的諸多難點，有一樣東西是一直沒有變的，那就是**，要麼是落地日誌、要麼是硬體裝置或系統資訊、要麼就是一堆自定義的程式埋點（當然也可以把日誌作為埋點的一種實現方式）。只是在微服務架構下，資訊收集後你需要的處理動作（關聯、合併、過濾、去重等等）更多更複雜了，我們可以想想一些實際的應用場景：
微服務的日誌收集場景，假設現在我是乙個平台的運維人員，我肯定不希望登到每台宿主伺服器上去看各種日誌，最好是把日誌都收集到一起展現，然後做後續的分析挖掘，基本流程如下圖所示：
從左至右，先是從宿主伺服器上去收日誌，緊接著是乙個管道，負責資料傳輸，接著資料被分流，部分進了儲存系統，比如elasticsearch、hadoop，部分進了實時系統，比如storm、esper，再往右就很明了了。這個架構已經被很多的網際網路公司應用，我所知道的**、噹噹、美團等都是這個基礎架構。但這個架構設計中有幾個點值得大家關注：
· 管道除了傳輸，還有很多能力，最常用的是簡單預處理和資料緩衝（比如很多架構裡用到了kafka）
· 傳輸可以是多級，一般來說規模大到一定程度，資料往乙個點的海量匯聚很容易出問題，分級處理是個很好的方式
· 日誌收集方式盡量統一，很多設計裡對於業務日誌、容器日誌（如docker）、宿主機日誌等採用不同agent，這是乙個不好的設計方式，agent也要管理，引入太多agent只會給自己增加不必要的麻煩
· 都可以做到的前提下，後端採集是首選
· 前端採集盡量採用框架進行埋點，不要到處插入自定義**（框架的做法其實不複雜，比如web端，用過類似selenium這些框架自然就清楚原理了）
· 埋點很難做到語言無關性，尤其後端埋點，微服務架構下，盡量結合各微服務語言特徵來實現
系統效能跟蹤場景，這個其實倒和傳統架構下的方案類似，比如通過協議採集系統的cpu、記憶體、磁碟io等，進而分主題入指標庫。不過像我們採用容器來承載微服務的做法，比起傳統架構來說，需要採的系統資訊更多了，比如容器的效能資訊，同時在建立效能相關的主題時，資料的關聯性也顯然更複雜了。
· 指標庫的選型一般會採用一些記憶體計算框架，對於主題的設計和優化要充分考慮記憶體容量。
· 無論容器、虛機、物理機，效能資料採集都面臨著視窗的問題，一般是兩個視窗（多長時間採集一次和採集的資料是多長時間的資料平均值），需結合業務設定合理值。
· 還有一點，包括上述的兩個場景也都要注意，就是採集器本身對宿主機的效能影響，需盡量降到最低。
前面從技術或業務架構上談監控，除此之外，微服務架構下，在做監控設計時，還有一項重要因素：人（ps：我不是要說康威定律），前面有一句話，不知道大家有沒有在意，「給我看到我最想要的資訊」，「我」很重要，我可以是很多角色，即使是同乙個微服務，不同的角色對於想看到的資訊都可能是不一樣的，結合角色考慮，往往在微服務架構中可以給我們的設計留有很大優化空間，舉個例子：
我們曾經在乙個專案中採集效能資訊，後端的指標庫用了influxdb，儲存虛擬機器的各效能資料，每次採集資訊作為某時間點的一條完整記錄（預設是1分鐘採集一次），中間架了緩衝（kafka），然後由處理器訂閱，並對一批資料向influxdb做批量插入，示意圖如下：
我們一開始認為這就可以了，後面基於類sql語句和內建函式完全就可以得到想要的資訊了。比如每天的效能曲線，可以將一天的資料通過mean計算出24個點，而每個月的時間曲線，可以將乙個月的資料計算出30個點。我們就這麼傻呵呵的把資料持續積累著（要求半年），直到一段時間後，發現撐不住了，怎麼辦呢？我們回過頭來，看看實際上不同的角色要什麼資訊？他們是怎麼消費資料的？
· 決策者：最關注的是這週或這個月比前段週期負載增加或降低了多少，給他的只需是個數字對比結果，明細資料根本不重要，最多他希望能對比到半年前即可
· 運維人員：運維人員其實對資料實時性要求很高，他們根本不在乎幾個月前的資料，只要能看到最近時間的資料有沒有問題即可
這麼一考慮，那優化方式其實就很多，詳細資料雖然需要存檔，但完全可不放在時序庫中，針對決策者，資料按每週或每月彙總再存入線性指標庫即可（influxdb continuous queries）；而針對運維人員，資料駐留記憶體週期可大幅縮短。
總的來說，在微服務架構下，監控確實變得越來越複雜，但無論怎麼複雜，我們都時刻需要結合業務需要和角色識別，來進行監控方案的設計與優化。
·日誌收集的需求，因為我們是基於容器技術的，使用的coreos系統，最終我們採用了journald+fluentd+elasticsearch的技術（業務日誌亦是如此），簡單場景下，elk、flume等其實就足夠了，我們在一些小專案中實踐過。而實時分析系統部分，大家可選擇akka、或者esper、或者storm作為實現框架，akka通過actor模型實現資訊流轉，esper我們是用來做cep產品的，storm就不用多說了。
·對於效能指標的一些需求，influxdb可作為後端儲存（不過influxdb的版本間相容性做的很一般），大家盡可能使用最新版本，還有opentsdb，有朋友推薦過，不過畢竟是基於hbase的，比較重，大家有興趣可嘗試。
普元雲計算專區：
怎麼辦，怎麼辦？
我在一家軟體公司做程式設計師，也有一年多，我是做.net方向的，公司活還可以，就是工資給的少。本來想在工作半年的時候提出加薪的要求，可事事難料啊？就在我剛要開口的時候公司發生了變動。收購 我公司被乙個集團收購了，在收購的這段期間我們公司真是損兵折將啊，走了一大批人，其中包括我們原來的專案經理。這樣一...
也許狼真的來了，我們該怎麼辦？
還記得小學一年級的時候，有一則寓言故事叫 狼來了 它講述的是 乙個放羊娃三番兩次用謊言欺騙山下的村民，前兩次村民都相信了放羊娃的話，急忙的跑到山上去趕走狼，然而發現被戲弄。第三次放羊娃發現狼真的來了，但是此時此刻去尋求村民的幫助時候，發現村民並不會再次相信他了，最終導致大部分羊被狼咬死，損失慘重。雖...
mysql 怎麼辦 mysql 密碼忘記怎麼辦
一 若資料庫是初次登陸 linux系統給資料庫生成了乙個原始密碼在檔案 var log mysqld.log中 grep temporary password var log mysqld.log 找到原始密碼 登陸 mysql uroot p 你找到的密碼 mysql set global val...