FluentD Aggregator - Quand utiliser?

Question

Nous envisageons d'utiliser FluentD pour envoyer les événements du journal Blue Coat des serveurs dhcp proxy & à élastique. L'une des principales exigences est de signaler les anomalies & anomalies dès que possible.

Pour une telle exigence est-il logique d'utiliser FluentD Aggregator prendre à des événements de plusieurs (potentiellement des centaines) d'agents collecteurs FluentD? Alternativement, est-il préférable que les agents FluentD envoient des événements à un cluster Kafka qui écrit sur Elastic?

sera vraiment utile si je peux obtenir des lignes directrices pour le moment d'utiliser FluentD Aggregator.

Merci, Sharod

Answer 1

Généralement parlant, il y a 2 cas communs.

1 - Lorsque vous avez besoin d'utiliser plusieurs plugins pour les filtres 2 - pour un débit d'étranglement service de destination/db/etc ...

Plugins pour le filtre consomme beaucoup de performance. Cela signifie qu'il peut affecter un serveur qui génère un journal. Donc, fluentd sur le serveur devrait faire un travail minimum, qui transfère un journal à un agrégateur ou Kafka ou quelque chose.

Autre cas d'utilisation, si vous avez besoin de réécrire des configs parfois, vous n'avez pas besoin de redémarrer tout fluentd sur le serveur, si vous utilisez les filtres dans des serveurs agrégés.

2 - En général, un service externe/DB a beaucoup de limitations à jour/insérer des données à son stockage. Si beaucoup de fluentd essaie d'écrire des données fréquemment, ils montreront facilement n'importe quelle exception. Afin d'éviter un tel cas, un agrégateur doit être utilisé.