Зіткнувся з ситцією і питанням на новому проекті – Fluentd how to exclude some logs, що Fluentd налаштовано за замовченням (default configuration) – що пересилає геть усі логи до OpenSearch, це створювало додаткове зайве навантаження
Після деякого аналізу з’ясувалось що до логів потрапляє занадто багато “шлаку”, тобто того – що ніким не аналізується і не цікавить, наприклад записи стосовно kubernetes-external-secrets, для вирішення цього питання мені прийшлось винести конфіг Fluentd в окрему конфігурацію та вимкнути конфігурацію за замовченням. Маючи певний конфігурацію – на базі якого terraform генерував шаблон, зробив зміни у тому шаблоні, а саме додав відключення default configs:
|
1 2 3 4 5 6 7 |
configMaps: useDefaults: containersInputConf: false systemInputConf: false forwardInputConf: false monitoringConf: false outputConf: false |
Після цього додав дефолтні конфіги зі своїми правками через extraConfigMaps:
|
1 2 3 4 5 6 |
extraConfigMaps: containers.input.conf: |- <source> @id fluentd-containers.log @type tail ..... |
Щоб зробити exclude для певних записів, потрібно використовувати плагін фільтрації grep, який має у своєму арсеналі параметр exclude
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<filter kubernetes.**> @type grep <and> <exclude> key $.kubernetes.container_name pattern ^kubernetes-external-secrets$ </exclude> <exclude> key $.stream pattern ^stdout$ </exclude> </and> </filter> |
Ми створили фільтр, до якого під’єднали плагін grep, далі через конструкцію об’єднання <and></and> додав два правила, які знаходять в логах поле kubernetes.container_name зі значенням kubernetes-external-secrets та в цьому ж повідомленні перевіряють що stream=stdout ця конструкція говорить Fluentd що не потрібно ці логи відправляти та обробляти.
Важливо зазначити, що неможна використовувати два рази один і той самий key, бо це буде викликати конфлікт конфігурації.
