KibanaでIndex Patternsを作ると、Service Unabailableとなる

表題の通り、IndexPatternを作ろうとすると、Creating index pattern...となるところで Service Unavailableになります。
[Management/Kibana/IndexPatterns]で作成したものを選択しても表示されず、[SavedObjects]で選択して削除するしか方法がなくなります。
ログをみる限り成功しているように見えます。

入れる際に@timestampの調整をしているのですが、それが原因な気がするのですが、同様な状況になった方はいらっしゃいますでしょうか?

Service Unavailable
------
Error: Service Unavailable
    at _callee$ (http://10.23.3.171:5601/bundles/commons.bundle.js:3:426540)
    at tryCatch (http://10.23.3.171:5601/bundles/vendors.bundle.js:29:602784)
    at Generator.invoke [as _invoke] (http://10.23.3.171:5601/bundles/vendors.bundle.js:29:606666)
    at Generator.prototype.(anonymous function) [as throw] (http://10.23.3.171:5601/bundles/vendors.bundle.js:29:603907)
    at step (http://10.23.3.171:5601/bundles/commons.bundle.js:3:423136)
    at http://10.23.3.171:5601/bundles/commons.bundle.js:3:423296
/var/log/elasticsearch/elasticsearch.log
----
[2018-09-06T16:50:11,393][INFO ][o.e.c.m.MetaDataIndexTemplateService] [SCcSKBL] adding template [kibana_index_template:.kibana] for index patterns [.kibana]

時刻をいじる

  • 元データ[09/Aug/2018:09:00:24 +0900]をgrokのmatchで%{HTTPDATE:datetime}で回収
  • date{} で match と target で @timestamp に値を設置
  • elasticsearch上では 2018-08-09T00:00:24.000Z で見えるので、時刻として認識はしているはず。(TimzeZoneがおかしい気がしますが)
logstash.yml
-----
.....
date {
  match => ["datetime", "dd/MMM/yyyy:HH:mm:ss Z"]
  target +> "@timestamp"
}
.....

結果、以下のデータがelasticsearchに入ってる

GET /対象のINDEX/_search?q=*
....
 "hits": {
    "total": 1,
    "max_score": 1,
    "hits": [
      {
        "_index": "対象のINDEX",
        "_type": "doc",
        "_id": "xxxxxxxxxx",
        "_score": 1,
        "_source": {
          "@timestamp": "2018-08-09T00:00:24.000Z",
.....

すみません、Index Patternsに登録しようとしているインデックスのマッピング設定を教えていただくことは可能でしょうか?
GET 対象のINDEX/_mapping

Saved Objectsから選択して削除できるのであれば.kibanaにはIndex Patternを登録できているのかなと思います。
もしかしたら、その登録したIndex PatternのドキュメントをElasticsearchから取得する時か、Kibana上で利用する時にエラーになってしまっているのかもしれません。

1 Like

はじめましてー

問題の原因がどこにあるか把握するため、
一旦時間をいじる部分抜きでIndexを生成してそのIndexを対象にCreating index patternを試してみてはどうですか?

Kibanaが問題なのか、
Logstashの設定で投入したデータがIndex上で問題を起こしてるのかは一旦はっきりさせたほうがよさそうですねー

2 Likes

Nao_Mk2さん、返信ありがとうございます!

マッピング状は @timestamp はdateになっているようです。

  • [08/Aug/2018:01:23:45 +0900]が @timestampだと YYYY-MM-DDT...表示なので、一旦はマッピング自体は問題ないかもしれません。
  • 元データは IBMHTTPServerのaccesslogだったりします。
    • NNN.NNN.NNN.NNN - - [dd/MMM/yyyy:HH:mm:ss +0900] "GET /targetPage.jsp HTTP/1.1" 200 1234

r4-keisukeさんのエントリにも書きますが、@timestamp書き換えなくても同様の状況になるため、timestampの部分が問題では無さそうなことが分かりました。

{
  "ibmhttpd-YYYYMMDD": {
    "mappings": {
      "doc": {
        "properties": {
          "@timestamp": {
            "type": "date"
          },
          "@version": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "auth": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "beat": {
            "properties": {
              "hostname": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              },
              "name": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              },
              "version": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              }
            }
          },
          "bytes": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "clientip": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "fields": {
            "properties": {
              "logtype": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              }
            }
          },
          "host": {
            "properties": {
              "name": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              }
            }
          },
          "httpVersion": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "ident": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "input": {
            "properties": {
              "type": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              }
            }
          },
          "offset": {
            "type": "long"
          },
          "prospector": {
            "properties": {
              "type": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              }
            }
          },
          "request": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "response": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "source": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "tags": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "verb": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          }
        }
      }
    }
  }
}

r4-keisukeさん

@timestampの書き換えをせずにデータを入れた所、ServiceUnabailableでした。
結果として、

  • timestamp以外のところで発生しているらしい
  • elasticsearchには入る(index template未使用)
  • kibanaでは、Index Patternsを作ると Service Unabailableになる
    でした。

現状、elasticsearchにはデータは 恐らく正常に 入っている(_searchで検索はできている?)=logstash的には問題ない?、状況に見えています。

"Logstashの設定で投入したデータがIndex上で問題を起こす"状況の経験がなく、どうやって切り分けたらいいのかがいまいち分からない状態です。。

全体としては以下のようになっていて、elasticsearchまでの登録は問題ないように思えています。
; index templateは後ほど作るつもりです。IPアドレスはIP型(?)にするとか。

grok辺りが間違っている(分割はできてる)のでしょうか。。

  • userIDが%{USERNAME}ではないのは、Windowsのユーザ名が入る(DOMAIN\USERNAME)場合の対策です。

; Forumsであり サポートではないということは理解していますので、何か思いつく点が有れば教えて頂ければ助かります。ほんと、すみません。。


  1. データの入力
123.234.123.234 - - [02/Jun/2018:01:23:45 +0900] "POST /POST_PAGE.jsp HTTP/1.1" 200 12345
  1. filebeatでlogstashに転送

  2. logstashでgrokして、elasticsearchに転送

filter {
    grok {
      match => { "message" => "%{IPORHOST:clientip} (?<ident>[a-zA-Z0-9._\\-]+) (?<auth>[a-zA-Z0-9._\\-]+) \[%{HTTPDATE:datetime}\] \"(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpVersion})?|%{DATA:rawRequest})\" %{NUMBER:response} %{USERNAME:bytes}" }
    }

 if !("_grokparsefailure" in [tags]) {
   date {
     match => ["datetime", "dd/MMM/yyyy:HH:mm:ss Z", "yyyy-MM-dd HH:mm:ss"]
     target => "@timestamp"
   }
   mutate {
     remove_field => ["message","datetime"]
   }
 }
}

output {
  if "_grokparsefailure" in [tags] {
    file {
      path => "/tmp/parseErr-%{fields[logtype]}-%{+YYYYMMdd}.txt"
      codec => line { format => "%{host[name]}: %{message}"}
    } else {
        elasticsearch {
        hosts => ["localhost:9200"]
        index => "test-%{+YYYYMMdd}"
     }
    }
  }
}

  1. KibanaでIndex Patternを作る
  • Time Filter field name: @timestamp
  • Service Unabailable になる。
  1. Elasticsearchには、データはいるみたい
GET test-20180601/_search?q=*

{
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 1,
    "hits": [
      {
...

hogehugaさん

マッピング設定やその他詳細な状況を共有いただき、ありがとうございます。

作成したIndex Patternについて、.kibanaの登録状態を確認してみるのはいかがでしょうか。
エラーがおきてもSaved Objectsから削除できるということなので、.kibanaへの登録は出来ていそうです。

ですので、登録されたドキュメントと正常な場合のドキュメントを比べてみることで、原因の切り分けの参考にならないかなと考えています。
(データ起因でちゃんとIndex Patternが作れていないのか、ドキュメントをKibana側で利用する際に問題が起きているのか 等)

Elasticsearchのバージョンが6以上なら、以下のクエリで確認することができます。

POST .kibana/_search
{
  "query": {
    "term": {
      "type": {
        "value": "index-pattern"
      }
    }
  }
}
.....
"hits": [
  {
    "_index": ".kibana",
    "_type": "doc",
    "_id": "index-pattern:index-pattern-test",
    "_score": 1,
    "_source": {
      "type": "index-pattern",
      "updated_at": "2018-09-07T00:00:00.000Z",
      "index-pattern": {
        "title": "index-pattern-test",
        "timeFieldName": "@timestamp",
.....
1 Like

Nao_Mk2さん

他の正常なIndex Patternとの違いが見えてきました!
今回のデータだと Fields が一切存在していませんでした。

  • Elasticsearch側には、一応ドキュメントが登録されている
  • KibanaのIndex Patternでは、Fieldが登録できていない
POST .kibana/_search

...
      {
        "_index": ".kibana",
        "_type": "doc",
        "_id": "index-pattern:89855c70-b24b-11e8-a8d2-7dc2e4d62374",
        "_score": 1,
        "_source": {
          "type": "index-pattern",
          "updated_at": "2018-09-07T03:10:13.431Z",
          "index-pattern": {
            "title": "test*", 
            "timeFieldName": "@timestamp"
          }
        }
      }
    ]
  }
}

データ的には stdout { codec => rubydebug } をみると、問題ないように見えます。
grokで分割する部分を減らして、順次登録できるか確認していく必要がありそうなので、確認してみます。

{
           "host" => {
        "name" => "転送元ホスト"
    },
       "response" => "200",
         "source" => "/opt/ファイルパス/ファイル名.log",
           "auth" => "-",
          "bytes" => "12345",
     "@timestamp" => 2018-06-01T16:23:45.000Z,
          "ident" => "-",
         "fields" => {
        "logtype" => "ibmhttpd"
    },
    "httpVersion" => "1.1",
           "tags" => [
        [0] "beats_input_codec_plain_applied"
    ],
         "offset" => 1561832,
           "beat" => {
            "name" => "ホストネーム",
        "hostname" => "ホストネーム",
         "version" => "6.4.0"
    },
           "verb" => "POST",
          "input" => {
        "type" => "log"
    },
       "@version" => "1",
       "clientip" => "123.234.123.234",
     "prospector" => {
        "type" => "log"
    },
        "request" => "/POST_PAGE.jsp"
}

いろいろ試した所、Kibanaが何かおかしいことになっているらしいことが分かりました。
既に有る(使える)Index Patternを削除し、再作成しようとしてもServiceUnabailableになりました。
IndexPattern作成部分だけ壊れた?Ubuntuなので debで入れ直しても治らず。

とりあえず、Kibanaが何らかの問題が発生してた、Elasticsearchは問題ないようだ、切り分け方法を教えて頂いてとりあえず切り分けができた、という状態です。

とりあえずサーバ作り直すのが手っ取り早そうなので、そのようにします。

色々助言いただき、ありがとうございました。

1 Like

もうサーバーを入れ直すという話なので、遅いかもですが、
Kibanaのログには何も出てないでしょうか?
KibanaとEsの間に何かプロキシとかが居たりしないでしょうか?

1 Like

johtaniさん、ありがとうございます

logging.destでファイル出力してみましたが、200, 302くらいの応答が記録されていただけでした。
Proxyは使っていて除外していたはずですが、経由していた可能性はあります。確かに、proxyが影響している可能性が高いですね。
本番ではないので再構築はすぐにできたので、後ほどproxyを意図的にかけたりして確認します。

再現と確認ができましたので、共有します。

  • Elasticsearch/Kibana/Logstashは同一サーバに設置
  • 設定用のブラウザもローカルに存在
  • 意図せずブラウザにproxy設定が入り込み、indexPattern作成時にエラーになる
  • proxyを システムの設定 ではなく、無し、にすることで問題なく利用可能となる

proxy設定により、"Index Pattern作成以外は動作するが、Index Pattern作成時のみService Unabailableとなる"状態でした。
(なので、サーバ入れ直す必要はなかった…)

色々助言を頂き、ありがとうございました。
原因も対処法も確定しましたので、完全に問題解決しました。
ありがとうございます。

1 Like

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