logstash和filebeat是什么關系？logstash和filebeat的關系：它是單獨其它的東西LogstashForwarder的下一代Logstash收集器，是是為更飛快穩(wěn)定點輕量低耗地

logstash和filebeat是什么關系？

logstash和filebeat的關系：

它是單獨其它的東西LogstashForwarder的下一代Logstash收集器，是是為更飛快穩(wěn)定點輕量低耗地進行收集到工作，它是可以很更方便地與Logstash有直接與Elasticsearch通過對接.

filebeat是在LogstashForwarder的源碼基礎上演化進來的項目.

1.logstash和filebeat大都也可以才是日志哪采的工具，目前日志喂養(yǎng)靈獸的工具有很多種，如fluentd,flume,logstash,betas等等。甚至還之后我決定用filebeat充當日志采藥端工具的時候，還有人問為什么不需要flume,logstash等采集工具。

2.logstash又出現(xiàn)時間要比filebeat早許多，伴隨著時間經(jīng)濟的發(fā)展，logstash不僅是一個日志采集工具，它都是可以不另外一個日志各種資料工具，有豐富地的input|filter|outputs插件這個可以可以使用。具體方法的ELK日志采集方案中，大部分的做法是將所有節(jié)點的日志內(nèi)容上回到kafka消息隊列，然后把使用logstash集群讀取數(shù)據(jù)消息隊列內(nèi)容，依據(jù)什么配置文件參與過濾。上送回elasticsearch。logstash詳細信息可返回

3.logstash是不使用Javac語言程序，插件是建議使用jruby編譯程序，對機器的資源沒有要求會比較高，網(wǎng)上有一篇關與其性能測試的報告。前的做過和filebeat的測試對比。在采集日志方面，對CPU，內(nèi)存上都要比前者高很多。LogStash::Inputs::Syslog性能測試與優(yōu)化

又是elastic.公司開發(fā)的，其官方的說法是目的是替代logstash-moving。常規(guī)go語言開發(fā)。代碼閉源。elastic/beatsfilebeat是beats的一個文件采集工具，目前其官方基于libbeats平臺開發(fā)的也有Packetbeat，Metricbeat，Winlogbeat。filebeat性能相當好，布署簡單的。是一個的很實現(xiàn)理想的文件采集工具。自己采集工具都是設計和實現(xiàn)beats源碼通過的二次開發(fā)。

我希望對你有幫助~

服務器數(shù)量比較少，怎么運維比較好？

你好，很不高興解釋你這個問題。從運維的角度來講，服務器的數(shù)量少卻不是換句話說我們的運維工作就的很很快，只不過我們更應該要看重此階段的工作。

我們也可以從200以內(nèi)幾方面來積極開展我們的運維工作：

1.應用服務器

我們是可以從當前服務器中看出大概2個節(jié)點裝Vsphere虛擬化，組建一個數(shù)據(jù)中心、集群；如果沒有你的服務器有多網(wǎng)卡和SCSI，還也可以做一些更中級的應用，如vmotion、負載均衡、高可用等。當虛擬機或服務器故障，這個可以基于故障自動出現(xiàn)需要轉(zhuǎn)移，有效的避免了單節(jié)點的故障，提供服務器的容錯率。

我們可以在新建項的虛擬機部署Web、API等各種應用，并且虛擬機是可以在vCenter圖形化界面下統(tǒng)一管理。這好象是中小公司的在服務器方面的解決方案。

當然，我們對docker比較清楚，也可以不使用一套docker解決方案，這比Vsphere更能節(jié)約時間一部分資源。其實這個是需要的技能要求也比較高，是需要我們不斷的積累。

2.數(shù)據(jù)庫服務器

數(shù)據(jù)庫服務器在此我們不能拿出來，是是因為數(shù)據(jù)庫對服務器性能、磁盤IO要求也很高，不太見意可以使用虛擬機，當然了這要依據(jù)業(yè)務的不好算情況來做選擇。數(shù)據(jù)庫我們不需要通過一主一從、一主二從的實現(xiàn)方法高可用，來盡量避免數(shù)據(jù)庫單點問題，我們還可以不選擇最合適的proxy來參與讀寫分離、讀負載均衡等。另又要確定數(shù)據(jù)的本地系統(tǒng)備份、異地備份，來必須保證數(shù)據(jù)可復原。

3.系統(tǒng)監(jiān)控

當我們在應用服務器和數(shù)據(jù)庫服務器上線一套系統(tǒng)后，我們必須實際監(jiān)控完全掌握從服務器硬件、基礎狀態(tài)、應用、數(shù)據(jù)庫等從下到上的運行狀態(tài)，以便我們能夠?qū)Ω婢欢ㄒ皶r做出決定做出反應。考慮到到可以報警的及時處理性，我們要監(jiān)控接入功能高效報警渠道，如、釘釘、郵件、短信等。監(jiān)控的目的是才發(fā)現(xiàn)問題、可以解決訪問，所以我們需要踏實的做到這踏上一步，才能為我們的業(yè)務保駕護航。

行了，不過無論服務器多少，我們都需要打扎實的把基礎打好，那樣才能以不變應萬變遇上各種情形。我希望我的回答也能幫到你。

我是【木訥大叔愛運維】，請關注，與你彼此分享運維路上的點點滴滴！