Kibanaのキホンのキ@Elastic stack Advent Calendar 2017 3日目

はじめに

意外とKibanaにフォーカスした記事をみない気がしたので、
今回はKibanaの簡単なハンズオン的なブログを書いていこうと思います。
また、Kibanaの操作にフォーカスを当てるため、それ以外の設定等についてはなるべく簡略化しています。

※書いている最中に記載量が膨大になってきたので、前後編にわけていきます・・・

全体を通して、Elastic Stackでわからないところがあれば、こちらへ質問どうぞ! :) discuss.elastic.co

今回試す構成について

1台のVirtualBox上のサーバで以下ミドルウェアをインストールして試しています。

  • OS:CentOS 7.4 x86-64
  • JDK: jdk1.8-1.8.0_151-fcs
  • Elasticsearch: 6.0.0
  • Metricbeat: 6.0.0
  • Kibana: 6.0.0

構築手順

詳細手順は公式サイト見るのが一番なので、リンクの紹介だけしておきます。

ElasticsearchとKibanaを構築する時のTips

設定の説明は公式サイトにもありますが、
初めて触る方がいきなり全ての英語のドキュメントの意味を把握するのはハードルが高いかと思います。
そのため、ここではよくつまづきそうなポイントだけ紹介します。

Elasticsearch、Kibanaへの接続IPの変更

KibanaやElasticsearchはデフォルトだとlocalhostからしか繋がりません。
VirtualBox等でサーバ構築した上でListen IPを修正するには以下を修正してください。

$ vim /etc/elasticsearch/elasticsearch.yml --cmd "set nu"
  55 #network.host: 192.168.0.155 network.host: _local_,_site_
$ vim /etc/kibana/kibana.yml --cmd "set nu"
  7 #server.host: "localhost"7 server.host: "サーバのIPアドレス"
$

ElasticsearchとMetricbeatの動作確認

Elasticsearchの動作確認

$ curl localhost:9200
{
  "name" : "-kDPg7S",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "8I6dEp6fQhyi2nOcYcBLpA",
  "version" : {
    "number" : "6.0.0",
    "build_hash" : "8f0685b",
    "build_date" : "2017-11-10T18:41:22.859Z",
    "build_snapshot" : false,
    "lucene_version" : "7.0.1",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

Metricbeatの動作確認

MetricbeatはElasticsearchインストール後にインストールして起動するだけでデータがすぐに入ります。

# データが入っていないことを確認
$ curl localhost:9200/_cat/indices

# Metricbeatを起動してデータが入ることを確認
# Index名はKibanaを使うときに使うので覚えておいてください
$ sudo systemctl start metricbeat
$ curl "localhost:9200/_cat/indices?s=index:asc&v"
health status index                       uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   metricbeat-6.0.0-2017.12.01 1aPqivtrTfWKQSFhKEE9gg   1   1        380            0    234.9kb        234.9kb

Tips

  • cat APIについて
    様々なステータスを表示するための便利なAPIです。
    試しに「curl localhost:9200/_cat」を叩いてみると色々出るので試してみてください:)
    また、12/9に@muraken720さんが「cat APIs にまじめに入門する話」というお話をされる予定とのことですので詳細はこちらで乞うご期待!!

Kibanaの基礎設定

IndexをKibanaに認識させる

Elasticsearchへデータ投入も終わったので、Kibanaへログインしてみましょう。 ブラウザに「http://KibanaのサーバのIP:5601」と入力してアクセスしてみます。

画像のように投入したmetricbeatのIndex名を入力します。 f:id:st1t:20171201222013p:plain

Indexが読み込まれると認識されているField名と、データの型が一覧表示されます。 f:id:st1t:20171201222026p:plain

Discoverについて

Indexのデータを表示する画面

Discover画面の概要

f:id:st1t:20171201222055p:plain

Discover画面でデータ詳細を見る

f:id:st1t:20171201225906p:plain

表示させたいFieldを指定する

f:id:st1t:20171201230259p:plain

表示させたいデータをクエリで絞り込む

試しにsystem.process.cmdlineにjavaを含んでいて、system.process.fd.openが10より大きいデータを表示させてみます。
テキストボックスに 「system.process.cmdline: java AND system.process.fd.open: (>10)」と入力してみましょう。 f:id:st1t:20171201231339p:plain

せっかくなので、この検索条件を「search-process-java」として保存してみましょう。
後でDashbordに表示させてみます。 f:id:st1t:20171201232558p:plain

Add a filterを試してみる

上記項目では手動でクエリを書きましたが、
Field名が多かったりすると正確な名前が思い出せないことが多々あります。
また、まずはボタンをぽちぽちして手軽に絞り込みを試したいときもあるかもしれません。
そんなときは「Add a filter」を試してみると良いかもしれません。
複雑な条件はできませんが、単純な値比較等はできます。 f:id:st1t:20171202120603p:plain 上記画像の「is」の部分はFilterが数値型なのか、文字列なのかで項目が変わります。
色々試してみてください:)

Visualizeについて

Discoverで確認したデータをグラフ化するためのものです。
Kibanaを使う上で肝となるVisualizeについですが、
全てのVisualizeを説明するのはページ数が膨大になりますので、
まずはメモリの使用率が多いプロセストップ5を時系列で可視化してみようと思います。
その代わり、なるべく他のVisualizeを使うときでも使いまわしが効くよう解説していきたいと思います。

今回使うVisualize

Create a Visualizationを押して、
今回はAreaチャートでmetricbeat-*のIndex patternを可視化していきます。 f:id:st1t:20171202131734p:plain f:id:st1t:20171202131746p:plain f:id:st1t:20171202131755p:plain

Areaチャートの設定

まず、殆どのVisualizeで共通するMetricsとBucketsという2種類の設定があります。
少し乱暴かとは思いますが、ざっくりと最初のイメージとしては
Metrics=グラフの縦軸
Buckets=グラフの横軸
と思ってもらえれば良いかなと思います。

このイメージを持ってもらった上で今回可視化したいグラフの集計を整理してみます。

可視化したい内容を整理してみる

やりたいこと:メモリの使用量を多く消費しているプロセストップ5を時系列に積み上げグラフで可視化したい

このやりたいことを実際の設定に落とし込むと以下のようなものになります。
この時Buckets内の順番には注意してください。
特にサーバ単位でグラフを分けていてBarグラフを設定した時に大きく変わります。

  1. Metrics
    1. メモリの使用量平均値を表示させる
  2. Buckets(Metricsのデータを細かく集計)
    1. 1.1のデータを時系列に集計
    2. 2.1のデータをプロセス名毎にグラフを分岐させトップ5で絞る
    3. 2.2のデータをホスト単位でデータを分岐させる

Metricsの設定

Aggregationは縦軸で表示させるデータをどのように集計するかを設定するものになります。
今回はメモリ使用量の平均値を表示させたいので、
AggregationはAverageでFiledにsystem.process.memory.rss.byteを使います。
また、Custom Labelを使うことでグラフの縦軸に好きなラベルを設定出来ます。 f:id:st1t:20171202151758p:plain

Bucketsの設定

時系列の集計@X-Axis

横軸は時系列に表示させるため、
X-AxisのAggregationはDate Histogram、Fieldには@timestampを設定します。
また、右上の表示時間帯を変更すると、
IntervalがAutoになっているためデータの表示される粒度が変わります。
より細かい粒度で見たいときはIntervalを秒単位や分単位で設定しても良いかもしれません。
ただし、あまりにも長い期間を表示する時(1ヶ月や半年、1年など)は手動で設定指定も自動でIntervalが設定されるので注意してください。 f:id:st1t:20171202152141p:plain

プロセス名毎にグラフを分岐させトップ5で絞る@Split Series

プロセス名別に表示を分けるため、SubAggregationにTermsとsystem.process.nameを設定します。
TermsはひとまずField名のイメージを持っておいてもらえれば良いかと思います。 f:id:st1t:20171202153422p:plain

ホスト単位でデータを分岐させる@Split Chart

今回は1台分のデータしかElasticsearchへ登録していないのでわかりづらいのですが、
添付画像のように設定すると緑色の枠の部分がホスト単位で複数できるようになります。 f:id:st1t:20171202154829p:plain

Metrics&Axes

Metrics

f:id:st1t:20171202155632p:plain

Y-Axes

Y-Axesは設定項目が多くてスクショできなかったので、
使いそうなところを少しだけ紹介します。 Scale to Data Bounceを設定すると、表示されるデータの下限値が動的に変更されます。
この設定をONにすることによって、桁数の多い数値のデータの変化に気が付きやすくなります。
f:id:st1t:20171202155942p:plain

Panel Settings

Legend Positionを設定するとプロセス名の部分を別の場所に表示することが出来ます。
横枠を少しでも広げたい方には設定しても良いかなと思います。
また、ちょっとわかりづらいですが、X-Axis LinesやY-Axis Linesを設定するとグラフの後ろに縦線や横線を設定することも出来ます。 f:id:st1t:20171202190322p:plain

保存しておく

作成したグラフをDiscoverのときと同じように保存しておきます。
ここではused-memory-processとしておきます。 f:id:st1t:20171202190844p:plain

Tips

グラフからElasticsearchへのクエリを確認する

私はElasticsearchのクエリの書き方を忘れることがあるのですが、そんなときはVisualizeからクエリを確認したりしています。
f:id:st1t:20171202232408p:plain f:id:st1t:20171202232452p:plain f:id:st1t:20171202232622p:plain

グラフのデータをCSVでダウンロードする

上記のクエリ確認の画面と同じように、Visualizeの左下に出てくる小さい三角を押して、ExportのRawかFormattedを使うことでCSVファイルをダウンロード出来ます。
f:id:st1t:20171202232408p:plain f:id:st1t:20171202232759p:plain

Dashbordについて

DiscoverやVisualizeで保存したものをまとめて表示させます。

Visualizeを追加する

f:id:st1t:20171202191329p:plain

Discoverで保存した検索を追加する

f:id:st1t:20171202192040p:plain

ダッシュボードの色を白から黒に変更してみる

f:id:st1t:20171202192008p:plain

次回予告

残念ながら本来書こうと思っていた詳細は全然書ききれませんでした・・・
KibanaだけでもVisualbuilder、Dev Tools、Grok Debugger、LogstashのPipilineの処理時間の可視化などなど紹介したい機能はたくさんあります。
他にもVisualizeを使ううえでログの設計や送信する際に考えておくべき箇所などなど。
今月のAdvent Calendarが最後の方まで残っていたら追加別記事にTips集的な感じで書こうと思います。
明日は@_bsooさんから書いていただけるようですので、乞うご期待!!

builderscon tokyo 2017行ってきた@前夜祭編

行ってきました、builderscon、略してびるこん。

builderscon.io


今日は前夜祭なので18時から慶應義塾大学日吉キャンパスの協生館にお邪魔しました。

f:id:st1t:20170803220908j:plain
みんなだいすきカジュアルウォーター👍

【前夜祭】オンプレミスデータセンター撤退! - 大人のビルコン 〜撤退技術スペシャル〜(1)

すごーい!
後半は自分も同じような経験が・・・うっ、頭がっ

【前夜祭】データストア撤退の歴史 - 大人のビルコン 〜撤退技術スペシャル〜(2)

すごーい!
昔よく怪我したなぁ・・・

【前夜祭】PaaS完全撤退の歴史 - 大人のビルコン 〜撤退技術スペシャル〜(3)

すごーい!
かなしみ。合掌。
でもどこかでバトンが渡ってると思うと良いおはなし。

【前夜祭】ブロックストレージとの戦い、そして撤退 - 大人のビルコン 〜撤退技術スペシャル〜(4)

すご・・・やべえ
信頼関係って大事。
内容はたぶんインフラ屋さんならあるあるネタかな。
うっ、お腹が痛い・・・。

というわけで、非常に充実した前夜祭でした!!
前夜祭の内容は完全オフレコなので書けませんでした、すいません!!

見た人にだけわかるように一言だけ感想書いときました。
題名の下に白文字で書いたので反転して見てください😇
懐かしいと思った人はきっとインターネット老人

明日はもう少しきちんと書きます💪

先日起きたNetwork疎通のおはなし@自戒をこめて

ある日のこと

Aさん「んー?切り出したサーバがpingすら上手く通らない。。。Firewall絡みかな?」
自分「telnetでつなげて対向先サーバでtcpdumpしてパケットは来てる?」
Aさん「来ていますね」
自分「iptablesは?」
Aさん「落としてます」
自分「んー・・・?デフォゲも設定&疎通出来ているされているしな・・・はて・・・」

先日こんなことがあったのですが、
わかると単純なんですがハマってしまって解決するのに30分ほどかかってしまいました。
恐らくわかる方はすぐわかってしまうかと思います。
自戒をこめて今回書き記しておこうと思います。

状況を整理すると以下の通り。

接続イメージ

Xサーバ(データ送信元) -> 🔥Firewall🔥 -> Zサーバ(データ送信先)

聞き取り調査状況

  • XとZサーバはNWセグメントは別
  • XからZサーバへpingを投げても応答を返さない。また、その逆のZからXサーバも応答が返ってこない。
  • Xサーバからtelnet接続するとtcpdumpで見る限りパケットはZサーバに問題なく来ている
  • ZサーバでiptablesはOFFにしている
  • X及びZサーバのデフォルトゲートウェイ(以下DG)は適切に設定されている。また、DGに対してpingは返ってくる
  • Zサーバでtsharkでパケットの中身を眺めてみても異常はなさそう

その後...

自分「んー・・・iptablesは切ってるし、そもそもパケットフィルタが原因ならtcpdump上は返すように見えると思うんだよなぁ」
自分「そもそも自分のパケットと認識していないような挙動だし・・・」

Xサーバ以外のNWからpingを投げてみたら応答が返ってきました。
ここまでを振り返ると、どうやらFirewallやpingそのものがおかしいわけではなさそうでした。

ふと何気なくルーティングを見ていたら、

自分「ん?XサーバのNWアドレスとバッティングしたNWアドレスがZサーバ内のブリッジに向けてある・・・なんだこりゃ」
ex. XサーバのNWアドレス(192.168.0.0/24)、Zサーバ内のルーティング(192.168.0.0/16)のようなイメージ

ということで、
応答を返さない原因はルーティングテーブルが原因でした。
後にAさんに事情を聞いてみたところ、
どうやらコンテナを設定するのに以前使っていたのが残ったままになってしまっていたようでした。
既に使っていなかったようで、削除してもらったら無事に疎通出来るようになりました。

ここまでは単なるルーティングミスのおはなしですが、
ふと思いました。
時間かけすぎてしまった、と。
ここからは、どうしたらもっと早く気がつけたのか振り返ってみようと思います。

振り返り

  1. DGの設定確認したときに、ルーティングテーブルもきちんと見るべきだった
  2. FWやiptables等のパケットフィルタは調査当初から問題なさそうという認識はあったが、いまいち断言しきれずにtsharkでパケットの中身を見ることを優先しすぎてしまった
  3. パケットが着信しているにもかかわらず自分のものと認識していないのはアプリレイヤの設定に何かあるのかと壮大な勘違いをしていた

正直1を徹底するにつきてしまうのですが、
3も個人的に結構な反省点だと思っています。

もっとパケットの気持ちになって
デバイス -> Kernel -> ユーザランドでどういう風にデータが流れていくのか、
そもそも、パケットフィルタとルーティングの処理される位置関係がどうだったのか
再認識してみようとおもいます。

Linux Kernel Networkingについて

www.slideshare.net

こちらのスライドのp.40を見るとデバイスに着信してから上位レイヤに渡されるまでの概要が記載されています。

せっかくですので、linux-3.10.105のip_input.cの中身を追いかけて書いていたのですが、
別のブログで既に整理して記載がありましたのでここではご紹介に留めておこうと思います。

ip_input.cを見てからブログを拝見するとスッキリしました。

enakai00.hatenablog.com

その他参考

ElasticsearchでXFSとBtrfsを容量削減目的で比較してみた

Elasticsearchでなるべく長期間データ保存をしておきたいけど、データ容量が結構大きい。。。
ということで、圧縮できないかXFSとBTrfsを試してみました。

目的

  • データ圧縮してストレージ容量の削減をしたい

観点

  • どの程度容量が圧縮されるのか
  • 検索速度はどの程度違うのか
  • 負荷はどのレイヤがどの程度変わるのか

注意

今回紹介するBtrfsの圧縮機能の状態はまだmostly OKなので利用時はデータの破損等自己責任でお願いします。
備考には(needs verification and source) auto-repair and compression may crashとの記載あり。
Status - btrfs Wiki

XFSとBtrfsについて

各ファイルシステムの紹介は細かく記載してくださっているサイトがあるので、
ご紹介程度にとどめておきます。

試したファイルシステムの設定種類

サーバ名 OS Instance Type ファイルシステム ファイルシステムオプション(fstab)
ec2-xfs-default CentOS Linux release 7.2.1511 t2.medium xfs defaults
ec2-btrfs-default CentOS Linux release 7.2.1511 t2.medium btrfs defaults
ec2-btrfs-force-lzo CentOS Linux release 7.2.1511 t2.medium btrfs noatime,autodefrag,compress-force=lzo,space_cache
ec2-btrfs-force-zlib CentOS Linux release 7.2.1511 t2.medium btrfs noatime,autodefrag,compress-force=zlib,space_cache

試した環境イメージ

f:id:st1t:20170408162353p:plain

投入したデータについて

ec2-dsrc01,02からmetricbeatを使って毎秒以下の通りデータを投入。

$ sudo cat /etc/metricbeat/metricbeat.yml
metricbeat.modules:

#------------------------------- System Module -------------------------------
- module: system
  metricsets:
    # CPU stats
    - cpu

    # System Load stats
    - load

    # Per CPU core stats
    - core

    # IO stats
    - diskio

    # Per filesystem stats
    - filesystem

    # File system summary stats
    - fsstat

    # Memory stats
    - memory

    # Network stats
    - network

    # Per process stats
    - process

    # Sockets (linux only)
    - socket
  enabled: true
  period: 1s
  processes: ['.*']

ディスク容量の推移

f:id:st1t:20170408164453p:plain
ec2-xfs-defaultとec2-btrfs-defaultではあまり大きな容量の差は見られませんでした。
しかし、ec2-btrfs-force-lzoはec2-btrfs-defaultと比較して3割強、
ec2-btrfs-force-zlibに至っては6割のデータ容量が削減されていることが確認できました。

CPU使用率(USER)の推移

f:id:st1t:20170412200544p:plain
予想に反してbtrfs-zlibの使用率が低い結果になりました。
※全台たまに使用率が跳ねているのは恐らくSegment Mergeが起きていたのではないかと思います。
今回は検証の範囲外のため行っていませんが、もし本当にSegment Mergeであるか確認するなら、
_cluster/settingsのindices.store.throttle.max_bytes_per_sec等を修正すると影響があるかもしれません。

www.elastic.co
blog.mikemccandless.com

簡単なクエリを投げ続けてみた

以下のような直近1日のCPU使用率を取得するクエリを投げてみました。
なお、get-cpu.shを叩く前に全台Elasticsearchを再起動してメモリキャッシュをクリアさせています。

get-cpu.sh

#!/bin/bash

LOG=/tmp/get-average-cpu-24hour-`date +%Y%m%d-%H%M%S`.log

# Warmup
date >> $LOG
echo "start warmup." >> $LOG
for i in {1..500}
do
  (time curl -s -XGET {{ ansible_default_ipv4.address }}:9200/metricbeat-*/_search -d @get-average-cpu-24hour.json | jq .) > /dev/null 2>&1
done
date >> $LOG
echo "stop warmup." >> $LOG

date >> $LOG
echo "sleep 1m." >> $LOG
sleep 60
date >> $LOG

# exe
date >> $LOG
echo "start benchmark." >> $LOG
for i in {1..1000}
do
  (time curl -s -XGET {{ ansible_default_ipv4.address }}:9200/metricbeat-*/_search -d @get-average-cpu-24hour.json | jq .) 2>&1 | grep ^real >> $LOG
done
date >> $LOG
echo "stop benchmark." >> $LOG

get-average-cpu-24hour.json

{ 
  "size": 0,
  "query": {
    "bool": {
      "must": [
        { 
          "query_string": {
            "query": "*",
            "analyze_wildcard": true
          }
        },
        { 
          "range": {
            "@timestamp": {
              "gte": 1491554333990,
              "lte": 1491640733990,
              "format": "epoch_millis"
            }
          }
        }
      ],
      "must_not": []
    }
  },
  "_source": {
    "excludes": []
  },
  "aggs": {
    "2": {
      "date_histogram": {
        "field": "@timestamp",
        "interval": "30m",
        "time_zone": "Asia/Tokyo",
        "min_doc_count": 1
      },
      "aggs": {
        "1": {
          "avg": {
            "field": "system.process.cpu.total.pct"
          }
        }
      }
    }
  }
}

実行時間

トータル実行時間

btrfsは一度読み込むとメモリ乗っかるせいか、
圧縮オプションによる実行時間はほとんど変わりませんでした。
XFSは2倍強くらいになってしまいました。。。

サーバ名 実行時間
ec2-btrfs-force-zlib 1m 55s
ec2-btrfs-default 1m 56s
ec2-btrfs-force-lzo 1m 56s
ec2-xfs-default 4m 51s
単一実行時間の散布図

f:id:st1t:20170410120406p:plain
縦軸:処理時間(秒)
横軸:回数

CPU負荷のかかり方(USER)

f:id:st1t:20170412204854p:plain
ユーザランドのCPU使用率だけ見てみると全台綺麗にCPUを使い切っていて、
負荷のかかりかた自体は大きな違いがあるようではなさそうでした。

DISK IOの負荷のかかり方

f:id:st1t:20170412203632p:plain

  • 11:54 - 11:56周辺の山:Elasticsearchを再起動実施タイミング
  • 11:59 - 12:01周辺の山:ベンチマーク中

DISKの圧縮が効いていればいるほどDISKのIO Waitが小さく、かつIOが出ているようです。

参考:timelionのクエリ(ec2-xfs-default)

※以下クエリは意図的になるべく見やすくするために意図的に改行を付加してますが、
実際はワンライナーで記載する必要があります。

(
  .subtract(
    .es(index=metricbeat-*,metric=max:system.diskio.read.count,q=beat.hostname:ec2-xfs-default),
    .es(index=metricbeat-*,metric=max:system.diskio.read.count,q=beat.hostname:ec2-xfs-default,offset=-1s)
  ).label("ec2-xfs-default:read i/o"),
  .subtract(
    .es(index=metricbeat-*,metric=max:system.diskio.write.count,q=beat.hostname:ec2-xfs-default),
    .es(index=metricbeat-*,metric=max:system.diskio.write.count,q=beat.hostname:ec2-xfs-default,offset=-1s)
  ).label("ec2-xfs-default:write i/o")
).bars(width=1).yaxis(1,max=1500,label="DISK IO Count"),
.multiply(
  .es(index=metricbeat-*,metric=max:system.cpu.iowait.pct,q=beat.hostname:ec2-xfs-default),
  100
).lines(width=1).label("ec2-xfs-default:cpu i/o wait").yaxis(2,max=100,label="CPU IO wait(%)")

念のため3回ほど回してみた

f:id:st1t:20170412204234p:plain
DISKやCPUの負荷傾向は同じ傾向となりました。

結論

  • btrfsをデフォルト設定で使ってもDISK容量削減だと意味がなさそう
    • 圧縮率を求めるならcompress-forceでlzoかzlibを使う必要がある
  • 今回みたいな小さいクエリの場合はXFSよりBtrfsのほうが早い模様
    • なぜそうなるのかが追求できていないので全体的な傾向としてBtrfsが早いのか、今回の条件に限りなのかは要確認

Elasticsearch Rallyを試してみる

Rallyとは?

RallyとはElastic社から公式でベンチマークツールとしてリリースされているものです。
Rally登場:Elasticsearchのベンチマークツール | Elastic

なぜやるのか

色々なスペックのサーバを扱うことが出てきたため、
OSレイヤだけではなくM/Wレイヤでもベンチマークして参考にしていきます。
※大人の事情により実環境におけるベンチマークスコアや具体的にどういう目的でどういう項目を細かく見ているのかは伏せています。。。
また、導入手順はAnsibleのPlayBook化していますので、興味ある方は試してみてください。

ベンチマーク環境

環境

クラウド:AWS
インスタンス:m3.2xlarge
ami:AWS MarketplaceのCentOS 7 (x86_64) - with Updates HVMを利用
(最初CentOS6でやったらgccのバージョンが古く、esrallyを起動時にbzip2絡みでコケました)
DISK:/home/user/.rally配下がrallyのテストデータ落とすため約3GB使います。
ノード数:1ノード

Ansible Playbook

Playbookは自分自身にAnsibleでデプロイする内容になっています。
github.com

インストール手順

#はrootユーザで実行
##はコメント
$は一般ユーザで実行

## Ansible Install
# yum install -y epel-release
# yum install -y ansible git
# ssh-keygen
# cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# git clone https://github.com/st1t/setup-rally.git
# cd setup-rally

## Ansibleのデプロイ先サーバ(localhost)への接続確認
# ansible -i hosts rally -m ping
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is 6f:bb:62:2c:72:c6:fe:40:41:80:80:fe:09:3f:e4:24.
Are you sure you want to continue connecting (yes/no)? yes
localhost | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

## ORACLE JDKは手動でインストール
## http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

## Ansibleの実行タスクとデプロイ先を確認
# ansible-playbook -i hosts rally.yml --list-tasks --list-hosts
playbook: rally.yml

  play #1 (rally): rally        TAGS: []
    pattern: [u'rally']
    hosts (1):
      localhost
    tasks:
      elasticsearch : please install Oracle JDK manually        TAGS: [setup_elasticsearch]
      elasticsearch : add rpm gpg key   TAGS: [setup_elasticsearch]
      elasticsearch : add elasticsearch.repo    TAGS: [setup_elasticsearch]
      elasticsearch : yum install elasticsearch TAGS: [setup_elasticsearch]
      elasticsearch : template files    TAGS: [setup_elasticsearch, template_files]
      rally : yum install packages      TAGS: [setup_rally]
      rally : download python-3.5.3     TAGS: [setup_python, setup_rally]
      rally : unarchive python-3.5.3    TAGS: [setup_python, setup_rally]
      rally : configure python-3.5.3    TAGS: [setup_python, setup_rally]
      rally : make install python-3.5.3 TAGS: [setup_python, setup_rally]
      rally : ensure pip        TAGS: [setup_python, setup_rally]
      rally : download git-2.11.1       TAGS: [setup_git, setup_rally]
      rally : unarchive git-2.11.1      TAGS: [setup_git, setup_rally]
      rally : configure git-2.11.1      TAGS: [setup_git, setup_rally]
      rally : make install git-2.11.1   TAGS: [setup_git, setup_rally]
      rally : pip3.5 install esrally    TAGS: [setup_esrally, setup_rally]
# 

## デプロイを実行
# ansible-playbook -i hosts rally.yml

PLAY [rally] *******************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [elasticsearch : please install Oracle JDK manually] **********************
changed: [localhost]

TASK [elasticsearch : add rpm gpg key] *****************************************
changed: [localhost]

TASK [elasticsearch : add elasticsearch.repo] **********************************
changed: [localhost]

TASK [elasticsearch : yum install elasticsearch] *******************************
changed: [localhost]

TASK [elasticsearch : template files] ******************************************
changed: [localhost] => (item=etc/elasticsearch/elasticsearch.yml)
changed: [localhost] => (item=etc/elasticsearch/jvm.options)

TASK [rally : yum install packages] ********************************************
changed: [localhost] => (item=[u'gcc', u'openssl-devel', u'bzip2-devel', u'perl-ExtUtils-MakeMaker', u'curl-devel'])

TASK [rally : download python-3.5.3] *******************************************
changed: [localhost -> localhost]

TASK [rally : unarchive python-3.5.3] ******************************************
changed: [localhost]

TASK [rally : configure python-3.5.3] ******************************************
changed: [localhost]

TASK [rally : make install python-3.5.3] ***************************************
changed: [localhost]

TASK [rally : ensure pip] ******************************************************
changed: [localhost]

TASK [rally : download git-2.11.1] *********************************************
changed: [localhost -> localhost]

TASK [rally : unarchive git-2.11.1] ********************************************
changed: [localhost]

TASK [rally : configure git-2.11.1] ********************************************
changed: [localhost]

TASK [rally : make install git-2.11.1] *****************************************
changed: [localhost]

TASK [rally : pip3.5 install esrally] ******************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=17   changed=16   unreachable=0    failed=0

# 

## Elasticsearchの起動&動作確認
# systemctl start elasticsearch
# curl localhost:9200
{
  "name" : "ip-172-64-1-146",
  "cluster_name" : "my-application",
  "cluster_uuid" : "Jjl-G0Y9R2WyqvI6opQYHw",
  "version" : {
    "number" : "5.2.0",
    "build_hash" : "24e05b9",
    "build_date" : "2017-01-24T19:52:35.800Z",
    "build_snapshot" : false,
    "lucene_version" : "6.4.0"
  },
  "tagline" : "You Know, for Search"
}
# 

## esrallyの設定
## esrallyはrootでは動かないようになっているため、root以外のユーザへ移動(今回はcentos)
# su - centos
## JDKのRootディレクトリパスを設定
$ esrally configure

    ____        ____
   / __ \____ _/ / /_  __
  / /_/ / __ `/ / / / / /
 / _, _/ /_/ / / / /_/ /
/_/ |_|\__,_/_/_/\__, /
                /____/

Running simple configuration. Run the advanced configuration with:

  esrally configure --advanced-config

INFO:rally.config:Running simple configuration routine.
[✓] Autodetecting available third-party software
which: no gradle in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/centos/.local/bin:/home/centos/bin)
  git    : [✓]
  gradle : [✕]
  JDK 8  : [✕] (You cannot benchmark Elasticsearch 5.x without a JDK 8 installation)

**********************************************************************************
You don't have the necessary software to benchmark source builds of Elasticsearch.

You can still benchmark binary distributions with e.g.:

  esrally --distribution-version=5.0.0
**********************************************************************************

[✓] Setting up benchmark data directory in [/home/centos/.rally/benchmarks] (needs several GB).

Enter the JDK 8 root directory:: /usr/java/jdk1.8.0_121

[✓] Configuration successfully written to [/home/centos/.rally/rally.ini]. Happy benchmarking!

To benchmark Elasticsearch 5.0.0 with the default benchmark run:

  esrally --distribution-version=5.0.0

For help, type esrally --help or see the user documentation at https://esrally.readthedocs.io/en/0.4.8/
$ 

## esrallyを実行
## esrallyの実行ウィンドウとは別のウィンドウで[dstat -tlcmgdn --socket --tcp --io]を実行しながら眺めると良いかも
$ esrally --pipeline=from-distribution --distribution-version=5.2.0

    ____        ____
   / __ \____ _/ / /_  __
  / /_/ / __ `/ / / / / /
 / _, _/ /_/ / / / /_/ /
/_/ |_|\__,_/_/_/\__, /
                /____/

[INFO] Writing logs to /home/centos/.rally/benchmarks/races/2017-02-14-14-47-08/local/logs/rally_out.log
Running index-append                                                           [100% done]
Running force-merge                                                            [100% done]
Running index-stats                                                            [100% done]
Running node-stats                                                             [100% done]
Running default                                                                [100% done]
Running term                                                                   [100% done]
Running phrase                                                                 [100% done]
Running country_agg_uncached                                                   [100% done]
Running country_agg_cached                                                     [100% done]
Running scroll                                                                 [100% done]
Running expression                                                             [100% done]
Running painless_static                                                        [100% done]
Running painless_dynamic                                                       [100% done]
[INFO] Racing on track [geonames], challenge [append-no-conflicts] and car [defaults]

[INFO] Rally will delete the benchmark candidate after the benchmark

------------------------------------------------------
    _______             __   _____                    
   / ____(_)___  ____ _/ /  / ___/_________  ________ 
  / /_  / / __ \/ __ `/ /   \__ \/ ___/ __ \/ ___/ _ \
 / __/ / / / / / /_/ / /   ___/ / /__/ /_/ / /  /  __/
/_/   /_/_/ /_/\__,_/_/   /____/\___/\____/_/   \___/ 
------------------------------------------------------

|   Lap |                         Metric |            Operation |     Value |   Unit |
|------:|-------------------------------:|---------------------:|----------:|-------:|
|   All |                  Indexing time |                      |   34.2623 |    min |
|   All |                     Merge time |                      |   9.54963 |    min |
|   All |                   Refresh time |                      |   3.23123 |    min |
|   All |                     Flush time |                      |   0.27265 |    min |
|   All |            Merge throttle time |                      |   0.92085 |    min |
|   All |               Median CPU usage |                      |     397.8 |      % |
|   All |             Total Young Gen GC |                      |    19.179 |      s |
|   All |               Total Old Gen GC |                      |     1.538 |      s |
|   All |                     Index size |                      |   2.57505 |     GB |
|   All |                Totally written |                      |   14.7806 |     GB |
|   All |         Heap used for segments |                      |    14.036 |     MB |
|   All |       Heap used for doc values |                      |  0.110653 |     MB |
|   All |            Heap used for terms |                      |   12.9623 |     MB |
|   All |            Heap used for norms |                      | 0.0703735 |     MB |
|   All |           Heap used for points |                      |  0.247314 |     MB |
|   All |    Heap used for stored fields |                      |  0.645348 |     MB |
|   All |                  Segment count |                      |        93 |        |
|   All |                 Min Throughput |         index-append |   26655.1 | docs/s |
|   All |              Median Throughput |         index-append |   27401.3 | docs/s |
|   All |                 Max Throughput |         index-append |   27994.1 | docs/s |
|   All |      50.0th percentile latency |         index-append |   1306.33 |     ms |
|   All |      90.0th percentile latency |         index-append |   1706.22 |     ms |
|   All |      99.0th percentile latency |         index-append |   4132.19 |     ms |
|   All |      99.9th percentile latency |         index-append |   7894.34 |     ms |
|   All |       100th percentile latency |         index-append |   8290.49 |     ms |
|   All | 50.0th percentile service time |         index-append |   1306.33 |     ms |
|   All | 90.0th percentile service time |         index-append |   1706.22 |     ms |
|   All | 99.0th percentile service time |         index-append |   4132.19 |     ms |
|   All | 99.9th percentile service time |         index-append |   7894.34 |     ms |
|   All |  100th percentile service time |         index-append |   8290.49 |     ms |
|   All |                 Min Throughput |          force-merge |  0.387803 |  ops/s |
|   All |              Median Throughput |          force-merge |  0.387803 |  ops/s |
|   All |                 Max Throughput |          force-merge |  0.387803 |  ops/s |
|   All |       100th percentile latency |          force-merge |   2578.61 |     ms |
|   All |  100th percentile service time |          force-merge |   2578.61 |     ms |
|   All |                 Min Throughput |          index-stats |   100.058 |  ops/s |
|   All |              Median Throughput |          index-stats |   100.082 |  ops/s |
|   All |                 Max Throughput |          index-stats |   100.134 |  ops/s |
|   All |      50.0th percentile latency |          index-stats |   1.96378 |     ms |
|   All |      90.0th percentile latency |          index-stats |   2.08593 |     ms |
|   All |      99.0th percentile latency |          index-stats |   2.52601 |     ms |
|   All |      99.9th percentile latency |          index-stats |    16.778 |     ms |
|   All |       100th percentile latency |          index-stats |   17.6823 |     ms |
|   All | 50.0th percentile service time |          index-stats |   1.83976 |     ms |
|   All | 90.0th percentile service time |          index-stats |   1.96208 |     ms |
|   All | 99.0th percentile service time |          index-stats |   2.38526 |     ms |
|   All | 99.9th percentile service time |          index-stats |   10.8649 |     ms |
|   All |  100th percentile service time |          index-stats |   14.0383 |     ms |
|   All |                 Min Throughput |           node-stats |   99.8284 |  ops/s |
|   All |              Median Throughput |           node-stats |   100.124 |  ops/s |
|   All |                 Max Throughput |           node-stats |   100.788 |  ops/s |
|   All |      50.0th percentile latency |           node-stats |   1.98919 |     ms |
|   All |      90.0th percentile latency |           node-stats |   2.10209 |     ms |
|   All |      99.0th percentile latency |           node-stats |   3.51366 |     ms |
|   All |      99.9th percentile latency |           node-stats |   16.0786 |     ms |
|   All |       100th percentile latency |           node-stats |   18.5991 |     ms |
|   All | 50.0th percentile service time |           node-stats |    1.8646 |     ms |
|   All | 90.0th percentile service time |           node-stats |   1.97835 |     ms |
|   All | 99.0th percentile service time |           node-stats |   3.36162 |     ms |
|   All | 99.9th percentile service time |           node-stats |   7.46198 |     ms |
|   All |  100th percentile service time |           node-stats |   18.4724 |     ms |
|   All |                 Min Throughput |              default |    50.006 |  ops/s |
|   All |              Median Throughput |              default |   50.0084 |  ops/s |
|   All |                 Max Throughput |              default |    50.024 |  ops/s |
|   All |      50.0th percentile latency |              default |   16.7353 |     ms |
|   All |      90.0th percentile latency |              default |   16.9511 |     ms |
|   All |      99.0th percentile latency |              default |   20.5111 |     ms |
|   All |      99.9th percentile latency |              default |   26.1668 |     ms |
|   All |       100th percentile latency |              default |   26.4457 |     ms |
|   All | 50.0th percentile service time |              default |   16.6098 |     ms |
|   All | 90.0th percentile service time |              default |   16.8254 |     ms |
|   All | 99.0th percentile service time |              default |   17.7306 |     ms |
|   All | 99.9th percentile service time |              default |   26.0405 |     ms |
|   All |  100th percentile service time |              default |   26.3195 |     ms |
|   All |                 Min Throughput |                 term |   200.108 |  ops/s |
|   All |              Median Throughput |                 term |   200.152 |  ops/s |
|   All |                 Max Throughput |                 term |   200.253 |  ops/s |
|   All |      50.0th percentile latency |                 term |    1.2319 |     ms |
|   All |      90.0th percentile latency |                 term |   1.28896 |     ms |
|   All |      99.0th percentile latency |                 term |   1.85857 |     ms |
|   All |      99.9th percentile latency |                 term |   6.55233 |     ms |
|   All |       100th percentile latency |                 term |   6.96907 |     ms |
|   All | 50.0th percentile service time |                 term |   1.10788 |     ms |
|   All | 90.0th percentile service time |                 term |   1.16574 |     ms |
|   All | 99.0th percentile service time |                 term |   1.49258 |     ms |
|   All | 99.9th percentile service time |                 term |   5.63515 |     ms |
|   All |  100th percentile service time |                 term |   6.84347 |     ms |
|   All |                 Min Throughput |               phrase |   200.097 |  ops/s |
|   All |              Median Throughput |               phrase |   200.136 |  ops/s |
|   All |                 Max Throughput |               phrase |   200.225 |  ops/s |
|   All |      50.0th percentile latency |               phrase |    1.6242 |     ms |
|   All |      90.0th percentile latency |               phrase |   1.68859 |     ms |
|   All |      99.0th percentile latency |               phrase |   2.19295 |     ms |
|   All |      99.9th percentile latency |               phrase |   7.07005 |     ms |
|   All |       100th percentile latency |               phrase |   8.55214 |     ms |
|   All | 50.0th percentile service time |               phrase |   1.49897 |     ms |
|   All | 90.0th percentile service time |               phrase |    1.5647 |     ms |
|   All | 99.0th percentile service time |               phrase |   1.94413 |     ms |
|   All | 99.9th percentile service time |               phrase |   5.39353 |     ms |
|   All |  100th percentile service time |               phrase |   6.94662 |     ms |
|   All |                 Min Throughput | country_agg_uncached |   5.45032 |  ops/s |
|   All |              Median Throughput | country_agg_uncached |   5.46468 |  ops/s |
|   All |                 Max Throughput | country_agg_uncached |   5.46946 |  ops/s |
|   All |      50.0th percentile latency | country_agg_uncached |    162963 |     ms |
|   All |      90.0th percentile latency | country_agg_uncached |    228239 |     ms |
|   All |      99.0th percentile latency | country_agg_uncached |    242750 |     ms |
|   All |      99.9th percentile latency | country_agg_uncached |    244180 |     ms |
|   All |       100th percentile latency | country_agg_uncached |    244330 |     ms |
|   All | 50.0th percentile service time | country_agg_uncached |   182.442 |     ms |
|   All | 90.0th percentile service time | country_agg_uncached |    189.22 |     ms |
|   All | 99.0th percentile service time | country_agg_uncached |   206.477 |     ms |
|   All | 99.9th percentile service time | country_agg_uncached |   227.438 |     ms |
|   All |  100th percentile service time | country_agg_uncached |   235.705 |     ms |
|   All |                 Min Throughput |   country_agg_cached |   100.062 |  ops/s |
|   All |              Median Throughput |   country_agg_cached |   100.092 |  ops/s |
|   All |                 Max Throughput |   country_agg_cached |   100.174 |  ops/s |
|   All |      50.0th percentile latency |   country_agg_cached |   1.28296 |     ms |
|   All |      90.0th percentile latency |   country_agg_cached |   1.33427 |     ms |
|   All |      99.0th percentile latency |   country_agg_cached |   1.62056 |     ms |
|   All |      99.9th percentile latency |   country_agg_cached |    4.7723 |     ms |
|   All |       100th percentile latency |   country_agg_cached |   4.79509 |     ms |
|   All | 50.0th percentile service time |   country_agg_cached |    1.1585 |     ms |
|   All | 90.0th percentile service time |   country_agg_cached |   1.21304 |     ms |
|   All | 99.0th percentile service time |   country_agg_cached |   1.49657 |     ms |
|   All | 99.9th percentile service time |   country_agg_cached |   4.64836 |     ms |
|   All |  100th percentile service time |   country_agg_cached |   4.66964 |     ms |
|   All |                 Min Throughput |               scroll |   60.6234 |  ops/s |
|   All |              Median Throughput |               scroll |   60.7549 |  ops/s |
|   All |                 Max Throughput |               scroll |    60.782 |  ops/s |
|   All |      50.0th percentile latency |               scroll |    391710 |     ms |
|   All |      90.0th percentile latency |               scroll |    547911 |     ms |
|   All |      99.0th percentile latency |               scroll |    583086 |     ms |
|   All |      99.9th percentile latency |               scroll |    586607 |     ms |
|   All |       100th percentile latency |               scroll |    586989 |     ms |
|   All | 50.0th percentile service time |               scroll |   411.999 |     ms |
|   All | 90.0th percentile service time |               scroll |   415.801 |     ms |
|   All | 99.0th percentile service time |               scroll |   419.931 |     ms |
|   All | 99.9th percentile service time |               scroll |   425.589 |     ms |
|   All |  100th percentile service time |               scroll |   425.727 |     ms |
|   All |                 Min Throughput |           expression |   2.89118 |  ops/s |
|   All |              Median Throughput |           expression |   2.90642 |  ops/s |
|   All |                 Max Throughput |           expression |   2.91998 |  ops/s |
|   All |      50.0th percentile latency |           expression |    294333 |     ms |
|   All |      90.0th percentile latency |           expression |    413862 |     ms |
|   All |      99.0th percentile latency |           expression |    440851 |     ms |
|   All |      99.9th percentile latency |           expression |    443586 |     ms |
|   All |       100th percentile latency |           expression |    443885 |     ms |
|   All | 50.0th percentile service time |           expression |   347.375 |     ms |
|   All | 90.0th percentile service time |           expression |   360.064 |     ms |
|   All | 99.0th percentile service time |           expression |   372.304 |     ms |
|   All | 99.9th percentile service time |           expression |    379.48 |     ms |
|   All |  100th percentile service time |           expression |   386.623 |     ms |
|   All |                 Min Throughput |      painless_static |   1.94561 |  ops/s |
|   All |              Median Throughput |      painless_static |    1.9468 |  ops/s |
|   All |                 Max Throughput |      painless_static |   1.94792 |  ops/s |
|   All |      50.0th percentile latency |      painless_static |    463873 |     ms |
|   All |      90.0th percentile latency |      painless_static |    649285 |     ms |
|   All |      99.0th percentile latency |      painless_static |    691026 |     ms |
|   All |      99.9th percentile latency |      painless_static |    695246 |     ms |
|   All |       100th percentile latency |      painless_static |    695709 |     ms |
|   All | 50.0th percentile service time |      painless_static |   512.775 |     ms |
|   All | 90.0th percentile service time |      painless_static |    539.99 |     ms |
|   All | 99.0th percentile service time |      painless_static |   566.923 |     ms |
|   All | 99.9th percentile service time |      painless_static |   577.931 |     ms |
|   All |  100th percentile service time |      painless_static |   578.523 |     ms |
|   All |                 Min Throughput |     painless_dynamic |   1.99401 |  ops/s |
|   All |              Median Throughput |     painless_dynamic |   1.99582 |  ops/s |
|   All |                 Max Throughput |     painless_dynamic |   1.99775 |  ops/s |
|   All |      50.0th percentile latency |     painless_dynamic |    451470 |     ms |
|   All |      90.0th percentile latency |     painless_dynamic |    630959 |     ms |
|   All |      99.0th percentile latency |     painless_dynamic |    671680 |     ms |
|   All |      99.9th percentile latency |     painless_dynamic |    675685 |     ms |
|   All |       100th percentile latency |     painless_dynamic |    676132 |     ms |
|   All | 50.0th percentile service time |     painless_dynamic |   500.268 |     ms |
|   All | 90.0th percentile service time |     painless_dynamic |   523.014 |     ms |
|   All | 99.0th percentile service time |     painless_dynamic |   543.797 |     ms |
|   All | 99.9th percentile service time |     painless_dynamic |   559.719 |     ms |
|   All |  100th percentile service time |     painless_dynamic |   564.137 |     ms |


[INFO] Archiving logs in /home/centos/.rally/benchmarks/races/2017-02-14-14-47-08/local/logs-geonames-append-no-conflicts-defaults.zip

----------------------------------
[INFO] SUCCESS (took 3377 seconds)
----------------------------------
$ 

やってみた感想

ベンチマークするときは何を目的にどうベンチマークを実行するかは結構難しくいつも頭を悩ませています。
今回もただ実行するだけではなかなか自分自身にとって意味のある数値にするのは難しいかなと思います。
しかし、インスタンス間の相対評価にはなるかなと思うのと、特別な設定をいれなくてもマルチコアを使ってくれてることが確認できただけでも個人的には良かったです。
何より公式でベンチマークツールを用意していただいているので困ったときには
Discuss the Elastic Stackに聞けますし、今後もElasticのリリース速度に合わせてメンテナンスされつづけるのは大きいと思います。
今後のrallyのロードマップにも期待してます!

最後に

Elasticの話題は以下公式サイトで日本語でも聞けるところが用意されているみたいなので、
盛り上がるとうれしいなーなんて思っております😃
discuss.elastic.co

2017年にやること

アウトプットを増やす

  • ブログから情報発信(隔週更新くらいはしていきたい)
  • 好きなOSSにContributeしていく
    • 多分ElasticのBeatsが主になりそう

インフラコマンド系を作成

  • 多分今年はgolangを主軸に色々コマンドを整備予定(ブログじゃ書けないけど。。。)

機械学習によるデータ解析システムを準備して以下検証

  • パフォーマンスチューニングの取っ掛かりの低敷居化
  • より精度の高いサービス監視

英語力の強化

  • PullrequestとかIssueとか書く時にいい加減辛いのでなんとかしなければ。。。