Reporting: ability to create a report from any Kibana URL

[stacey-gammon]

In order to implement the feature request of creating images server side as part of alerts and actions, we will need this kind of service. It happens to be a goal of the reporting team anyway, since this will create a clear line of responsibilities - apps manage there URLs, reporting just takes a URL and creates an image from it (perhaps with some optional extra info like title, pdf or png, etc).

This feature, along with #25247, would allow for threshold alerts to create a preview of the embeddable it was generated from to do something like:

createThresholdAlert(sourceEmbeddable, alertParameters, alertAction) {
  const previewUrl = directAccessLinkPlugin.getLinkGenerator('embeddableReportingViewer').createLink(sourceEmbeddable.getInput());
  alertAction.attachImageUrl(previewUrl);
}

and if had a chat ops service, it could use this like so:

route.add('api/chatops', (params) => {
  const { command, ...args } = parse(params);
  if (command === 'dashboard') {
    const { dashboardId, filters, query, timeRange } = args;

    // Use the direct access link generator to create a link for the dashboard but in preview mode.
    const previewUrl = directAccessLinkPlugin.getLinkGenerator('dashboardReportPreview').createLink({
      dashboardId, filters, query, timeRange
    });
    const png = await ReportingPlugin.generatePng(previewUrl);

    // Use the direct access link generator to create a link for the main dashboard app page.
    const mainUrl = directAccessLinkPlugin.getLinkGenerator('dashboardApp').createLink({
      dashboardId, filters, query, timeRange
    });

    return { message, image: png, link: mainUrl};
  
  }
}); 

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[tsullivan]

Reporting Services team will provide a way for plugins to generate reports by distributing the load of multiple Kibana instances (aka queueing an immediate task with Task Manager, also used to schedule reports). That should be helpful for environments where Kibana is already distributed to handle large workloads: generating a screenshot is the biggest load you can put onto the Kibana server as far as I know.

There will also be direct access to the function that returns an observable to the screenshot result(s), which developers would be able to access when they aren't concerned with distributing the workload and want the screenshot to just run on the local instance. That might be a better way to go for alerts, when you need the result ASAP.

These ideas have just been slowly guiding the way we've worked on Reporting since we knew we are going to move to using Task Manager and eventually launch Scheduled Reports. I feel like our implementations of PNG and multi-page PDF export have gotten more general, which led to the having functions in our libraries that could be wired out for a public contract exposed by the Reporting plugin.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[tsullivan]

Hi @stacey-gammon can you talk about this issue in a more current context? How important is this for Alerting, or anyone else? Is it blocking anything?

I'm thinking off kicking off refactoring that would break out the screenshot modules in Reporting into a separate plugin that Reporting would depend on. When an alert triggers the need to generate a screenshot, I think it's appropriate to make a screenshot directly, instead of going through the Reporting "queue" where a job is picked up and stores the screenshot in a report. We just need to make sure that Kibana is only running a single headless browser child process at a time, regardless if it called from Alerting or Reporting.

cc @jloleysens @dokmic

[tsullivan]

`const png = await ReportingPlugin.generatePng(previewUrl);`

I don't think we would write it this way, since the png variable isn't a report, it's an actual image. We should allow plugins to programmatically create reports, but that would mean queueing a job that can be downloaded later.

What this sounds like is the need to move the screenshot code and the layout definitions out of Reporting into a new plugin, and have multiple plugins get the ability to create screenshot images.

[tsullivan]

Closing for #116503