📝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 編寫.