[Response Ops][Reporting] Scheduled Reports - Task (merging into feature branch)

[ymao1]

Towards #216313

Note

This PR will be merged into a feature branch

Summary

This PR adds the scheduled_report task, which generates reports on a recurring cadence.

• maxConcurrency of this task is 1 so only one can run at a time
• this task shares concurrency with the existing report:execute task, so only one of either task type can run at a time
• this task requires an API key to run so it will only run when ES security and API keys are enabled and a permanent encryption key for Kibana is set
• when the task runs, it creates a new ReportSource document in the .kibana-reporting index that stores the final base64 encoded generated output. This ReportSource matches the data model of existing reports with the addition of a scheduled_report_id field which links to the scheduled report saved object ID.

Verify

• Use the dev console to schedule some reports.
• Verify the the reports get generated at the expected cadence
• Verify that the correct time range is used for each scheduled report

Note, the UI has not been updated to differentiate between scheduled and single run reports. They will look the same from in the report listing, except the scheduled report will have a timestamp appended to the report name.

In the cloud deployment for this PR, we have an example scheduled report that is running every day at 4:45 EDT: https://kibana-pr-219770.kb.us-west2.gcp.elastic-cloud.com/app/management/insightsAndAlerting/reporting

[elasticmachine]

⏳ Build in-progress, with failures

• Buildkite Build
• Commit: f3efd5a
• Cloud Deployment

Failed CI Steps

• FTR Configs #37
• FTR Configs #37

Test Failures

• [job] [logs] FTR Configs #37 / console app misc console behavior keyboard shortcuts open documentation should open documentation when Ctrl+/ is pressed
• [job] [logs] FTR Configs #37 / console app misc console behavior keyboard shortcuts open documentation should open documentation when Ctrl+/ is pressed

History

• 💚 Build #301110 succeeded 4ca09af
• 💛 Build #299874 was flaky ea37895
• 💛 Build #299433 was flaky 9a7bda6
• 💛 Build #299078 was flaky e20f1bf
• 💚 Build #299027 succeeded 4a4e0c5

[pmuellr]

Took me a bit to figure out, so saving for posterity. curl command to schedule the web logs dashboard to generate a report every hour:

curl $KB_URL/internal/reporting/schedule/printablePdfV2 \
  -H "kbn-xsrf: foo" \
  -H "x-elastic-internal-origin: kibana" \
  -H "content-type: application/json" \
  -d '
{
  "jobParams":"(browserTimezone:America/New_York,layout:(dimensions:(height:2220,width:1335),id:preserve_layout),locatorParams:!((id:DASHBOARD_APP_LOCATOR,params:(dashboardId:edf84fe0-e1a0-11e7-b6d5-4dc382ef7f5b,preserveSavedFilters:!t,timeRange:(from:now-7d/d,to:now),useHash:!f,viewMode:edit))),objectType:dashboard,title:LogsWebTraffic)",
  "schedule": { "rrule": { "freq": 3, "interval": 1, "byhour": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23] } }
}
'

[pmuellr]

I tried creating a scheduled report in a non-default space, via my incantation above, but with a /s/test prefix, and saw the following logged when the report finally ran:

[ERROR][plugins.reporting.runTask] Error: Saved object [scheduled_report/ebcfc3e8-13ad-405c-b486-66b4bcc5ea0e] not found
    at Function.createGenericNotFoundError (saved_objects_error_helpers.ts:259:28)
    at performGet (get.ts:73:36)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at SavedObjectsRepository.get (repository.ts:371:12)
    at RunScheduledReportTask.prepareJob (run_scheduled_report.ts:44:24)
    at Object.run (run_report.ts:443:15)

I actually referencede a dashboard that WASN'T in this space, which I realized later, so I wouldn't have expected it to actually generate a report. But it looks like it had a problem loading the scheduled report saved object.

[pmuellr]

Given the error I saw, mentioned in the comment above, I noticed it did NOT get retried. I think this is by design, but probably something we want to figure out, since it sometimes happens that a retry will get the search indices warmed up to get a long-running report to succeed after an initial failure.

[ymao1]

I tried creating a scheduled report in a non-default space, via my incantation above, but with a /s/test prefix, and saw the following logged when the report finally ran:

Good catch! Updated to be space aware in 1f46d45

[ymao1]

Given the error I saw, mentioned in the comment above, I noticed it did NOT get retried. I think this is by design, but probably something we want to figure out, since it sometimes happens that a retry will get the search indices warmed up to get a long-running report to succeed after an initial failure.

Yea, we typically don't perform retries for recurring tasks so there's no built in retry. I think we'd have to update task manager to allow retries for recurring tasks if we want that ability. I can open an issue to discuss

[pmuellr]

Yea, we typically don't perform retries for recurring tasks so there's no built in retry. I think we'd have to update task manager to allow retries for recurring tasks if we want that ability. I can open an issue to discuss

Ya, let's open an issue. Given Tim's previous note that "subsequent attempts often succeed", I think we'll have to do something. Doesn't seem like a blocker to get the basic function out. Wondering if we'd just want to do an "inline retry" of these, which would complicate the task itself, but not require any new tasks, or changes to TM ...

[ymao1]

Ya, let's open an issue. Given Tim's previous note that "subsequent attempts often succeed", I think we'll have to do something. Doesn't seem like a blocker to get the basic function out. Wondering if we'd just want to do an "inline retry" of these, which would complicate the task itself, but not require any new tasks, or changes to TM ...

Issue: #222079

[pmuellr]

LGTM, was able to generate PDF reports as usual in default and a test space, as well as schedule a report in both spaces, and have them run successfully.

[pmuellr]

I wonder if this could be confusing in the future, since it returns either a scoped or internal client. And complicates the typing (minor concern). Would it be better to have separate methods? It seems pretty obvious to me in the code, right now ...

[ymao1]

Split into separate functions in ad65b91

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: ad65b91
• Cloud Deployment

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/reporting-common	90	93	+3

Async chunks

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

id	before	after	diff
fleet	1.7MB	1.7MB	+252.0B

Page load bundle

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

id	before	after	diff
reporting	49.7KB	49.9KB	+194.0B

Unknown metric groups

API count

id	before	after	diff
@kbn/reporting-common	100	103	+3

History

• 💛 Build #303439 was flaky 035d994
• 💔 Build #303399 failed a3ed61d
• 💚 Build #302662 succeeded 3955376
• 💚 Build #302071 succeeded d60bbff
• 💚 Build #301395 succeeded 4750222

cc @ymao1