はじめに 意外とKibanaにフォーカスした記事をみない気がしたので、 今回はKibanaの簡単なハンズオン的なブログを書いていこうと思います。 また、Kibanaの操作にフォーカスを当てるため、それ以外の設定等についてはなるべく簡略化しています。 ※書いている最中に記載量が膨大になってきたので、前後編にわけていきます・・・ 全体を通して、Elastic Stackでわからないところがあれば、こちらへ質問どうぞ！ :) discuss.elastic.co 今回試す構成について １台の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 構築手順 詳細手順は公式サイ

株式会社クイックでアプリケーションエンジニアをしているhamanokamiです。 弊社ではあるシステムの検索機能でElasticsearchを使用しています。 ただチームメンバ全員がElasticsearchの知識を持っているわけではないため、 Elasticsearchに詳しくなくても、ある程度運用できるように設計を行っています。 その1つとして、無停止でのインデックス再構築フローがあります。 Elasticsearchを運用していると、途中でマッピング構造やフィールド型を変更したいことがあります。 その場合、サービスでは既存マッピングで検索機能を使用しつつ、 裏でインデックスを再構築を行うことで、サービスの質を保ちたいものです。 その方法として一般的なのは、エイリアスを使用した再構築フローだと思います。 (参考) http://techlife.cookpad.com/entry/20

Elasticsearch は、Index や Type など論理的なインデックスを管理するものや、Shard や Replica、Node など物理的なインデックスを管理するものなど、主要要素がいくつもあるのでなるべくわかりやすく整理します。 論理的なインデックスElasticsearch の論理的なインデックスは、Index、Type、Document の３つの要素から構成されています。 論理的なインデックスの構成要素IndexIndex は論理的なインデックスを構成する一番上位のオブジェクトです。Elasticsearch は、複数のIndexをサポートしています。各インデックスを横断して検索することもでき、任意のインデックスのみ検索対象にすることもできる。 TypeType は、各 Index 毎に複数作成可能なRDBのテーブルのようなものです。Type はフィールドやインデックス

オープンソースのパフォーマンス監視ツールであるstagemonitorのプロジェクトマネージャーとして、優れてはいるものの経年劣化してきたGraphiteの時系列データベース(TSDB)に取って代わるバックエンドのデータベースを模索していました。TSDBとは、アプリの応答時間やサーバーのCPU使用率といった(パフォーマンス)指標データを保存する専用パッケージです。弊社では最終的に、簡単にインストールでき、スケーラブルで、さまざまな機能を備え、指標の視覚化もサポートするデータストアを探すことにしました。 Elasticsearchは以前に使ったことがあったため、簡単にインストールでき、スケーラブルで、多くのアグリゲーション機能を備えていることは知っていましたし、Kibanaにすばらしい視覚化ツールがあることも分かっていました。けれども、時系列データに向いているかどうかは不明でした。 こうした

2. 目次 • 自己紹介 • ディスプレイ広告配信DSP「Smalgo」について • インフラ選定と設計 • データ構造とリアルタイム集計 • 運用開始して分かったこと • トラブルとその対応 3. 自己紹介 • 山田 直行（やまだ なおゆき） Twitter @satully blog.kirishikistudios.com • 株式会社サイバーエージェント アドテクスタジオ エンジニア 2011年入社。前職はソーシャルゲームのエンジニア • 担当分野：DevOps インフラ設計／運用・データ集計／分析・CIなど • AWS認定ソリューションアーキテクト アソシエイト • データの活用について、インフラ構築から分析、実サービスへの適用までを通して できるエンジニアを目指しています 4. ディスプレイ広告配信DSP「Smalgo」について プロダクト概要 • ディスプレイ広告（≒バナー広

みなさんこんにちは。@ryuzeeです。 6月10日にAmazon Web Services企業導入ガイドブックが発売になっていますのでよろしくお願いします。 さて今回はAWS上でログ収集と分析をする際に、Amazon Elasticsearch Serviceを使う前提とした場合だとどのような構成案がありそうかいくつか考えてみたのでご紹介します。 なお、検討の材料にしている全体の構成としては、複数のVPC(またはAWSアカウント)があって、さらにオンプレ側とDirect ConnectやInternet VPNで接続しているような、よくあるそれなりの規模の構成になります。 各VPCの中には複数のサブネットがあり、そのうちのいくつかはプライベートサブネットに分かれているものとします(個人的にはインターネットゲートウェイの有無しか違いがないので、プライベートサブネットあまり作りたくない)。

Amazon Elasticsearch Serviceにfluentdでnginxのアクセスログを流し込んでKibanaで可視化する。 2016-06-19 Uncategorized splapiのアクセスログの可視化を始めてみた。 – return $lock; 導入にめちゃくちゃ苦労してしまったので、後で記事にしようと思います。 記事にしました。 前置き Kibanaで可視化するにあたってnginxのアクセスログをltsv形式にしてfluentdで送出しています。 導入当初はt2.microインスタンス（Amazon EC2の無料枠）をログ収集サーバ（fluentd→elasticsearch）にした上で、Kibana 4を動かしていたのですが、以下の問題がありほぼまともに運用出来てない状態でした。 kibanaがリソース不足（多分）で5時間と起動し続けられない elasticse

昨年10月にAmazon Elasticsearch Service(Amazon ES)がリリースされました。 今まではEC2インスタンスにElasticsearch をインストールして運用していましたが、AWS側でマネージドしてくれるということでとても便利そうだなと思い使ってみました。 動作環境は以下の通りです。 Fluentd 0.10.58 fluent-plugin-elasticsearch 0.9.0 Amazon Elasticsearch Service r3.xlarge 構成としては、各WebサーバからApacheのアクセスログをFleuntdサーバに集約してAmazon ESへ転送するようにしていました。 しかし、FluentdからAmazon ESへ転送する際に途中でエラーが出てしまい、転送できなくなることがありました。 2015-12-14 07:00:55 +

こんにちは、技術開発グループの松原です。 AWSでログを処理するときは以下の方法が考えられるかと思います。 CloudWatch LogsのデータをAmazon Elasticsearch Serviceにストリーミングする FluentdやLogstashを使ってログの収集、処理をする Fluentdを利用する場合はAggregatorがあった方が、リトライやバッファリング、タグを追加したいなどの場合にAggregatorの設定を変更するだけですむなど利点が多いです。 ただし、サーバの台数が少ない場合はAggregatorを構築するほどでも無いと思う場合もあるかと思います。 そこで、今回は以下のような構成を試してみます*1。 ここではログの格納先をS3にしていますが、Kinesisに置き換えても同様に実現可能かと思います。 Fluentdの設定 Fluentdで集めたログデータをS3に送

現在、ログを収集し分析するシステムを構築しようとした場合に、オープンソースの組み合わせですぐに始められる構成としてはじめに思いつくのは Fluentd + ElasticSearch + Kibana の構成です。 Web上の記事や書籍も充実していますし、日本にもユーザーが多そうなので割と安心して利用できる環境でもあると思われます。 この記事では、Fluendによりログ収集しElasticSearchに保存し、それをKibana 4で分析する環境の構築手順について調べた内容をまとめてみました。 今回試したのは以下のように、Apacheのアクセスログをtailして、Fluentdで収集しElasticSearchに保存、Kibanaでログの検索、分析を行うシンプルなシステム構成です Apacheのログを収集するサーバーおよびElasticSearch、Kibanaをインストールするサーバーと

初めてこのブログに投稿します、PlNOKlOです！ 皆さんよろしくお願いします。 このエントリーは、Elasticsearch Advent Calendar 2015の15日目です。 さて、 今日紹介したいのは、elasticの新プロダクト「Beats」シリーズです。 社内で @cero_t さんが「みんなでBeatsのWebinarを見る夕食会」なるイベントを 突発的に企画したので、よく分からないながらも参加してきたのですが、、、 震えました モニタリングツールとしてかなりよくできている感じで、 @cero_t さんが騒ぐ理由も分かる気がしました。 特にPacketbeatは想像以上にヤバかったですね。 皆さん、こいつは注目です！ ということで、そんなBeatsシリーズのうち、 TopbeatとPacketbeatの2つについて、私の震えポイントを紹介します！ 1. Beatsとは？

今回は、agent(1台)、elasticsearch + kinbana 同居(1台)の2台で構成します。 クラスタは今回は使いません！(あとでハマるので1台構成は注意) Logstashは今回使わなかったのですが。 訳があったので、記しておきます。 ログが存在するサーバーにJava8(JRE)を入れる必要があった (入れたくなかった、環境をできるだけいじりたくなかった) beatsがなかなか軽量で、Javaも必要無く要件を満たした。 検証サーバーのインスタンスサイズ「t2.micro」だとlogstash入れて動かしたら、ハングアップした・・・。 収集先でfilter要素で logstash 使えそうだったが、今回はそこまでの要件がなかった。 同様にfilter要件で、 td-agent も入れてみたがうまくelasticsearch5.0にデータが入れられなかった。 注意点 kiba

はじめに 藤本です。 みなさん、Beats使っていますか？ 過去のエントリで全公式＋一つのコマーシャルBeatsを紹介してきました。 Topbeat + boot2dockerでMacBookのシステムモニタリング Filebeat + boot2dockerでMacBookのログモニタリング Packetbeatでパケットモニタリング WinlogbeatでWindowsログモニタリング RedisbeatでAmazon ElastiCache(Redis)をモニタリングする 概要 Beatsは軽量なデータ収集ツールです。Golangで実装されていて、軽量なフットプリント、クロスプラットフォームで動作するため、各種クライアントで動作させるには嬉しいですね。JRuby（JVM上）で動作するLogstashと比較しても導入のハードルは低いでしょう。 ただし、Beatsを導入すればLogsta

はじめに もうこの際はっきり言っておきますけど今日はAmazon Elasticsearch Service(Amazon ES)のことしかやってません。どうも佐々木です。 朝からずーっとAmazon ESのブログ書いてました。 [新機能]Amazon Elasticsearch Serviceがリリースされました！ Amazon Elasticsearch Serviceでkuromojiを使って日本語全文検索する すると、同僚がネタを提供してくれました！ awslabs/logstash-output-amazon_es AWS謹製のLogstashプラグインです。Amazon ESはIAMによってアクセス制御を行うのですが、このLogstashプラグインを使うことで、EC2に割り当てたIAM Roleを使ってAmazon ESにデータを投入することができます。EC2でアクセスキーを持

はじめに こんにちは植木和樹＠上越妙高オフィスです。本日はAmazon Elasticsearch Serviceのお話です。 Webシステムで問題が発生した場合には、まずELBのログを調査することが多いかと思います。HTTP_5xxエラーの件数とか、日時とか、頻発しているパスとか。ログの量が少なければgrep, awkあたりで集計するのですが、量が多かったり分析の視点が多かったりする時にはツールのお世話になりましょう。 AWSではElasticsearch Serviceが提供されており、グラフィカルなログ分析もKibanaを使ってすぐに始められます。ただ、まずはS3に溜まった（大量の）ELBログファイルをElasticsearchに取り込む必要があります。 今回はログの取り込みにlogstashというツールを使ってみました。 環境構築手順 Elasticsearch Serviceクラ

こんにちは、fujiiです。 最近、社内でもElasticsearchを使う機会も増えてきてました。 インストールも簡単ですし、 ちょっと設定するだけでログの解析も手軽にできるので、 便利だと思って使い始めるのですが、 ・必要以上に負荷のかかる設定になっている。 ・システムダウンしたときの復旧を考慮していなかった。 ・初期構築などで大量にデータを入れようとしたら、一部データが入っていなかった。 と、後から反省することも多くあります。 （私も最初は知らないことが多く、反省点ばかりでした） そのため、Elasticsearchを初めて使うときの注意点をまとめ、 社内で講習会を開きました。 以下に公開しました。 実際に案件で利用しようと思った時にパフォーマンスなどで迷うこともありますので、 そんな時の一つの参考になればと思います。 Elasticsearchを使うときの注意点 公開用スライド f

Elasticsearchを使おうとすると、まずアプリケーションの仕様にしたがってインデックス定義やマッピング定義を設計しなければならない。これはMySQLを使っていてスキーマを考えるフェーズに相当する。 この時、考えることが非常に多く、いろいろなドキュメントを参照し設計したので、今回はその手順について書いていきたいと思う。 インデックスやマッピングが何かという話は、次の記事を参考に。 Elasticsearchチュートリアル - 不可視点 Mapping and Analysis | Elasticsearch: The Definitive Guide [2.x] | Elastic また対象とするElasticsearchのversionは記事執筆時点の安定版の2.3.5とする。 今回サンプルとする例 実際のプロジェクトを参考例にすることは流石にできないので、今回はブログの記事を検索