Amazon: NOT OK - why we had to change Elastic licensingObservability, security, and search solutions — powered by the Elasticsearch Platform.
Amazon Elasticsearch Serviceを使ったログ収集基盤の構成を考えてみた
みなさんこんにちは。@ryuzeeです。 6月10日にAmazon Web Services企業導入ガイドブックが発売になっていますのでよろしくお願いします。 さて今回はAWS上でログ収集と分析をする際に、Amazon Elasticsearch Serviceを使う前提とした場合だとどのような構成案がありそうかいくつか考えてみたのでご紹介します。 なお、検討の材料にしている全体の構成としては、複数のVPC(またはAWSアカウント)があって、さらにオンプレ側とDirect ConnectやInternet VPNで接続しているような、よくあるそれなりの規模の構成になります。 各VPCの中には複数のサブネットがあり、そのうちのいくつかはプライベートサブネットに分かれているものとします(個人的にはインターネットゲートウェイの有無しか違いがないので、プライベートサブネットあまり作りたくない)。
時系列DBって結局どれがいいんだっけ #TSDB - weblog of key_amb
※4/6 その後調べた情報などを記事末尾に追記 前提となるニーズ サーバの負荷情報とか、アクセス状況のような KPI を取得・保存し、可視化(参照してグラフ化)したい。 リアルタイム性が要求される。5分以上前のデータしか見れませんみたいなのはお呼びでない。 古いデータはそんなに精度は気にしないけど、ロングスパンで俯瞰して見れたら便利。 最近はビッグデータ環境の時系列データ解析もビジネスではけっこうニーズがありそうだけど、そっちはもう少し要求が多そう。 ここでは考えないことにする。 選択肢になりそうなもの 古きよき RRDtool Elasticsearch + Kibana Graphite + Grafana InfluxDB + Grafana 等 Zabbix 他に、現実的には SaaS に任せるという手段もあるだろうけど、そう言うと話が終わってしまいそうなので、ここでは考えないこと
elasticの新プロダクト「Beats」シリーズに震える！ - Taste of Tech Topics
初めてこのブログに投稿します、PlNOKlOです！ 皆さんよろしくお願いします。 このエントリーは、Elasticsearch Advent Calendar 2015の15日目です。 さて、 今日紹介したいのは、elasticの新プロダクト「Beats」シリーズです。 社内で @cero_t さんが「みんなでBeatsのWebinarを見る夕食会」なるイベントを 突発的に企画したので、よく分からないながらも参加してきたのですが、、、 震えました モニタリングツールとしてかなりよくできている感じで、 @cero_t さんが騒ぐ理由も分かる気がしました。 特にPacketbeatは想像以上にヤバかったですね。 皆さん、こいつは注目です！ ということで、そんなBeatsシリーズのうち、 TopbeatとPacketbeatの2つについて、私の震えポイントを紹介します！ 1. Beatsとは？
Elasticsearch 2.0.0-beta1リリース（日本語訳）
※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta1をリリースしました。 本リリースは469名のコミッターからの2,500以上ものpull requestを含んでいます。 pull requestのうち、約850が2.0のための新規のものとなります。 注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta1は Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。 本番環境には利用しないでください。 Elasticsearch 2.0.0-beta1のダウンロードおよび、すべての変更についてはリンクをごらんください
Elasticsearch AWS で Multi-AZ 配置
AWSでは高可用性を高めるためにマルチAZの配置を推奨しています。サーバーをマルチZA配置にすることで、物理的に独立した複数のAZ (Availability Zone)にサーバーを稼働させることができるので、障害に強いシステムを構築できる素晴らしい仕組みです。 いいことずくめの仕組みなのですが、唯一の欠点はAZ間のレイテンシです。Elasticsearchは受け付けた検索要求をすべてのシャードへ問い合わせる仕組みのため、マルチAZ配置にするとAZ間の通信が発生してしまうので、どうしてもパフォーマンスが落ちてしまいます。 これを避けるには、１つのAZ内に配置されているElasticsearchのノードだけで完全なインデックス（シャード）を保持し、受け付けた検索要求は同じAZ内で検索を完結できるように構成する必要があります。それを実現するのが Shard Allocation Awarene
Kibana 4 BETAファーストインプレッション - Qiita
Kibana4のBETAがリリースされたことに、Kibana3のissueがcloseされた通知で気がついた。Kibana3のbugfixはやってくれなさそうだけど、とりあえず、Kibana4を試すことにした。 必要なもの JVM Kibana 4.0.0-BETA1 Elasticsearch 1.4.0.beta1 初期設定 Kibana4をとりあえず使ってみるために必要な項目は次の通りだ。 Elasticsearch 1.4.0.beta1をセットアップする Kibana 4.0.0-BETA1をセットアップする インデックスの初期設定を行う Elasticsearch 1.4.0.beta1を準備する Kibana4ではElasticsearch 1.4以降が必要になっている。ベータ版がリリースされているので、適当にダウンロードして起動しよう。 Elasticsearch.org
Kibana の elasticsearch のデータで監視 - Qiita
2016/1/12 追記 elasticsearch 2.x では Facet 機能が無くなっているので Aggregation を使って同様の結果を得る方法を追記しました Kibana でグラフなどを眺めるだけでなく、elasticsearch (以降ES) の計算機能を利用して監視に使う方法です。 ブラウザの Developer Tools などで Kibana が ES に問い合わせているクエリを確認しながら試します。ES は機能が豊富すぎてなかなか大変です。ES を使うなら「高速スケーラブル検索エンジン ElasticSearch Server」を読むと良いと思いますが、本だけ読んでもクエリの種類や機能が多すぎて挫折します。試しながら必要な時に必要な箇所を読みましょう。全く読まないとそれはそれで落とし穴に嵌りそうなのが ES です。暗黙での動作に要注意です。 それでは本題です。 K
Kibana3というのもありまして
前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というのが存在します。 Kibana3って？ Kibana2はRubyで書かれていましたが、Kibana3はHTML＋JavaScriptで構成されています。 ですので、ApacheなどのWebサーバに配置することで、利用が可能となります。 ただ、HTML＋JavaScriptのため、ブラウザ上で動作するためブラウザが動作するマシンからElasticSearch（通常だとhttp://マシン名orIPアドレス:9200/とか）にアクセスできなければいけないという制限があります。 この条件さえクリア出来れば、Kibana3ではKibana2よりも様々なパネルが用意されていて、色々できそうなのでお勧めです。 インストール ElasticSearchやログについて
dstat + fluentd + Elasticsearch + kibana でサーバモニタリングする - blog.nomadscafe.jp
普段はサーバのメトリクス可視化のためにcloudforecastを使っていますが、某案件用に数秒単位で数十台のサーバのメトリクスを表示したいので、記事タイトルのような構成を作ってみた。 dstatでとった各種値の他に、nginxとmemcachedの情報も合わせて表示させています。 セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにElasticsearchとkibanaをいれる。環境はCentOS6 $ sudo yum install java-1.7.0-openjdk $ sudo rpm -Uvh https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.x.x.noarch.rpm Elasticsearchは特に設定なく起動 $ sudo service
Kibanaのダッシュボード設定を動的生成してみる
インフラ担当の池田（@mikeda）です。 最近、Kibanaでアクセスログの可視化をやってみてるのですが、手でダッシュボードいじるのがダルいです。 例えばうちの場合はサーバクラスタ、顧客アカウントごとのアクセスを見たい場合が多く、その条件を毎回指定するのがめんどくさい。 ここを動的に生成できないかな、と思って調べてみました。 イメージとしては、 内部管理画面にクラスタ/顧客アカウントの一覧があるのでそこにKibanaのリンクを設置して、 クリックすると適切に設定されたKibanaに飛ぶ、 という感じです。 Kibanaのソースコードやドキュメントはぜんぜん読んでないのですが（すませんｗ）、UIをポチポチ触ってるととりあえず以下の2つの方法でなんとかできそうでした。 Kibanaサーバに設定ファイル配置 ElasticSearchに設定突っ込んでリダイレクト Kibanaサーバに設定ファイ
Elasticsearch Marvelの紹介と第一印象
昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想を書いてみました。 Marvelって？ Elasticsearch社が初のプロダクトとしてリリースした、Elasticsearchクラスタモニタリングツールです。 次のような特徴があります。 plugin形式で提供 GUIがKibana メトリックスはElasticsearchに保存 SenseがChrome以外でも使える プロダクション環境で利用する場合は有料ですが、開発用途では無料で利用できます。 現時点(2014/01/29)では、0.90.9以上のバージョン(1.0.0.RC1含む)で利用が可能です。 なにができるの？ Elasticsearchクラスタに関するメトリックスを保存、可視化できるプロダクトです。 ドキュメント数やJVMの状況、クラ
CactiのデータをElasticSearch+Kibanaでまとめてみてみよう
斎藤です。こんにちは。 最近、会社の中で様々な部活動が始まっています。「プログラミング部」や「フットサル部」といったメジャー(?)なものから、「サイクリング部」「P部(プロレス観戦部)」そして「二郎部」などなど、エッジが効いたものまであります。そうそう、私は「サイクリング部」と「P部」に所属しています。 さて、今回はKibanaを使って、Cacti(RRDTool)が収集したモニタリングデータを参照してみようと思います。Cactiはモニタリングデータを収集・ビジュアライズするツールとして普及していますが、他のサーバ・指標と比較するのがちょっと面倒です。そこを、Kibanaを用いてより見やすくしようと言うのが目的です。Kibanaとは、収集したログをGUIで整理しつつビジュアライズできるデータ分析ツールの一種です。たいてい、データストアとしてElasticSearchというNoSQL DBサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HAROiDプラットフォームのリアルタイムログサービス
Kibana入門