在我們的應用程序中，我們記錄重要信息以記錄文本文件以供以後調試。使用splunk，如果我已經有一些數據點，如訂單號或「找不到對象引用」類型的錯誤，則很容易識別問題。但對我來說，使用splunk來得到整體問題的整體情況非常重要。爲了能夠識別軟件中的實際問題，我必須通讀可能的多個日誌文件或整個日誌文件，以便在問題發生之前查看應用程序正在執行的操作。以人爲的方式讀取整個日誌文件可以幫助我確定應用程序在發生實際問題之前如何與其他數據點一起運行。換句話說，我很難看到splunk錯誤的「真正的根本原因」。你在軟件開發領域的經驗是什麼？您在使用splunk時遇到的挑戰
這很難去除人的方面。話雖如此，我最近不得不領導發展的一部分，並且有一些很棒的工具可以滿足您的一些需求。使用splunk的內置警報是實現這一點的最簡單方法。不幸的是，對於許多splunk相關的東西（我的意思是，嚴格來說，請不要在每個webservice或rest api的示例中使用不安全標誌的curl，請在splunkbase或其他地方使用curl實例）互聯網。無論哪種方式，我找到的用於查找特定類型的日誌或日誌數據的最優雅的解決方案都是在我的搜索中大量使用「rex」命令。它將指定Perl正則表達式以幫助從正確的字段中提取正確的信息。 012 spl來自splunk的網站。
這當然假設您知道哪些字段包含您正在查找的數據。不幸的是，如果在索引器中沒有正確設置，這可能是Windows日誌的問題。
對於Splunk以您可能想要的方式工作（根據您的描述來判斷），您將被迫「修改」應用程序的某些部分以適應Splunk索引和存儲數據的方法。
Splunk依賴於事件索引，這些事件是來自系統中各種日誌的錯誤或狀態消息。 Splunk索引的主要目標是日期，因此沒有日期意味着沒有索引，之後會導致Splunk搜索的結果更少。
在不同情況下保留不同搜索條件的列表或備忘單也是一種很好的做法，因此，以後您可以輕鬆生成曾經發現成功的結果。
在我們公司，我們爲客戶創建了特定版本的軟件，他們選擇使用Splunk作爲他們所選擇的監控工具。這個自定義應用程序和我們的標準應用程序之間的基本區別在於，它非常強烈地依賴於將它所做的所有操作寫入日誌文件，並使用「segemtn - time - root cause - user- group - file - action將其保存在邏輯事件中 - 結果 - 備註「 這使我們能夠實時發現和發現問題，並且成本比以前更低。
正確的地方要問Splunk的問題是
那裏的人，這將有助於你的生活共同體...
@Cninroh是錯誤的大多數賬戶。我在Splunk工作。
您可以根據需要製作搜索以查找根本原因。您需要根據您的需要制定搜索。我不知道你的數據，但是，例如，下面的搜索會發現，以root身份登錄「磁盤錯誤」之前權限的用戶...
login root [ search disk-error | head 1 | eval latest = _time - 5*60 ] | head 1
你可以還設置警報以尋找異常值和其他意想不到的事情，因此您不必積極尋找問題。他們可以推到你身邊。
就像您需要了解如何閱讀和評估日誌文件一樣，您需要了解如何使用Splunk來充分利用您的努力。
對於在單臺機器上運行代碼的開發人員，您可以輕鬆讀取一個日誌文件並查看發生了什麼事情。一旦您釋放代碼並在多層或分佈式架構上運行，您就無法輕鬆跟蹤發生什麼事情的時間和地點。也許你甚至無法訪問生產系統日誌。
下面是一個例子。通過簡單的關鍵字搜索找到您的錯誤。點擊有趣事件的時間戳。這使Splunk的時間範圍達到1秒。清除關鍵字搜索並輸入*以在1秒內查看所有事件。將您正在看到活動的主機和設備限制在您感興趣的系統/應用程序中。
您現在正在一個視圖中看到應用程序中涉及的所有系統發生的事件。如果需要捕獲根事件，您可以縮小到更多時間。如果要按時間順序閱讀（頂部（最早）到底部（最新）），而不是Splunk的默認反向時間順序，請使用「|反向」命令。
一旦找到問題，您可以將該搜索轉換爲Splunk警報，以便將來收到通知。在解決該問題後，您可以啓用警報，以便如果您的修復在所有情況下都不是100％有效，或者未納入您的下一個主要/次要版本，您將收到通知。