This repository has been archived by the owner on Nov 3, 2023. It is now read-only.
Designing the input configuration #20
jasonrhodes
started this conversation in
General
Replies: 1 comment
-
agree with option B @jasonrhodes. is there anything we need to be aware from the agent side to implement this correctly? AFAICT, once we write a shared config struct for assets it should 'just work'? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We discussed this in another repo and came up with the following examples.
Previously Specified Options
There are multiple ways how behind the scene asset collection can be implemented (cloudbeat, metricbeat, assetbeat, inputs v2). No matter the implementation, the elastic agent configs for asset collection should always look the same. This issue is to discuss how the config should look like.
Config proposals
The following is a list of potential options to get the discussion started.
A) Single asset input
A single input is configured to collect assets and with it the types of assets that should be collected:
B) Input per collection target
An input is created per collection target. The assumption is, that this target has shared configuration options like access key / secret for AWS, simliar for k8s.
This also allows configs to collect all assets by default:
C) Input per asset
Each asset collection has an input specified:
Personal preference
My personal preference is with B as it is a good middle ground. It allows to share connection configs in an easy way and to still specify
*
patterns to collect all assets (not possible with C).There is a good chance that not all assets should be collected with the same frequency. This leads to a config as following:
My ideal scenario is that eventually there is a subscribe mechanism for asset changes which means
period
becomes obsolete.Examples
Here's a more complete config example, mostly drawing from Option B above, with some inline questions about how we might want to adjust. I've shown some credentials examples here based on what I see in existing AWS integrations, just for example's sake.
I started an example of the other options, e.g. Option C:
Beta Was this translation helpful? Give feedback.
All reactions