做者:南非螞蟻前端
來源:https://blog.51cto.com/ixdbaweb
運維是一個融合多學科(網絡、系統、開發、安全、應用架構、存儲等)的綜合性技術崗位,從最初的網絡管理(網管)發展到如今的系統運維工程師、網絡運維工程師、安全運維工程師、運維開發工程師等,能夠看出,運維的分工一直在細化,而且對綜合技能要求愈來愈高,能夠看出,將來運維的發展趨勢是高、精、尖,高表示高度,精表示精通,尖表示尖端,也就是運維職場必定要站在必定的技術高度,在多個技術領域中,要精通某項技能,同時對尖端前沿技術必定要能掌控趨勢。數據庫
1、運維職位的發展和趨勢,獲取更多技術知識點+v156 5219 9186,歡豆×××姐在線解答哦~後端
根據不一樣的運維領域和技術面以及分工流程三個方面來了解下2019年運維職位的發展趨勢。緩存
一、按領域來劃分安全
1)、基礎設施運維:IDC/網絡運維、服務器/存儲設備運維服務器
2)、系統運維:系統中間件運維、雲計算平臺運維restful
3)、數據運維:數據庫運維、大數據技術平臺運維網絡
4)、應用運維:應用軟件系統架構
5)、雲平臺運維:公有云平臺運維
6)、容器運維:基於容器服務的運維
二、按技術切面來分
1)、安全運維
2)、性能運維
3)、數據運維
4)、集成運維
三、按流程來劃分
1)、構建/持續集成、發佈
2)、安裝部署、升級、遷移、合併、擴展
3)、配置、初始化、配置變動
4)、備份、傳輸、恢復
5)、日誌、監控、預警
6)、診斷排查、優化
2、系統運維技能圖譜
系統運維是運維的基礎,新的一年中,對基礎運維技能要求也在提升,打好系統運維基礎,才能深刻學習後面的各類運維技能。
下圖列出了系統運維要掌握的必備技能:
3、web運維技能圖譜
web運維是運維崗位中崗位最多的一個,薪資也相對較高,但須要掌握的知識點也比較多,新的技能要掌握,老的運維技能也不能丟,下圖列出了web運維要掌握的各類必備技能。
4、大數據運維技能圖譜
大數據從2017年開始逐漸走到生活的各個角落,2018年在逐漸落地,而在2019年,大數據依然火熱,加上國家對大數據產業的扶持,大數據產業在新的一年崗位需求必定會更加大,所以掌握大數據運維技能,就走在了運維的前沿,下圖列出了大數據運維要掌握的各類必備技能。
5、容器運維技能圖譜
容器的產生,是一次IT行業的革命,2015 年到 2016 年,是業界廣泛認爲的容器技術爆發的一年,短短一年多時間裏,容器技術在中國大陸完成了從零星概念到烽火燎原的壯舉。
時至今日,容器技術在國內大多數企業中落地已成爲一種共識,而國內的生態系統,也呈現出了企業產品、開源社區和公有云齊頭並進的良好局面。所以,2019年也是容器繼續快速落地的一年,下圖列出了大數據運維要掌握的各類必備技能。
6、數據爲王的時代
萬丈高樓平地起,高樓穩不穩取決於地基是否紮實。運維數據即是運維管理這座高樓的地基。運維數據大體分爲CMDB、日誌、生產DB、知識庫四個方面。
CMDB中文是配置管理數據庫,存儲與管理企業IT架構中設備的各類配置信息,主要是IT資產管理信息。
日誌數據保護了企業服務器上運行的各類系統產生的應用日誌,系統日誌、設備日誌、數據庫日誌等數據,這部分數據是企業數據的核心。
DB數據主要是全部IT系統的數據庫信息,包括運維管理系統自己的數據庫,數據庫包含生產數據庫、測試數據庫、開發數據庫三種類型。
知識庫主要存儲平常開發、測試、運維管理中發生的事件、問題以及一些經典問題的解決和經常使用的解決方案,主要起到運維管理輔助的功能。
對數據的維護和管理只管重要,特別是日誌數據,對運維來講,經過日誌能夠比較準確全面地知道系統或是設備的運行狀況,能夠返查問題產生的緣由,還原問題發生的整個過程。經過日誌也能夠提早預測系統可能要發生的問題或是故障,如系統安全日誌,若是網絡攻 擊會在系統安全日誌中有必定的體現。
下面簡單介紹下,運維重點收集的日誌數據有哪些部分以及用途。
一、系統日誌
系統日誌主要指的是操做系統的日誌,主要在/var/log下的各類日誌信息。包含系統操做日誌、系統安全日誌、定時任務日誌等。系統日誌是運維管理安全模塊中審計的重要依據。通常默認的操做系統日誌不能知足要求,須要對系統的參數進行修改,如爲history命令加上時間戳、IP,而且長久保留歷史等功能。而且對日誌文件進行處理,不容許用戶進行清空命令,只能追加。
二、應用日誌
應用日誌主要記錄應用服務的健康運行狀況以及業務操做的具體日誌兩部分。應用監控運行狀況反應應用服務的健康狀態,若是應用佔用CPU或是內存太高或是忽高忽低不定,均可以經過分析應用日誌結合業務操做日誌得出結論。業務操做日誌能夠爲業務審計提供主要依據。有一些系統喜歡把業務操做日誌寫到數據庫中,這個也是須要注意的。不過無論在哪一個地方,要求是不可缺乏的,它爲之後業務審計和問題返查提供依據。
三、數據庫日誌
數據庫日誌主要反饋數據庫的運行狀況。經過監控和管理數據庫的日誌,及時瞭解數據庫的運行狀況,遇到問題及時解決等。能夠經過數據庫日誌結合數據庫系統自帶的數據庫如Oracle的系統視圖v$開頭,MySQL的performance_schema等。雖然數據庫的一些信息不是存在日誌中而是在數據庫裏面,可是也能夠做爲數據庫日誌的一部分進行管理和監控,已便咱們及時知道數據庫的監控情況,從而預防可能出現的問題。
四、設備日誌
設備日誌通常是一個比較容易忽略的地方,但設備日誌每每能夠反映設備的運行狀況。交換機故障,防火牆故障等設備故障均可能引發大面積的系統和服務故障。因此設備日誌必定要收集,分析和監控預警。經常使用的設備日誌有交換機日誌、防火牆日誌、網絡安全設備日誌等。
這麼多的日誌,運維要經過各類手段完成日誌的收集、過濾分析、可視化展現,那麼如何實現這些功能呢,方法不少,例如ELK集成套件(Elasticsearch , Logstash, Kibana)就能夠輕鬆實現日誌數據的實時收集、分析傳輸以及圖形化展現。
Elasticsearch是個開源分佈式搜索引擎,提供蒐集、分析、存儲數據三大功能。它的特色有:分佈式,零配置,自動發現,索引自動分片,索引副本機制,restful風格接口,多數據源,自動搜索負載等。
Logstash主要是用來日誌的蒐集、分析、過濾日誌的工具,支持大量的數據獲取方式。通常工做方式爲c/s架構,client端安裝在須要收集日誌的主機上,server端負責將收到的各節點日誌進行過濾、修改等操做在一併發往elasticsearch上去。
Kibana 也是一個開源和免費的工具,Kibana能夠爲 Logstash 和 ElasticSearch 提供的日誌分析友好的 Web 界面,能夠幫助彙總、分析和搜索重要數據日誌。
另外,還有Filebeat能夠替換Logstash做爲日誌收集工具,Filebeat隸屬於Beats。目前Beats包含四種工具:
Packetbeat(蒐集網絡流量數據)
Topbeat(蒐集系統、進程和文件系統級別的 CPU 和內存使用狀況等數據)
Filebeat(蒐集文件數據)
Winlogbeat(蒐集Windows事件日誌數據)
能夠看到,Beats涵蓋了全部收集日誌數據的各個方面。
那麼要如何使用ELK呢,根據日誌量的不一樣,對應的ELK架構也不盡相同,看下面幾個常見架構:
此架構主要是將Logstash部署在各個節點上搜集相關日誌、數據,並通過分析、過濾後發送給遠端服務器上的Elasticsearch進行存儲。Elasticsearch再將數據以分片的形式壓縮存儲,並提供多種API供用戶查詢、操做。用戶能夠經過Kibana Web直觀的對日誌進行查詢,並根據需求生成數據報表。
此架構的優勢是搭建簡單,易於上手。缺點是Logstash消耗系統資源比較大,運行時佔用CPU和內存資源較高。另外,因爲沒有消息隊列緩存,可能存在數據丟失的風險。此架構建議供初學者或數據量小的環境使用。
由此衍生出來了第二種架構:
此架構主要特色是引入了消息隊列機制,位於各個節點上的Logstash Agent(一級Logstash,主要用來傳輸數據)先將數據傳遞給消息隊列(常見的有Kafka、Redis等),接着,Logstash server(二級Logstash,主要用來拉取消息隊列數據,過濾並分析數據)將格式化的數據傳遞給Elasticsearch進行存儲。最後,由Kibana將日誌和數據呈現給用戶。因爲引入了Kafka(或者Redis)緩存機制,即便遠端Logstash server因故障中止運行,數據也不會丟失,由於數據已經被存儲下來了。
這種架構適合於較大集羣、數據量通常的應用環境,但因爲二級Logstash要分析處理大量數據,同時Elasticsearch也要存儲和索引大量數據,所以它們的負荷會比較重,解決的方法是將它們配置爲集羣模式,以分擔負載。
此架構的優勢在於引入了消息隊列機制,均衡了網絡傳輸,從而下降了網絡閉塞尤爲是丟失數據的可能性,但依然存在Logstash佔用系統資源過多的問題,在海量數據應用場景下,可能會出現性能瓶頸。
最後,還有第三種架構:
這個架構是在上面第二個架構基礎上改進而來的,主要是將前端收集數據的Logstash Agent換成了filebeat,消息隊列使用了kafka集羣,而後將Logstash和Elasticsearch都經過集羣模式進行構建,此架構適合大型集羣、海量數據的業務場景,它經過將前端Logstash Agent替換成filebeat,有效下降了收集日誌對業務系統資源的消耗。同時,消息隊列使用kafka集羣架構,有效保障了收集數據的安全性和穩定性,然後端Logstash和Elasticsearch均採用集羣模式搭建,從總體上提升了ELK系統的高效性、擴展性和吞吐量。
7、用大數據思惟作運維監控
大數據分析最先就來源於運維人的日誌分析,到逐漸發展對各類業務的分析,人們發現這些數據蘊涵着很是大的價值,經過實時監測、跟蹤研究對象在互聯網上產生的海量行爲數據,進行挖掘分析,揭示出規律性的東西,提出研究結論和對策。這就是大數據的用途。
一樣,經過大數據分析,咱們能夠獲得各類指標,例如:
一、在業務層面,如團購業務每秒訪問數,團購券每秒驗券數,每分鐘支付、建立訂單等。
二、在應用層面,每一個應用的錯誤數,調用過程,訪問的平均耗時,最大耗時,95線等
三、在系統資源層面:如cpu、內存、swap、磁盤、load、主進程存活等
四、在網絡層面: 如丟包、ping存活、流量、tcp鏈接數等
而這些指標,恰好是運維特別須要的東西。經過大數據分析出的這些指標,能夠解決以下方面的問題:
系統健康情況監控
查找故障根源
系統瓶頸診斷和調優
追蹤安全相關問題
那麼如何用大數據思惟作運維呢,大數據架構上的一個思惟就是:提供一個平臺讓運維方便解決這些問題, 而不是,讓大數據平臺去解決出現的問題。
基本的一個大數據運維架構是這樣的:
對於運維的監控,利用大數據思惟,須要分三步走:
獲取須要的數據
過濾出異常數據並設置告警閥值
經過第三方監控平臺進行告警
全部系統最可靠的就是日誌輸出,系統是否是正常,發生了什麼狀況,咱們之前是出了問題去查日誌,或者本身寫個腳本定時去分析。如今這些事情均可以整合到一個已有的平臺上,咱們惟一要作的就是定義分析日誌的的邏輯。獲取更多技術知識點+v156 5219 9186,歡豆×××姐在線解答哦~
好啦,這就是今天要給你們介紹的新時期核心運維技能啦,抓住時機,開始全新學習吧!