“日志管理”包括自動備份的設置、備份數據的導入和刪除等功能。
過去十年來，隨著分布式系統的發展，日志數據管理起來更加復雜。如今，系統中可以容納數以千計的服務器實例或者微服務容器，而所有這些實例或容器又會生成自己的日志數據。隨著以云為基礎的系統快速出現并占據主導地位，由機器所生成的日志數據呈爆炸性增長。而日志管理隨之成為現代化IT運營中的重要任務，為包括調試、生產監控、性能監控、支持援助與故障查找之類的許多用例提供輔助支撐。
1. 設立策略
日志記錄不可盲目，要對所記錄的內容以及這樣做的原因進行仔細考量。就像其他重要的IT組件一樣，記錄日志是需要策略的。在構建DevOps設置時，甚至只是發布一個單獨的新功能時，都要確保做好日志記錄的計劃。沒有明確的戰略時，由于最終需要手動管理一個日漸龐大的日志數據集，識別重要信息的過程就會變得極為復雜。
在策劃日志戰略時，需要從自身角度考慮什么是最重要的，想要從日志中獲得什么價值。你的計劃應當包含：日志的記錄方式與工具，數據托管的位置，以及最重要的——具體要尋找什么信息。
2. 日志數據的結構
除了要制定策略，還要考慮日志格式，這點也很重要。如果日志格式難以理解，想要識別日志，并從中總結出見解就很困難。無論對象是機器還是人類，日志的結構都應當清晰易懂。
管理者能夠通過易讀的日志更容易地找到故障，有時候還能使用日志管理服務對日志數據做進一步處理，讓得出的見解更有深度，數據可視化更為優秀。兩種常見的日志結構格式分別是JSON和KVP(主鍵配對)。兩種日志數據均清晰易懂，適合人類理解，并且方便記錄日志的軟件解決方案從半結構化的格式中提取信息。
3. 日志數據的分離與集中
日志應當由系統自動收集并發送到集中的地點，與生產環境相分離。合并日志數據促進管理的有序與分析能力的增強，管理者能夠有效地運行交叉分析，并識別不同數據源之間的關聯。將日志數據集中化同時也降低了在自動擴展環境中損失日志數據的風險。
將日志數據轉發到統一的位置后，系統管理員可以授權開發者、QA和支持團隊訪問日志數據，而無需賦予他們訪問生產環境的權限。因而，這些團隊可以使用日志數據調試，但不會有影響生產環境的風險。復制與獨立化的日志數據也解決了相應的安全漏洞，避免攻擊者刪除日志數據，就算系統被破壞了，日志仍是安全的。
4. 端對端記錄日志
為了簡化定位故障的復雜度，在應用和系統層面獲得更全局化的觀點，應當在所有系統組件中監控并記錄日志。大多數人都知道要記錄服務器日志，比如Windows的安全日志。但是，在底層基礎架構、應用層面和終端用戶客戶端記錄所有相關的指標與事件也同樣重要。
端對端日志記錄讓管理者得以從終端用戶的角度了解系統性能，比如網絡延遲、數據庫事務處理延遲與頁面加載時間。在這些地方清楚明了有利于提供無縫的用戶體驗。
5. 相關數據來源
將端對端日志統一記錄到集中的地方，就可以動態聚合不同來源的各類數據流，比如來自應用的、服務器的、用戶的和CDN的，從而分析得到相應的關鍵趨勢與指標。這些關聯的數據可以讓管理者快速準確識別并理解導致系統故障的事件。例如，實時發現基礎設施資源使用與應用出錯率之間的關聯，能夠協助管理者在終端用戶受到影響前先一步識別出異常與影響。
6. 使用唯一標識符
在調試、支持救援與分析中使用唯一的標識符非常有用。通過標識符可以追蹤特定的用戶會話，并精確地找出某個用戶的活動。如果知道用戶的唯一ID，就能搜索到某一時段用戶的所有活動。一旦用戶活動出現中斷，可以通過追蹤整個事務來查找。
7. 增加背景信息
將日志用做數據時，考慮每個數據點的背景情況非常重要。了解用戶點擊了一個按鈕，也許比不上知道用戶具體點擊了“購買”按鈕。增加額外的背景能夠揭示購買模式。如果用戶的購買請求出現錯誤，相應背景也能讓問題更快解決。
8. 執行實時監控
服務中斷會引發一系列不幸的結果，包括引發用戶不滿、購買意向流失與數據丟失。一旦出現生產層面的問題，在這個爭分奪秒的時刻，實時監控非常重要。
除了發布簡單的通知之外，能夠實時分析問題與識別重要信息也同樣重要。在日志數據中能夠查看“實時軌跡”，使開發者和管理者能夠在用戶與應用或系統互動時分析日志事件。搜索并報告“實時軌跡”還能讓支持團隊對用戶的問題進行分析與解決。
9. 使用日志來識別關鍵趨勢
查找故障和調試只涉及了日志數據提供的表層信息。之前，查找日志曾因過于費勁，而被認為是查找信息的最終手段，而如今的日志服務可以讓所有人——包括開發者、數據科學家都能從應用和系統中識別出有用的趨勢與關鍵的見解。
10. 增強整個團隊
只開放給高級技術團隊的日志管理與分析服務嚴重限制了公司從日志數據中獲得好處的機會。日志管理與分析工具應當能讓開發者實時追蹤調試，讓管理者實時收到警報，讓數據科學家集合數據并可視化，讓支持團隊執行實時搜索與篩選，而無需賦予他們訪問生產環境的權限。