Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add appender support to autodiscover #6469

Merged
merged 6 commits into from
Mar 14, 2018

Conversation

vjsamuel
Copy link
Contributor

@vjsamuel vjsamuel commented Feb 26, 2018

Appenders have the ability to append additional info into the configuration. There are two appenders that are part of this PR:

config appender: This appender can append a templatized config into all of the generated configs by either templates or builders and can be used by any Beat.

Sample config:

appenders:
  - type: config
     - condition.equals:
          kubernetes.labels.app: "prometheus"
        config: 
           fields:
             test: success  

kubernetes.token appender: There are endpoints in kubernetes that require bearer token authentication. This appender can add headers.Authorization to a metricset configuration. This can be used to collect metrics from Kube API server.

appenders:
  - type: "kubernetes.token"

@elasticmachine
Copy link
Collaborator

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

Condition *processors.Condition
}

func NewTokenAppender(cfg *common.Config) (autodiscover.Appender, error) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exported function NewTokenAppender should have comment or be unexported

configMaps []configMap
}

func NewConfigAppender(cfg *common.Config) (autodiscover.Appender, error) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exported function NewConfigAppender should have comment or be unexported

@ruflin
Copy link
Member

ruflin commented Feb 27, 2018

jenkins, test it

@exekias
Copy link
Contributor

exekias commented Feb 27, 2018

I'm wondering if this construct should be moved to the module level instead, for a wider usage. As you could need this exact functionality outside autodiscover.

They could add in the same way as processors, where you could define global appenders, scoped to all modules/prospectors, or module specific ones.

WDYT?

@vjsamuel
Copy link
Contributor Author

I thought of the same as well. Any specific thoughts on how it should look?

@ruflin
Copy link
Member

ruflin commented Feb 28, 2018

I definitively think the features we brought to k8s so far can also be useful in a more generic way like mentioned above. I'm wondering if we could go forward with the above implementation for now, mark it as beta, learn from it and then extract it to be also reused in other parts?

@exekias
Copy link
Contributor

exekias commented Feb 28, 2018

The thing is this specific appender would be cool also for some commonly static Metricbeat modules, like kubernetes, prometheus or even http, as it gives them auth inside the cluster.

I could also implement that at the http helper level, and expose the settings only on these modules, but appender interface sounds like the right solution to the problem

@ruflin
Copy link
Member

ruflin commented Mar 4, 2018

@exekias WDYT about moving forward. Getting it in as is and abstract it later or you think that will be tricky?

@vjsamuel
Copy link
Contributor Author

vjsamuel commented Mar 4, 2018

@ruflin i have added experimental tag to all the builders/providers and appenders.

// Merge the template with all the configs
for _, cfg := range cfgs {
cf := common.MapStr{}
err := cfg.Unpack(&cf)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error is not being checked

@exekias
Copy link
Contributor

exekias commented Mar 4, 2018

Ok, let's get this in, we can make it general later

I left just a minor comment

@vjsamuel
Copy link
Contributor Author

vjsamuel commented Mar 5, 2018

@exekias @ruflin done with all review comments.

Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks well done. We need to have some level of documentation for this that explains what it does, when/why to use it, and how to configure it.


appender := r.GetAppender(config.Type)
if appender == nil {
return nil, fmt.Errorf("Unknown autodiscover appender %s", config.Type)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

configMaps []configMap
}

// NewConfigAppender creates a configAppender that can append tempatized configs into built configs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/tempatized/templatized/

cf := common.MapStr{}
err := cfg.Unpack(&cf)
if err != nil {
logp.Debug("config", "unable to unpack config due to error: %v", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these have a higher visibility than Debug? You would know better than me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can be left as is.

var appenders autodiscover.Appenders
for _, acfg := range config.Builders {
if appender, err := autodiscover.Registry.BuildAppender(acfg); err != nil {
logp.Debug("docker", "failed to construct autodiscover appender due to error: %v", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise, should this be at the Info or Warn levels?

@vjsamuel
Copy link
Contributor Author

vjsamuel commented Mar 8, 2018

@andrewkroh i have incorporated review comments.

@andrewkroh
Copy link
Member

Thanks.

Looks like we still need documentation on Appenders.

And since there is config associated with appenders we should have it in the reference config. @exekias How come add_kubernetes_metadata isn't in the reference config?

@vjsamuel
Copy link
Contributor Author

vjsamuel commented Mar 8, 2018

@andrewkroh we talked about the documentation and some consensus needs to be arrived at for the structuring of autodiscover documentation as there are providers, templates, builders and appenders that needs documentation at the moment. i would reserve that for a separate PR.

@andrewkroh
Copy link
Member

andrewkroh commented Mar 8, 2018

I think we could at least document the basics of what it does, when/why to use it, and how to configure it without knowing what the exact final structure will be by adding a new "Appenders" section to the autodiscover topic. If we produce the content our talented technical writers can later shape it and give it more structure.

Basically I dislike adding new features without docs. Sometimes writing the docs even leads you to re-think how something you wrote should work or be configured.

@vjsamuel
Copy link
Contributor Author

vjsamuel commented Mar 8, 2018

Sure thing. Let me add a documentation commit.

@vjsamuel vjsamuel force-pushed the add_autodiscover_appenders branch 3 times, most recently from f315f95 to 46a670f Compare March 12, 2018 05:01
@andrewkroh
Copy link
Member

jenkins, test it

@exekias exekias merged commit 3be3556 into elastic:master Mar 14, 2018
@vjsamuel vjsamuel deleted the add_autodiscover_appenders branch July 25, 2018 06:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants