Generate PDF report not working in Kibana

Elastic Stack Kibana
1

Hi,
I am trying to generate the PDF report from Kibana dashboard but I end up getting the warning
'The "open URL" phase took longer than 60 seconds. You may need to increase "xpack.reporting.capture.timeouts.openUrl"

I ran the reporting diagnostics from the Reporting paging and got the below error.

image
image918×770 46.3 KB

Am I missing any configuration?
Why does the error in run diagnostics points to 'https://0.0.0.0:5601/kibana' although I have the setup in Kubernetes?
Kindly help
Kibana version - 7.17.3

2

Hi @pranay_jain

By default in Kibana's settings there is a timeout of 120s and if kibana is "overloaded" the time will not be enough to generate the reports. Therefore, these errors occur. You can increase the amount of memory in kibana, to have a "slack" in the workload or increase the timeout that can take several minutes for Kibana to generate the reports.

To increase the timeout just go to the kibana.yml configuration file and edit the property: xpack.reporting.queue.timeout

Reporting settings in Kibana | Kibana Guide [8.2] | Elastic

3

Hi @grfneto ,
I tried increasing the timeout but I still get the same error.
I noticed from the logs that it is tried to connect to https://0.0.0.0/kibana

'Chromium received a non-OK response (500) for request https://0.0.0.0:5601/kibana/s/myspace/app/management/insightsAndAlerting/reporting/r?forceNow=2022-05-27T12%3A00%3A24.186Z"'

I fail to understand why it is looking at localhost, could this be the reason for the failure?

4

Dear Kibana Support Team
is there any reply to this message from pranay_jain? why is that looking at localhost? is that the reason of the failure?

5

@pranay_jain it looks like the error is, the Reporting plugin is not able to open the given URL which should load the dashboard for a PDF snapshot. The reason it's not able to open the URL is, "too many redirects"

  • Which version of Kibana are you using?
  • Do you have any xpack.reporting.server.* settings in your configuration? (Hopefully, you will not need any of them.)
  • Do you have server.basePath and/or server.rewriteBasePath in your configuration?

I have found an issue with getting PDF reports when deploying Kibana with Kubernetes, with the given documentation from Elastic on Kibana deployments: [Reporting] Document how to make screenshot reports work in ECK · Issue #131100 · elastic/kibana · GitHub.

There aren't any required settings to make PDF reports work, but it's possible that you have settings you don't need - if possible, please provide the settings I mentioned above, or your entire settings, if that is easier.

I guess this is because you have server.basePath in your settings (/kibana), but server.rewriteBasePath is not enabled - this means a proxy is required to rewrite the basePath and make requests compatible with where Kibana expects requests to come from. On the Kibana side, its intention is to make a direct request to the Kibana web server from the context of running a browser on the same server. The browser tries to open server.host. This technique tends to work fine, unless there is an indirect path that is required to be taken to Kibana. The browser can't open the URL, because the URL expect requests to come in through your proxy.

The most likely solution is to set server.rewriteBasePath: true, and then update your proxy's deployment configuration for the endpoint to not have a rewrite rule to modify the base path.

If you have any xpack.reporting.server.* settings, you do not need them if Kibana is rewriting requests to use the base path you want. The only things you'll want to do with deploying Kibana in Kubernetes with the intention to use PDF reports, is to make sure there is plenty of RAM in the system, and that Kibana isn't hogging all of the system's RAM. I think I explain that in the issue I mentioned.

Hope that helps

6

Hi @tsullivan , indeed the issue was related to proxy. We wanted to connect to Kibana via proxy. I was able to fix this problem by specifying the proxy address using property xpack.reporting.kibanaServer.hostname. Thank you for your help !

1 Like
7

Glad this worked for you. I didn't suggest using this as the first line of resolving this, because that setting is very "touchy." In my experience, it introduced a whole new category of problems, such as unknown DNS, unverifiable SSL, etc. But I am glad it works for you. :slight_smile:

8

What should be the appropriate CPU when I set the memory to 8Gi ? I have set it to 4 and it is working well.
Also under resources we have limits and requests. Should the 'cpu' and 'memory' be same?

resources:
    limits:
       cpu: 4
       memory: 8Gi
    requests:
       cpu: 4
       memory: 8Gi
9

Also under resources we have limits and requests. Should the 'cpu' and 'memory' be same?

Hi, you should use the CPU limits that work and that you are comfortable with for your environment. I don't think you need a requests section, unless you are doing benchmarking. I recommend sticking to as many defaults as possible and tweaking only what needs to be changed to have things work well.

10

Hi @tsullivan, Thank your for your response.
I was following this document where it is specified that 'to minimize disruption caused by Pod evictions due to resource contention, you can run Pods at the "Guaranteed" QoS level by setting both requests and limits to the same value'.
Am I missing something?

11

Hi, it looks like you've found the right documentation.

If it's working well with 4GB, it sounds like you are good to go.

12

@tsullivan Thank you very much !

13

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.