docker-library / kibana Goto Github PK

View Code? Open in Web Editor NEW

106.0 18.0 112.0 193 KB

DEPRECATED; https://github.com/docker-library/official-images/pull/15808

Home Page: https://www.elastic.co/guide/en/kibana/current/_pulling_the_image.html

License: Apache License 2.0

Shell 78.30% Dockerfile 21.70%

kibana's Introduction

https://github.com/elastic/kibana

Maintained by: the Elastic Team

This is the Git repo of the Docker "Official Image" for kibana (not to be confused with any official kibana image provided by kibana upstream). See the Docker Hub page for the full readme on how to use this Docker image and for information regarding contributing and issues.

The full image description on Docker Hub is generated/maintained over in the docker-library/docs repository, specifically in the kibana directory.

See a change merged here that doesn't show up on Docker Hub yet?

For more information about the full official images change lifecycle, see the "An image's source changed in Git, now what?" FAQ entry.

For outstanding kibana image PRs, check PRs with the "library/kibana" label on the official-images repository. For the current "source of truth" for kibana, see the library/kibana file in the official-images repository.

Build	Status	Badges	(per-arch)

kibana's People

Contributors

Stargazers

Watchers

Forkers

infosiftr gerardorochin bossjones czerasz jfindley mistsys naag jefflaplante zerocoolys jeremymturner tebriel greyhawk patrickmslatteryvt garyelephant instedd montge hi15r visity sfossen rchicoli j782700885 cloudxtreme containersolutions tymate wangchenshu ne4l4ng sporty actionsperminute hstack tc0208 myoung34 descrepes nodeintegration jy4618272 nearit f3rdy castroarguello ind3x alino topecz spidercpsf travel-syndication-technology nidcode konduruvijaykumar harishaws lukasz-bielinski yunier-org butterhc iganari jihoshin fighterld sixeyed thanhson1085 condevops cspnanda sype perfectmemory faithlife hongchhe mandycoston visaxin shailaja183 pmayer harryge00 hlorenzoz dxawnw kleopatra999 avisri chenjun3092 bnulwh cmp1234 adyekjaer longquan7 dingbb calinah dliappis ethan-2017 raymoneyan anishanil ngzerone c3c1l13 jethr0null chengfuyi86 vishu77 bhanditz haotianya wwpigc kakada lx096 shanzemin kxion takas12 jinx-heniux isabella232 gopi54 terrorizer1980 sibuvilakazi desintegrators seanpm2001 appscode-images

kibana's Issues

Documentation provides a link that does NOT exist

The below URL provides a link that is incorrect

https://github.com/docker-library/kibana/blob/014d49e819ccf947882b6c9c809f62896f534dae/6/Dockerfile

Please see line 11

For Elasticsearch documentation visit https://www.elastic.co/guide/en/kibana/reference/current/docker.html

gi

This image is officially deprecated in favor of the kibana image provided by elastic.co which is available to pull via docker.elastic.co/kibana/kibana:[version] like 5.2.1. This image will receive no further updates after 2017-06-20 (June 20, 2017). Please adjust your usage accordingly.

Elastic provides open-source support for Kibana via the elastic/kibana GitHub repository and the Docker image via the elastic/kibana-docker GitHub repository, as well as community support via its forums.

Hi, I run this kibana/kibana:7.0.0 but "Kibana server is not ready yet"

expose 5601 is OK with this image?

Kibana docker instance stops running

I need help/advice in debugging this issue. I start a kibana docker instance and it runs fine for a few days. But then it stops running and I am not sure how to debug this issue.

sudo docker logs kibana has this:

{"type":"log","@timestamp":"2015-11-14T08:49:15+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T08:50:15+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T08:50:30+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T08:51:05+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T08:51:08+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T08:52:56+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T08:53:40+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T08:55:39+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T08:55:42+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T08:59:30+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T08:59:33+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T09:00:18+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T09:00:22+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T09:04:30+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T09:04:33+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T09:08:07+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T09:08:10+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T09:09:37+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T09:09:40+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T09:10:45+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T09:10:48+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-14T09:13:20+00:00","tags":["status","plugin:elasticsearch","error"],"pid":1,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 1500ms","prevState":"green","prevMsg":"Kibana index ready"}
{"type":"log","@timestamp":"2015-11-14T09:13:24+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 1500ms"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:kibana","info"],"pid":1,"name":"plugin:kibana","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"yellow","message":"Status changed from uninitialized to yellow - Waiting for Elasticsearch","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:kbn_vislib_vis_types","info"],"pid":1,"name":"plugin:kbn_vislib_vis_types","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:markdown_vis","info"],"pid":1,"name":"plugin:markdown_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:metric_vis","info"],"pid":1,"name":"plugin:metric_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:spyModes","info"],"pid":1,"name":"plugin:spyModes","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:statusPage","info"],"pid":1,"name":"plugin:statusPage","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:table_vis","info"],"pid":1,"name":"plugin:table_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["listening","info"],"pid":1,"message":"Server running at http://0.0.0.0:5601"}
{"type":"log","@timestamp":"2015-11-16T19:01:38+00:00","tags":["status","plugin:elasticsearch","info"],"pid":1,"name":"plugin:elasticsearch","state":"green","message":"Status changed from yellow to green - Kibana index ready","prevState":"yellow","prevMsg":"Waiting for Elasticsearch"}

I looked at the ElasticSearch container logs:

[2015-11-10 22:05:42,556][INFO ][node                     ] [Googam] version[2.0.0], pid[1], build[de54438/2015-10-22T08:09:48Z]
[2015-11-10 22:05:42,558][INFO ][node                     ] [Googam] initializing ...
[2015-11-10 22:05:42,660][INFO ][plugins                  ] [Googam] loaded [], sites []
[2015-11-10 22:05:42,808][INFO ][env                      ] [Googam] using [1] data paths, mounts [[/usr/share/elasticsearch/data (/dev/vda1)]], net usable_space [32.7gb], net total_space [39.2gb], spins? [possibly], types [ext4]
[2015-11-10 22:05:46,067][INFO ][node                     ] [Googam] initialized
[2015-11-10 22:05:46,087][INFO ][node                     ] [Googam] starting ...
[2015-11-10 22:05:46,212][INFO ][transport                ] [Googam] publish_address {192.168.180.45:9300}, bound_addresses {192.168.180.45:9300}, {[fe80::42:c0ff:fea8:b42d]:9300}
[2015-11-10 22:05:46,223][INFO ][discovery                ] [Googam] elasticsearch/Z05hfVF5RfOVQ2TPL6RZRg
[2015-11-10 22:05:49,309][INFO ][cluster.service          ] [Googam] new_master {Googam}{Z05hfVF5RfOVQ2TPL6RZRg}{192.168.180.45}{192.168.180.45:9300}, reason: zen-disco-join(elected_as_master, [0] joins received)
[2015-11-10 22:05:49,375][INFO ][gateway                  ] [Googam] recovered [0] indices into cluster_state
[2015-11-10 22:05:49,381][INFO ][http                     ] [Googam] publish_address {192.168.180.45:9200}, bound_addresses {192.168.180.45:9200}, {[fe80::42:c0ff:fea8:b42d]:9200}
[2015-11-10 22:05:49,382][INFO ][node                     ] [Googam] started
[2015-11-10 22:06:01,463][INFO ][cluster.metadata         ] [Googam] [.kibana] creating index, cause [api], templates [], shards [1]/[1], mappings [config]
[2015-11-10 22:06:10,307][INFO ][cluster.metadata         ] [Googam] [.kibana] deleting index
[2015-11-10 22:06:10,862][INFO ][cluster.metadata         ] [Googam] [jenkins_build_output] creating index, cause [api], templates [], shards [1]/[0], mappings [build_output]
[2015-11-10 22:06:11,391][INFO ][cluster.metadata         ] [Googam] [.kibana] creating index, cause [api], templates [], shards [1]/[0], mappings [index-pattern, visualization, search, config, dashboard]
[2015-11-10 22:06:12,421][INFO ][rest.suppressed          ] /.kibana/config/4.2.0 Params: {index=.kibana, op_type=create, id=4.2.0, type=config}
[.kibana][[.kibana][0]] DocumentAlreadyExistsException[[config][4.2.0]: document already exists]
    at org.elasticsearch.index.engine.InternalEngine.innerCreateNoLock(InternalEngine.java:411)
    at org.elasticsearch.index.engine.InternalEngine.innerCreate(InternalEngine.java:369)
    at org.elasticsearch.index.engine.InternalEngine.create(InternalEngine.java:341)
    at org.elasticsearch.index.shard.IndexShard.create(IndexShard.java:517)
    at org.elasticsearch.index.engine.Engine$Create.execute(Engine.java:789)
    at org.elasticsearch.action.support.replication.TransportReplicationAction.executeIndexRequestOnPrimary(TransportReplicationAction.java:1073)
    at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:170)
    at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryPhase.performOnPrimary(TransportReplicationAction.java:579)
    at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryPhase$1.doRun(TransportReplicationAction.java:452)
    at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
[2015-11-10 22:15:10,739][INFO ][cluster.metadata         ] [Googam] [jenkins_build_output] create_mapping [build_event]
[2015-11-10 22:23:43,953][INFO ][cluster.metadata         ] [Googam] [.kibana] deleting index
[2015-11-10 22:23:45,002][INFO ][cluster.metadata         ] [Googam] [.kibana] creating index, cause [api], templates [], shards [1]/[0], mappings [index-pattern, visualization, search, config, dashboard]
[2015-11-10 22:53:28,989][INFO ][cluster.metadata         ] [Googam] [.kibana] deleting index
[2015-11-10 22:53:30,240][INFO ][cluster.metadata         ] [Googam] [.kibana] creating index, cause [api], templates [], shards [1]/[0], mappings [index-pattern, visualization, search, config, dashboard]
[2015-11-12 16:52:36,310][INFO ][cluster.metadata         ] [Googam] [.kibana] deleting index
[2015-11-12 16:52:37,304][INFO ][cluster.metadata         ] [Googam] [.kibana] creating index, cause [api], templates [], shards [1]/[0], mappings [index-pattern, visualization, search, config, dashboard]

Basically, there is no action after 11/12. And both containers are running on the same host and the kibana instance is linked to the elasticsearch instance.

Also, here is the output for sudo docker images:

REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
jenkins_master      latest              99783f1cb836        8 days ago          768.4 MB
elasticsearch       latest              8112755253f1        2 weeks ago         345.2 MB
jenkins             latest              5da1f62066bc        2 weeks ago         707.3 MB
kibana              latest              e2d1404d4133        2 weeks ago         260.1 MB
nginx               latest              914c82c5a678        2 weeks ago         132.7 MB

I have had to start kibana instance a couple of times now. I don't think I encountered this issue in the previous version. And also I am not sure where else to look into why kibana instance stops running.

Any advice/help would be greatly appreciated.

Thanks.

Kibana plugins

Since ES 2.0, kibana supports plugins (and needs it, if one wants to keep using marvel).

Has any thought gone into how to tackle that with the docker container?

For now I'm starting kibana container, then exec'ing kibana plugin -i $whatevs on that container and restarting the container, but there must be a more elegant approach.

Perhaps adding some functionality to the docker-entrypoint that takes a list from env and checks if plugin has been installed and if not installs it on startup?

Specifying Elasticsearch URL without docker run -e

I'm using Kubernetes to define my containers which means I don't use the docker run command. I am trying to have Kubernetes set the environment variable in the container but it still doesn't start up properly. I also didn't get it to work by just mounting a file into the config directory.

Here's the error I've been getting:

{"name":"Kibana","hostname":"kibana-rc-3iatx","pid":1,"level":50,"err":
{"message":"Service Unavailable","name":"Error","stack":"Error: Service Unavailable\n
    at respond (/opt/kibana/src/node_modules/elasticsearch/src/lib/transport.js:235:15)\n
    at checkRespForFailure (/opt/kibana/src/node_modules/elasticsearch/src/lib/transport.js:203:7)\n
    at HttpConnector.<anonymous> (/opt/kibana/src/node_modules/elasticsearch/src/lib/connectors/http.js:156:7)\n
    at IncomingMessage.bound (/opt/kibana/src/node_modules/elasticsearch/node_modules/lodash-node/modern/internals/baseBind.js:56:17)\n
    at IncomingMessage.emit (events.js:117:20)\n
    at _stream_readable.js:944:16\n
    at process._tickCallback (node.js:442:13)"},"msg":"","time":"2015-11-20T21:14:39.777Z","v":0}

{"name":"Kibana","hostname":"kibana-rc-3iatx","pid":1,"level":60,"err":
{"message":"Service Unavailable","name":"Error","stack":"Error: Service Unavailable\n
    at respond (/opt/kibana/src/node_modules/elasticsearch/src/lib/transport.js:235:15)\n
    at checkRespForFailure (/opt/kibana/src/node_modules/elasticsearch/src/lib/transport.js:203:7)\n
    at HttpConnector.<anonymous> (/opt/kibana/src/node_modules/elasticsearch/src/lib/connectors/http.js:156:7)\n
    at IncomingMessage.bound (/opt/kibana/src/node_modules/elasticsearch/node_modules/lodash-node/modern/internals/baseBind.js:56:17)\n
    at IncomingMessage.emit (events.js:117:20)\n
    at _stream_readable.js:944:16\n
    at process._tickCallback (node.js:442:13)"},"msg":"","time":"2015-11-20T21:14:39.779Z","v":0}

What's the best way to go about this?

Docker ES and Kibana won't connect localhost

I run my docker images like such:

docker run -d -v "$PWD/esdata":/usr/share/elasticsearch/data -p 9200:9200 -p 9300:9300 elasticsearch

and

docker run -e ELASTICSEARCH_URL=http://localhost:9200 -p 5601:5601 -d kibana

When I test Elastic:

http://localhost:9200/_cluster/health
{
  "cluster_name": "elasticsearch",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 0,
  "active_shards": 0,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100
}

When I check Kibana:
Unable to connect to Elasticsearch at http://localhost:9200.

Kibana container stopped working after upgrading to 4.2.1 from 4.2.0

docker logs shows only this:

fs.js:565
fs.write = function(fd, buffer, offset, length, position, callback) {
                                                 ^
Error: EACCES, permission denied '/opt/kibana/optimize/.babelcache.json'
    at Error (native)
    at Object.fs.openSync (fs.js:500:18)
    at Object.fs.writeFileSync (fs.js:1099:15)
    at save (/opt/kibana/node_modules/babel-core/lib/api/register/cache.js:35:19)
    at process._tickDomainCallback (node.js:381:11)
    at Function.Module.runMain (module.js:503:11)
    at startup (node.js:129:16)
    at node.js:814:3

Kibana Docker image should ship with "optimized code"

When starting a freshly pulled Kibana image from the registry, we get the following message:

{"type":"log","@timestamp":"2016-01-27T11:03:24+00:00","tags":["info","optimize"],"pid":1,"message":"Optimizing and caching bundles for kibana and statusPage. This may take a few minutes"}
{"type":"log","@timestamp":"2016-01-27T11:03:50+00:00","tags":["info","optimize"],"pid":1,"message":"Optimization of bundles for kibana and statusPage complete in 26.08 seconds"}

Would it be possible to ship the Docker image with this optimization phase already done? This would save some CPU cycles, allow to scale Kibana on new instances faster and allow the deployment inside read-only containers more straightforward.

Kibana does not retry connections.

Hi.

Apparently my elasticsearch is taking too long to start. Kibana does not retry it's connection to elasticsearch.

https://docs.docker.com/compose/startup-order

executable file not found

Hi there,

I'm getting "error: exec: "kibana" executable file not found in $PATH"

Running the container with "docker run -it --name kibana -p 5601:5601 --link elasticsearch kibana"

This is on RHEL 6.7

I have tried on CentOS 6.5 and the container runs successfully.

Docker version 1.7.1

Failed to generate PDF reporting using kibana latest docker

There was an error generating your report for the "STATS" dashboard: HeadlessError: Phantom immediately exited with: 127

Using latest docker both for kibana and for elastic

Ability to set a default dashboard (or really any defaultAppId)

Would there be any way to modify the entrypoint so that it looked for an environment variable containing an alternative default app to run at launch, and modify the kibana.yml file accordingly? The ideal would be to be able to do something along the lines of docker run --name kibana -e DEFAULT_APP_ID="dashboard/my-custom-dashboard" -p 5601:5601 -d kibana and have that work...

Kibana connects to http://localhost:9200 instead of http://elasticsearch:9200 as advertised in documentation

The doc for the image says:

$ docker run --link some-elasticsearch:elasticsearch -d kibana

But then when connecting to Kibana, it complains that it cannot connect to http://localhost:9200.

Adding ELASTICSEARCH_URL=http://elasticsearch:9200 to the environment does the trick.

I don't know if we want to provide that as a default env var, or update the docs, or both, but something has to be done :-)

Unable to detach / terminate

Docker v 1.9.0
Docker Machine v 0.5.0
Kibana image 4.2.1
docker run -p 5601:5601 --link elastic:elasticsearch -v "$PWD"/kibana/config:/etc/kibana/config kibana:4.2.1

It runs and works, but won't respond to Ctrl + C and Ctrl + P, Ctrl + Q. I have to stop the container from a different shell. If I use docker compose, I get an ERROR: Aborting. when stopping it.

kibana red status due to ES Request Timeout

Hello,

I'm running kibana:4.5 docker image on Openshift. It works but after minutes (not always after the same time) I got this message :

{"type":"log","@timestamp":"2017-03-28T13:25:48+00:00","tags":["status","plugin:elasticsearch","error"],"pid":51,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 3000ms","prevState":"green","prevMsg":"Kibana index ready"}

after that this status flaps :

{"type":"log","@timestamp":"2017-03-28T13:25:48+00:00","tags":["status","plugin:elasticsearch","error"],"pid":51,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 3000ms","prevState":"green","prevMsg":"Kibana index ready"} {"type":"log","@timestamp":"2017-03-28T13:26:21+00:00","tags":["status","plugin:elasticsearch","info"],"pid":51,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 3000ms"} {"type":"log","@timestamp":"2017-03-28T13:26:27+00:00","tags":["status","plugin:elasticsearch","error"],"pid":51,"name":"plugin:elasticsearch","state":"red","message":"Status changed from green to red - Request Timeout after 3000ms","prevState":"green","prevMsg":"Kibana index ready"} {"type":"log","@timestamp":"2017-03-28T13:26:55+00:00","tags":["status","plugin:elasticsearch","info"],"pid":51,"name":"plugin:elasticsearch","state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Request Timeout after 3000ms"}

I verified my Elasticsearch cluster and it's up and running, reachable by network, cluster ehealth status green, nothing in the logs.
When I want to access to kibana, I'm directly redirected to the status find, mentionning the red status due to the request Timeout after 3000ms

I tried to increase the timeout > 3000ms by changing elasticsearch.requestTimeout and elasticsearch.pingTimeout in kibana.yaml to find a workaround but it doesn't seem take it into account because the status page still show Request Timeout after 3000ms.

Kibana not connecting to Elasticsearch with username and password

We tried running the container as

docker run -e ELASTICSEARCH_URL='http://a.b.c.d:9200'
                   -e ELASTICSEARCH_USERNAME='elastic' 
                   -e ELASTICSEARCH_PASSWORD='secret!' 
                   -p 127.0.0.1:5601:5601 -d kibana:5.2.0

When we browse Kibana UI we see plugin:[email protected] Authentication Exception

we can reach ES by curl directly just fine

$ curl -u elastic:secret! http://a.b.c.d:9200/_cat/indices?v

Inside container variables are set just fine.

$ docker exec <cont name> bash -c 'echo "$ELASTICSEARCH_URL,$ELASTICSEARCH_USERNAME,$ELASTICSEARCH_PASSWORD"'

http://a.b.c.d:9200,elastic,secret!

But if we look at

$ docker exec <cont name> bash -c 'cat /etc/kibana/kibana.yml'

elasticsearch.url: 'http://a.b.c.d:9200' => this is fine
#elasticsearch.username: "user" . => This is not set
#elasticsearch.password: "pass" . => This is not set

Please support KIBANA_INDEX to allow specify kibana index

Please support KIBANA_INDEX to allow specify kibana index, like:
https://hub.docker.com/r/bobrik/kibana/

This is a very import and common config.

Override any setting in kibana.yml via docker command line or environment variable

I need to change the server.basePath config variable and don't want to write to clone the official repo. Right now only the elasticsearch config can be changed, but I propose to extend the 'sed' to include any variable in kibana.yml. Thanks.

No cleanup is performed - reduce the image size, please.

At least:
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Could not get container for elasticsearch

kibana installation error

While installation of lates version of Kibana, they crashed with following error:
error: exec: "tini": executable file not found in $PATH

run kibana as non-root

Some container hosts don't allow you to run as root (OpenShift):

"Image kibana runs as the root user which might not be permitted by your cluster administrator."

It looks like in the Dockerfile, there is already a Kibana user!

I see that gosu is used to switch to the Kibana user, but it still won't be able to start in unprivileged environments.

ARM missing on 8.11.1

It's there on 8.11.0

dial tcp: lookup index.docker.io on [::1]:53: read udp [::1]:48468->[::1]:53: read: connection refused

When I tried to install x pack to elk using the bellow command I face error as shown bellow, so can you help me with this please.

sudo docker pull danielguerra/elasticsearch-x-pack

Using default tag: latest
Pulling repository docker.io/danielguerra/elasticsearch-x-pack
Error while pulling image: Get https://index.docker.io/v1/repositories/danielguerra/elasticsearch-x-pack/images: dial tcp: lookup index.docker.io on [::1]:53: read udp [::1]:48468->[::1]:53: read: connection refused

Status 404 while fetching image layer (972313908e2a58b09eaefadd73bcfbfb2d416db08e4bb7d95b56cde3d94b8c85)

Getting the following error:

# docker -D pull kibana
Pulling repository kibana
bfd322ebb208: Error pulling image (latest) from kibana, Server error: Status 404 while fetching image layer (972313908e2a58b09eaefadd73bcfbfb2d416db08e4bb7d95b56cde3d94b8c85) dd73bcfbfb2d416db08e4bb7d95b56cde3d94b8c85)
bf84c1d84a8f: Download complete
c68155341966: Download complete
972313908e2a: Error pulling dependent layers
FATA[0013] Error pulling image (latest) from kibana, Server error: Status 404 while fetching image layer (972313908e2a58b09eaefadd73bcfbfb2d416db08e4bb7d95b56cde3d94b8c85)

# docker info
Containers: 4
Images: 4
Storage Driver: devicemapper
 Pool Name: docker-252:3-133516-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 576.1 MB
 Data Space Total: 107.4 GB
 Metadata Space Used: 1.253 MB
 Metadata Space Total: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 3.8.13-26.2.1.el6uek.x86_64
Operating System: <unknown>
CPUs: 1
Total Memory: 3.861 GiB
Name: devkibana.example.com
ID: 6KKR:EGTP:KRJY:LSOD:M4DQ:JOIN:HTV4:F2GV:VXA5:CHO4:DQQ2:SEQ3

# docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

4.1.3 tag not found

Despite the official Docker Hub page saying that 4.1.3 is a supported tag, it doesn't actually appear to exist — it's not listed on the tags page, nor is it in the Github tag details page. Is there a process by which that tag needs to be populated in the hub?

(Given that Elastic is billing this as an important security update, I'd like to be able to update to it...)

support arm64 architecture

I want to build this image on arm64 architecture but I don't found some package support arm64 at https://artifacts.elastic.co/packages/5.x/apt/dists/stable/Release . So I want to know this image whether or not support arm64 architecture.

Export log from kibana container to host machine

Hello All,

I want to change logging for kibana docker.

By default kibana docker writes output to stdout but after changing kibana.yml file , I am changing destination path to location: /var/log/kibana/kibana.log ( I have created folder /var/log/kibana in docker container)

Issue:
If I use root access to folder (/var/log/kibana) I am not able to write logs in this folder. So that I changed permission of this folder to kibana user and I can able to write files to this folder but with kibana user I am not able to mount directory from docker container to my host file system.

Any idea or ideal suggestion to write log files from kibana container to host machine ?

Regards,
Parth

Serving kibana at port 443

I just encountered a problem with running the kibana docker container with port 443.

The only way possible was running kibana with root privileges. This is possible with gosu

`
FROM kibana:4.5.4

RUN chmod o+w /opt/kibana/optimize/.babelcache.json

CMD ["gosu", "root", "kibana"]
`

The chmod was necessary because of this error

`fs.js:549
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^

Error: EACCES: permission denied, open '/opt/kibana/optimize/.babelcache.json'
at Error (native)
at Object.fs.openSync (fs.js:549:18)
at Object.fs.writeFileSync (fs.js:1156:15)
at save (/opt/kibana/node_modules/babel-core/lib/api/register/cache.js:35:19)
at nextTickCallbackWith0Args (node.js:420:9)
at process._tickDomainCallback (node.js:390:13)
at Function.Module.runMain (module.js:443:11)
at startup (node.j

The original error message was
{"type":"log","@timestamp":"2016-10-12T13:52:53+00:00","tags":["fatal"],"pid":12,"level":"fatal","message":"listen EACCES 0.0.0.0:443","error":{"message":"listen EACCES 0.0.0.0:443","name":"Error","stack":"Error: listen EACCES 0.0.0.0:443\n at Object.exports._errnoException (util.js:873:11)\n at exports._exceptionWithHostPort (util.js:896:20)\n at Server._listen2 (net.js:1237:19)\n at listen (net.js:1286:10)\n at net.js:1395:9\n at nextTickCallbackWith3Args (node.js:453:9)\n at process._tickDomainCallback (node.js:400:17)","code":"EACCES"}} FATAL { [Error: listen EACCES 0.0.0.0:443] cause: { [Error: listen EACCES 0.0.0.0:443] code: 'EACCES', errno: 'EACCES', syscall: 'listen', address: '0.0.0.0', port: 443 }, isOperational: true, code: 'EACCES', errno: 'EACCES', syscall: 'listen', address: '0.0.0.0', port: 443 }

Is there a cleaner way to do this?

Install Sense

I'm trying to install the sense plugin with
docker run --name kibana --link elasticsearch:elasticsearch -d kibana -p 5601:5601 --plugin elastic/sense

But when I hit : http://192.168.99.100:5601/app/sense

I got :
{"statusCode":404,"error":"Not Found","message":"Unknown app sense"}

(Also the port the exposing of the port doesn't work, I have to set it up with Kitematic)

kibana:5 service is not exposed outside the container: server.host: localhost

Hi,

I tried to use kibana:5 image, but I can only access it inside the container using wget. Looks like property server.host is commented and by default is localhost, so port-forwarding does not work.

I did this as a workaround:
https://github.com/sysco-middleware/docker-compose-elastic-stack/blob/master/kibana/Dockerfile

I'm wondering if this need to be fixed in the distribution of kibana to make it easier to config from docker command and docker-compose.

5.0.0-alpha3 not available

Not sure if it is correlated with the issue of neo4j, but while elasticsearch is available, Kibana tag is still not.

Forcing linking with Elasticsearch

Hi,

I'm not sure it is a good idea to force the linking of an elasticsearch container. It forces single a point of failure and makes usage of the kibana container hard with clusering tools like mesos.

Why not at least allow to overwrite the ELASTICSEARCH_PORT_9200_TCP variable, instead of forcing the value?

On launch, I now get the following:

"type":"log","@timestamp":"2016-11-14T14:58:13Z","tags":["fatal"],"pid":13,"level":"fatal","message":"EACCES: permission denied, open '/usr/share/kibana/optimize/bundles/monitoring.entry.js'","error":{"message":"EACCES: permission denied, open '/usr/share/kibana/optimize/bundles/monitoring.entry.js'","name":"Error","stack":"Error: EACCES: permission denied, open '/usr/share/kibana/optimize/bundles/monitoring.entry.js'\n    at Error (native)","code":"EACCES"}}

Presumably something to do with the permissions run when the start-up script does not get run with kibana as the only argument?