[BB-1312] - Pulling in upstream helm chart

Updating chart/ to be based off of the upstream helm chart provided by fluent: https://github.com/fluent/helm-charts/blob/master/charts/fluent-bit/

addresses #2 (closed)

added 1 commit

• 11be5e9a - feat: Consuming upstream fluent chart

Compare with previous version

mentioned in issue #2 (closed)

marked this merge request as ready

added 1 commit

• 744b3dbf - refactor: Adjusting pod tpl variables

Compare with previous version

added 1 commit

• 110934df - refactor: Updating values for filter options

Compare with previous version

added 1 commit

• cc4992c6 - refactor: pod tpl machine-id for non k3s clusters

Compare with previous version

added 1 commit

• 97fa708a - refactor: Removing values for apiserver vers

Compare with previous version

added 1 commit

• 2e017854 - feat: Consuming upstream fluent chart

Compare with previous version

added 1 commit

• 6d6f0ff6 - feat: Consuming upstream fluent chart

Compare with previous version

changed the description

assigned to @kavitha

changed the description

marked this merge request as draft

added 1 commit

• 30800b54 - chore: kpt get from upstream for fresh pull

Compare with previous version

Ish, can you check this out?

assigned to @iahmad

Will be deploying in a test env, later today. Will let you guys know what I find.

@ryan.j.garcia what are your thoughts on adding

## Prevent fluent from picking up its own logs
Exclude_Path      /var/log/containers/*fluent*.log

Is there a reason we wouldn't want those in ES+Kibana? I can see both ways why we could leave it or why we shouldn't include them.

hmmm i've always seen the following fluentd config:

    ## Ignore fluentd own events
    <match fluent.**>
      @type null
    </match>

to prevent an infinite loop of fluent erroring on something, then picking up on its own log errroring on something, and getting caught in a loop. But I think that would only happen if fluentbit is throwing an error in which case it most likely isn't successfully writing out to ec + kibana. Or maybe fluentbit handles this differently all together?

I believe it is handled differently, that config you mentioned is fluentD and fluentbit may have built in logic to handle that as it's not included in any of their recommended configurations.

I deployed this successfully with no issues. Externalizing the config via the values.yaml helped make this chart more extensible and usable. LGTM

marked this merge request as ready

approved this merge request

mentioned in merge request !8 (closed)

changed the description

mentioned in commit 92e2001b

merged