This behavior can be bypassed by providing <charm>/files/kibana.tgz
payload prior deployment. The given payload will be used, without any
checksum verification, and unpacked to /srv/kibana4.

Configuration

listens only on localhost:5601. uses rinetd to redirect ip-addr:80 to localhost:5601.
This should allow for haproxy etc to be used in front.
Could configure apache reverse proxy in front if you want SSL / .htaccess

Other

supports multiple ES servers in cluster. This should help with balancing the load on ES and dealing with failure.

see logstash-indexer charm's README.md file for usage examples.

Deploy / Add Dashboards

The Kibana charm ships with a action to deploy dashboards into
the Kibana instance. You will however, have to have them loaded into the charm
before the user deploys it, which means a pull request to the upstream charm to
include you're awesome dashboard for everyone!

For example, to deploy the included 'beats' dashboard with < Juju 2.0:

juju action do kibana/0 load-dashboard dashboard=beats

For 2.0 +

juju run-action kibana/0 load-dashboard dashboard=beats

This invokes the action, which in turn looks in the 'dashboards' directory for$DASHBOARD_NAME/load.sh

Which is the repository layout adopted by Elasticsearch for their own dashboards.
to include your own, simply make a directory, a mirror the launch.sh script to
curl to your elasticsearch instance (by default: localhost:9200 will work as its
proxying the connection to your ES cluster) and it will declare any indexes
as well as load any dashboard JSON definitions you include. For more information
consult the dashboards/beats/load.sh script.

Space-separated list of Elasticsearch visualization dashboards to
load on deployment. Dashboards must exist in 'dashboards' directory
and contain a load.sh script to populate into Elasticsearch.
The only dashboard currently supported out-of-the-box is "beats".