Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに Elasticsearchのv1.0.0 が無事リリースされ、Aggregations APIの利用が可能になりました。 Elasticsearchはこれまで、検索結果を集約して解析する仕組みとしてFacets APIを提供していましたが、実質SQLのGroup byでのcountに相当する機能しかなかったため、maxやavgといった複雑な条件で集約を行いたい場合、クエリを分けて集約したり解析したりするしかありませんでした。 v1.0.0でAggregations APIが提供されたことで、maxやavgはもちろん、日付でヒストグラムを取得するといった複雑な集約も楽に行えるようになり、SQL型検索エンジンからの置き換えも行いやすくなってきたのではないかと思います。 内容 Aggregationsで何ができるのか、SQLのGroup byとの置き換えを例に検証してみましたので、その
注意:この記事の最新版があります 新しいバージョンのElasticsearch,Kibanaを試したい方は、こちらの記事を参照してください。 (2014/8時点の最新版で作る)Vagrantだけあればいい、5分でできるElasticsearch,Fluentd,Kibanaのお試し環境構築 背景 以前Kibanaについて書いた記事がいくつかありますが、Elasticsearchが1.0になったり、KibanaがいつのまにかElasticsearchの一部になっていたりと、ここ半年ぐらいでも、いろいろと変化がありました。 環境構築についても書いたことがありますが、その際はVMを3台使用するような構成だったので、ちょっと試してみるには重たい内容でした。 この記事では最新のElasticsearch環境を構築し、ApacheのアクセスログをFluentd(td-agent)経由でElastics
2016/1/12 追記 elasticsearch 2.x では Facet 機能が無くなっているので Aggregation を使って同様の結果を得る方法を追記しました Kibana でグラフなどを眺めるだけでなく、elasticsearch (以降ES) の計算機能を利用して監視に使う方法です。 ブラウザの Developer Tools などで Kibana が ES に問い合わせているクエリを確認しながら試します。ES は機能が豊富すぎてなかなか大変です。ES を使うなら「高速スケーラブル検索エンジン ElasticSearch Server」を読むと良いと思いますが、本だけ読んでもクエリの種類や機能が多すぎて挫折します。試しながら必要な時に必要な箇所を読みましょう。全く読まないとそれはそれで落とし穴に嵌りそうなのが ES です。暗黙での動作に要注意です。 それでは本題です。 K
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Webサービスでは、Solr、Elasticsearchをはじめとする検索エンジンの結果をキャッシュしたいことは比較的よくあるはなしではないだろうか。ユーザー向けに提供している検索では、人気のワードで検索されやすく、それ相応の負荷になる。また、コンテンツに付加されているタグをクリックすると同じタグが付けられているコンテンツが検索される事例など、おなじようなクエリが投げられやすい状況は容易に推測できる。 さて、このような場合検索エンジンにおいてはどのようなキャッシュ戦略をとれば良いか。 1. Solr、Elasticsearchなどの検索
説明 searchkickとは検索エンジンの一つであるelasticsearchを簡単に扱えるようにしたGemです。これを使うことにより 高速検索 誤字訂正してくれる検索 部分合致検索 -自動補完 etc… など様々な検索に関する機能を実装することが出来ます。 今回はこのsearchkickを使うために公式ドキュメントを和訳したのでそれを記しときます。 以下ドキュメントの和訳です Searchkickとは searchkickとはユーザーが検索をするときの方法です。これを使うことによりより多くの人が簡単により良く検索結果を得ることが出来るようになります。 Searchkickを利用する機会 制御 -tomatoesをtomatoで合致するようにする 固有のもの ―jalapenoがjalapeñoと合致するようにする 余分な余白 - dishwasher が dish washer に合致
おしらせ Fluentdは入っていませんが、こちらの記事だと新しめのEs,Kibana環境が作れます。 入門記事:Elasticsearch1.4.0とKibana4.0.0の環境構築 Fluentd込みの環境も欲しいというかたがいれば、最新版にアップデートしつつ作るかもしれないので、コメントなどでお気軽にお声がけください。 まえがき 以前に書いた「Vagrantだけあればいい、5分でできるElasticsearch,Fluentd,Kibanaのお試し環境構築」がたまにストックされていてうれしいのですが、半年前の記事なので、2014/8/29時点のバージョンを使用してVagrantfileを書き換えました。 この記事で紹介するVagrantfileでは以下のバージョンを使用しています。 Ubuntu: 14.04(ubuntu/trusty32) Elasticsearch: 1.3.2
まえがき 前の記事でKibana4をソースからビルドする手順を紹介しましたが、そこでビルドしたソース(とElasticsearchの設定)に手を加えるだけで、bin/kibanaを使わなくてもKibana4を利用できることがわかりました。 これができれば、慣れ親しんだApacheやnginxでアクセス制限ができたりしそうなので、今回はその手順を紹介します。 前提 前の記事で紹介した手順に従って、Kibana4をソースからビルドしてください。 ビルドが済んでいて、Kibana4のプロジェクトディレクトリー内にbuild/srcができていることを前提とします。Elasticsearchの起動もお忘れなく。 動作確認にpythonのSimpleHTTPServerを使用するため、Pythonが入っていることが望ましいです。 もし、Pythonがインストールされていなくても、Apacheやngin
前書き @sawanoboly さんによるOhai版記事のSpecinfra Host Inventory版的なやつです。 踏襲したタイトル付けたらメッチャ長いタイトルになったw 何気なく軽量で実行方式(ローカルとかSSH越しとか)が選べて取り回しの良いインベントリ収集ライブラリは何かに使えるんじゃないかなーと思いつつ、ItamaeはChef Server的な存在が居ないし、こういう感じでインベントリを集めてみるのはどうでしょうかというコンセプトモデル的な何かです。 構成 Azureの無料枠が余っていたのでAzure上でやってみましたが、 慣れてないので複数のVMを纏めて扱うのが厳しそうだったので、 普通に大きめのVMをWEBコンソールから立てて、その中にDockerで複数の環境を構築しました。 詳細 構成方法 Chef test-kitchen + kitchen-docker_cli
Dockerイメージは2つあります。ひとつはNginx側に動くセンサーfluentd-agent( https://github.com/liubin/fluentd-agent )です。もひとっつはローグを集約するElasticSearchとデータ可視化するKibanaのかたまりes-dashboard( https://github.com/liubin/es-dashboard )です。 なおDockerHubにて公式イメージも用意されているので、下記のコマンドはそのまま実行できます(はずです)。 環境: CentOS 7 Fluentd 0.10.61 JDK 1.7.0 ElasticSearch 1.5.0 Kibana 4.0.2 1.Dashboardの起動 es-dashboardは1つのコンテナに動けます。また、コンテナが使えるリソースが制限されている場合、Elasti
はじめに 皆さんが有用な情報をどんどん世界に発信している中、このような無駄以外の何物でもない記事を書いてしまったこと、深く反省しています。 しかし無駄は楽しい。 無駄とわかっていても、やってみたらどうなるだろうという興味に負けてしまいました。 可視化結果 まずは結果から。グラフ化されるとちょっと気持ちいい。 ダッシュボードは適当に作ったもので、どのレポジトリでいつどれだけ作業したのか、どのファイルを特に更新しているのか、また更新した行数などを出せるようにしています。 何となく自分で 俺少しは作業したわー 感が味わえればそれで良かろうなのです。 これ以降は手法などの解説なので、興味のある方だけどうぞ。 可視化の方法 やったことはとても単純で、以下の通りです。 autocmd を使って発生したイベント毎に情報を収集 収集したデータを Elasticsearch に記録 Kibana で可視化
これは Elasticsearch Advent Calendar 2014 15日目の記事です。 今秋、Qiitaの検索システムが刷新されました。 Qiita/Qiita:Teamの検索システムがパワーアップしました - Qiita Blog ブログ記事の中でも簡単に紹介していますが、例えば title:"elasticsearch 入門" と検索すると、タイトルに "elasticsearch" と "入門" を単語を含んだ記事を検索できたり、他にも OR が使えたり、マイナス検索ができたりします。 一見すると query string query でも使ってるみたいですが実際はそんなことはなく、泥臭く検索文字列をその都度解析し、生成したクエリをElasticsearchに投げています。この記事では、なぜ query string query を使わずに自分で書いたのかという話と、公開
Embulkを使って大量の謎ログを読み込ませる手順 2015.3.16: @hiroysatoさんから教えていただいたnewコマンドをベースにした方法へ大幅に書き換え。 背景 セキュリティ関係のなんとかみたいな仕事をしていると、ある時急に数TBの謎のログを手渡されて「これ明日までになんか解析してみて」みたいなムチャぶりが飛んでくることがあります。このようなデータ分析では分析手法云々という前に、正規化してDBに取り込んだりする作業に相当の労力が必要になります。こういう事案に対していまどきなデータ転送ソフトウエアであるembulkを使うとだいぶ分析にとりかかれるまでの作業が楽になるのではないかと思ったので、一連の手順をまとめてみました。 前提条件 大きいサイズ(数GB〜数TB)のログデータを取り込みたい ログデータは1行1レコード形式のテキストで複数ファイルに分割されている ログの出力形式など
このエントリーはドワンゴアドベントカレンダー17日目のエントリーです。 ストリーム処理エンジンのNorikraについて、最近聞くことが増えてきました。 使ってみたい方は結構いるのではないでしょうか。 とは言え、「ストリーム処理を試してみたい、環境構築してやってみよう」と思っても、JRuby入れてNorikra入れて、fluentd入れてNorikraとのin/outの連携して、集計結果を格納する為にElasticsearch構築して、Kibanaから見れるようにして、認証機構や改廃の機構も入れて...あ、ストリームソースも用意しなきゃ...となって、そこそこ手間が掛かります。 一揃いの環境構築するのは面倒、という方向け(自分向け)に、手軽にコマンド一発で立ち上げられる環境を作りました。 Norikraそのものについては、こちらの記事が素晴らしかったです。 http://hase.hateb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く