Installed X-Pack on Kibana 5.3.2 running on CentOS 7.3.
Reporting successfully generates PDFs. But the PDFs are one A4 page, with only about 1/3 of actual column headings, entry delimiters (horizontal lines), and absolutely no data.
Furthermore, the column headings only go as far as the width of the A4 PDF (about 1/3 of the columns in the Saved Search, remainder (about 2/3) are chopped.
Is this normal behavior for X-Pack Reporting?
hi
This is definitely not the normal behavior for x-pack reports. I have 5.3.2 on my local ( MacOSX) I was not able to reproduce your issue. My reports were delivered in full. It would be good to check the ES and Kibana logs and also attach a screenshot of your issue, would be helpful to give more info.
Thanks
Rashmi
Attached is an example of what any report I try to generate looks like:
no text content, goes about 1/4 of the way in terms of column headings.
A sanitized view of one of nine hits that I attempted to report looks as
follows:
@GJahchan is this a new CentOS 7.3 server, and if so would you mind explaining your installation method and environment? We've had another customer report the same issue with CentOS 7.3 but are having issues replicating this behavior to investigate what might be going wrong.
This is almost certainly a missing, usable font issue. It's manifested in other ways for other users, and it's a recurring issue with CentOS and RHEL.
@GJahchan Can you try installing the open sans font package on the machine that's running Kibana? The package should just be called open-sans-fonts, and you can use yum to install it.
If that doesn't fix it, we've had success internally with the google-roboto-mono-fonts package too, so try installing that next. As a last resort, some others have had success just doing yum install -y gnu-free-*.
I am on CentOS 7.3 indeed.
Installed open-sans-fonts and gnu-free-* fonts. This has resolved the issue of text content not printing.
The report is limited to about half an A4 page, the number of columns is limited to what fits on an A4 page, and the number of rows to about 5 1/2 entries.
Sanitized screenshot of PDF Report:
@GJahchan I'm glad to hear that installing those fonts resolved the issue that you were experiencing! Currently, all generated PDFs are optimized for that A4 page size; however, we have some improvements in the pipeline that will allow you to include all the content in the PDF.
As it stands, these reports are pretty much useless. Will the improvements you mention find their way into 5.3.2?
Generating a Print to PDF from Google Chrome results in usable PDF output (just specify A0 format, no headers/footers).
PDF is formatted, and useful for relaying a message but cannot be utilized for further analysis.
May I suggest reporting to comma separated values for tabular information (.csv). It can further be processed using powerful Unix command line tools, or imported into a spreadsheet for further analysis.
May I suggest reporting to comma separated values for tabular information (.csv). It can further be processed using powerful Unix command line tools, or imported into a spreadsheet for further analysis.
This is exactly what we're intending to do; however, it's currently targeted at 6.0
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.
