Adds an option to the cdk-base role to not automatically start fluentbit on instance start
How to test
Create a recipe using this role with start_fluentbit: false in the custom variables. Does the instance automatically start sending logs, or does it wait for a command (either from a logged in dev or the user data script) to start?
What is the value of this?
Currently if you want or need to add extra fluentbit config at instance start time (ie. in user data script) you must systemctl restart td-agent-bit.service, which means that the cloud-init logs up to that point will be resent from the start, meaning some logs are sent twice! If instead we never add the start-fluentbit script, we can start it when we have the full config in place, and still benefit from devx-logs!
Have we considered potential risks?
Is a user of this option has a user data script that fails before it reaches a step which starts td-agent-bit.service, no logs will ever be shipped from that instance. This is called out in the README, and feels like an acceptable risk since users have explicitly opted into the behaviour, presumably to customise log shipping behaviour.
What does this change?
Adds an option to the cdk-base role to not automatically start fluentbit on instance start
How to test
Create a recipe using this role with
start_fluentbit: falsein the custom variables. Does the instance automatically start sending logs, or does it wait for a command (either from a logged in dev or the user data script) to start?What is the value of this?
Currently if you want or need to add extra fluentbit config at instance start time (ie. in user data script) you must
systemctl restart td-agent-bit.service, which means that the cloud-init logs up to that point will be resent from the start, meaning some logs are sent twice! If instead we never add the start-fluentbit script, we can start it when we have the full config in place, and still benefit fromdevx-logs!Have we considered potential risks?
Is a user of this option has a user data script that fails before it reaches a step which starts
td-agent-bit.service, no logs will ever be shipped from that instance. This is called out in the README, and feels like an acceptable risk since users have explicitly opted into the behaviour, presumably to customise log shipping behaviour.Testing