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

fluentdを使う時にまず知っておいたほうがよさそうなこと はじめに 朝からElasticsearchへのデータの投げ込み方を考えていました。 データベースやメッセージキューなどにデータを投げ込んでおいて、ニアリアルなバッチでElasticsearchに投げ込むよりも、fluentdを使う方が圧倒的に簡単で信頼性が高いものができますね。自分で作りこむのがバカらしくなりますね。 ということで、fluentd利用時に気を付けておきたいことについて調べてみました。内容は公式ドキュメントの内容をベースに自身で調べたことを追記しています。公式ドキュメントへのリンクも貼ってありますので適宜そちらをご覧いただければと。 環境 CentOS6.7 td-agent 0.12.19 Ruby2.2.2(リストアスクリプトで利用) Fluent-Logger(0.5.1) Elasticsearch2.1.
表のDockerについて。。。 Engineはいわゆる普通のDocker。Dockerの実行環境です。 MachineはローカルやAWSなどの別環境にDockerのホストマシンを構築するツール。 通常、MacやWindowsでDockerを使う場合は、このMachineを用いて、ローカルのVirtualBoxにDockerホストのVMを作って、それに対して、dockerコマンドを実行していきます。 Composeは複数のコンテナのパラメータをYAMLファイルに記述しておいて、ワンボタンで環境構築するものです。 はじめにdockerの環境を整えておく Dockerで構築しておくと何度も同じインストール作業をしなくてよくなります。 MacだとDocker Toolboxをインストールすれば、Docker Engine, Machine, Composeの準備がすべて整います。 https://
現在、ログを収集し分析するシステムを構築しようとした場合に、オープンソースの組み合わせですぐに始められる構成としてはじめに思いつくのは Fluentd + ElasticSearch + Kibana の構成です。 Web上の記事や書籍も充実していますし、日本にもユーザーが多そうなので割と安心して利用できる環境でもあると思われます。 この記事では、Fluendによりログ収集しElasticSearchに保存し、それをKibana 4で分析する環境の構築手順について調べた内容をまとめてみました。 今回試したのは以下のように、Apacheのアクセスログをtailして、Fluentdで収集しElasticSearchに保存、Kibanaでログの検索、分析を行うシンプルなシステム構成です Apacheのログを収集するサーバーおよびElasticSearch、Kibanaをインストールするサーバーと
April 20, 201514:08 カテゴリ Kibanaによるログデータのビジュアライズ ツイート こんにちは。ゲーム統括部 ヱヴァンゲリオンバトルミッション(バトエヴァ)チームの長坂(@phelrine)です. 本稿ではKibanaを利用したログデータのビジュアライズ方法について紹介します.一般的なソーシャルゲームではユーザーの行動ログをKPIの計測のためや不具合の補填のために保存しています.当社でもユーザーの行動ログをフィルタリングしKPIを計測しているサービスが多数あります.このような仕組みでもKPIの計測は行えるのですが指標の追加や期間別の分析, クエリの条件を少し変更したい等のゲームプランナーの要望に対応するために時間がかかる場合があります. この問題に柔軟に対応するためにKibanaを導入しました.KibanaはElasticsearchをバックエンドにしたビジュアライズ
概要 fluentdでログ転送&収集を行い、 Elasticsearchでデータを保存し、 kibanaでデータの可視化を行う。 サーバー構成 APIサーバー(複数台) 【nginx】→【fluentd】→ログ収集サーバーへ転送 ログ集約サーバー(兼 解析サーバー) APIサーバーから転送→【fluentd】→【Elasticsearch】⇔【kibana】 サーバー設定 APIサーバー nginx nginxはインストール済みとする。 nginxのアクセスログをltsvフォーマットにする log_format ltsv 'time:$time_iso8601\t' 'remote_addr:$remote_addr\t' 'request:$request\t' 'request_method:$request_method\t' 'request_length:$request_len
目次 1. まえがき 2. pairsとシステム 3. kibana サンプルシステム構築 3.1 サンプルのサーバー構成例 3.2 fluentd 3.3 Elasticsearch 3.4 kibana 4. kibanaを使う 5. エウレカでの実際の活用事例 6. 〜終章〜 1. まえがき 1.1 対象者 気軽にデータ収集をしたいと思っている開発者 基本的なLinuxコマンドの理解がある方 1.2 この記事を読んで分かること fluentd x Elasticsearch x kibana を用いたアクセスログの収集・計測方法 pairsのシステム概要 私の好きなアニメ pairs高速化チーム 1.3 この記事を読んでも分からないこと 本格的な統計解析 恋人の作り方 1.4 自己紹介 はじめまして。サービス事業部の森川と申します。 エウレカには今年のはじめ頃にJoinしました。 エ
<match kpi.user_register> type copy <store> type elasticsearch index_name kpi type_name user_register include_tag_key true tag_key @log_name host localhost port 9200 logstash_format true logstash_prefix kpi.user_register flush_interval 3s </store> <store> type file path /var/log/td-agent/kpi.user_register.log </store> </match> <match kpi.user_login> type copy <store> type elasticsearch index_name
2.2. システム処理イメージ ログを解析する仕組みとして、こんなフローを考えてみました。 (1) OpenStackが出力するログを、ログ中継サーバーへ集約する。 (2) 集約したログをElasticsearchとNorikraへ送信する。 (3) Norikraへ送られたログを、SQLストリーミング解析にかける。 (4) 解析の結果は問題の有無に関わらずElasticsearchへ格納し、異常が検出された場合はZabbixへ通知する。 (5) 通常のサーバー監視はZabbixが行う。 (6) (2)、(4)でElasticsearchへ送られたデータはKibanaを使用して可視化する。 図 1 システム処理イメージ 3. ログを収集してグラフ化してみる。 まずは、OpenStackの各コンポーネントが出力するログ量の推移と、API実行数の推移のグラフ化してみました。ログメッセージの内容
前書き @sawanoboly さんによるOhai版記事のSpecinfra Host Inventory版的なやつです。 踏襲したタイトル付けたらメッチャ長いタイトルになったw 何気なく軽量で実行方式(ローカルとかSSH越しとか)が選べて取り回しの良いインベントリ収集ライブラリは何かに使えるんじゃないかなーと思いつつ、ItamaeはChef Server的な存在が居ないし、こういう感じでインベントリを集めてみるのはどうでしょうかというコンセプトモデル的な何かです。 構成 Azureの無料枠が余っていたのでAzure上でやってみましたが、 慣れてないので複数のVMを纏めて扱うのが厳しそうだったので、 普通に大きめのVMをWEBコンソールから立てて、その中にDockerで複数の環境を構築しました。 詳細 構成方法 Chef test-kitchen + kitchen-docker_cli
このエントリーはドワンゴアドベントカレンダー17日目のエントリーです。 ストリーム処理エンジンのNorikraについて、最近聞くことが増えてきました。 使ってみたい方は結構いるのではないでしょうか。 とは言え、「ストリーム処理を試してみたい、環境構築してやってみよう」と思っても、JRuby入れてNorikra入れて、fluentd入れてNorikraとのin/outの連携して、集計結果を格納する為にElasticsearch構築して、Kibanaから見れるようにして、認証機構や改廃の機構も入れて...あ、ストリームソースも用意しなきゃ...となって、そこそこ手間が掛かります。 一揃いの環境構築するのは面倒、という方向け(自分向け)に、手軽にコマンド一発で立ち上げられる環境を作りました。 Norikraそのものについては、こちらの記事が素晴らしかったです。 http://hase.hateb
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
% docker version Client version: 1.3.0 Client API version: 1.15 Go version (client): go1.3.3 Git commit (client): c78088f OS/Arch (client): darwin/amd64 Server version: 1.3.0 Server API version: 1.15 Go version (server): go1.3.3 Git commit (server): c78088f 構成 今回は fig を使って以下の3つのコンテナを作成して連携させる。 コンテナ名: web Apache fluentd コンテナ名: elasticsearch Elasticsearch コンテナ名: kibana Apache Kibana webコンテナがフロントエンドの
以下は2014年末での情報です。fluentd-0.12.xでの利用方法については追記2をご確認ください。 背景 Fluentd+Elasticsearch+Kibanaの構成でミリ秒単位のタイムスタンプを扱いたい。 fluentd 内部でレコードに対して付与されるtimeはunixtimeである。 そのため、ミリ秒単位でのタイムスタンプを標準でサポートしていない。 (内部データをfloatにする方法が検討されているらしい。) fluent-plugin-elasticsearch fluentdの内部で渡されるtimeを@timestampに変換してelasticsearchへ渡している。 レコードに@timestampが予め用意されている場合はそれをelasticsearchへ投げる。 この段階で@timestampがミリ秒のデータを含み、適切なフォーマット"%Y-%m-%dT%H:%
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く