-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Monitoring] Metricbeat Migration Wizard (last step!!) #45799
[Monitoring] Metricbeat Migration Wizard (last step!!) #45799
Conversation
…fferent in setup mode
Pinging @elastic/stack-monitoring |
💔 Build Failed |
This is not how it works now, but I can understand the desire for this. It is an inconsistent experience for the users now. I think we can solve it two ways:
I personally lean towards the first option as it feels less restrictive for the user - they don't have to worry about leaving set up mode to go and look up some monitoring data. I'm curious to thoughts from @elastic/stack-monitoring |
Nice catch. Fixed 906c254 |
Yes, this is a good point. We are currently using the term What about something like Also, are we adding complexity/confusion by using the term |
I really like "Self Monitoring" personally over "internal collection". I think it's far more self-explanatory to users than internal collection but I think we might want to include an explainer tooltip or something anyway?
I think this would actually be more confusing since a user can have internal collection with
++ to this. Again, we (the developers on the team) know that where the collection happens from is one of the things that has changed between internal collection and Metricbeat collection. However, it's not the only change (also being able to ship directly to the Monitoring cluster is the other change) AND collection is just one part of the overall monitoring process. As far as a user is concerned I agree that we should try and avoid the term "collection" and use "monitoring" (and its variants) instead. |
To be clear, I had said the placement is not ideal. That you could consider moving it to a button somewhere on the Overview page which would be better placement but then the button wouldn't be visible on all pages. This might be alright though. |
Yeah, in the interest of moving this PR forward I'm alright with the way it is now. We can always tweak it later in a follow up PR. Mostly I wanted to confirm that this wasn't a TODO item still meant to be addressed in this PR, which sounds like it isn't. |
💚 Build Succeeded |
++ to using ++ to using I'll review this text and look for this change. |
Both are these are now done -> 05279cf |
💚 Build Succeeded |
This looks ready to go at this point from my perspective. Great work, @chrisronline ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@chrisronline Not sure if you were expecting to hear from others about #45799 (comment), but I'm okay with the current behavior for now. As you outlined there are pros/cons to either approach so I'm good with shipping the current behavior and adjusting based on feedback.
Great job, not just on this final PR (which had reviews from multiple people and took a lot of iterations) but on the Setup UI as a whole. I'm very happy that we can provide this to our users to aid Metricbeat migration today and do other potential setup tasks in the future!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't look like any of my concerns here cause problems: https://github.com/elastic/kibana/pull/45799/files/d86ebba8ba9cfc453770955ce3ed07bca3d332d9, so I'm going to go ahead and approve.
Nice work 🥇
I agree with @chrisronline that the first option is the better one. |
💚 Build Succeeded |
* Enable setup mode UI toggles * We want to keep the no data page but update the copy * More updated copy * Remove manual checks for logstash, beats, apm and kibana * Hide the setup mode controls on the no data page. There is nothing different in setup mode * Setup mode test * Fix bug with disabling internal collection for ES * First steps towards the redesign of setup mode * Consolidate UI code, design changes, use constants defined in our plugin * Fix tooltips * Design/copy feedback * Use badge and onClick * More feedback * Only detect usage on the live cluster * Fix existing tests, remove test that will be added in other PR * Fix failing test * Fix issue with wrong callout showing * Ensure we check for live nodes if no cluster uuid is provided * We need a custom listing callout for ES * Custom callout for kibana instances * More space from the bottom bar * Disable switching if they enabled internal collection * Copy updates * Fix broken tests * Fix more tests * Fix i18n * Update copy * Fix a couple i18n issues * Fixing a couple of missing scenarios * Fix translations * Update snapshots * PR feedback * PR feedback * We also need totalUniqueInternallyCollectedCount to identify when we have detected products but they are not monitored (thinking ES and Kibana) * Remove why documentation link until we have the resource available * Ensure tabs are properly disabled * Address issue with the ES nodes callout not working at times * Ensure we check if setup mode is enabled * Change internal collection to self monitoring, and remove the word 'collection' usage * Only show Enter setup mode on pages with valid setup mode options * Copy updates * Copy updates * Ensure we update the top nav item when we toggle setup mode on or off
Backport: 7.x: 8751538 |
This PR is the culmination of work specified in #39010
It adds the actual UI to enable and disable setup mode, along with various bug fixes and design/copy updates.
This also changes the
/no-data
page to start recommending users to set up Monitoring with Metricbeat:The one thing this PR will not have is the tests that go along with this code. I don't want to bloat this PR review with a bunch of test files, but I will open a separate PR with the tests (which are already written) to ensure those go in as well.
The biggest thing for this PR is to really hammer home the testing aspect. This is our last chance to make sure this migration is air-tight and our messaging/design is clear and well understood.
There will continue to be iterative changes in this PR, as we get more feedback from design and tech writers on clearer ways of expressing our intent.