㈠ 分布式日誌系統Graylog、Loki及ELK的分析和對比
日誌系列：
企業級日誌平台新秀Graylog，比ELK輕量多了
日誌系統新貴Loki，比ELK輕量多了
1. 為什麼需要集中的日誌系統？
在分布式系統中，眾多服務分散部署在數十台甚至是上百台不同的伺服器上，要想快速方便的實現查找、分析和歸檔等功能，使用Linux命令等傳統的方式查詢到想要的日誌就費時費力，更不要說對日誌進行分析與歸納。
如果有一個集中的日誌系統，便可以將各個不同的伺服器上面的日誌收集在一起，不僅能方便快速查找到相應的日誌，還有可能在眾多日誌數據中挖掘到一些意想不到的關聯關系。
作為DevOps工程師，會經常收到分析生產日誌的需求。在機器規模較少、生產環境管理不規范時，可以通過分配系統賬號，採用人肉的方式登錄伺服器查看日誌。然而高可用架構中，日誌通常分散在多節點，日誌量也隨著業務增長而增加。當業務達到一定規模、架構變得復雜，靠人肉登錄主機查看日誌的方式就會變得混亂和低效。解決這種問題的方法，需要構建一個日誌管理平台：對日誌進行匯聚和分析，並通過Web UI授權相關人員查看日誌許可權。
2. 日誌系統選擇與對比
關於企業級日誌管理方案，比較主流的是ELK stack和Graylog。
常見的分布式日誌系統解決方案有經典的ELK和商業的splunk。為什麼沒有選擇上面的兩種方案呢，原因主要是如下兩種：
ELK目前很多公司都在使用，是一種很不錯的分布式日誌解決方案，但是需要的組件多，部署和維護相對復雜，並且佔用伺服器資源多，此外kibana也在高版本中開始商業化。
splunk是收費的商業項目，不在考慮范圍。
3. 認識graylog
3.1 簡介
graylog是一個簡單易用、功能較全面的日誌管理工具，graylog也採用Elasticsearch作為存儲和索引以保障性能，MongoDB用來存儲少量的自身配置信息，master-node模式具有很好的擴展性，UI上自帶的基礎查詢與分析功能比較實用且高效，支持LDAP、許可權控制並有豐富的日誌類型和標准（如syslog，GELF）並支持基於日誌的報警。
在日誌接收方面通常是網路傳輸，可以是TCP也可以是UDP，在實際生產環境量級較大多數採用UDP，也可以通過MQ來消費日誌。
3.2 優勢
部署維護簡單
資源佔用較少
查詢語法簡單易懂(對比ES的語法…)
內置簡單的告警
可以將搜索結果導出為 json
UI 比較友好
3.3 graylog單機架構圖
3.4 graylog集群架構
4、基於 GrayLog & ELK 的日誌監控
Collector
FileBeat：輕巧佔用資源少，但是功能有點弱。「想起了一些東西，都是淚」
Fluentd：個人理解在Logstash與FileBeat中間，可以簡單處理一些日誌，插件豐富「要再研究下」
自己弄：架構圖裡面只是mysql調用了自己實現的解析工具，但是其實當日誌大到一定的量的還是必須自己來的，類似日誌抽樣、降級、控制頻率等功能，是要真真切切的花費大量時間精力下去的一個sidecar並非動動嘴巴就能搞定的。「都是淚」
Queue
Kafka：王者地位「量小的時候也可以不用這個直接朝後面輸出，有很多中間方案大家自己腦補」，不同的日誌分不同的topic，嚴格區分日誌所屬類型，為後續消費打下基礎，比如A業務進入A Topic並在日誌中打上所屬語言類型的Tag。
Consumer
Logstash：其實這個東西也可以作為收集端來使用，就是比較耗費資源有點重，還會莫名其妙掛了「應該是我不會玩」
GrayLog：本人最喜歡的一個組件，集解析、報警、簡單分析、Dashboard、日誌TTL的綜合體，有這個東西吧其實Kibana就沒啥用了，畢竟誰沒事天天去分析日誌。
Storage
ElasticSearch：全文索引Engine，其實並沒有官方說的那麼牛，當到一定的並發寫入、大量查詢之後其實根本不是加機器能解決的，怎麼分shard，是按照天保存還是按照條數保存「我比較喜歡按照條數保存，這樣可以保證每個index都差不多大小，對於reblance是有好處的，重復利用多盤」如何保存是需要不斷調整的。「我們這邊不討論MongoDB去存日誌，看著都不靠譜」
規范
其實日誌系統最關鍵的是怎麼打、什麼格式打、但是這個東西需要消耗大量的時間去定義與各個部門Pk，遇到過大量不講理的輸出，直接線上Debug，600k的並發寫入，日誌又大又臭誰能扛得住「阿里雲的SLS是真的很牛」
捲起袖子加油干，少動嘴，多動手，日誌很好玩。在容器化的大環境下也越發的重要。
Flunted + Elasticsearch + Kibana的方案，發現有幾個缺點：
不能處理多行日誌，比如Mysql慢查詢，Tomcat/Jetty應用的Java異常列印
不能保留原始日誌，只能把原始日誌分欄位保存，這樣搜索日誌結果是一堆Json格式文本，無法閱讀。
不符合正則表達式匹配的日誌行，被全部丟棄。
對比圖
總結
雖然兩種解決方案在功能上非常相似，但仍有一些差異需要考慮。
兩者之間最重要的區別在於，從一開始，Graylog就定位為強大的日誌解決方案，而ELK則是大數據解決方案。Graylog可以通過網路協議直接從應用程序接收結構化日誌和標准syslog。相反，ELK是使用Logstash分析已收集的純文本日誌的解決方案，然後解析並將它們傳遞給ElasticSearch。
在ELK中，Kibana扮演儀表盤的角色並顯示從Logstash收到的數據。Graylog在這點上更方便，因為它提供了單一應用程序解決方案（不包括ElasticSearch作為靈活的數據存儲），具有幾乎相同的功能。因此，部署所需的時間更短。此外，與ELK相比，Graylog開箱即用，且具有出色的許可權系統，而Kibana則不具備此功能。作為Elasticsearch的粉絲，我更喜歡Graylog而不是ELK，因為它完全符合我在日誌管理方面的需求。
Graylog具有直觀的GUI，並提供警報、報告和自定義分析功能。最重要的是，它能在多個日誌源和跨機房收集數TB的數據。基於這些優勢，我更喜歡用Graylog而不是另一個具有類似功能的流行堆棧——ELK。
如果有需要領取免費資料的小夥伴們， 可以點擊此處領取資料哦！
㈡ 如何清理MySQL 的查詢緩存
MySQL的FLUSH可以清理mysql資料庫緩存數據
MySQL的FLUSH句法(清除或者重新載入內部緩存） FLUSH flush_option [,flush_option]，如果你想要清除一些MySQL使用內部緩存，你應該使用FLUSH命令。為了執行FLUSH，你必須有reload許可權。
flush_option 可以是下列任何東西：
HOSTS 這個用的最多，經常碰見。主要是用來清空主機緩存表。如果你的某些主機改變IP數字，或如果你得到錯誤消息Host ... isblocked，你應該清空主機表。當在連接MySQL伺服器時，對一台給定的主機有多於 max_connect_errors個錯誤連續不斷地發生，MySQL為了安全的需要將會阻止該主機進一步的連接請求。清空主機表允許主機再嘗試連接。
LOGS 關閉當前的二進制日誌文件並創建一個新文件，新的二進制日誌文件的名字在當前的二進制文件的編號上加1。
PRIVILEGES 這個也是經常使用的，每當重新賦權後，為了以防萬一，讓新許可權立即生效，一般都執行一把，目地是從資料庫授權表中重新裝載許可權到緩存中。
TABLES 關閉所有打開的表，同時該操作將會清空查詢緩存中的內容。
FLUSH TABLES WITH READ LOCK 關閉所有打開的表，同時對於所有資料庫中的表都加一個讀鎖，直到顯示地執行unlock tables，該操作常常用於數據備份的時候。解鎖的語句就是unlock tables。
FLUSH TABLES WITH READ LOCK對於資料庫是全局的表鎖定，如果只想鎖定幾個表，可以用LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} 。這個命令同樣需要unlock tables來解鎖。
read-lock: 允許其他並發的讀請求，但阻塞寫請求，即可以同時讀，但不允許任何寫。也叫共享鎖。write-lock: 不允許其他並發的讀和寫請求，是排他的(exclusive)。也叫獨占鎖
STATUS 重置大多數狀態變數到0。
MASTER 刪除所有的二進制日誌索引文件中的二進制日誌文件，重置二進制日誌文件的索引文件為空，創建一個新的二進制日誌文件,不過這個已經不推薦使用，改成reset master 了。可以想像，以前自己是多土啊，本來一條簡單的命令就可以搞定的，卻要好幾條命令來，以前的做法是先查出來當前的二進制日誌文件名，再用purge 操作。
QUERY CACHE 重整查詢緩存，消除其中的碎片，提高性能，但是並不影響查詢緩存中現有的數據，這點和Flush table 和Reset Query Cache（將會清空查詢緩存的內容）不一樣的。
SLAVE 類似於重置復制吧，讓從資料庫忘記主資料庫的復制位置，同時也會刪除已經下載下來的relay log,與Master一樣，已經不推薦使用，改成Reset Slave了。這個也很有用的。
一般來講，Flush操作都會記錄在二進制日誌文件中，但是FLUSH LOGS、FLUSH MASTER、FLUSH SLAVE、FLUSH TABLES WITH READ LOCK不會記錄，因此上述操作如果記錄在二進制日誌文件中話，會對從資料庫造成影響。
㈢ 用內存做硬碟緩存有用嗎一般大家都怎麼給電腦提速啊~
實在是沒有必要，無異於大炮打蚊子。
除非你內存32g或者64g，那麼可以分出16g以上去作為硬碟緩存，這樣讀取部分軟體會起到加快響應時間的作用，你如果本來就8個g
分出2個g做緩存不但速度沒提升，反而因為運行內存不夠降低速度。