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

Simplify exporting dashboards for Devs #7730

Merged
merged 2 commits into from
Nov 20, 2018
Merged

Conversation

ruflin
Copy link
Member

@ruflin ruflin commented Jul 25, 2018

A new mage command is introduced to simplify exporting dashboards and contributing them to Beats. Currently a contributor is required to know about folder hierarchy under which dashboards are stored and are versioned. To simply this a simple mage command is provided:

MODULE=mysql ID=the-dashboard-id mage ExportDashboard

The Dev must provide the module he wants to export the dashboard for and the dashboard id. The script will take care of extracting it from Kibana, creating directories and files. The current script only supports to export dashboards from localhost:5061 as no params are provided to change the host at the moment. Also this change is only for Metricbeat for now. Filebeat should also be added.

Additional changes:

  • Create directories
  • Pass module and dashboard id
  • Add exit code 1 in case of export failure
  • Improve error handling

@ruflin ruflin added in progress Pull request is currently in progress. :Dashboards :Infra labels Jul 25, 2018
@ruflin ruflin requested a review from andrewkroh July 25, 2018 09:42
@@ -96,6 +98,27 @@ func Fields() error {
return mage.GenerateFieldsYAML("module")
}

func ExportDashboard() error {

Choose a reason for hiding this comment

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

exported function ExportDashboard should have comment or be unexported

"github.com/magefile/mage/sh"
)

func ExportDashboard(id, path string) error {

Choose a reason for hiding this comment

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

exported function ExportDashboard should have comment or be unexported

@ruflin
Copy link
Member Author

ruflin commented Jul 25, 2018

@andrewkroh My first time creating a mage target. Questions:

  • Should there also be a make command for this or is it ok to only have mage?
  • Is the way I execute the command the recommended way?

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.

My approach so far has been to:

  • Create ExportDashboard(params ExportDashboardArgs) in dev-tools/mage.
  • Create an ExportDashboardArgs struct with all the available parameters to control the behavior.
  • Provide a DefaultExportDashboardArgs that returns a ExportDashboardArgs object initialized with the defaults (including reading the env vars, see mage.EnvOr). This it's still possible to override params programmatically if need be.
  • Update each magefile.go to use the new common method.
    func ExportDashboards() error { return mage.ExportDashboards(mage.DefaultExportDashboardsArgs()) }

dev-tools/cmd/dashboards/export_dashboards.go Outdated Show resolved Hide resolved
dev-tools/cmd/dashboards/export_dashboards.go Outdated Show resolved Hide resolved
metricbeat/magefile.go Outdated Show resolved Hide resolved
metricbeat/magefile.go Outdated Show resolved Hide resolved
metricbeat/magefile.go Show resolved Hide resolved
@ruflin
Copy link
Member Author

ruflin commented Jul 27, 2018

Unfortunately in this case I think there are no defaults. Do we have a way to make certain ENV variables required? Similar to EnvOr but EnvRequired?

Do you add all magefile commands to the Makefile or would it be ok to have new commands only in mage?

@andrewkroh
Copy link
Member

Do you add all magefile commands to the Makefile or would it be ok to have new commands only in mage?

No, my goal is just to not break the existing Makefile targets and interface that people depend on. I think we can add mage targets and iterate on them.

Do we have a way to make certain ENV variables required? Similar to EnvOr but EnvRequired?

Not at the moment. And I'm not sure we should. The underlying function that consumes the params would still need to validate them any way. So I'd opt for using EnvOr("MY_VAR", "") then validating the incoming args and returning an informative error message.

@ruflin ruflin added review and removed in progress Pull request is currently in progress. labels Aug 29, 2018
@ruflin
Copy link
Member Author

ruflin commented Aug 29, 2018

@andrewkroh Could you have a look again?

docs/devguide/newdashboards.asciidoc Outdated Show resolved Hide resolved
dev-tools/mage/dashboard.go Outdated Show resolved Hide resolved
dev-tools/mage/dashboard.go Outdated Show resolved Hide resolved
dev-tools/mage/dashboard.go Outdated Show resolved Hide resolved
dev-tools/mage/dashboard.go Outdated Show resolved Hide resolved
metricbeat/magefile.go Show resolved Hide resolved
@ruflin ruflin added the in progress Pull request is currently in progress. label Oct 18, 2018
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.

There's a compile issue, but besides that LGTM. This seems worthy of a note in the developer changelog.

dev-tools/mage/dashboard.go Outdated Show resolved Hide resolved
}

// TODO: This is currently hardcoded for KB 6, we need to figure out what we do for KB 7
file := filepath.Join(beatsDir, BeatName, "module", module, "_meta/kibana/6/dashboard", id+".json")
Copy link
Contributor

Choose a reason for hiding this comment

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

How does this work with dashboards at locations like https://github.com/elastic/beats/tree/master/heartbeat/monitors/active/http/_meta/kibana/6/dashboard ?

Should those move to this new simpler pattern?

Copy link
Member Author

Choose a reason for hiding this comment

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

It doesn't at the moment. We should probably make the path a config param which each beat can set, so it also work here (follow up PR).

Copy link
Member

Choose a reason for hiding this comment

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

For the output file you don’t want to use a path that is relative to the ElasticBeatsDir because this won’t work for community beats or x-pack beats. Instead use CWD() or just leave it as a relative path assuming the tool this is being passed to does the write thing and writes the output based on the CWD that it was executed from.

So in short, use file := CWD(“module”, module, “_meta/kibana/6/dashboard”, id+”.json”).

@andrewkroh
Copy link
Member

x-pack/filebeat/magefile.go would benefit from this new command. Can you please add it there too.

I think this is looking good. We should get it merged soon.

@ruflin
Copy link
Member Author

ruflin commented Nov 9, 2018

Did rebase and quickly run it locally but exited with 1. Need to investigate what changed.

A new `mage` command is introduced to simplify exporting dashboards and contributing them to Beats. Currently a contributor is required to know about folder hierarchy under which dashboards are stored and are versioned. To simply this a simple `mage` command is provided:

```
MODULE=mysql ID=the-dashboard-id mage ExportDashboard
```

The Dev must provide the module he wants to export the dashboard for and the dashboard id. The script will take care of extracting it from Kibana, creating directories and files. The current script only supports to export dashboards from localhost:5061 as no params are provided to change the host at the moment. Also this change is only for Metricbeat for now. Filebeat should also be added.

Additional changes:

* Create directories
* Pass module and dashboard id
* Add exit code 1 in case of export failure
* Improve error handling
@ruflin ruflin removed the in progress Pull request is currently in progress. label Nov 15, 2018
@ruflin
Copy link
Member Author

ruflin commented Nov 15, 2018

@andrewkroh Should be ready for an other round of review. Tested now locally and works.

@ruflin
Copy link
Member Author

ruflin commented Nov 15, 2018

@andrewkroh I tried to add it to x-pack filebeat and it the export worked. But it seems as BeatsDir it takes the one from the OSS Filebeat and puts the data there. I wonder if this is a general issue with the magefile?

I suggest for now we skip this and get this in to then iterate on top of it.

@andrewkroh
Copy link
Member

@ruflin I see the problem that would prevent you from using it in x-pack and left a comment on how to fix it. Should be a simple fix.

@kvch
Copy link
Contributor

kvch commented Nov 16, 2018

If this is merged my PR needs an rebase: #9097
This is a somewhat othogonal change in functionality, but we touch the same files.

@ruflin
Copy link
Member Author

ruflin commented Nov 19, 2018

@andrewkroh I tried it with your adjustement in the code. It keeps working in OSS but for x-pack it still creates the data in OSS. I would prefer to rather get this PR in as is and get it improved in a follow up PR, especially as this conflicts with the work from @kvch .

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.

I'm good with merging it in its current state. And then have it fixed for x-pack/*beat in a follow-up PR.

@ruflin ruflin merged commit 1cbd201 into elastic:master Nov 20, 2018
@ruflin
Copy link
Member Author

ruflin commented Nov 20, 2018

@kvch Merged. You can rebase your PR on top of it now. In case you plan to backport your PR, should we backport this one too to 6.x?

@ruflin ruflin deleted the export-dashboard branch November 20, 2018 06:32
@kvch
Copy link
Contributor

kvch commented Nov 20, 2018

I think we can backport it along with the follow-up PR with the fix. But TBH I don't see as much value of this improvement on 6.x than on master. Devs would run it on master or on a branch from master, then backport the dashboards they have exported to 6.x.

@ruflin
Copy link
Member Author

ruflin commented Nov 20, 2018

@kvch Ok, leave it up to you to decide if you will need this in 6.x or not.

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.

5 participants