使用ELK堆栈的应用日志记录

Question

使用NLog和弹性搜索目标将日志转发到作为服务的AWS弹性搜索集群，以便在Kibana进行可视化。

这很好，但是我担心在生产中使用它，因为ES集群可用性以及集群故障转移所带来的影响，当日志是通过elasticsearch-网络客户端发送的。

我正在考虑为NLog使用不同的目标，将日志发送到更可靠的目标(文件，S3 ?)然后有其他的东西(Logstash，AWS )将它们捡起来并发送到ES，这样可以最大限度地降低应用程序本身的风险。

想听听你的想法

更新

主要关注的是应用程序的可用性，并使用了防止丢失日志的次要目标。

使用最新的NLog和throwExceptions设置为false，此时不使用异步目标，但考虑到这一点，因为我们有很多异步代码。

为了提供更多的上下文，"app“是一组API (WebAPI和WCF)，它们可以获得10-15KRPM。

场景

请求传入，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="10000“batchSize=100实现弹性搜索目标的异步包装器

问：

• 创建了另一个threadB吗？
• 随后的请求会重用线程B并对日志记录请求进行排队吗？
• 当到达queueLimit时会发生什么？
• 额外的线程B1 ..。开始了吗？(这将淹没连接池)

Answer 1

问得好。

没有什么可担心的，但是正确配置NLog是很重要的。

不确定什么应该是可靠的，运行程序还是不丢失日志消息，因此对于这些情况：

• 如果您害怕丢失一些日志消息

- Write to multiple targets (from NLog), e.g. File **and** Elasticsearch. 
- Optional, use a fallbackgroupwrapper (in case of an error when writing to the target)
- If async is enabled, [check the overflow/queue settings](https://github.com/NLog/NLog/wiki/AsyncWrapper-target#async-attribute-will-discard-by-default) - discard is enabled by default (to protect from CPU or memory overload)

​

• 如果您担心日志记录会破坏您的应用程序：

- Use the latest stable version of NLog
- Don't enable `throwExceptions` (disabled by default)
- If you enable `async`, the errors are written to the target in another thread, so it could not break your app. 
- Also when using `async`,  [check the overflow and queue settings](https://github.com/NLog/NLog/wiki/AsyncWrapper-target#async-attribute-will-discard-by-default)

​

更新

案件1，

当无法到达目标时，主线程会发生什么情况？

没什么。主队列将消息放在缓冲区中。另一个(Timer)线程正在处理这些消息。如果这将失败，并且throwException未启用，则只会将错误写入internalLog (启用时)。所有的例外都会被抓住。当写入目标失败时，您将丢失消息。

案件2，

创建了另一个threadB吗？

将创建一个Timer。这将创建一个用于处理消息的线程。

随后的请求会重用线程B并对日志记录请求进行排队吗？

是的，但不能保证它会是同一条线。定时器将从池中创建一个线程。注:只有一个线程将同时存活。

当到达queueLimit时会发生什么？

取决于你的配置。默认情况下，它将在默认情况下丢弃，如上文所述。见检查溢出/队列设置。就内存和CPU而言，这是最安全的选择。您可以选择丢弃、阻塞(停止主线程)或增长队列(通过了解内存使用情况)。

额外的线程B1 ..。开始了吗？(这将淹没连接池)

1号定时器，1个线程池。有关详细信息，请查看定时器的MSDN页面或参考源。