NOTE: 這篇文章原文來(lái)自 寫(xiě)時(shí)模式 vs 讀時(shí)模式，個(gè)人以為，名字也可以叫： Elastic vs. Splunk &。
Elastic Stack（或者通常所說(shuō)的 ELK Stack）是一種存儲(chǔ)日志的熱門(mén)工具。
很多用戶開(kāi)始存儲(chǔ)日志時(shí)，僅會(huì)解析出時(shí)間戳，可能還會(huì)添加一些簡(jiǎn)單標(biāo)簽以便篩選，此外就沒(méi)有其他結(jié)構(gòu)了。Filebeat 默認(rèn)就是這樣做的：盡快對(duì)日志進(jìn)行 tail 操作并將其發(fā)送到 Elasticsearch，而不會(huì)提取任何其他結(jié)構(gòu)。Kibana 的 Logs UI 也不考慮日志結(jié)構(gòu)：包括“@timestamp”和“message”的簡(jiǎn)單模式就足夠了。我們將這種日志處理方法稱為最簡(jiǎn)模式。這種方法固然可以節(jié)省磁盤(pán)空間，但只能用于簡(jiǎn)單的關(guān)鍵字搜索和基于標(biāo)簽的篩選，除此之外便沒(méi)有多大用處了。
<figcaption style="box-sizing: border-box; display: block; margin: 0px 0px 20px; text-align: center; font-style: italic; font-size: 14px; line-height: 24px; color: rgb(52, 55, 65); font-family: Inter, sans-serif; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">最簡(jiǎn)模式</figcaption>
隨著對(duì)日志越來(lái)越熟悉，您通常希望對(duì)日志進(jìn)行更多操作。如果發(fā)現(xiàn)日志中的數(shù)字與狀態(tài)代碼有關(guān)聯(lián)，您可能希望對(duì)這些數(shù)字進(jìn)行計(jì)數(shù)，從而了解在過(guò)去一小時(shí)內(nèi)出現(xiàn)了多少次 5xx 級(jí)別的狀態(tài)代碼。Kibana 腳本字段能夠讓您在搜索時(shí)對(duì)日志應(yīng)用模式，從而提取出這些狀態(tài)代碼并針對(duì)這些狀態(tài)代碼進(jìn)行聚合、可視化以及其他類型的操作。我們通常將這種處理日志的方法稱為讀時(shí)模式。
<figcaption style="box-sizing: border-box; display: block; margin: 0px 0px 20px; text-align: center; font-style: italic; font-size: 14px; line-height: 24px; color: rgb(52, 55, 65); font-family: Inter, sans-serif; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">讀時(shí)模式</figcaption>
盡管這種方法十分便于開(kāi)展臨時(shí)性探索，但卻有一大缺點(diǎn)，那就是：如果采用這種方法制作長(zhǎng)期報(bào)告和儀表板，您每次執(zhí)行搜索或者對(duì)可視化進(jìn)行重新渲染時(shí)都需要重復(fù)運(yùn)行字段提取工作。相反，一旦您固定下來(lái)所需的結(jié)構(gòu)化字段，便可在后臺(tái)啟動(dòng)一個(gè) reindex 進(jìn)程，以“持續(xù)”將這些腳本字段添加到永久性 Elasticsearch 索引中的結(jié)構(gòu)化字段內(nèi)。而且，對(duì)于流式傳輸?shù)?Elasticsearch 的數(shù)據(jù)，您可以設(shè)置一個(gè) Logstash 或者采集節(jié)點(diǎn)管道來(lái)通過(guò) dissect 或 Grok 處理器主動(dòng)提取這些字段。
這就為我們引出了第三種方法，也就是在寫(xiě)入時(shí)對(duì)日志進(jìn)行解析，以主動(dòng)提取出上述字段。這些結(jié)構(gòu)化日志能夠?yàn)榉治鰩熖峁┖芏囝~外好處，讓他們無(wú)需在事件之后確定如何提取字段，還可提高查詢速度，并且大幅提高他們從日志數(shù)據(jù)中獲得的價(jià)值。這種適用于集中式日志分析工作的“寫(xiě)時(shí)模式”方法受到了很多 ELK 用戶的歡迎。
<figcaption style="box-sizing: border-box; display: block; margin: 0px 0px 20px; text-align: center; font-style: italic; font-size: 14px; line-height: 24px; color: rgb(52, 55, 65); font-family: Inter, sans-serif; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">寫(xiě)時(shí)模式</figcaption>
在這篇博文中，我會(huì)詳細(xì)講解這些方法的利弊，以及如何從規(guī)劃角度思考這個(gè)問(wèn)題。我還會(huì)說(shuō)明為何在前期解析日志結(jié)構(gòu)有內(nèi)在價(jià)值，以及我為什么認(rèn)為隨著您的集中式日志部署越來(lái)越成熟，即使您在前期基本沒(méi)有結(jié)構(gòu)，“寫(xiě)時(shí)模式”都是一個(gè)發(fā)展方向。
探索“寫(xiě)時(shí)模式”的優(yōu)勢(shì)（并消除誤解）
首先說(shuō)一下，您為什么要在將日志寫(xiě)入集中式日志集群時(shí)便解析日志結(jié)構(gòu)。
更佳的查詢體驗(yàn)。 當(dāng)您從日志中搜索寶貴信息時(shí)，起初時(shí)會(huì)很自然地單純搜索關(guān)鍵字，例如“error”（錯(cuò)誤）。要想返回此類查詢的結(jié)果，可以通過(guò)下面的方法來(lái)實(shí)現(xiàn)：將每個(gè)日志行都視作倒排索引中的一個(gè)文檔，然后執(zhí)行全文本搜索。然而，如果您想問(wèn)一些更復(fù)雜的問(wèn)題，例如“向我提供 my_field 等于 N 的所有日志行”，結(jié)果會(huì)怎么樣呢？ 如果并未定義 my_field 字段，您便不能直接問(wèn)這個(gè)問(wèn)題（不能使用 autocomplete（自動(dòng)完成）功能）。而且，即使您知道自己的日志中包括此信息，為了將其與預(yù)期值進(jìn)行比較，您在查詢時(shí)也需要編寫(xiě)解析規(guī)則以將這個(gè)字段提取出來(lái)。在 Elastic Stack 中，如果您在前期解析日志結(jié)構(gòu)，Kibana 的 autocomplete（自動(dòng)完成）功能會(huì)自動(dòng)提示字段和值來(lái)幫助您構(gòu)建查詢。這能夠大大提高分析師的工作效率！現(xiàn)在，您和您的同事能夠直接提問(wèn)，無(wú)需你們每個(gè)人費(fèi)心琢磨有哪些字段，也無(wú)需你們編寫(xiě)搜索時(shí)用來(lái)提取字段的復(fù)雜解析規(guī)則。
更快地完成歷史數(shù)據(jù)的查詢和聚合。 在 Elastic Stack 中對(duì)結(jié)構(gòu)化字段進(jìn)行查詢時(shí)，即使涉及大量的歷史數(shù)據(jù)，也可在幾毫秒內(nèi)返回結(jié)果。相比之下，如果使用通常的“讀時(shí)模式”系統(tǒng)，則需要數(shù)分鐘甚至數(shù)小時(shí)才能返回答案。之所以會(huì)有這樣的差別，是因?yàn)榕c對(duì)每個(gè)日志行運(yùn)行正則表達(dá)式來(lái)提取字段并進(jìn)行數(shù)學(xué)運(yùn)算相比，對(duì)前期已提取并索引的結(jié)構(gòu)化字段進(jìn)行篩選和運(yùn)行統(tǒng)計(jì)聚合操作要快得多?！白x時(shí)模式”對(duì)臨時(shí)查詢而言尤為重要，因?yàn)槟恢涝谡{(diào)查時(shí)要運(yùn)行哪個(gè)查詢，所以前期工作并不能加快此類查詢的速度。
從日志到指標(biāo)。 這一點(diǎn)與上一點(diǎn)相關(guān)，從結(jié)構(gòu)化日志中提取數(shù)值后得到的結(jié)果與數(shù)值型時(shí)序數(shù)據(jù)或者指標(biāo)出奇地類似。從運(yùn)營(yíng)角度來(lái)說(shuō)，對(duì)這些寶貴的數(shù)據(jù)點(diǎn)運(yùn)行聚合操作能夠產(chǎn)生巨大價(jià)值。如果數(shù)據(jù)量大，通過(guò)結(jié)構(gòu)化字段，您能夠?qū)⑷罩局械臄?shù)值型數(shù)據(jù)點(diǎn)視作指標(biāo)。
時(shí)間準(zhǔn)確。 如果需要處理諸如“IP 地址至主機(jī)名”之類的字段，您必須在索引時(shí)應(yīng)用模式，而不能于后期查詢時(shí)再應(yīng)用模式，這是因?yàn)槿绻笃谔幚淼脑挘赡軐?duì)之前的事務(wù)根本是無(wú)效的（一周后，該 IP 地址可能會(huì)鏈接至完全不同的主機(jī)名）。這一點(diǎn)適用于對(duì)僅提供映射關(guān)系最近快照的外部來(lái)源進(jìn)行的查詢，例如基于身份管理系統(tǒng)處理用戶名，基于 CMDB 處理資產(chǎn)標(biāo)簽，等等。
實(shí)時(shí)異常檢測(cè)和警報(bào)。 與聚合類似，數(shù)據(jù)量大時(shí)，如果使用結(jié)構(gòu)化字段，實(shí)時(shí)異常檢測(cè)和警報(bào)的效率最高。如不使用結(jié)構(gòu)化字段，對(duì)集群長(zhǎng)期處理能力的要求將是一項(xiàng)十分繁重的任務(wù)。我們與很多對(duì)創(chuàng)建警告和異常檢測(cè)作業(yè)持猶豫態(tài)度的客戶交談之后，發(fā)現(xiàn)他們之所以止步不前，是因?yàn)閷?duì)他們所需的警報(bào)數(shù)量而言，搜索時(shí)提取字段這種方法完全不具有可擴(kuò)展性。這意味著他們收集的日志數(shù)據(jù)基本只適用于被動(dòng)用例，進(jìn)而限制了他們?cè)陧?xiàng)目上的投資回報(bào)率。
可觀察性計(jì)劃中的日志。 如果正在開(kāi)展可觀察性計(jì)劃，您肯定知道僅簡(jiǎn)單地采集和搜索日志并不能滿足需求。理想狀況下，日志數(shù)據(jù)應(yīng)該與指標(biāo)（例如資源使用情況）和應(yīng)用程序痕跡進(jìn)行關(guān)聯(lián)，從而讓運(yùn)營(yíng)人員無(wú)論數(shù)據(jù)點(diǎn)來(lái)自哪里，都能全面了解服務(wù)的運(yùn)行狀況。進(jìn)行關(guān)聯(lián)時(shí)，結(jié)構(gòu)化字段的效果最佳；否則查詢速度會(huì)非常慢，而且對(duì)于擁有大規(guī)模數(shù)據(jù)量的實(shí)際情形，分析結(jié)果根本無(wú)法使用。
數(shù)據(jù)質(zhì)量。 如果對(duì)事件進(jìn)行前期處理的話，您將有機(jī)會(huì)檢查無(wú)效、重復(fù)或缺失的數(shù)據(jù)，并糾正這些問(wèn)題。如果依靠“讀時(shí)模式”方法，由于前期并未驗(yàn)證您的數(shù)據(jù)的有效性和完整性，所以您并不知道返回的結(jié)果是否準(zhǔn)確。這可能導(dǎo)致結(jié)果不準(zhǔn)確，并致使您基于返回的數(shù)據(jù)得出錯(cuò)誤結(jié)論。
細(xì)粒度訪問(wèn)控制。 對(duì)非結(jié)構(gòu)化數(shù)據(jù)應(yīng)用細(xì)粒度安全規(guī)則（例如字段級(jí)限制）是件極富挑戰(zhàn)性的事。某些篩選條件能夠在搜索時(shí)限制數(shù)據(jù)訪問(wèn)，這種方法雖有一定幫助，但卻面臨極大的限制，例如無(wú)法返回包含字段子集的部分匹配結(jié)果。在 Elastic Stack 中，字段級(jí)安全功能可讓擁有較低權(quán)限集合的用戶看到部分字段，而看不到整個(gè)數(shù)據(jù)集中的其他字段。所以要想保護(hù)日志中的 PII（個(gè)人身份信息）數(shù)據(jù)，同時(shí)讓規(guī)模更大的用戶集合針對(duì)其他信息進(jìn)行操作，字段級(jí)安全功能可讓您極其輕松、無(wú)比靈活地實(shí)現(xiàn)這一目標(biāo)。
硬件要求
關(guān)于“寫(xiě)時(shí)模式”的一個(gè)常見(jiàn)誤解是，這直接意味著您的集群需要更多資源來(lái)解析日志并同時(shí)存儲(chǔ)未解析和已解析（或“已索引”）格式的日志。我們來(lái)看一下針對(duì)自己的具體用例您應(yīng)該權(quán)衡的幾個(gè)利弊點(diǎn)，因?yàn)榇鸢笇?shí)際上取決于多項(xiàng)因素。
一次性解析 vs 持續(xù)性字段提取。 解析日志并以結(jié)構(gòu)化格式進(jìn)行存儲(chǔ)的確會(huì)在采集端消耗處理能力。然而，如果針對(duì)非結(jié)構(gòu)化日志運(yùn)行重復(fù)查詢，并且此類查詢會(huì)執(zhí)行復(fù)雜的正則表達(dá)式語(yǔ)句來(lái)提取字段，那么長(zhǎng)遠(yuǎn)來(lái)看這種做法消耗的 RAM 和 CPU 資源會(huì)多得多。如果您預(yù)計(jì)自己日志的常見(jiàn)用例僅僅是滿足偶爾的搜索需求，則在前期解析日志結(jié)構(gòu)可能的確有些小題大做。但如果您預(yù)計(jì)會(huì)對(duì)日志進(jìn)行主動(dòng)查詢并對(duì)日志數(shù)據(jù)運(yùn)行聚合操作，則采集時(shí)的一次性成本可能會(huì)低于在查詢時(shí)重復(fù)運(yùn)行同一操作的長(zhǎng)期成本。
采集要求。 由于前期需要進(jìn)行額外處理，所以如果不采取其他措施的話，您的采集通量可能會(huì)比正常情況稍慢一些。您可以引入額外的采集基礎(chǔ)設(shè)施來(lái)處理這一負(fù)荷，只需單獨(dú)擴(kuò)展您的 Elasticsearch 采集節(jié)點(diǎn)或者 Logstash 實(shí)例即可。關(guān)于如何完成這一操作，有一些很好的資源和博客文章可供參考，如果您正在使用 Elastic Cloud 上的 Elasticsearch Service，擴(kuò)展采集節(jié)點(diǎn)的工作無(wú)比輕松，只需添加更多“能夠采集”的節(jié)點(diǎn)即可。
存儲(chǔ)要求。 盡管與人們的正常認(rèn)知相違背，但實(shí)際情況卻的確如此：如果您在前期做一些額外工作來(lái)理解自己日志的結(jié)構(gòu)，存儲(chǔ)要求反而會(huì)較低。日志可能會(huì)十分冗長(zhǎng)，并且包含很多無(wú)用內(nèi)容。如果在前期對(duì)它們進(jìn)行研究（即使不全部解析每個(gè)字段），您便能夠決定在自己的集中式日志集群中在線存儲(chǔ)哪些用于搜索的日志行和已提取字段，哪些內(nèi)容可以立即進(jìn)行歸檔。存儲(chǔ)冗長(zhǎng)且包含無(wú)用信息的日志時(shí)，這一方法能夠降低整體磁盤(pán)要求。Filebeat 提供輕量型 dissect 和 drop 處理器，正好可以實(shí)現(xiàn)這一目的。
即使由于法規(guī)要求您必須存儲(chǔ)每個(gè)日志行，也仍有方法來(lái)優(yōu)化與“寫(xiě)時(shí)模式”相關(guān)的存儲(chǔ)成本。首先，控制權(quán)在您；您并非必須解析全部日志結(jié)構(gòu)：如果用例允許的話，僅添加幾項(xiàng)重要的結(jié)構(gòu)化元數(shù)據(jù)即可，而無(wú)需解析其他日志行。另一方面，如果完整解析日志結(jié)構(gòu)的話，即所有重要信息都以結(jié)構(gòu)化方式加以存儲(chǔ)，則您沒(méi)有必要在存儲(chǔ)已索引日志的同一集群中保留“源”字段，可以將它們歸檔到費(fèi)用較低的存儲(chǔ)選項(xiàng)。
如果存儲(chǔ)空間仍然是一個(gè)大顧慮，還有很多方式可以優(yōu)化 Elasticsearch 的默認(rèn)配置；您只需進(jìn)行些許調(diào)整，即可將壓縮率降下來(lái)。對(duì)于保留期較長(zhǎng)但訪問(wèn)不太頻繁的數(shù)據(jù)，您還可以使用熱溫架構(gòu)和凍結(jié)索引來(lái)最充分利用自己的存儲(chǔ)空間。然而，務(wù)必記住，對(duì)于頻繁使用的數(shù)據(jù)，相較于在最需要的時(shí)候不得不等待數(shù)分鐘來(lái)獲得查詢結(jié)果，存儲(chǔ)費(fèi)用還是要相對(duì)低一些的。
在前期定義結(jié)構(gòu)
我們聽(tīng)到的另一個(gè)誤解是：在存儲(chǔ)之前就解析日志結(jié)構(gòu)操作起來(lái)很困難。我們接下來(lái)打破這一誤解。
結(jié)構(gòu)化日志。 很多日志在生成時(shí)便采用結(jié)構(gòu)化格式。大部分常見(jiàn)應(yīng)用程序都支持直接生成 JSON 格式的日志。這意味著，您開(kāi)始時(shí)便可直接將日志采集到 Elasticsearch 中，無(wú)需進(jìn)行解析便可將它們以結(jié)構(gòu)化格式進(jìn)行存儲(chǔ)。
預(yù)構(gòu)建解析規(guī)則。 目前有數(shù)十個(gè) Elastic 正式支持的預(yù)構(gòu)建解析規(guī)則。舉例說(shuō)明，Filebeat 模塊會(huì)為您解析已知供應(yīng)商日志的結(jié)構(gòu)，而 Logstash 則包含大量的 Grok 模式庫(kù)。社區(qū)內(nèi)還有更多預(yù)構(gòu)建解析規(guī)則。
自動(dòng)生成的解析規(guī)則。 可以使用諸如 Kibana Data Visualizer（Kibana 數(shù)據(jù)可視化工具，可以自動(dòng)提示如何對(duì)日志進(jìn)行解析）等工具，來(lái)幫助定義從自定義日志中提取字段時(shí)所用的規(guī)則。只需將一段日志樣本粘貼過(guò)去，然后便能獲得可在采集節(jié)點(diǎn)或者 Logstash 中使用的 Grok 模式。
如果日志格式發(fā)生變化呢
我們聽(tīng)到的最后一項(xiàng)誤解是，如果采用“寫(xiě)時(shí)模式”方法的話，會(huì)更加難以應(yīng)對(duì)日志格式發(fā)生變化這種情況。這種說(shuō)法是完全錯(cuò)誤的：無(wú)論您采用哪種方法（前期或發(fā)生之后）從日志中提取情報(bào)，總歸要有人應(yīng)對(duì)日志格式發(fā)生變化這種情況，當(dāng)然前提是您的需求不僅限于“全文本”搜索。無(wú)論您使用采集節(jié)點(diǎn)管道在索引時(shí)對(duì)日志進(jìn)行 Grok 解析，還是使用 Kibana 腳本字段在搜索時(shí)完成同樣的任務(wù)，當(dāng)日志格式發(fā)生變化時(shí)，您都需要對(duì)字段提取邏輯進(jìn)行修改。請(qǐng)注意，對(duì)于我們維護(hù)的 Filebeat 模塊，我們會(huì)跟蹤上游日志供應(yīng)商何時(shí)推出新版本，而且會(huì)在測(cè)試之后更新兼容性。
可以通過(guò)多種方法應(yīng)對(duì)寫(xiě)入時(shí)日志結(jié)構(gòu)發(fā)生變化這種情況。
提前修改解析邏輯。 如果知道日志格式即將發(fā)生變化，則您可以創(chuàng)建平行的處理管道，并在過(guò)渡期間同時(shí)支持兩種日志版本。這通常適用于您在公司內(nèi)部可以控制的日志格式。
在解析失敗時(shí)以最簡(jiǎn)模式寫(xiě)入。 并非所有變更都會(huì)提前通知，有時(shí)您控制范圍之外的日志會(huì)不予通知便發(fā)生變更。您可以從一開(kāi)始的時(shí)候便在日志管道中將這種可能性考慮在內(nèi)。如果 Grok 解析失敗，則以最簡(jiǎn)模式寫(xiě)入（僅包括時(shí)間戳和未解析消息），并向運(yùn)營(yíng)人員發(fā)送警報(bào)。接下來(lái)，運(yùn)營(yíng)人員便可針對(duì)新日志格式創(chuàng)建腳本字段，從而避免分析工作流發(fā)生中斷，然后修改之后的管道，并考慮對(duì)短暫的解析邏輯中斷期間的日志重新索引字段。
解析失敗時(shí)推遲編寫(xiě)事件。 如果以最簡(jiǎn)模式寫(xiě)入起不到幫助作用的話，則您可以在解析邏輯失敗時(shí)不寫(xiě)入日志行，而是將事件存儲(chǔ)到“dead letter queue”（未處理消息隊(duì)列，Logstash 提供這一開(kāi)箱即用的功能），并向運(yùn)營(yíng)人員發(fā)送警報(bào)，運(yùn)營(yíng)人員然后便可修復(fù)邏輯問(wèn)題并通過(guò)新的解析管道從“dead letter queue”重新運(yùn)行事件。這會(huì)造成分析中斷，但是您無(wú)需處理腳本字段，亦無(wú)需進(jìn)行重新索引。
一個(gè)極為恰當(dāng)?shù)念惐?/h3>
這是一篇特別長(zhǎng)的博文，如果您讀到這里的話，我要給您一個(gè)贊！恰當(dāng)?shù)念惐瓤梢院芎玫貛椭依斫馍願(yuàn)W概念。和 Elastic 的安全專家 Neil Desai 交談之后，我最近聽(tīng)到了一個(gè)關(guān)于“讀時(shí)模式”和“寫(xiě)時(shí)模式”之間對(duì)比的最恰當(dāng)類比，希望也能幫助到您。
<iframe allow="autoplay; fullscreen; picture-in-picture; camera; microphone; display-capture" allowfullscreen="" allowtransparency="true" aria-label="Video" class="vidyard-iframe-GrRfKk1q28x3cRMtP3VJiw" frameborder="0" height="100%" width="100%" scrolling="no" src="https://play.vidyard.com/GrRfKk1q28x3cRMtP3VJiw?disable_popouts=1&v=4.2.20&type=inline" title="Video" style="box-sizing: border-box; position: absolute; top: 0px; bottom: 0px; left: 0px; border: 0px; width: 825px; height: 287px; opacity: 1; background-color: transparent;"></iframe>
結(jié)語(yǔ)：需要您自行定奪
如我在最開(kāi)始所說(shuō)的那樣，對(duì)于在“寫(xiě)時(shí)模式”和“讀時(shí)模式”之間如何選擇，并沒(méi)有適用于每個(gè)集中式日志部署的統(tǒng)一答案。實(shí)際上，我們看到的大部分部署都介于兩者之間：它們會(huì)詳細(xì)解析某些日志的結(jié)構(gòu)，而會(huì)將其他日志保留為最基本模式（@timestamp 和 message）。這完全取決于您要用日志實(shí)現(xiàn)什么目的，以及您更看重結(jié)構(gòu)化查詢的速度和效率，還是更希望無(wú)需操心前期工作便將數(shù)據(jù)盡快寫(xiě)入磁盤(pán)中。Elastic Stack 同時(shí)支持這兩種方法。
如要開(kāi)始使用 Elastic Stack 處理日志，您既可以通過(guò) Elasticsearch Service 快速部署一個(gè)集群，也可以進(jìn)行本地下載。同時(shí)，歡迎試用我們 Kibana 中的全新 Logs 應(yīng)用，該應(yīng)用能夠優(yōu)化您處理日志時(shí)的工作流，無(wú)論日志是何形式或格式，也無(wú)論是結(jié)構(gòu)化還是非結(jié)構(gòu)化日志，都不在話下。
