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

[Observability] New "No Data" screens #107709

Merged
merged 102 commits into from
Oct 6, 2021
Merged

Conversation

cchaos
Copy link
Contributor

@cchaos cchaos commented Aug 4, 2021

Observability work for #107682

APM -- Split to new PR #111630

Historical context

Adds logic to dynamically show the no data screen on APM.

  • A new API was created GET /api/apm/has_data which looks if there is any data available in the APM indices.
  • Removed the hasHistoricalData from the services API.
  • Removed the old empty message that was located inside the service inventory page.
  • Added API tests

When there is no data:
Screen Shot 2021-09-08 at 13 28 14

When there is data:
Screen Shot 2021-09-08 at 13 30 26

Originally posted by @cauemarcondes in cchaos#31


✅ Getting Started -- Split to new PR #111803

Historical context Screen Shot 2021-08-16 at 16 34 58 PM

✅ Overview -- Split to new PR #111803

Historical context Screen Shot 2021-08-16 at 16 38 27 PM

Logs @afgomez (Closes #111386)

Screenshot Screen Shot 2021-08-16 at 16 21 44 PM

Uptime @shahzad31 / @justinkambic -- Split to a new PR #112403

Historical context - [x] Logic based on `const { data } = useSelector(indexStatusSelector)` - [x] `learn more` url: [`core.docLinks.links.observability.guide`](https://www.elastic.co/guide/en/kibana/master/observability.html) - [x] `Add data` url: `/app/home#/tutorial/uptimeMonitors` Screen Shot 2021-08-16 at 15 59 59 PM

User Experience -- Split to new PR #111866

Historical context Screen Shot 2021-08-16 at 15 42 47 PM

✅ Observability Metrics @afgomez (closes #111387)

  • Logic based on const { metricIndicesExist } = useContext(Source.Context); which currently doesn't take into account the default metrics index
  • learn more url: core.docLinks.links.observability.guide
  • Add data url: /app/home#/tutorial/metrics
Screenshot Screen Shot 2021-08-16 at 16 29 17 PM

Checklist

Delete any items that are not applicable to this PR.

@cchaos cchaos added the WIP Work in progress label Aug 4, 2021
Copy link
Contributor Author

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

Observability: cc @jasonrhodes

I've made PR comments where I need help getting/checking the logic. The locations where the new page contents is passed to the template is the best location I have found for each of the Obs solutions as it should prevent the render of any subsequent pages and can be the entire page (with still showing the solution navigation).

The next thing we'd like to tackle is getting the top menu bar's Add Data buttons going to the right places and possibly also displaying the right content when there's no data. But that does not have to be this PR.

x-pack/plugins/infra/public/pages/logs/page_template.tsx Outdated Show resolved Hide resolved
Comment on lines 35 to 40
const { metricIndicesExist } = useContext(Source.Context);
const noDataConfig: KibanaPageTemplateProps['noDataConfig'] = metricIndicesExist
? undefined
: {
solution: 'Observability',
pageTitle: 'Set up Metrics for Observability!',
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Metrics

Copy link
Member

Choose a reason for hiding this comment

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

I think you can use:

const { metricIndicesExist } = useSource();

and just import useSource instead of Source from that same file.

But they both seem to be doing the same thing. @simianhacker @neptunian could you just confirm that this will correctly return whether metrics indices exist at this point in the app?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks like useSource requires a parameter of sourceId.
Screen Shot 2021-08-12 at 11 11 46 AM

Copy link
Member

Choose a reason for hiding this comment

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

OK ... interesting. I'm not sure how it works the way you're doing it, then, but if it does, great!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, that's what I want to confirm. 😆

Copy link
Member

Choose a reason for hiding this comment

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

@weltenwort if you have a minute can you help me confirm whether this context access is expected to work without designating the source ID? I don't want to tell Caroline to "just use 'default' here" because that seems bad, but I wasn't able to figure out how we are supposed to interact with this...

x-pack/plugins/uptime/public/routes.tsx Outdated Show resolved Hide resolved
@snide
Copy link
Contributor

snide commented Aug 9, 2021

@gchaps We'll need some help for UI text on this one. Specifically the difference between using Integrations with Agent vs. using Beats on their own.

The core differences:

  • Integrations with Agent provide a continuous system that auto-upgrades related assets (like dashboards).
  • Fleet provides orchestration of Agents for easier central management and dedicated policies for data ingestion
  • An agent is installed once (per server), with the integrations being one-click installs on top of agent beyond it.
  • Beats require a separate Beat to be installed for every integration.
  • Integrations with Agents through Fleet is our longer term future.

The reasons not to go with Integrations with Agent right now are:

  • The integrations (in Observability) is not yet GA
  • Beats may provide some functionality that the Fleet system does not yet provide (yet)

From our designs we'll be using cards to show off the choice. The only difference per solution would be the suggested method (which would hinge on whether the related integration is GA). I'd like to distill these two cards into a short sentence.

Use beats when...
Use Integrations with Agent when...

Yell if you need more context.

@gchaps
Copy link
Contributor

gchaps commented Aug 9, 2021

@dedemorton, @bmorelli25 Can you please look at the the request for text on the Beats and Elastic Agent cards?

I'd prefer we didn't use "Confused on which to use?". I'd rather the text give in the card give enough info and then include just the link "Check our docs for more information".

Setup Beats > Set up Beats

@shahzad31
Copy link
Contributor

@elasticmachine merge upstream

@snide
Copy link
Contributor

snide commented Oct 5, 2021

@elasticmachine merge upstream

@snide
Copy link
Contributor

snide commented Oct 6, 2021

@elasticmachine merge upstream

Jest tests passed locally after a merge. 🎲

@shahzad31
Copy link
Contributor

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
infra 966 965 -1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
infra 938.7KB 938.0KB -670.0B
observability 355.2KB 355.2KB +13.0B
uptime 569.1KB 569.1KB -36.0B
total -693.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
kibanaReact 94.1KB 94.2KB +37.0B

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@snide
Copy link
Contributor

snide commented Oct 6, 2021

@snide snide added the auto-backport Deprecated - use backport:version if exact versions are needed label Oct 6, 2021
Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

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

Reviewed locally. Looks good. Merging this since we've had trouble with tests and now have green. Set the auto-backport flags.

@snide snide merged commit 74da7d3 into elastic:master Oct 6, 2021
@kibanamachine
Copy link
Contributor

💔 Backport failed

Status Branch Result
7.x Commit could not be cherrypicked due to conflicts

To backport manually run:
node scripts/backport --pr 107709

snide added a commit that referenced this pull request Oct 6, 2021
* [Observability] New "No Data" screens (#107709)

Adds empty states for all of Obs that lead to their various ingest flows.

* merge conflicts

* Fix missing DTS addition to template

Co-authored-by: Caroline Horn <549577+cchaos@users.noreply.github.com>
Co-authored-by: cchaos <caroline.horn@elastic.co>
@cchaos cchaos deleted the design/add_data_screens branch October 19, 2021 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated - use backport:version if exact versions are needed release_note:enhancement Team:APM All issues that need APM UI Team support Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability v7.16.0 v8.0.0 WIP Work in progress
Projects
None yet