應用程序日誌堆棧

使用NLOG與Elasticsearch target到的日誌信息轉發到AWS Elasticsearch as a Service簇在Kibana可視化。應用程序日誌堆棧

這可以正常工作，但由於ES羣集可用性以及羣集故障轉移具有的影響，因此在使用elasticsearch-net client通過HTTP發送日誌時，我擔心在生產中使用此功能。

我正在考慮爲NLog使用不同的目標，它將日誌發送到更可靠的目的地（File，S3？），然後讓別的東西（Logstash，AWS Lambda）將它們接收併發送給ES，這樣儘量減少應用程序本身的風險。

想聽聽您的想法

UPDATE

主要關注的是應用程序的可用性和防止丟失日誌使用次要目標。

使用最新NLOG和throwExceptions設置爲false，而不是使用異步目標，在這一點上，但考慮到這是我們有很多的異步代碼。

爲了讓更多的上下文中的「應用程序」是一組獲得10的API（的WebAPI和WCF）的 - 15K RPM。

方案

請進來，ES羣集不可用。

案例1 - NLOG沒有異步目標

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd" 
     autoReload="true" 
     throwExceptions="false" 
     internalLogLevel="Off" 
     internalLogFile="c:\temp\nlog-internal.log"> 

    <targets> 
     <target name="elastic" 
       xsi:type="BufferingWrapper" 
       flushTimeout="5000"> 
     <target xsi:type="ElasticSearch" 
       layout="${logger} | ${threadid} | ${message}" 
       index="logstash-${date:format=yyyy.MM.dd}" 
       includeAllProperties="true" 
       uri="..."> 

      <field name="user" 
       layout="${windows-identity:userName=True:domain=False}"/> 
      <field name="host" 
       layout="${machinename}"/> 
      <field name="number" 
       layout="1" 
       layoutType="System.Int32"/> 

     </target> 
     </target> 
    </targets> 
    <rules> 
     <logger name="*" 
       minlevel="Debug" 
       writeTo="elastic" /> 
    </rules> 
    </nlog>

問：

與主線程時會發生什麼目標不能達到？

案例2 - NLOG與異步目標

使用異步包裝用於與queueLimit elasticsearch目標= 「10000」 BATCHSIZE = 「100」

問：

是另一線程[B]創建？
將隨後的請求重用線程[B]並排隊記錄請求？
當達到queueLimit時會發生什麼？
會啓動附加線程[B1 ... Bn]嗎？（這將淹沒連接池）

來源

2016-11-25 thedev

好問題。

沒有什麼可擔心的，但正確配置NLog很重要。

不知道什麼應該是可靠的，運行程序或不丟失日誌信息，所以對於那些情況：

如果你害怕，如果你失去了一些日誌信息
- 寫到多個目標（來自NLog），例如文件和 Elasticsearch。
- 可選，（寫入到目標時發生錯誤的情況下）
- 如果異步啓用，check the overflow/queue settings使用fallbackgroupwrapper - 丟棄默認啓用
（從CPU或內存過載保護）
如果你害怕記錄可能會破壞您的應用程序：
- 使用NLOG的最新的穩定版本（4.3）
- 不要啓用throwExceptions（用d禁用默認）
- 如果啓用async，則錯誤會寫入另一個線程中的目標，因此它不會中斷您的應用程序。
- 還使用async時，check the overflow and queue settings

更新

理想的情況下，這應該是獨立的StackOverflow問題;）

案例1，

與發生了什麼邁當目標無法到達時，是否有n個線程？

沒有。主要將消息排入緩衝區。另一個（Timer）線程正在處理這些消息。如果這將失敗，並且throwException未啓用，則只有錯誤將寫入內部日誌（啓用時）。所有異常都會被捕獲。寫入目標失敗時，您將丟失消息。

案例2，

是另一個線程[B]產生的？

將會創建一個Timer。這將創建一個處理消息的線程。

將後續請求重用螺紋[B]和隊列記錄請求？

是的，但不保證不會在同一個線程。計時器將從池中創建一個線程。注意：只有一個線程會同時存在。

當達到queueLimit時會發生什麼？

取決於您的配置。默認情況下，它將按照上面所述默認放棄。請參閱check the overflow/queue settings。就內存和CPU而言，這是最安全的選擇。你可以選擇丟棄，阻塞（停止主線程），或增長隊列（通過知道內存使用情況）。

會啓動額外的線程[B1 ... Bn]嗎？（這將泛洪連接池）

1號計時器，1線程池。有關詳細信息，請檢查MSDN page for Timer或reference source。

來源

2016-11-25 17:53:28 Julian

沒有考慮throwExceptions標誌。感謝您指出了這一點！我已經更新了這個問題，你能再看一下嗎？ – thedev

應用程序日誌堆棧

回答

相關問題