elasticsearch5 + kibana5 + logstash5 をdockerで動かす - Qiita
es: image: elasticsearch:5 ports: - "9200:9200" - "9300:9300" volumes: - ./es_config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml - ./es_data/:/usr/share/elasticsearch/data/ environment: - ES_JAVA_OPTS=-Xms512M -Xmx512M ki: image: kibana:5 ports: - "5601:5601" links: - es environment: - ELASTICSEARCH_URL=http://es:9200
リアルタイム集計・可視化環境(Norikra+Kibana4+Elasticsearch+Fluentd+Nginx)をfig一発で気楽に立ち上げる。 - Qiita
リアルタイム集計・可視化環境(Norikra+Kibana4+Elasticsearch+Fluentd+Nginx)をfig一発で気楽に立ち上げる。ElasticsearchDockerNorikraKibanafig このエントリーはドワンゴアドベントカレンダー17日目のエントリーです。 ストリーム処理エンジンのNorikraについて、最近聞くことが増えてきました。 使ってみたい方は結構いるのではないでしょうか。 とは言え、「ストリーム処理を試してみたい、環境構築してやってみよう」と思っても、JRuby入れてNorikra入れて、fluentd入れてNorikraとのin/outの連携して、集計結果を格納する為にElasticsearch構築して、Kibanaから見れるようにして、認証機構や改廃の機構も入れて...あ、ストリームソースも用意しなきゃ...となって、そこそこ手間が掛かりま
cAdvisorとInfluxDBとGrafanaでDockerリソースの可視化を行うDockerコンテナ群をFigでデプロイしたPaaS上にてGo言語でRedisを叩く
当サイトおよびコンテンツは有志により作成・運営されています。特定の企業・団体に属するものではありません。 5日目 keith です、どうも。タイトル長くてすみません。 半年くらい前から、社内でもDockerについて見解を求められる機会が増えています。 僕はこう答えます。 「めっちゃ遊べるツールだけど、遊んでいられる時間はあとわずか（ガチ勢と初学者との差が決定的になるので）」 そんな感じで（？）、今年最もバズっているホットなテーマの一つといえば Docker ということで異論は認めませんし、 今回はただひたすらバズることを目的に、記事を書きます。 Dockerとは 説明不要ですね。 Dockerのリソース可視化 Dockerのホストと、各コンテナについて、リソースの使用状況を知りたくない人は居ませんよね。 そういうわけで、ここでは、cAdvisorを使ってリソースを収集、それをI
Scalable Docker Monitoring with Fluentd, Elasticsearch and Kibana 4 | Snapdragon Tech Blog
Scalable Docker Monitoring with Fluentd, Elasticsearch and Kibana 4 Docker is a great set of technologies. Once you are comfortable with using it, you are presented with a set of challenges, you didn’t have before. To name some: log consolidation: How to retrieve log files from dozens of containers? monitoring: How much RAM and CPU is each container using? There are a few articles on this topic ou
Google グループ
Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
第2回 ElasticSearch勉強会で発表してきました＆参加レポート #elasticsearchjp - Y-Ken Studio
2013年11月12日にリクルートテクノロジーズで開催された「第2回 ElasticSearch勉強会」に参加＆発表しましたので、レポートします。 発表テーマ 「ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウ」というテーマで発表しました。 ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウ from Kentaro Yoshida まだ検証段階ではありますが、ElasticSearchとKibanaの組み合わせはかなり気に入っています。 なお、発表で言及した0.90.6の不具合が修正された elasticsearch-0.90.7 が既にリリースされておりますので、これからElasticSearchを使われる方は0.90.7をお使いください。 聴講メモ ElasticSearchの書籍
Kibana+Elasticsearchで文字列の完全一致と部分一致検索の両方を実現する - Qiita
Elasticsearchはデフォルトで文字列を要素解析して保存する。これによって部分一致検索ができるようになるのだが、完全一致検索が難しくなる。 便利なTermsがうまくいかない KibanaにはTermsという値の上位10件とかを表示してくれるパネルがある。次のようなデータを入れているとする。 { "@timestamp": "2013-12-17T10:12:40+09:00", "remote_addr": "203.0.113.10", "country_code": "JP", "request_uri": "/index.php", "user_agent": "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)" } すると、いまアクセスされている国の比率とかを見たければ、count
Kibana3で同じダッシュボードを対象indexを変えて沢山作る - Qiita
はじめに 色々な種類のログをElasticSearchに貯める場合に、indexを分けるのか、同一indexでtypeを分けるのか、という点について、stackoverflowの記事に以下のようにありました。 個々のログのサイズが大きいのならindexを分けることで、検索を効率よく実行できる そうでないならtypeを分けると、沢山のindexを持つ際のストレージ容量のオーバーヘッドを避ける事ができる indexを分けると、同じようなダッシュボードで対象indexを変えたものを沢山作りたくなります。その方法を考えてみました。 ここでは、題材としてHadoop daemonのログを利用しており、NameNode, DataNodeと言ったdaemonごとにindexを分けるケースを想定しています。(ちなみに、ログ自体はfluent-plugin-elasticsearchで格納しており、flu
Elasticsearchにmappingをtemplate設定してみた - ほわいとぼーど
Elasticsearchはスキーマレスなのでそのままデータ突っ込んでも動きますが、 デフォルトだとStringとして取り込まれるし、無駄に要素解析されます。 効率や検索性を考えて部分的にスキーマを先に設定しておきます。 自分の場合、今回はApacheなログだったので、 ・request_time:ログ日付をdate_formatで認識させたい ・req_size, response_time: 数字として認識させたい ・protocol, method, code: 要素解析しない みたいなmappingを設定をしました。 なお、res_sizeも数字にさせたかったのですが、 method:HEADみたいな時に「-」が入ってきてしまってParseErrorだったので、 とりあえず今はStringで我慢しています。 ということで書いたのは以下。 { "template_1" : { "te
fluentd -> elasticsearchでつっこんだデータのstringになっているやつをintegerに変換する - Qiita
fluentd -> elasticsearchでつっこんだデータのstringになっているやつをintegerに変換するFluentdElasticsearch [2015/08/25]追記 この方法では一時的にそのindexではうまくいきますが、fluentdから送られるデータは変わっておらず、新しいindexを作成するタイミングでまた同じ状況になってしまいます。 下記が現状での正しい対処法です。 Elasticsearchでintegerになっていて欲しいところがstringになっていた時の対処法 - Qiita 概要 fluentd + elasticsearch + kibanaを作成して、apacheのlatencyでsortしようとしたら、なんか上手くいかない。latencyがstringではいっていることに気づいた。 確認法 $ curl -X GET localhost:
Private Presentation
Private content!This content has been marked as private by the uploader.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウ
SSSSLIDE
Kibana入門