Регистрация приложений с помощью стека ELK

Question

Использование NLog с Elasticsearch target для пересылки журналов в AWS Elasticsearch as a Service кластер для визуализации в Кибане.

Это работает нормально, но я заинтересован в том, чтобы использовать его в процессе производства из-за доступности кластера ES и последствий отказоустойчивости кластера, когда журналы отправляются с использованием elasticsearch-net client через HTTP.

Я рассматриваю возможность использования другой цели для NLog, которая отправляет журналы в более надежный пункт назначения (файл, S3?), А затем имеет что-то другое (Logstash, AWS Lambda), забирает их и отправляет их в ES, таким образом минимизации рисков для самого приложения.

хотел бы услышать ваши мысли

UPDATE

основной проблемой является наличие приложений и предотвратить недостающие журналы используется вторичная цель.

Использование последних значений NLog и throwExceptions установлено в false и не использует асинхронные цели на данный момент, но учитывая это, поскольку у нас много асинхронного кода.

Чтобы дать немного больше контекста, «приложение» представляет собой набор API (WebAPI и WCF), которые получают 10 - 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> 

Q:

• , что происходит с главным потоком, когда цель не может быть достигнута?

Случай 2 - NLog с целевым асинхронным

Использованием асинхронной обертки для elasticsearch мишени с queueLimit = "10000" BATCHSIZE = "100"

В:

• является еще одним поток [B] создан?
• будет выполнять последующие запросы повторно использовать поток [B] и ставить очереди на запросы регистрации?
• Что происходит, когда достигается очередь queueLimit?
• будет запущен дополнительный поток [B1 ... Bn]? (это будет пул подключений)

Answer 1

Хороший вопрос.

Не о чем беспокоиться, но правильная настройка NLog важна.

Не уверен, что должно быть надежным, запустив программу или не потерять сообщение журнала, так и для тех случаев:

• Если вы боитесь, если вы потеряете некоторые сообщения журнала

  • Написать для нескольких целей (из NLog), например Файл и Elasticsearch.
  • Дополнительно используйте fallbackgroupwrapper (в случае ошибки при записи к цели)
  • Если асинхронный включено, check the overflow/queue settings - отбрасывать включен по умолчанию (для защиты от ЦП или перегрузки памяти)

• Если вы боитесь, что регистрация может нарушить ваше приложение:

  • Используйте последнюю стабильную версию NLog (4,3)
  • не включайте throwExceptions (отключено г efault)
  • Если вы включите async, ошибки будут записаны в цель в другом потоке, чтобы он не смог сломать ваше приложение.
  • Также при использовании async, check the overflow and queue settings

Update

В идеале это должны быть отдельные вопросы StackOverflow;)

Случай 1,

, что происходит с май n, когда цель не может быть достигнута?

Ничего. Основные очереди сообщений в буфере. Другой поток (Timer) обрабатывает эти сообщения. Если это не удастся, и throwException не включен, во внутренний журнал (если он включен) будут записаны только ошибки. Все исключения будут пойманы. Вы потеряете сообщение, если запись на целевую страницу не удалась.

Случай 2,

является другой поток [B] создано?

Один Timer будет создан. Это создаст поток для обработки сообщения.

последует запрос на повторное использование потока [B] и очереди запросов на регистрацию?

Да, но нет гарантии, что она будет той же нитью. Таймер создаст поток из пула. NB: только один поток будет активен одновременно.

Что произойдет, когда достигнут queueLimit?

В зависимости от конфигурации. По умолчанию он будет отбрасываться по умолчанию, как указано выше. См. check the overflow/queue settings. Это самый безопасный вариант с точки зрения памяти и процессора. Вы можете отказаться, заблокировать (остановить основной поток) или увеличить очередь (узнав об использовании памяти).

Будет ли запущен дополнительный поток [B1 ... Bn]? (это будет пул подключения пула)

№ 1 Таймер, 1 threadpool. Для получения дополнительной информации проверьте MSDN page for Timer или reference source.