Kibana 4 unattended configuration of default index pattern?


Today configuration is often managed by software (Chef, Ansible, etc.) with zero human interaction. Configuring Kibana4's required default index pattern on first install, however, seems to be intended to require human attendance. Is there a reason why?

We do not want to require a human to be present, and the configuration file does not seem to allow for specifying a default index pattern, so we have been forced to use an init.d script which does this:

ensure_default_index_pattern() {
        local lock_file="${KIBANA_DIR}/default_index_pattern_is_defined.lock"
        local url_prefix="http://localhost:9202/elasticsearch"
        local index_pattern_url="${url_prefix}/.kibana/index-pattern/logstash-*?op_type=create"
        local ping_url="${url_prefix}/.kibana/config/4.0.2"
        local config_url="${url_prefix}/.kibana/config/4.0.2/_update"
        local curl_params="--include --silent --retry 5 --retry-delay 3 --write-out %{http_code}\n --output /dev/null"
        [[ -f "$lock_file" ]] && return

        set -e
        echo -n "Creating index pattern... "
        curl $curl_params -X POST "${index_pattern_url}" -d '{"title":"logstash-*","timeFieldName":"@timestamp","customFormats":"{}"}'

        echo -n "Setting index pattern as default... "
        curl $curl_params -X POST "${config_url}" -d '{"doc":{"doc":{"buildNum":6004,"defaultIndex":"logstash-*"},"defaultIndex":"logstash-*"}}'

        # put a lock file to tell us it's done
        echo "The presence of this file indicates Kibana4 has initialized the default index pattern" > $lock_file
        set +e

Is there a better way?

(Mark Walkom) #2

We are working on making this process easier and will be releasing automated deployment of Kibana via puppet and other config management tools in the near future.
To assist in this there will also be packaged versions of Kibana (deb/rpm).

I don't have a timeframe though sorry!


Good to hear it's in the works - thanks!

(Ade Miller) #4

@mpavlov Thanks for the example code! This is a huge deal for us too. Especially as in order to break up dashboards (not indexes) by groups of users we look like we will have to install many kibana instances, each with a different default.

(Phil Scala) #5

yeah I too was faced with this, my solution (workaround) is similar to yours, I am writing directly to the .kibana index , essentially, in Ansible I will end up doing something like this in a post deploy task:

curl -XPUT http://<es node>:9200/.kibana/index-pattern/events-* -d '{"title" : "events-*",  "timeFieldName": "EventTime"}'
curl -XPUT http://<es node>:9200/.kibana/config/4.1.1 -d '{"defaultIndex" : "events-*"}'

I don't really want to be writing to that index but I also did not want to use the Kibana HTTP flows...So I am interested doing this in a more supported manner.

(Tanya Bragin) #6

You may want to comment on this Github issue, if this is important to you:

Deploying Kibana indexes, searches, visualization and dashboard in production
(Cătălin Liviu Vrînceanu) #7


Thanks for the info. I found in logs few java errors because the buildNum was removed.
For Kibana 4.1 and elasticsearch 1.7.3 I use:

curl -XPUT http://localhost:9200/.kibana/config/4.1.3 -d '{"buildNum":7601, "defaultIndex":"logstash-*"}'


(Rajeev) #8

Hi Phil,

I am having the issue so can you tell me How can I add index programmatically in kibana in C#.


FWIW, seems this issue will be fixed with Kibana 5.0.

(Gunay) #10

Is the following line preventing Kibana to show dublicate data? If not, what is its function? Thanks.

local index_pattern_url="${url_prefix}/.kibana/index-pattern/logstash-*?op_type=create"

(system) #11