?Description:
我們都知道為什麼 Loki 對日誌管理有很大幫助。但這裡有所有的原因，為什麼你公司的會計和運營團隊也會喜歡 Loki。
為什麼應該使用 Loki?
—— 降低成本，簡化運營，建立更好的團隊
除了技術方面的理由，以及它的可伸縮性之外，它的組織收益往往會被低估或忽視。
我想談談 Loki 所做的事情——或者更好的是，它能讓你避免做什麼。這些都是我吃了苦頭才學會的。當你擴充人員、團隊或專案而不是資料集時，這些事情可能是有意義的。
這大致可以分為兩個陣營：成本和過程，假設成本是貨幣的，過程是組織的。
Loki 技術原理簡介
首先是對 Loki 工作原理的簡要介紹，這應該有助於其他方面的介紹。Loki 是一個具有成本效益的、可擴充套件的、無偏見的日誌聚合器，它主要基於 Prometheus 標籤正規化，並與 Cortex 內部結構縫合在一起，以實現擴充套件。.
Loki 攝取了你的日誌，並使它們可以被搜尋。你知道，那些包含技術債務的無定形表現的文字檔案。你的應用程式的脆弱的、試探性的故事情節。衡量標準的簡短性永遠無法表達的東西。除錯日誌在陽光和彩虹下看起來毫無用處，但在故障期間卻價值連城。
從本質上講，Loki 做出了兩個選擇，其他一切都繼承了這個選擇。
- 它只對後設資料的一部分進行索引，而不是整個日誌行。
- 它將其儲存層解耦為一對可插拔的後端：一個用於索引，一個用於壓縮日誌。
為什麼 Loki 只索引後設資料
所以，Loki 只對後設資料進行索引。這到底是如何使它的執行更具成本效益的，又有多少？
對於全文索引來說，索引本身最終會比它們所索引的資料大，這很常見。而索引的執行成本很高，因為它們需要更昂貴的硬體（通常是佔用大量記憶體的例項）。
Loki 根本不對日誌的內容進行索引，而只是對其來源的後設資料進行索引（標籤如app=api，environment=prod，machine_id=instance-123-abc）。
因此，Loki 不需要維護昂貴的例項叢集來提供大型的全文索引，而只需要擔心一小部分的資料。根據經驗，這比資料要小 4 個數量級（萬分之一）。
因此，一開始，Loki 就把執行索引日誌聚合器中通常操作成本最高的部分降到最低。
為什麼 Loki 使用物件儲存作為日誌儲存
我們剛剛介紹了 Loki 做出的索引決定；現在我們來看看 解耦儲存 如何幫助降低成本。畢竟，Loki 也需要儲存日誌。它透過將它們以壓縮塊的形式傳送到 AWS S3 這樣的可插拔物件儲存中。
與我們之前談論的昂貴的記憶體飢餓例項相比，物件儲存是白菜價便宜的，非常具有成本效益。日誌一直在那裡，直到被訪問為止。從本質上講，微小的標籤索引被用來將請求路由到物件儲存中的壓縮日誌，然後在商業硬體上以高度並行的方式解壓縮和掃描。
為了幫助我們過渡到更多的程式導向的好處，我想指出的是，當日志記錄很便宜時，它消除了減少日誌記錄的反常動機。不記錄那些除錯日誌是一種反模式（因為它們的儲存和檢索成本很高）。當儲存便宜的時候，我們可以避免這些艱難的決定，並確保我們在對抗故障時有我們需要的資源。
Loki 如何減少你的運營頭痛問題
現在我們已經介紹了我們的會計人員喜歡 Loki 的原因，讓我們來看看我們的運營團隊為什麼也喜歡 Loki 的細微原因。
因為 Loki 採取了非索引的日誌記錄方式，它避免了對結構化日誌記錄的依賴，以推動對日誌資料的運營洞察力。這意味著不需要用預處理工具來協調模式定義，也不需要在多個應用程式或團隊中嘗試改變這些模式時進行後續的打怪遊戲。
構建臨時管道工具和向後相容遷移的問題其實並不適用。然而，在避免預處理時，有必要提及權衡。在查詢時，我們必須瞭解如何與資料進行有意義的互動。
但是，這種區分是多麼的好啊！查詢時間的技術債務可以用任何方式管理，並在很長一段時間內管理，或者根本不管理（這也是我們在查詢時間使用logfmt進行可讀性/grepping 的一個主要原因）。
另一方面，攝取時間的預處理需要巨大的前期努力，對變化極其脆弱，並導致組織摩擦。
問題始終是，內部各組之間存在著各種各樣的使用案例、格式和專業知識。但是這些記錄方法中的一個給了我們圍繞這個問題的靈活性，而另一個則沒有。
Loki 缺乏正式的模式 (202204 有了），這並不是說它不能用於分析。但它是為開發者和操作者量身定做的，更傾向於實現事件響應而不是歷史分析。也就是說，Loki 的下一個版本將帶來強大的分析能力，用於臨時性的指標。
它也不只是 grep。它的 LogQL 查詢語言以 Prometheus 的 PromQL 為模型，能夠快速證明假設並在日誌和指標之間無縫切換。例如，從日誌條目中快速生成錯誤率，就像這樣簡單。
如前所述，我最喜歡 Loki 的一些東西是它使我們能夠避免做的事情。
還記得我們的小索引和無模式的資料模型嗎？Loki 允許我們避免處理冷熱索引、生命週期管理，以及當審計問題出現時，為重新啟用舊資料而進行的一次性歸檔資料取回處理。只要把你的舊資料運送到廉價的物件儲存中，就不用擔心在昂貴的硬體上管理連續的以效能為重點的索引層。
Loki 會自動建立、旋轉和過期自己的微小索引，確保它不會增長得太大，並使使用者能夠透明地查詢任何資料，只要你指定保留時間。
Loki 還能無縫地處理其內部儲存版本的升級。想利用一些新的改進嗎？沒問題。Loki 為這些之間的邊界保持一個參考，在它們之間透明地分割查詢，並將它們縫合在一起。不需要擔心解除安裝和重新載入舊的模式版本的相容性問題。
Loki 如何改善你的團隊
接下來，我想談一談 dev 和 ops。將這兩者結合起來已經變得越來越流行（而且有充分的理由）。
不過這裡有一個區別--不要把理解軟體的部署方式/地點與執行可觀察性系統混為一談。讓你的應用程式開發人員記錄他們想要的東西，而不用擔心他們需要使用哪種日誌模式來確保不會破壞他們的觀察工具的一些預處理管道。
如前所述，我們在 Grafana Labs 更喜歡 logfmt，因為它的簡單輸出可以實現 grep 友好的查詢時間過濾/操作。重點是，某種程度的一致性是好的，但不是必須的。讓你的開發者和運維專注於他們所需要的本質，而不用擔心你的可觀察性系統的正規化。
Loki 缺乏使用者定義的模式，而且它的非索引性質消除了開發人員和運維人員的認知負擔，使他們能夠重新關注他們工作的本質，然後在需要時轉向查詢 Loki。
讓你的運營團隊瞭解執行和擴充套件 Loki，包括配置 promtail（或你使用的任何代理）的輔助需求。我建議使用標籤來給你的日誌附加環境識別符號，比如application=api，env=prod，cluster=us-central等。然後，使用者可以混合和匹配標籤過濾器，以快速細化問題發生的地方，並利用 Loki 的讀取路徑的大規模並行性質，以低成本在潛在的巨大資料集上進行任意的查詢。
而且不用擔心-- Loki 是開源的。它確保瞭解 Loki 的入門門檻相對較低。不需要覺得只從其他大型組織中招聘，也不需要擔心新來的工程師沒有使用你所選擇的工具的經驗。
Loki 可以在單機上以單二進位制模式執行（像 Prometheus），然後在你的用例因規模、冗餘或可用性問題而增長時橫向擴充套件。我們有大量的使用者在從樹莓派到大規模、水平擴充套件的叢集中執行 Loki。
Loki 並不是什麼都能做，但我們認為它對其使用情況做了很好的權衡：一個快速、經濟、高度可擴充套件的日誌聚合器，與 Prometheus 標籤模型有很好的整合，可以毫不費力地在指標和日誌之間切換。
Grafana 系列文章
三人行, 必有我師; 知識共享, 天下為公. 本文由東風微鳴技術部落格 EWhisper.cn 編寫.