.NET Core API Serilog-ELK VS logstash / fluentd

1. зачем мне логсташ | fluentd, могу ли я напрямую отправлять журналы в ELK, используя приемник serilog в моем API?
2. Если я отправлю с помощью serilog sing на ELK напрямую, что произойдет, если соединение с ELK прервано? он сохранит временно и повторно отправит?

Вопрос 2 отвечает на вопрос 1 здесь. У FluentD есть проверенный в боевых условиях механизм буферизации для устранения сбоев в работе ELK. Более того, вы не хотите использовать поток приложения для решения задачи, совершенно не связанной с доставкой журналов приложения. Это усложняет ваше приложение и снижает переносимость.

1. Я читал в статье, в которой говорится, что FluentD использует постоянную очередь, а Logstash - нет, но зачем именно эта очередь нужна? скажем, если у моего приложения есть 1 файл журнала, и он обновляется каждую секунду. Итак, logstash отправляет весь файл в ELK каждую секунду? даже если это не удается, он может повторно отправить мой файл журнала в ELK, верно? Итак, зачем нужна постоянная очередь для сравнения Fluentd / logstash.

Верный. У FluentD есть буфер https://docs.fluentd.org/configuration/buffer-section. Он отправит все, что пришло за период времени, который вы установили в match (здесь буфер используется для накопления журналов за период времени). Если бэкэнд журнала (ELK) не работает, он продолжит сохранять в буфере неудачные записи журнала. В зависимости от размера буфера это может справиться с довольно серьезными сбоями серверной части журнала. Как только серверная часть журнала (ELK) снова будет запущена, все буферы будут отправлены в нее, и вы ничего не потеряете.

постоянная очередь Logstash - похожий механизм, но они пошли дальше и после буфера в памяти добавили внешние очереди, такие как Kafka. FluentD также является может использовать очередь, когда вы используете kafka ввод / вывод, и у вас все еще есть буфер поверх этого на случай, если Kafka выйдет из строя.