Kibana on @johtaniの日記 3rd

Analyze UIとKibanaのプラグインの作成方法（第3回）

Fri, 20 Apr 2018 15:30:01 +0900

第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについてみていきます。（2018/02月時点で作成したディレクトリ構成にしたがって説明します）ちなみに、JavaScriptの優れた開発者ではないので、誤解している点や、効率の悪い書き方などがあるかもしれません。見つけた場合は、連絡をいただければと思います。

では、まずは作成したディレクトリ構成についてみていきましょう。

ディレクトリ構成

simple-sample-kibana-pluginがプラグインのプロジェクトのトップディレクトリになります。このディレクトリに次のような構成でサブディレクトリが存在します(なお、画像はIntelliJに取り込んだ後のディレクトリになっているので、.imlなど、不要なファイル/ディレクトリが存在しています)。

主要なディレクトリ、ファイルについて簡単に一覧で説明します(順不同)。

ファイル/ディレクトリ名	説明
index.js	プラグインの本体。Kibanaはこのファイルのオブジェクトを読み込みプラグインを起動。設定などの読み込みもこちら。
package.json	npm/yarnのパッケージに関する情報を定義するファイル
README.md	README。プラグインの説明などを記載する。インストール方法なども記載すると便利
public	ブラウザ側に配布されるプログラムや画像一式
public/less/main.less	LESS用のファイル。アプリ固有のスタイルなどを記載
public/app.js	ブラウザ側で読み込まれるプラグインのモジュールなど。
public/template/index.html	HTMLのテンプレート。ブラウザ上での描画に利用
server/routes	Kibanaサーバー側で動作するプラグイン。hapi.jsを利用してREST APIを実装する

重要なファイルについて少しだけ説明します。

package.json

npmやyarnでビルドなどをするときに使用するパッケージ情報を記載するためのファイルです。プラグインの名前、バージョン、説明などを記載します。 Kibanaのバージョンについてもこちらで管理します。この情報をまた、ライブラリなどの依存関係についてもこちらで記載しています。以下、抜粋。

{
  "name": "simple-sample-kibana-plugin",
  "version": "0.0.0",
  "description": "Sample plugin for explaining how to make kibana app",
  "main": "index.js",
  "kibana": {
    "version": "6.2.1",
    "templateVersion": "7.2.4"
  },
  "scripts": {
    "lint": "eslint **/*.js",
...
  },
  "devDependencies": {
    "@elastic/eslint-config-kibana": "^0.14.0",
    "@elastic/eslint-import-resolver-kibana": "^0.9.0",
    "@elastic/plugin-helpers": "^7.1.3",
...
    "expect.js": "^0.3.1"
  }
}

ちなみに私は、versionなどをリリースするたびに変更しています。

index.js

最初にKibanaに読み込まれるオブジェクトになります。 Kibanaのアプリの名前や、必要なモジュールなどを記載します。

また、kibana.ymlから設定など読み込む処理なども書くことができます。

2行目のexampleRouteはサーバー側のAPIとして利用するhapi.js用のファイルのパスになります。

uiExportsはこのアプリの画面に関する設定などの記載になります。 appの部分が実際にアプリの情報で、 mainがあとで説明するこのプラグインのUIのためのJavaScriptファイル(public/app.js)になります。mainですので、最初に読み込まれる処理が記載されているものを指定します。app.jsというファイル名を変更する場合は、こちらのappの部分を変更したファイルに合わせましょう。

config(Joi)の関数が設定ファイルの読み込みなどの処理を記載する場所です。

init(server, options)の関数が初期化処理を記載する場所になります。このサンプルアプリでは、2行目のimportで読み込んだhapi.js用のファイルの関数を呼び出しています。引数で渡しているserverがhapi.jsのserverオブジェクトになります。 routeメソッドを使用して作成しているプラグイン用のREST APIを追加しています。

import { resolve } from 'path';
import exampleRoute from './server/routes/example';

export default function (kibana) {
  return new kibana.Plugin({
    require: ['elasticsearch'],
    name: 'simple-sample-kibana-plugin',
    uiExports: {

      app: {
        title: 'Simple Sample Kibana Plugin',
        description: 'Sample plugin for explaining how to make kibana app',
        main: 'plugins/simple-sample-kibana-plugin/app'
      },

...
    },

    config(Joi) {
      return Joi.object({
        enabled: Joi.boolean().default(true),
      }).default();
    },

    init(server, options) {
      // Add server routes and initialize the plugin here
      exampleRoute(server);
    }
  });
};

public/app.js

画面用のモジュールです。 uiRoutesという機能を使用して、アプリの呼び出しURLを定義します。テンプレートで作成したばかりの場合は、/というURLが追加されるのみです。

実際に画面を表示する際に動くコントローラーの部分はその下の uiModules.controllerに指定してあるfunctionが画面描画の処理を書く部分になります。 templateで作成したプラグインでは、“title"など表示に必要なデータを$scopeというオブジェクトに詰め込んでいます。これはAngularJS(1系)でのモデルオブジェクトになります。

import moment from 'moment';
import { uiModules } from 'ui/modules';
import uiRoutes from 'ui/routes';

import 'ui/autoload/styles';
import './less/main.less';
import template from './templates/index.html';

uiRoutes.enable();
uiRoutes
  .when('/', {
    template,
    resolve: {
...
    }
  });

uiModules
  .get('app/simple-sample-kibana-plugin', [])
  .controller('simpleSampleKibanaPluginHelloWorld', function ($scope, $route, $interval) {
    $scope.title = 'Simple Sample Kibana Plugin';
    $scope.description = 'Sample plugin for explaining how to make kibana app';
...
    $scope.$watch('$destroy', unsubscribe);
  });

server/routes/example.js

hapi.jsというNode.jsのためのサーバーフレームワークです。このフレームワークをKibanaは使っており、Kibanaのサーバーとブラウザとのやり取りに使用するREST APIを記述するために使用しています。例えば、Elasticsearchとのやり取りを実際に行うAPIなどをこのREST API内部で記述します。

export default function (server) {

  server.route({
    path: '/api/simple-sample-kibana-plugin/example',
    method: 'GET',
    handler(req, reply) {
      reply({ time: (new Date()).toISOString() });
    }
  });

}

pathの部分がブラウザ側からアクセスするURLになります。実際にElasticsearchとやり取りする処理の書き方については、次回の記事で説明します。

アーキテクチャ（簡易版）

ざっくりですが、ファイルやディレクトリについて説明しました。簡単なデータのやり取りについての流れを説明します。

Kibana自体はNode.jsで実装されサーバーとして動作していますが、ブラウザでアクセスすることで画面を描画しています。簡単なコンポーネントを並べるとデータのやり取りはこのような形です。

すごく簡易で大雑把な絵ですが。。。

実際のプラグインとしては大きく、2つの処理があります。

ブラウザ上の処理
- クリックなどのイベント処理
- HTMLなどのレンダリング処理
Kibanaサーバー上の処理(Elasticsearchなどとの通信が必要な場合)
- 外部との通信処理
- ブラウザ上では重い処理

絵に記載しましたが、ブラウザ上の処理についてはAngularJSが主なフレームワークで、サーバー上の処理についてはhapi.jsがフレームワークとなっています。

まとめ

ということで、今回はディレクトリ構造とファイルの説明、どういったフレームワークが使われ、データのやり取りがどのように行われているか説明しました。

次回からは、実際に私が作成したAnalyze UIを元にElasticsearchとのデータのやり取りなどについて紹介していきます。

Analyze UIとKibanaのプラグインの作成方法（第2回）

Fri, 09 Feb 2018 18:17:37 +0900

第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。

第2回では、Kibanaのプラグインの作成方法を順を追って見ていこうと思います。今回は、プラグインのプロジェクトの作り方を説明します。どんなファイルがあるのかなどについては第3回で説明します（2018/02月現在の方法になります。残念ながら、Kibanaのプラグイン作成自体はまだExperimentalな話になっていますので、変更がある可能性があります）。

実はそれほど難しいというわけではありません。Kibanaのプラグインを作成するためのテンプレートが用意されています。template-kiban-pluginです。テンプレートのリポジトリのREADMEに作業手順の記載があります。

KibanaのリポジトリをClone、Checkout
Node.jsの環境を用意する
Kibanaを起動できるようにする
SAOのインストール
テンプレートによるプロジェクトファイルの生成

順を追って説明します。 PLUGIN_DEV_DIRというディレクトリ配下で作業をしている想定になります。

1. KibanaのリポジトリをClone、Checkout

開発環境として、Kibanaが必要です。Kibanaのプラグインを作るので。手順などはKibanaのCONTRIBUTING.mdに記載があります。ということで、まずはKibanaのリポジトリをCloneします。

cd PLUGIN_DEV_DIR
git clone git@github.com:elastic/kibana.git

このままだと、masterブランチなので、開発したい対象のKibanaのバージョンのブランチもしくはタグをcloneします。今回は6.2.1向けということで、次のようになります。

git checkout v6.2.1

これで、ソースが6.2.1向けになりました。

2. Node.jsの環境を用意する

Node.jsをインストールします。 Kibanaのリポジトリに.node-versionというファイルがあります。こちらにNode.jsのバージョンが記載されています。 Kibanaが使用しているNode.jsを利用できるようにします。ローカルではnvm利用してインストールしました。後から、切り替えが可能だからです。 nvm自体のインストールについてはnvmのサイトをご覧ください。 nvmがインストールできたら、次のコマンドで、Kibanaが使用しているバージョンをインストールします。

cd kibana
nvm install "$(cat .node-version)"

すでにnvmを利用している場合などは、Kibana起動時にKibanaのバージョンに合わせたNode.jsに切り替えるようにしてください。

3. Kibanaを起動できるようにする

Kibanaではyarnというjavascript向けのパッケージマネージャーを利用して起動やビルドなどを行います。まずはyarnをインストールします。最近npmからyarnに切り替えたようです。私はMacだったので、brewでインストールしました。インストールできたら、次のコマンドを実行します。

yarn

これにより、package.jsonから必要なライブラリなどをダウンロードして来てくれます。問題なければ「✨ Done in 439.30s.」というような表示がされます（結構時間かかりますね）。では、Kibanaを起動できるか確認してみましょう。さらに、Elasticsearchも起動してみます。 Kibanaのpackage.jsonの中にはElasticsearchを起動するためのスクリプトも用意されています。実際にはgruntを利用してタスクを実行しているようです。Elasticsearchの起動にはJavaが必要になります。今回は6.2.1なので、JDK 8以降がインストールされている必要があります。こちらはインストールされているものとします。

yarn elasticsearch

で起動できます。

>> Started 1 Elasticsearch nodes.

という表示が出てればOKです。次にKibanaです。別のTerminalを起動して、以下のコマンドで起動できます。

yarn start

これだけです。

server    log   [06:58:56.930] [info][listening] Server running at http://localhost:5603

この辺りが出てればKibanaのServerは起動済みです。また、Elasticsearchに接続できていれば、次のログが出ているはずです。

server    log   [07:02:18.010] [info][status][plugin:elasticsearch@6.2.1] Status changed from red to green - Ready

Elasticsearch接続用のKibanaのプラグインの状態になります。これで、Kibanaの環境が整ったことが確認できました。もちろん、Elasticsearchに関しては、yarnで起動せずに、tar.gzなどでダウンロードして来たElasticsearchを起動しておき、アクセスするといったことも可能です。プラグインなどをElasticsearchにもいれてテストしたい場合などはそちらの方が便利かもしれません。

4. SAOのインストール

では、一度、ElasticsearchとKibanaを停止しましょう。フォワグラウンドで起動しているので、それぞれのTerminalでCtrl+Cで停止できます。 Kibanaのプラグイン作成むけに、テンプレートが作られています。sao.jsというGitHubのリポジトリやnpmのパッケージをテンプレートとして使うことができるツールを利用してプラグインのプロジェクト（リポジトリ）を作成します。実際にテンプレートとなるリポジトリはtemplate-kibana-pluginになります。まずはSaoのインストールです。

npm install -g sao

プラグインのテンプレートのページには上記のようにnpmを利用したインストール方法になっていますが、次のようにyarnでも可能です。

yarn global add sao

これで、saoがインストールできました。

5. テンプレートによるプロジェクトファイルの生成

あとは、テンプレートを元にプロジェクトを作成します。 PLUGIN_DEV_DIRディレクトリ配下に、kibanaと同じ階層で作成するプラグイン用のディレクトリを作成します。

mkdir simple-sample-kibana-plugin

以下のような構成になります。

kibana                      simple-sample-kibana-plugin

次にテンプレートを適用していきます。

cd simple-sample-kibana-plugin
sao kibana-plugin@7.2.4

2行目がsaoを利用してプロジェクトを作成しているコマンドになります。すると、次のような質問が出て来ます。これらに答えるとプロジェクトに必要なファイル（package.jsonやREADME.mdなど）に入力した情報を適用したものを作ってくれます。

? Name of your plugin?
? Provide a short description
? What Kibana version are you targeting?
? Should an app component be generated?
? Should translation files be generated?
? Should an hack component be generated?
? Should a server API be generated?

実際に答えた内容はこちら。

? Name of your plugin? simple-sample-kibana-plugin
? Provide a short description Sample plugin for explaining how to make kibana app
? What Kibana version are you targeting? 6.2.1
? Should an app component be generated? Yes
? Should translation files be generated? Yes
? Should an hack component be generated? Yes
? Should a server API be generated? Yes

プラグインの名前などは、ディレクトリ名と同じものを入力補完してくれているので、そのままEnterでもOKです。 Descriptionについてはわかりやすいものを入力しましょう。バージョンは、先ほどのKibanaのリポジトリに合わせて、6.2.1にしてあります。あとは、作るプラグインの種類に応じて、必要なコンポーネントを作るかどうかの質問にYes/Noで答えます。今回はサンプルの説明ということもあるので、全てYesで答えました。ちなみに、私が実際に作成したanalyze-api-ui-pluginでは、appとtranslationとserverの3つを作成しました。ただし、translationについては現在はテンプレートで作成したままのファイルが入っており、実際には利用してないです。

完了したら、プラグインのサンプル入りのプロジェクトが完成です。もう一度、Elasticsearchを立ち上げて、プラグインのプロジェクトからKibanaを起動してアクセスしてみます。まずは、PLUGIN_DEV_DIR/kibanaディレクトリの下で、Elasticsearchを起動します。

yarn elasticsearch

次に、PLUGIN_DEV_DIR/simple-sample-kibana-pluginディレクトリの下で、以下のコマンドを実行し、プラグインが入った状態のKibanaを起動します。

yarn start

問題なく起動すれば、ブラウザでアクセスすると次のような画面が表示されるはずです。

左側にメニューが1つ増えています。クリックすると、上記画像のような画面が表示されるはずです。

これで、カスタムプラグインの開発ができる環境ができました！次回は、プロジェクトのディレクトリ構成や、どんなツールが内部で使用されてデータのやり取りが行われているかについて説明します。お楽しみに。

Analyze UIとKibanaのプラグインの作成方法（第1回）

Fri, 19 Jan 2018 15:36:46 +0900

あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。ということで、第1弾として、昨年少し作っていたKibanaのプラグインを何度かに分けて紹介したいと思います。

今回はAnalyze UIというプラグインの紹介です。

今回はインストール方法と簡単な機能紹介です。細かな紹介は個別にやりたいと思います。

Analyze UI pluginとは？

Elasticsearchの_analyzeというAPI(個人的に好きなAPIです)をご存知でしょうか？

Elasticsearchは全文検索エンジンで、データの検索には転置インデックスというものを使用します。 Elasticsearchにデータを登録する際に、text型のデータの場合、この転置インデックスのキーとなる単語を決める処理のことをAnalysisと呼びます（Analysisの詳細については割愛します。後日説明するかも？）。このAnalysisの処理が、入力されたデータの文字列に対してどのように行われて、結果としてどんな単語がキーとして用いられているかを確認できる機能が_analyze APIです。検索で単語がうまくヒットしないな？とか、なんで、こんなので検索結果に出てくるんだ？といった場合、このAPIを利用すると、どのような単語で転置インデックスが作られているかがわかるので、検索にヒットしない/する理由を見つけることができます。

Elasticsearchの便利な点はRESTfulなAPI＋JSONでやりとりができる点なのですが、_analyze APIの結果をJSONで受け取っても、見るのにちょっと苦労します。。。こんな感じ。

リクエスト：

POST _analyze
{
  "analyzer": "kuromoji",
  "text": "今年はブログをいっぱい書きますよ！"
}

レスポンス：

{
  "tokens": [
    {
      "token": "今年",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    },
    {
      "token": "ブログ",
      "start_offset": 3,
      "end_offset": 6,
      "type": "word",
      "position": 2
    },
    {
      "token": "いっぱい",
      "start_offset": 7,
      "end_offset": 11,
      "type": "word",
      "position": 4
    },
    {
      "token": "書く",
      "start_offset": 11,
      "end_offset": 13,
      "type": "word",
      "position": 5
    }
  ]
}

このくらいの量であればまだなんとかなりますが、文章が長くなると辛いですよね。

ということで、GUIがあると便利だろうなぁと。で、作ってみましたというのが今日紹介するKibana用のAnalyze UIプラグインです。こんな感じで、Kibanaのアプリの一部として動作しブラウザ上で、入力テキストの文字列がどのようにanalyzeされて、単語になるかがわかります。

（先ほどのAPIのサンプルと同じものを画面で入力した結果になります）。

インストール方法

現時点の最新版Kibana（6.1.2）に対応しています。 Kibanaのディレクトリでkibana-pluginコマンドを利用してインストールします。

./bin/kibana-plugin install https://github.com/johtani/analyze-api-ui-plugin/releases/download/6.1.2/analyze-api-ui-plugin-6.1.2.zip

これだけです。で、Kibanaを起動していただくと、左のメニューに「Analyze UI」という項目が増えています。

クリックすると、Analyze UIが表示されます。

初期画面は入力された文字を特定のAnalyzerで処理した場合の結果を見るための画面です。綱目の説明は画像をご覧ください。

先ほどのJSONよりは見やすくなったかと思います。そのほかにもいくつか画面や機能があるのですが、今日はこの辺りで。「_analyze API便利なんだけど、JSONは。。。」とか「検索うまくできないなぁなんでだろう？」と思っている方は、ぜひ試して見ていただければと。問題点などありましたら、GitHubのIssueを登録してください。

データ分析基盤構築入門を一部執筆しました。

Thu, 21 Sep 2017 10:02:30 +0900

久々に執筆しました。といっても、以前の書籍の更新版です。まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてますが。。。

ということで、みなさん「買って」から感想をいただけるとうれしいです！（以下の画像でAmazonにジャンプできます！Kindle版も発売中です。）

今回もElasticsearchの章を担当しました。 5.4ベースで書きましたが、ちょっとずつ6でどう変わるかなども記載してあります。また、付録ではLogstashやBeatsにもちょっと触れています。また、自分が一番好きなKibanaの機能であるDev ToolsのConsoleについても記載してあります。こちらも合わせて目を通していただければと。

みなさんのフィードバック（ツイート、ブログ、Amazonのコメントなどなど）をお待ちしております！

Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目

Tue, 01 Dec 2015 11:28:11 +0900

こんにちは、@johtaniです。

早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。ということで、Advent Calendarの季節が始まりました。

この記事はElasticsearch Advent Calendar 2015の1日目のエントリです。

今日は、最近公開されたTimelionの紹介をしたいと思います。

Timelion?

11/12に公開されたばかりのアプリになります。（公式のブログはこちら。ブログでは動画による説明もあり）

Kibanaにプラグインとしてインストールすることで使用することができるようになるアプリです。 Timelionと書いて「Timeline」と読むようです。 Kibanaとは異なるグラフ描画のプラグインになっています。

Kibana 4.2からプラットフォーム化

Kibana 4.2から、Kibanaにプラグイン機構が導入されました。 Kibanaとしての機能以外にも、プラグインとして、アプリを追加できるようになっています。 Timelionもその一つです。

インストール

Timelionを試してみるには、ElasticsearchとKibanaが必要になります。（こちらは、すでにインストールされているとして。。。）

Kibanaのコマンドを利用して、プラグインをインストールします。

bin/kibana plugin -i kibana/timelion

インストールしたら、Kibanaにアクセスして、Timelionを呼び出します。

Timelionへアクセス

ブラウザでlocalhost:5601にアクセスすると、Kibanaが出てきます。 Kibanaのプラグイン選択のアイコンをクリックし、Timelionのアイコンをクリックします。

すると、初期画面はこんな感じです。直近15分のElasticsearchに入っているデータがが全部出てきます。チュートリアルも出てきてます（初回起動時に出たはず）

Kibanaでの検索窓の部分に関数を指定していくことで、グラフが描画できるツールになっています。

サンプル：気温データを可視化

百聞は一見に如かずということで、気象庁のデータを使って、ちょっとしたグラフを書いてみました。 1年間の気温の推移と日照時間になります。

上のグラフが那覇、下グラフが札幌の気温のグラフになります。

赤いライン：最高気温
青いライン：最低気温
黄色い棒グラフ：日照時間

最低気温と日照時間はグラフは次のような式で描画しています。

青いラインの最低気温

気温のグラフになります。

.es(index='tenki2', q='city:naha', metric='avg:temperature_min').label('min'),

.es()がelasticsearchに対するデータ取得の関数です。引数は次のような意味になります。

index：対象とするインデックス名
q：検索クエリ。ここでは、cityというフィールドにnahaで検索。
metric：描画対象となっているデータの入ったフィールド。temperature_minというフィールドの1日毎の平均値を取得

最低気温と最高気温は別々のフィールドに格納してあります。最高気温の場合は（temperature_max）を指定します。

.label(min)で、グラフの凡例の指定です。残念ながら、日本語の指定は現時点（2015年12月01日時点）ではうまくいかなかったです。（https://github.com/elastic/timelion/issues/17）

デフォルトでは、線グラフが選択されているので、グラフの種類は特に指定はしていません。明確に指定する場合はlines()を指定します。

黄色い棒グラフの日照時間

.es(index='tenki2', q='city:naha', metric='avg:sunlight').label(sunlight).bars()

.es()に関しては最低気温のグラフとほぼ一緒です。異なるのは、metricの取得対象のフィールド名です。

.label()で凡例を指定しています。先程と同様です。

最後に、棒グラフにしたいため、.bars()を指定しています。

その他に用意されている関数について知りたい場合は、Timelionのヘルプを表示すると説明が出てきます。 cusum()のような値を累積して表示するような関数も用意されています。

まとめ

Kibanaとは少し違うアプローチで時系列データを描画するためのツールとなっています。線グラフと棒グラフを一つのグラフに描画したりもできますし、累積のグラフなんかも描画できるようになっています。

実験的なプロジェクトである、Timelionの紹介でした。ここでのノウハウがkibanaにフィードバックされると色々と面白いことになるんじゃないかなと。

ということで、

明日は、zoetroさんの「Kibanaのプラグインの話」になります。お楽しみに！

Kibana 4.2.0リリース（日本語訳）

Thu, 29 Oct 2015 16:20:19 +0900

※この記事は次のブログを翻訳したものになります。

原文：Kibana 4.2.0 released

Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。これが何を意味するでしょう？速さ、安定さ、新しい機能。試してみたい方は、いますぐダウンロードしてください。そうでない方は、Kibana 4.2の楽しい機能について読んでみてください。

暗黒面は怖い？

そんなことありません。私たちは常にチャートチャートとダッシュボードを組み立てている組み立てている間は明るいバックグラウンドを使うことを推奨してきましたが、時々、巨大なスクリーンで暗い部屋で誰も明るい画面から目を背けないようにしたいでしょう。その影響を小さくするためにダークモードを導入しました。あなたは、NOCや天文台、その他の暗い場所でKibanaのダッシュボードを楽しむことができます。

画像あり。 ※画像に関しては原文をご覧ください。

地図のカスタマイズ

Kibanaの地図は素晴らしいですが、もっと多くのオプションが望まれていると聞きました。もし地図に関して知識があるなら、Kibana 4.2のWMSバックグラウンド地図サポートを試してみてください。 WMSは非常に強力で、US Geological Surveyを含む多くの無料サービスがあります。 http://viewer.nationalmap.gov/example/services/serviceList.html

画像あり。 ※画像に関しては原文をご覧ください。

シナリオは？

何かおかしい時、何が起こっているかを正しく知ってもらいたいので、Kibanaがそのタイミングで注目したいコンポーネントがあるなら、どのように動いているかという概要を知るためのサーバステータスページを作りました。もちろん、全てがOKであるというのを知りたいだけの場合でも、settingメニューのStatusタブからいつでも呼び出せます。

画像あり。 ※画像に関しては原文をご覧ください。

全てにおいて速く

ブラウザリフレッシュはKibana 4.2の新しいコードビルディングシステムのおかげで、さらに早くなりました。また、メモリを覚えてます？~~Pepperidge Farm~~Kibanaが覚えています。 Kibana 4.2は小さな小さな小さなメモリフットプリントを管理している間、長い長い長い時間実行されているダッシュボードを見ることができるような大きなメモリのクリーンアップも含んでいます。

もっとありますが。。。

小さな微調整がいくつもあります。また、今後紹介する本当に刺激的なものの基礎を気づき上げてきました。これからもElasticのブログ、Twitter、KibanaのGitHubリポジトリに注目し、~~モンスタートラック~~アナリティクスの瞬間に立ち会ってください。

Release, we have（日本語訳）

Thu, 29 Oct 2015 14:18:59 +0900

※この記事は次のブログを翻訳したものになります。

原文：Relase, we have ※画像に関しては原文をご覧ください。

Elasticにとって大きな1日（社内では「release bonanza」と呼んでいる）です。多くの主要なプロダクトを新たにリリースしました。そして、本日、それらを一緒に利用する時にそれらを一緒に利用する時にユーザの体験についてまとめてみました。

次の通りです。

Elasticsearch 2.0リリース。大きなマイルストーン、チームによる改善、そして、コミュニティからの素晴らしい貢献。 Pipeline Aggsと呼ばれる新しいタイプのaggregations、クエリとフィルタのコンセプトを統合することにより簡素化されたクエリDSL、 better compressionオプション、 JavaのSecurity Managerを有効にすることによる強化されたセキュリティ、 FSの挙動に関する強化（fsync、checksum、atmicなリネーム）、パフォーマンス、マッピングの挙動の一貫性などなどです。また、我々のチームによる改善も含まれているLucene 5ベースにアップグレードしています。

Kibana 4.2リリース。 Elasticsearch 2.0対応、ダークテーマ、カスタマイズ可能な地図、多くの改善。 Kibana 4.2の多くに作業については外部プラグインサポートといった、内蔵に関するものでした。この後の説明に続きます。

Marvel 2.0リリース。 Elasticsearch 2.0対応、合理化されたメトリックス、簡素化されたUI、多くはKibanaプラグイン（Kibanaプラットフォーム上に構築）としての書き換えです。このKibana拡張の最初の努力は、Kibanaのプラグインをどうやって書くか、 Kibanaユーザに公式に何をする必要があるかといったものを特定するのに役立ちました。おっと、忘れるところでした、Marvelを全てのユーザにフリーで使えるようにしました。マルチクラスタサポートについては有償となります。

Sense 2.0リリース。 2つ目のKibanaプラグインがこれです。 SenseをKibanaプラグインとして書き換えました。 Elasticsearch 2.0サポート、複数リクエストの実行、 curlへのコピーなどです。おっと、忘れるところでした。オープンソースとすることにしました！

Shield + Watcher 2.0リリース。ElasticsearchのためのセキュリティプラグインであるShieldと、アラート管理のためのプラグインであるWatcherにも多くの結果が入っています。最も要求のあった機能である、フィールドお呼びドキュメントレベルでのセキュリティについて、Luceneに落とし込んで実装しました。また、セキュリティの操作についてプラガブルに実装できるように変更しました。 Watcherは監視の無効化、SlackやHipChatへの通知（bot ops向け）が可能です。

Logstash 2.0リリース。 Elasticsearch 2.0のサポート、クリーンな停止、全面的なパフォーマンス改善、Beatsサポート。

ご覧の通り、すべてのプロダクトに関する大きな結果です。チーム間およびFoundの開発者との間での密な連携に感謝します。これらが私たちが公式にElasticsearch / KibanaをホストしているFoundで利用可能です。

ひゅう、息切れしました。チームがしてきたことは、感動的で、謙虚で、刺激的です！ Elasticが会社として、全てのユーザ、コントリビュータがどのように私たちの大きなミッションに対する結果をもたらしたかという素晴らしい良い例です。ユーザに愛され、楽しまれ、成功に導き、革新させる製品を是非ご利用ください。ありがとうございます。

“A Lion, in Africa?” - まだまだ終わりではありません。この文言で終わりにしますが、すぐに（本当にすぐに）戻ってきます。;)

インデックステンプレートとLogstash

Tue, 25 Nov 2014 16:25:46 +0900

前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。前回の記事では、Logstashの設定ファイルについて説明しました。今回は「Elasticsearchに設定するインデックステンプレート」について説明します。

テンプレートの設定

Elasticsearchでは、登録するデータの特性に合わせてMappingを定義する方がデータを効率良く扱うことができる場合があります。この場合、通常ですと、インデックス作成時にMappingを指定します。

ただ、今回は、インデックス名に「年」を含める形で指定してあります。「年」はLogstashで処理したデータによって決まります。このため、あらかじめMappingを指定してインデックスを作成するのは難しいです。

このような場合に便利な機能として、「インデックステンプレート」があります。

インデックステンプレートとは

実際のテンプレートの説明に入る前に、少しだけ説明を。インデックステンプレートとは、インデックスが作成されるタイミングで自動的に適用される設定をテンプレートとして登録できる機能のことです。実際にテンプレートが適用されるかどうかは、インデックス名で判断されます。

例えば、大して重要でもなく、データ量も少ないインデックス用のテンプレートとして、シャード数が1、レプリカ数が0、"_source"を保存しない設定のテンプレートを登録する場合、次のようになります。

curl -XPUT localhost:9200/_template/template_1 -d '
{
  "template" : "te*",
  "settings" : {
    "number_of_shards" : 1,
    "number_of_replicas" : 0
  },
  "mappings" : {
    "type1" : {
      "_source" : { "enabled" : false }
    }
  }
}
'

_templateがインデックステンプレートを登録するためのエンドポイントです。 template_1がこのテンプレートのIDです。削除などについては、このIDを利用します。

そして、重要なのは、"template“の設定です。 “template“には、このテンプレートが適用されるべきインデックス名を記載します。上記サンプルではte*となっているため、teで始まる名前のインデックスを作成した場合にテンプレートにある設定が適用されます。

今回利用するテンプレート

私がJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモで利用したインデックスのテンプレートは次のものになります。 “template“には、前回の記事で紹介したoutput/elasticsearchの設定に合致するnew_demo_access_log-*を指定しています。

curl -XPUT localhost:9200/_template/new_access_log_for_demo -d '
{
  "template": "new_demo_access_log-*",
  "settings": {
    "number_of_shards": "2",
    "number_of_replicas": "0"
  },
  "mappings": {
    "_default_": {
      "dynamic_templates": [
        {
          "string_template": {
            "mapping": {
              "index": "not_analyzed",
              "type": "string"
            },
            "match_mapping_type": "string",
            "match": "*"
          }
        }
      ],
      "properties": {
        "path": {
          "type": "multi_field",
          "fields": {
            "no_analyzed": {
              "index": "not_analyzed",
              "type": "string"
            },
            "analyzed": {
              "index": "analyzed",
              "type": "string"
            }
          }
        },
        "referer": {
          "type": "multi_field",
          "fields": {
            "no_analyzed": {
              "index": "not_analyzed",
              "type": "string"
            },
            "analyzed": {
              "index": "analyzed",
              "type": "string"
            }
          }
        },
        "agent": {
          "type": "multi_field",
          "fields": {
            "no_analyzed": {
              "index": "not_analyzed",
              "type": "string"
            },
            "analyzed": {
              "index": "analyzed",
              "type": "string"
            }
          }
        },
        "geoip": {
          "type": "object",
          "properties": {
            "location": {
              "geohash": true,
              "geohash_precision": 10,
              "type": "geo_point",
              "lat_lon": true,
              "geohash_prefix": true
            }
          }
        },
        "response": {
          "copy_to": "response_int",
          "type": "string"
        },
        "bytes": {
          "type": "long"
        },
        "response_int": {
          "type": "integer"
        }
      }
    }
  }
}
'

settings設定

デモ用であり、手元で2台のノードを起動するということもあり、number_of_shardsに2を、number_of_replicasに0を指定してあります。

mappings設定

インデックスのタイプ

Mappingsの指定は通常、特定のタイプを指定します。今回のデモでは、1種類しかないのですが、タイプ名を特に意識しないために、_default_を使用しました。この場合、任意のタイプに適用されることとなります。タイプを指定してMappingの設定を行う場合は_default_の部分に特定のタイプ名を記入します。

"mappings": {
  "_default_": {
    ...

ダイナミックテンプレート

次はダイナミックテンプレートです。インデックステンプレートはインデックスの設定をテンプレート化しました。ダイナミックテンプレートはフィールドに対してテンプレートを設定できます。

以下のダイナミックテンプレートでは、stringタイプのフィールドのデフォルト設定を変更しています。通常、stringタイプのフィールドはanalyzedとなりますが、not_analyzedに変更してあります。詳しく検索したいフィールドの方が少ないためです。

...
"dynamic_templates": [
  {
    "string_template": {
      "mapping": {
        "index": "not_analyzed",
        "type": "string"
      },
      "match_mapping_type": "string",
      "match": "*"
    }
  }
],
...

multi_field指定

検索もしたいし、Terms Aggregationでも利用したいフィールドについては、multi_fieldを利用して、 analyzedとnot_analyzedの2種類のフィールドを用意しています。 multi_field設定を用いることで、1つのJSONのデータから、異なる形のフィールドを用意することが可能です。

今回のテンプレートでは、path、referer、agentにmulti_fieldを指定しました。

...
"path": {
  "type": "multi_field",
  "fields": {
    "no_analyzed": {
      "index": "not_analyzed",
      "type": "string"
    },
    "analyzed": {
      "index": "analyzed",
      "type": "string"
    }
  }
},
...

例えば、上記の設定の場合、入力のJSONはpathというデータのみですが、インデックス上にはpath.no_analyzedと path.analyzedというフィールドができあがります。実際に検索する場合は、path.analyzed:検索したい文字列という形で検索をすることで、いわゆる部分一致のような検索が可能です。また、完全一致をしたい場合はpath.no_analyzed:検索したい文字列という指定になります。用途を考えると、requestも指定したほうが良いかもしれません。

geoip

Logstashでgeoipデータを付与していました。このgeoipのデータをKibana4で利用するために、geoデータとして登録する必要があります。

"geoip": {
  "type": "object",
  "properties": {
    "location": {
      "geohash": true,
      "geohash_precision": 10,
      "type": "geo_point",
      "lat_lon": true,
      "geohash_prefix": true
    }
  }
},

上記の設定がgeoデータの指定です。 typeにobjectが指定してありますが、これは、geoipのデータがネストしているためです。 geoipオブジェクトのうち、緯度経度のデータはlocationに入っているため、こちらに緯度経度関係の設定を指定します。

"type": "geo_point"：geo_pointタイプであることを指定
"geohash": true：緯度経度のデータをもとに、geohashの値もインデックス
"geohash_precision": 10：geohashの精度の指定
"lat_lon": true：緯度経度を個別の.lat、.lonというフィールドにもインデックス
"geohash_prefix": true：該当するgeohashのみでなく、その親にあたるgeohashについてもインデックスする

response、response_int、bytes

最後は、response、response_int、bytesです。

responseには、HTTPステータスコードが入ります。文字列としても扱いたいですが、integerとして、Renge Aggregationなどを行いたいので、 response_intというフィールドにも値を入れています。 multi_fieldでも可能ですが、ここでは、copy_toを利用しました。 copy_toを用いることで、異なるフィールドに値をコピーすることができます。

bytesについては、longで扱いたいとういう理由だけです。


"response": {
  "copy_to": "response_int",
  "type": "string"
},
"bytes": {
  "type": "long"
},
"response_int": {
  "type": "integer"
}

まとめ

今回はデモに利用したインデックスてプレートについて説明しました。前回の、Logstashの設定とこのインデックステンプレートを用いることで、Kibanaで解析するデータの準備ができます。実際の操作などについては、また次回の記事で説明しようかと思います。

不明な点、誤植などありましたら、コメント欄へお願いします。

Logstashを利用したApacheアクセスログのインポート

Fri, 21 Nov 2014 17:30:39 +0900

JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。

ただ、セッションでは、どうやってElasticsearchに投入したのかという詳しい話をしていませんでした。本記事では、データ取り込み時に利用したLogstashの設定ファイルについて説明します。

Logstashの設定の説明に入る前に、全体の流れを。「ApacheアクセスログをKibana4により可視化」です。

材料の準備

「ApacheアクセスログをKibana4により可視化」に必要な材料は次の通りです。（今回は起動するところまでいかないので、実際に必要なのは次回以降になります。）

Java 7（u55以上を1つ）
Logstash 1.4.2（1つ）
Elasticsearch 1.4.0（1つ）
Kibana4 Beta2（1つ）
Apacheのアクセスログ（適量）

Apacheのアクセスログ以外は、公式サイトからダウンロードできます。それぞれをダウンロードして、起動できるようにしておきましょう。

※1台のマシン上で行う場合は、アクセスログの量を少なめにするなどの対策をとりましょう。 ※今回は、1台のマシン（Mac）上で、VMなどを利用せず、それぞれ直接起動するものとします。

可視化の手順と流れ

可視化の流れとしては、

Logstashでファイルを読み込み、各種処理（パースしたり、情報を追加したり、切り出したり）
Elasticsearchに保存
Kibanaでグラフを作ったり、検索してみたり

です。

今回は、1のLogstashでファイルを読み込んだりする設定ファイルの説明です。

Logstashの設定

Logstashの基本

まずは、Logstashの設定ですが、簡単にLogstashの説明を。 Logstashは大きく3つのパーツに分かれています。

input：データの入力処理
filter：inputで読み込んだデータに対する操作など
output：データの出力処理

inputでデータを読み込み（複数可）、filterでデータに対して各種処理を行い、outputでデータを指定されたところに出力（複数可）します。

アクセスログの読み込み設定

アクセスログの読み込み処理は大まかに次のようなものとなります。

アクセスログを読み込む（input/file）
読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok）
日付のパース（filter/date）
クライアントIPアドレスにgeoipの情報を付加（filter/geoip）
リクエストのパスの第1階層の抽出（filter/grok）
ユーザエージェントのパース（filter/useragent）
Elasticsearchへの出力（output/elasticsearch）

設定ファイルは次のようなものになります。

input {
  file {
    path => "/Users/johtani/demo_access_log/*/*.log"
    start_position => "beginning"
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
    break_on_match => false
    tag_on_failure => ["_message_parse_failure"]
  }
  date {
    match => ["timestamp", "dd/MMM/YYYY:HH:mm:ss Z"]
    locale => en
  }
  geoip {
    source => ["clientip"]
  }
  grok {
    match => { "request" => "^/%{WORD:first_path}/%{GREEDYDATA}$" }
    tag_on_failure => ["_request_parse_failure"]
  }
  useragent {
    source => "agent"
    target => "useragent"
  }
}

output {
  elasticsearch {
    host => "localhost"
    index => "new_demo_access_log-%{year}"
    cluster => "demo_cluster"
    protocol => "http"
  }
}

1. アクセスログを読み込む（input/file）

inputのfileモジュール(a)を使用してアクセスログのファイルを読み込みます。 pathでアクセスログのファイルのパスを指定します。今回利用したアクセスログはdemo_access_log/2010/access20100201.logといった日毎のファイルに分割されていたため、 *を利用してファイルのパスを指定しました。また、今回は既存のファイルの読み込みだけのため、start_positionにbeginningを指定してあります。デフォルトではendが指定されるため、Logstashを起動後に追記されたログから対象になってしまうためです。その他の設定については、公式ガイドをご覧ください。

input {
  file { # a
    path => "/Users/johtani/demo_access_log/*/*.log" # b
    start_position => "beginning" # c
  }
}

Logstashでは、ファイルをどこまで読み込んだかという情報を保持するために、sincedbを利用しています。設定変更後に同じファイルを最初から読み込みたい場合などは、こちらのファイルを一旦削除するなどの対応が必要です。

ちなみに、読み込んだデータは次のようなJSONになっています。

{
  "message": "読み込んだアクセスログ",
  "@version": "1",
  "@timestamp":"2014-11-21T06:16:21.644Z",
  "host":"jupiter.local",
  "path":"/Users/johtani/demo_access_log/2010/access20100201.log"}
}

特に指定がない場合は、messageに読み込んだデータが入ってきます。 @timestampがLogstashが読み込んだ時刻、hostはLogstashが動作しているホスト名です。 pathはfileモジュールが読み込んだファイルのパスを設定しています。この後の処理で、どこの項目に対して処理を行うかといったことが重要になるので、

2. 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok）

2.〜6.の処理は、inputで読み込んだ1アクセスログに対する処理となります。

ここでは、grokフィルタを使用して Apacheのアクセスログを各フィールドに分割します。 Logastashでは、簡単に使えるようにいくつかのパターンが用意されています。 Apacheのログのために、COMBINEDAPACHELOGというのが用意されています。今回はこちらを使用しています。その他にも日付などパターンが用意されているので、試してみてください。

messageにアクセスログが入っているので、こちらの項目に対してCOMBINEDAPACHELOGのパターンを matchで適用してフィールドに抜き出します。 tag_on_failureは、matchでパースに失敗した場合に、tagというフィールドに指定した文字列を出力する機能になります。デフォルトだと_grokparsefailureが付与されますが、ここでは、どの処理で失敗したがを判別するために文字列を変更しています。

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
    break_on_match => false
    tag_on_failure => ["_message_parse_failure"]
  }
  ...

clientip、ident、auth、timestamp、verb、request、httpversion、response、bytes、referrer、agentがgrokフィルタにより抜き出された項目です。

{
  "message":"アクセスログ",
  "@version":"1",
  "@timestamp":"2014-11-21T07:20:54.387Z",
  "host":"jupiter.local",
  "path":"/Users/johtani/demo_access_log/2010/access20100201.log",
  "clientip":"クライアントのIPアドレス",
  "ident":"-",
  "auth":"-",
  "timestamp":"01/Feb/2010:00:00:26 +0900",
  "verb":"GET",
  "request":"/images/favicon.ico",
  "httpversion":"1.1",
  "response":"200",
  "bytes":"318",
  "referrer":"\"-\"",
  "agent":"\"Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)\""
}

3. 日付のパース（filter/date）

Logstashは特に指定がない場合、inputでデータを取り出した日付が@timestampとなります。そして、このフィールドが特に指定がない場合は、Elasticsearchのデータの日付となり、Kibanaで利用する日付となります。

リアルタイムにアクセスログを読み込む場合は、読み込んだ日時でもほぼ問題はありませんが、過去データの場合はそうもいきません。そこで、dateフィルタを使用して、@timestampの値を書き換えます。

date {
  match => ["timestamp", "dd/MMM/YYYY:HH:mm:ss Z"]
  locale => en
}

上記では、timestampという項目に対してdd/MMM/YYYY:HH:mm:ss Zという日付パターンの場合に値を書き換える設定となります。なお、日付の月の部分がFebとなっているため、localeにenを指定しています。Logstashが動作するマシンのlocaleがjaなどの場合にパースに失敗するためです。

4. クライアントIPアドレスにgeoipの情報を付加（filter/geoip）

どの国からのアクセスかなどを判別したいので、IPアドレスを元にgeoipを利用してより詳細な情報を付与します。 Logstashでもこの機能が用意されており、簡単に利用ができます。

geoip {
  source => ["clientip"]
}

これだけです。対象とするIPアドレスのフィールドを指定しているだけです。 geoipというフィールドが追加され、次のような情報が付与されます。国名、緯度経度、タイムゾーンなどです。

{
  ...  
  "geoip": {
    "ip": "IPアドレス",
    "country_code2": "JP",
    "country_code3": "JPN",
    "country_name": "Japan",
    "continent_code": "AS",
    "latitude": 36,
    "longitude": 138,
    "timezone": "Asia/Tokyo",
    "location": [
      138,
      36
    ]
  }
  ...
}

5. リクエストのパスの第1階層の抽出（filter/grok）

リクエストされたURLはrequestフィールドにありますが、個別のURLだと、大まかな集計が大変です。もちろん、クエリで処理することもできますが、Logstashで処理するついでに、第1階層のディレクトリ名を抽出しておくことで、検索や集計を行いやすくしておきます。

grok {
  match => { "request" => "^/%{WORD:first_path}/%{GREEDYDATA}$" }
  tag_on_failure => ["_request_parse_failure"]
}

また、grokフィルタの登場です。今回は、WORD:first_pathという記述方法で、WORDパターンにマッチした文字列をfirst_pathというフィールドに展開する指定をしています。

例えば、サイトのスクリプトなどがscriptsというディレクトリにある場合は、first_pathの値を利用して、後続のフィルタでログデータを出力しないといった処理にも使えます。

6. ユーザエージェントのパース（filter/useragent）

Logstashではユーザエージェントの文字列から、いくつかの情報を付与するフィルタも用意されています。 useragentフィルタです。

useragent {
  source => "agent"
  target => "useragent"
}

agentというフィールドにユーザエージェントの文字列があるので、このフィールドに対してフィルタを適用します。元の文字列も取っておきたいので、useragentという別のフィールドに出力するように指定してあります。

"useragent": {
  "name": "Firefox",
  "os": "Windows XP",
  "os_name": "Windows XP",
  "device": "Other",
  "major": "17",
  "minor": "0"
},

このように、OS名やバージョン名などが抽出できます。

7. Elasticsearchへの出力（output/elasticsearch）

最後は、Elasticsearchへのデータの出力設定です。

indexにて、出力するindex名を指定してあります。また、年毎のインデックス名にするために%{year}を利用しています。 sprintf formatです。

elasticsearch {
  host => "localhost"
  index => "new_demo_access_log-%{year}"
  cluster => "demo_cluster"
  protocol => "http"
}

まとめ

ということで、今回はアクセスログをLogstashにて読み込む時の設定について説明してきました。次回は、実際にLogstashを起動してElasticsearchにデータを登録するところまでを説明します。

JJUG CCCや勉強会のデモに用いたデータは、 Elasticsearchにデータを登録する前にテンプレートも設定してありました。こちらについても、次回説明しようと思います。

不明な点、誤植などありましたら、コメント欄へお願いします。

サーバ/インフラエンジニア養成読本ログ収集~可視化編を手伝いました

Mon, 04 Aug 2014 21:54:00 +0900

懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！

本書について

共著者の方々のブログが詳しいので、そちらを読んでもらいつつ。実際にログを収集して解析されている方々と一緒に書かせていただくことで色々と勉強させていただいています。

共著者の方々のブログ

どの辺を書いたの？

「特集３：Elasticsearch入門」（なんか、入門ばっかりだなぁ）を書かせていただきました。データストア入門ということで、ほんとうに簡単な他のデータストアを説明し、Elasticsearchってどんなものかを単語の説明をしつつ紹介してみました。

Elasticsearch自体は多くの機能を持っており、それ単体で分厚い書籍がかけるので、ログ検索に関係ありそうな部分をピックアップしてみました。あとは、運用時に気をつける点や便利なツール（Curatorなど）の紹介をしています。

また、Hadoopと合わせて利用してみたい、すでにHadoopにあるデータも活用してみたいという話もありそうだということで、elasticsearch-hadoopについても簡単ですが紹介してあります。

その他感想

個人的に、忙しい時期（参考記事）だったので、あんまり力になれてないので大変申し訳なく思っています。。。ただ、素晴らしい出来（カラーでKibanaの解説が日本語で読めたり、Fluentdの逆引きのリストがあったり、ログを貯めて可視化する意義を説明してあったり）です。

ぜひ、読んだ感想をいただければと！

第2回elasticsearch勉強会を開催しました！ #elasticsearchjp

Tue, 12 Nov 2013 18:16:00 +0900

第2回を開催しました！すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。ステキな会場を提供していただいた、リクルートテクノロジーズさん、運営していただいた方々、スピーカーの皆さん、参加者の皆さん本当にありがとうございました。今回も素敵な看板ありがとうございます。

今回もしっかり楽しめたので、次回も頑張ります！

今回は、elasticsearch-jpMLの紹介とかをできたのでよかったかなぁと。ぜひ、活用してください！どんな質問でもいいので。

あと、スライドに入ってた例の本もよろしくです。

ということで、懇親会も盛り上がったし楽しかったです。今後も場の提供＋自分の勉強のトリガーとして、開催していくので、ご協力お願いします！聞きたい話など、MLや@ツイートしていただければと。

elasticsearchのRouting機能：株式会社シーマーク　大谷　純　（@johtani）

スライド：Routing機能※スライドはPDFです。

ド緊張で、大した発表ではなかったですが。。。どちらかと言うとSolr本の紹介だったかもなぁ。スミマセン。

※スライドが一部文字が消えてるので、作りなおすかも。

ElasticSearchを使ったBaaS基盤の開発(仮)：株式会社富士通ソフトウェアテクノロジーズ滝田聖己さん（@pisatoshi）

スライド：https://speakerdeck.com/pisatoshi/elasticsearch-trial-and-error

本日はお越しいただきありがとうございました！しかも静岡から！今後もよろしくお願い致します。

EnchantMoonでシステム構成ｗ
0.17.0から利用されていると。（スゴイ）
プライマリのデータストア！ただし、登録元データはMySQLにもある。
階層も深く、大きめのドキュメント。
レプリカ１、インデックスのバックアップも取ってないと。。。
ルーティングの機能
DynamicMappingの問題点
マッピング定義が肥大、型がコンフリクト。。。苦労しっぱなし
データ登録は１台にして、１台で一気に登録してから再配置
実際に運用とかされてるので、いろんなノウハウがまだまだありそう！

Kibana入門：水戸祐介さん（@y_310）

スライド：https://speakerdeck.com/y310/kibanaru-men

（やっぱりru-menになってるｗ）

実は、押しかけて話してもらうように説得したのでした。今後もよろしくです。

COOKPADの方によるKibanaのお話。
Kibanaの利点とかなんで？とか。
画面構成の説明から
ダッシュボードは必ず保存して！リロードしたら悲しい思いをしてしまうので。
sparkline便利そうだなぁ。ほんとに、データサイエンティスト系のツールを目指してるのかな
一通り、ダッシュボードに配置できるパネルの説明してもらえたのですごく参考になりました！
Tips周りが役に立ちそう。not_analyzedは重要ですよね。

LT

「データ集計用ダッシュボードブラウザとしても使えるElasticSearch＋Kibana v3を利用する際の運用ノウハウ紹介」：株式会社リブセンス Y.Kentaro さん (@yoshi_ken) さん

スライド：http://www.slideshare.net/y-ken/elasticsearch-kibnana-fluentd-management-tips

Kibanaの紹介とかFluentdの紹介。
Tips満載すばらしい。
JDBC riverは0.90.6ではうまく動かないので、気をつけてと。

「Fluentd as a Kibana」：@repeatedly さん

スライド(gist)？：https://gist.github.com/repeatedly/7427856

Kibanaがfluentdの中で動くと！？

「Authプラグインでアクセスコントロール」：株式会社エヌツーエスエム菅谷信介さん (@shinsuke_sugaya)

スライド：http://www.slideshare.net/shinsuke/es-auth-plugin

API毎？インデックスごと？にアクセス制御ができるプラグイン

Kibana3というのもありまして

Wed, 19 Jun 2013 23:43:00 +0900

前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな）

Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というのが存在します。

Kibana3って？

Kibana2はRubyで書かれていましたが、Kibana3はHTML＋JavaScriptで構成されています。ですので、ApacheなどのWebサーバに配置することで、利用が可能となります。ただ、HTML＋JavaScriptのため、ブラウザ上で動作するためブラウザが動作するマシンからElasticSearch（通常だとhttp://マシン名orIPアドレス:9200/とか）にアクセスできなければいけないという制限があります。

この条件さえクリア出来れば、Kibana3ではKibana2よりも様々なパネルが用意されていて、色々できそうなのでお勧めです。

インストール

ElasticSearchやログについては、前回の記事の環境を利用しました。ですので、Kibana3のインストールのみです。（ApacheもCentOSのサーバに入っていたので。）

ダウンロードして、Apacheの公開ディレクトリに置いただけです。（お試し環境のため、権限とかは大目に見てください。

$ git clone https://github.com/elasticsearch/kibana.git kibana-javascript
$ cp -R kibana-javascript /var/www/html

今回はApacheとElasticSearchが同一マシン（＝同一IPアドレスでアクセス可能）で動作している＋ElasticSearchへのアクセスのポートがデフォルト（9200）のため特に設定が必要ありませんでした。

ElasticSeachサーバとKibana3のApacheのサーバが別のサーバの場合やElasticSearchサーバのポートが異なる場合はkibana-javascript/config.jsファイルの編集が必要になります。 cloneしてすぐのconfig.jsは、以下のとおりです。

/*

elasticsearch:  URL to your elasticsearch server. You almost certainly don't
                want 'http://localhost:9200' here. Even if Kibana and ES are on
                the same host
kibana_index:   The default ES index to use for storing Kibana specific object
                such as stored dashboards
modules:        Panel modules to load. In the future these will be inferred
                from your initial dashboard, though if you share dashboards you
                will probably need to list them all here

If you need to configure the default dashboard, please see dashboards/default

*/
var config = new Settings(
{
  // By default this will attempt to reach ES at the same host you have
  // elasticsearch installed on. You probably want to set it to the FQDN of your
  // elasticsearch host
  elasticsearch:    "http://"+window.location.hostname+":9200",
  // elasticsearch: 'http://localhost:9200',
  kibana_index:     "kibana-int",
  modules:          ['histogram','map','pie','table','stringquery','sort',
                    'timepicker','text','fields','hits','dashcontrol',
                    'column','derivequeries','trends','bettermap'],
  }
);

ポート番号が異なる場合は、1つ目の「elasticsearch:」で指定されている「9200」を環境に合わせて編集するだけになります。 Kibana3とElasticSearchのホストが異なる場合は、1つ目の「elasticsearch:」の行をコメントアウトし、2つ目を有効にしてから環境に合わせたURLに修正して保存すればOKです。

以上で、インストールは完了します。あとは、以下のURLにアクセスするだけです。

http://hogehoge/kibana-javascript/

画面構成

アクセスすると次のような画面が表示されます。

初期画面

左上に赤い帯で、「 Oops! Could not match index pattern to any ElasticSearch indices」とエラーが表示されました。

KibanaはElasticSearchに「logstatsh-年.月.日」という日付ごとのインデックスが存在することが前提となっています。 Kibanaに初めてアクセスした場合、「logstash-当日日付」で始まるインデックスを描画しようとします。これは、私が前回利用したElasticSearchの環境に古いデータ（試したのが19日、データは10日のみ）しか入っていないために出たエラーです。

日付は「Options」というエラーが出ている付近の「Absolute」というリンクをクリックすると、特定の日付をカレンダーで指定することができるようになります。データは6/10にしか入っていないので、6/10（12時くらいから20時くらいまで）のを指定します。

日付指定

選択すると無事データが見えるようになりました。

データ描画

ダッシュボードの構成（初期）

Kibana3では、この画面をダッシュボードというようです。このダッシュボードは初期状態では、以下のパーツが表示されています。（子要素があとで説明するパネル名です）

Options：描画対象の日付の指定やダッシュボードの保存などを行うRow
- timepickerパネル：日付の指定
- dashcontrolパネル：ダッシュボードの制御（保存とか）
Query：ログ検索式を入れるところ
- stringqueryパネル
Graph：ヒストグラムの描画（X軸：時間、Y軸：ログ件数）
- histogramパネル
Events：検索にヒットしたログデータの描画領域
- fieldsパネル：表示するフィールドの選択（左側。チェックを入れると右側のログ表示領域のカラムが増える）
- tableパネル：ログデータ（右側。左側でチェックが入ったカラムだけが表示される。）

あくまで初期表示です。各パーツの設定アイコン（歯車のマーク）をクリックすると色々と設定が可能です。また、「Events」など名称はクリック可能となっていて、クリックすると、そのパーツが折りたたまれた状態にすることも可能です。

折りたたんだ状態

ダッシュボードの設定

ダッシュボードには独自のパネルを簡単に追加することができます。ダッシュボードの構成はページの一番上にある「Logstash Search」の設定アイコンをクリックすると設定画面が開きます。

ダッシュボード設定

「New row」にタイトル名を適当にいれて「Create Row」するとあたらしくパネルを追加することができるRowが追加されます。「Rows」の「Move」にある矢印でRow自体の表示場所を上下に移動することも可能です。

Rowの設定

追加した「Hoge」にパネルを追加する場合はHogeの上にある設定アイコンをクリックすると設定画面が開きます。

Rowの設定

ここでKibana3で用意されているパネルの追加ができます。

Panel追加ボタン

パネルを選んでボタンを押せばすぐに表示されます。

パネルの羅列

こんな感じです。とりあえず、ポコポコと追加してみました。

利用できるパネルの種類は以下の様なパターンです。適当ですが、表にしてみました。

パネル名	概要
column	Rowの中にパネルを配置するコンテナを用意するためのパネル
dashcontrol	ダッシュボードの保存、保存したダッシュボードの表示などの操作ボタン
text	markdown形式などで記述が可能な文章を表示できるパネル
stringquery	検索クエリ入力用パネル
derivequeries	フィールドと検索式がわかれた形式の検索入力用パネル
timepicker	ログ表示の期間を指定するパネル
histogram	ログの件数のヒストグラム表示用パネル
hits	ヒット件数表示用パネル
pie	パイチャート表示用パネル
trends	指定された時間でデータの増減を%表示するパネル
sort	ソート条件指定用のプルダウン表示用パネル（変更したらtableの内容がソートされる）
table	ログデータ表示用パネル
fields	tableパネルに表示するフィールドを選択するための補助パネル
bettermap	なんか地図が出てきたパネル GeoJSONデータをゴニョゴニョ（表示かな？）できるみたい
map	なんか世界地図が出てきたパネル２文字の国コード（jaとかか？）かU.S.の州コードのデータを元に地図に色をつけるのかな？

これらのパネルは個々に色々と設定が可能です。他にもdebug、map2など有りそうでしたがまだ使えないみたいです。

適当に触ってて気づいた注意点です。

tableは１ダッシュボードで１つだけが良さそう。
- ２つあると、どちらかにしか描画されない。columnに入れるとグルーピングできたりするのかなぁ？
stringquery、timepickerも１ダッシュボードで１つが良さそう。
- これもtableと似たような理由です。
ダッシュボード保存し忘れて泣きそうになる
- JSで実装されてて、自分で色々とカスタマイズできるのですが、保存するのを忘れて泣きそうになりましたｗ
- カスタマイズしたダッシュボードについては、ローカルに保存する以外にElasticSearchにも保存ができるみたいです。チームで共有することもできそうです。
derivequeriesを表示するとグラフがカラフルに
- derivequeriesを追加したらグラフが急にカラフルになりました。
- どうもderivequeriesのFieldの部分を変更すると、そのフィールドの値を元にグラフを細分化してくれるようです。色の数の上限はderivequeriesのLength属性の数値で制御出来ます。（5だと5個まで色が出る）
- histogramのパネルで自分でクエリを記載することも可能です。ただ、derivequeriesのフィールド変更すると書き換わっちゃいます。。。

derivequeriesを追加したらカラフルに

ヒストグラムは色々なパターンのグラフを描画できました。ラインによる描画（histo1）、総数を100%としたパーセンテージでの表示（histo2）、ライン＋点による描画（histo3）などです。

ヒストグラムのいくつかのパターン

感想

ということで、適当にですが触ってみました。 Kibana2はApacheのアクセスログとかの表示しかできない感じがしましたが、Kibana3だといろいろなデータを描画できそうだなと。 logstash形式のインデックスを用意するのが前提になってるので、時系列データをグラフ描画するのに向いてるんでしょうか。お手軽にグラフ化できるし、自分でダッシュボードをカスタマイズできるのは素敵です。ただ、クエリとグラフの関係などはちょっと癖があるかもしれないので、色々と試してみないといけないかもしれないです。（たとえば、特定のフィールドの値について「A、B、その他」みたいなグラフの描画とかをどうするかとか）

地図の描画は試してみたいかなぁ。

apache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ

Mon, 10 Jun 2013 23:34:00 +0900

もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのログ生成ツールからApacheのダミーログを流しこんで入れてみました。

参考URL

インストールと起動

今回はCentOSへのインストールです。基本的にはmemorycraftさんのブログの流れのままです。

elasticserchのインストールと起動

ダウンロードして、起動するだけ。お試しということで、-fオプションにてコンソールにログ出力。

curl -OL https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.1.tar.gz
tar zxvf elasticsearch-0.90.1.tar.gz
cd elasticsearch-0.90.1
./bin/elasticsearch -f

Kibanaのインストールと起動

git cloneしてbundleインストール

git clone --branch=kibana-ruby https://github.com/rashidkpc/Kibana.git
cd Kibana
bundle install
ruby kibana.rb

これで、Kibana＋ESのインストール＋起動が完了。下地が完了。

td-agentのインストールと起動

ログの流し込みはlogstashなのですが、fluentdのelasticsearchプラグインにて流しこむこともできます。 td.repoとしてtd-agentのリポジトリを登録してから以下を実行します。

yum install td-agent -y
/usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch
vim　/etc/td-agent/td-agent.conf
/etc/init.d/td-agent start

これで、td-agentがインストール出来ました。次は設定です。

<source>
  type tail
  format apache
  path /var/log/httpd/dummy_access_log
  tag dummy.apache.access
</source>

<match *.apache.*>
  index_name adminpack
  type_name apache
  type elasticsearch
  include_tag_key true
  tag_key @log_name
  host localhost
  port 9200
  logstash_format true
  flush_interval 10s
</match>

以上が設定です。td-agentはtd-agentというユーザで起動されるので、/var/log/httpdディレクトリにアクセスできるかだけ確認が必要です。
いくつかの設定値について気になったので調べました。

index_name：adminpackとなってるが、elasticsearchではlogstash-xxxとなってる。
- これは、logstash_formatがtrueの場合は、利用されないので、指定しなくてもいい。
type_name：Elasticsearchのタイプ名 *　これはlogstash_formatを指定しても有効。ただし、Kibana側で画面からのtype指定は不可能。KibanaConfig.rbにて指定することは可能。
logstash_format：Kibana用にlogstashフォーマットで出力するオプション
- この指定があるときは、index名が「logstash-YYYY.mm.dd」となる
- record（ログ）に@timestampとして時刻が追加される。
tag_key：include_tag_keyがtrueと指定されているため、record（ログ）にtag_keyで指定した文字列をキー、値としてtagの値（上記例だとdummy.apache.access）が付与されて登録される。

apache-loggenのインストールと起動

タムタムさんが作成されたApacheのログのダミーを生成するツールです。
gem化されてるので、インストールは非常に簡単です。

gem install apache-loggen

で、ログを出力します。出力先は先程設定したdummy_access_logです。

apache-loggen --rate=10 --progress /var/log/httpd/dummy_access_log

秒間10アクセスログを出力してくれます。これで、Kibanaでログが見れるようになりました。なんて簡単なんでしょう。。。簡単なログの検索ができてしまいました。他の形式のログがどうなるのかとかは、また時間があれば。。。

感想とか

非常に簡単でした。素敵です。いくつかこうなるのかな？というのを試してみたのでメモを。

いくつか疑問点です。

溜まったログの削除は手動？
- おそらく。日付ごとにindexが出来上がっているので、削除は楽そう。「logstash-年月日」なので。
認証とかかけれるの？
- ログ検索は内部でするだろうから、まぁ、なくていいのかな。ログインすらないし。
複数行のログとかってどーすんだろう？（JavaのExceptionとかが混ざるやつ）

本格的に触るようになれば調べるかなぁ。。。

あと、ログが増えてきた時にどういった分割構成ができるだろう？って思って考えてみたのが以下になります。

構成パターン

ログを複数扱う場合は次のようなパターンがありそうかと。

タグ（fluentdのタグ）で識別

「@log_name」という名前＝fluentdのタグにてログを識別することで、異なるログを検索することができそうです。タグであれば、プラグインによってはログ出力時に制御も可能だと思うので、td-agentの設定を変更したりすることもなく対応が可能かと。ただ、ログの種別ごとにKibanaのプロセスを別にして起動したいといった用途には向いてなさそうです。

type_nameによる識別

ElasticSearchの機能であるtypeを利用したログの識別パターンです。
fluent-plugin-elasticsearchの設定でtype_nameを指定しました。ここを別の名前にすることで、識別することも可能です。

~~ただし、この場合はKibanaの画面から指定して検索することができません。~~ →コメント頂きました。検索条件に「_type:タイプ名」と検索することでtypeを利用した検索が可能です。
タグ（@log_name）でも識別できるようにするなどの工夫が必要です。その代わり、タグ識別ではできなかったKibanaのプロセスを別にして起動することは可能になります。
KibanaConfig.rbのTypeに値を設定することで、起動したKibanaが対象とするログを絞り込むことが可能です。こうすることで例えば、apache用のKibanaとtomcat用のKibanaは別プロセスにして、ElasticSearchのクラスタは1つという構成も可能になります。

ElasticSearchサーバを別立て

ElasticSearchサーバをそもそも別のプロセスor別のサーバで起動し、Kibanaも別々にすればログの識別も可能です。可能ですが、色々と管理するものが増えてめんどくさそうですね。。。

インデックス名変更

最後は、fluent-plugin-elasticsearchの設定で「logstash_format」をfalseにすれば、好きなindex_nameを付与できるので、ログ種別ごとに名前を変更することで識別できます。
ただ、logstash形式でないインデックス名の場合、日付ローテーションができなかったり、Kibana内部で検索時に日付で検索対象を絞り込んで検索することで高速化するといった処理など、使えない機能が多々出てきてしまうのであまりおすすめじゃないかと。。。

ということで、流行りものは触っておこうということで、さわってブログ書いてみました。
開発中に立てておいて、各サーバのログを流しこんでおくなどにも利用できるかもしれないです。アラート通知などの機能が出てくるともっと便利かもしれないです。

Kibana on @johtaniの日記 3rd

Analyze UIとKibanaのプラグインの作成方法（第3回）

ディレクトリ構成

package.json

index.js

public/app.js

server/routes/example.js

アーキテクチャ（簡易版）

まとめ

Analyze UIとKibanaのプラグインの作成方法（第2回）

1. KibanaのリポジトリをClone、Checkout

2. Node.jsの環境を用意する

3. Kibanaを起動できるようにする

4. SAOのインストール

5. テンプレートによるプロジェクトファイルの生成

Analyze UIとKibanaのプラグインの作成方法（第1回）

Analyze UI pluginとは？

インストール方法

データ分析基盤構築入門 を一部執筆しました。

Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目

Timelion?

Kibana 4.2からプラットフォーム化

インストール

Timelionへアクセス

サンプル：気温データを可視化

青いラインの最低気温

黄色い棒グラフの日照時間

まとめ

ということで、

Kibana 4.2.0リリース（日本語訳）

暗黒面は怖い？

地図のカスタマイズ

シナリオは？

全てにおいて速く

もっとありますが。。。

Release, we have（日本語訳）

インデックステンプレートとLogstash

テンプレートの設定

インデックステンプレートとは

今回利用するテンプレート

settings設定

mappings設定

インデックスのタイプ

ダイナミックテンプレート

multi_field指定

geoip

response、response_int、bytes

まとめ

Logstashを利用したApacheアクセスログのインポート

材料の準備

可視化の手順と流れ

Logstashの設定

Logstashの基本

アクセスログの読み込み設定

1. アクセスログを読み込む（input/file）

2. 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok）

3. 日付のパース（filter/date）

4. クライアントIPアドレスにgeoipの情報を付加（filter/geoip）

5. リクエストのパスの第1階層の抽出（filter/grok）

6. ユーザエージェントのパース（filter/useragent）

7. Elasticsearchへの出力（output/elasticsearch）

まとめ

サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました

本書について

共著者の方々のブログ

どの辺を書いたの？

その他感想

第2回elasticsearch勉強会を開催しました！ #elasticsearchjp

elasticsearchのRouting機能：株式会社シーマーク 大谷 純 （@johtani）

ElasticSearchを使ったBaaS基盤の開発(仮)：株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん（@pisatoshi）

Kibana入門：水戸祐介さん（@y_310）

LT

「データ集計用ダッシュボードブラウザとしても使えるElasticSearch＋Kibana v3を利用する際の運用ノウハウ紹介」：株式会社リブセンス Y.Kentaro さん (@yoshi_ken) さん

「Fluentd as a Kibana」：@repeatedly さん

「Authプラグインでアクセスコントロール」：株式会社エヌツーエスエム 菅谷信介さん (@shinsuke_sugaya)

Kibana3というのもありまして

Kibana3って？

インストール

画面構成

初期画面

データ分析基盤構築入門を一部執筆しました。

サーバ/インフラエンジニア養成読本ログ収集~可視化編を手伝いました

elasticsearchのRouting機能：株式会社シーマーク　大谷　純　（@johtani）

ElasticSearchを使ったBaaS基盤の開発(仮)：株式会社富士通ソフトウェアテクノロジーズ滝田聖己さん（@pisatoshi）

「Authプラグインでアクセスコントロール」：株式会社エヌツーエスエム菅谷信介さん (@shinsuke_sugaya)