こんにちは。 @shin0higuchiです😊 この記事は Kibanaのマルチテナント運用について考えてみた(前編) - Taste of Tech Topics の後編となります。事前にそちらをご一読ください。 さて、前回の記事では データが入っているindexに対してアクセス制限をかけることで、見せたくないデータを隠すことができました。 しかし、ダッシュボードが編集できてしまうなどの問題がありました。 ここでは、その対策としてkibana_dashboard_only_userを使ってみます。 ダッシュボードの閲覧専用ユーザー バージョン5.xまでは自分で.kibanaへのアクセスを制限したroleを作る必要がありましたが、バージョン6からは予めkibana_dashboard_only_userというroleが定義されています。 これをkibana_userの代わりに付与してみま
Tweet 古いバージョンの EC2 上で動く Elasticsearch と Kibana を AWS Elasticsearch Service (5.1) & Kibana 5 に移行するときに、ちょっとハマったポイントがあったのでメモとして残しておきます。 一部のレコードがなぜか aggregate できない MySQL が吐くスロークエリログをいい感じにしたいとき、fluent-plugin-mysqlslowquery を利用して Elasticsearch に送り、Kibana を使って視覚化する、という常套手段があります。 このとき、以下のスクリーンショットのような感じで Split Bars の Sub Aggregation に Temrs を指定し、スロークエリの SQL 文 (sql.keyword) で棒を分割するでしょう。 このとき、雑に fluent-plug
概要 elasticsearchに入れたデータの型を修正する手順をメモ。 バージョン情報など elasticsearch-6.0.0-alpha2 kibana-6.0.0-alpha2 前提 ・elasticsearchにデータを入れてみたけど、やっぱりデータ型が違っていた。 ・データ量がそれほど大きくない reindexAPIを使った方がスマートな場合も多々ありますが、 今回はKibanaのConsoleからmappingを修正して、Logstashなどでデータを再投入する場合を想定します。 想定するシチュエーション ユーザーのアカウント情報を示すaccountというindexにデータを突っ込んでみました。 kibanaで可視化するためにindex patternを作成... 確認してみるとageがstringになっています。 平均年齢とかをグラフ化する時とかに困ります。 ageが数字
ElasticsearchのX-Packはマジ便利なんですが，有償なので (だたしmonitor機能なんかは無償のBasicライセンスで使えて最高) 使わない人も多いでしょう． そんな場合，Elasticsearch/KibanaをDockerで動かすという時にX-Packを取り除きたくなるというのが人情でしょう．コンテナは軽いと嬉しい． というわけでそういう場合の法です． Elasticsearch: FROM docker.elastic.co/elasticsearch/elasticsearch:5.6.3 RUN bin/elasticsearch-plugin remove x-packKibana: FROM docker.elastic.co/kibana/kibana:5.6.3 RUN bin/kibana-plugin remove x-packプラグインマネジメント
自分のところでは、社内の様々なログをfluentdで集めているのだけど、それらをElasticsearchに入れて、Kibanaで見えるようした話を書いてみる. Fluentd, Elasticsearch, Kibanaな組み合わせは既に多くの人が使ってるし、ブログ等の記事も沢山ある. けど、いくつか 引っ掛かった点などもあるので、それらを書き留めて置こうと思う. 要件 fluentdでストリームで集めてるログを、リアルタイムに近い鮮度でKibanaで見たい. 見たい、というのは検索したり、集計・可視化したり、ということ Kibanaでは短期(2日とか)のログが見えれば良い 規模感的には、ログの種類(=fluentdのtag数)が200くらい、流量はピークで2万メッセージ/秒くらい. が、実際には最も流量の多いログは除いたので、この半分〜3分の1くらいの流量 10shard/index
最近遅ればせながら光の戦士になった増田です。サボり癖がなかなか直りません。 さて、この度 Elasticsearch と Kibana の社内事例を作ることが出来ましたので、興奮のあまりお伝えします。 ずっと導入したかった 2014 年 3 月に中途で入社して以降、導入したかったものの 1 つが Elasticsearch でした。個人ではすでに導入しており、効果を実感できていたためです。 その前段である fluentd の社内初事例が 2015 年 4 月のこちらの記事。気がつけば社内の他のプロジェクトにも導入が進んでいました。 ElastiCacheをCloudWatch+fluentd+Zabbixで監視する | feedforce Engineers' blog ところで私は先月から DF PLUS というサービスにフルコミットし、主にエラー管理やログ基盤などを整備しています。 エ
[速報]Elastic Stackの新バージョンがリリースされました（Elasticsearch2.3、Logstash2.3、Kibana4.5、Beats1.2） はじめに 藤本です。 本日（現地時間3/30）、Elastic Stackの新バージョンがリリースされました。 つい二ヶ月弱前に新バージョンがリリースされたばかりなのに、もう新バージョンですよ。リリースペースが早いのは開発者にとっては嬉しい限りですね。一方でバージョンアップどうする？的な悩みも出てきますが。。 Elastic{ON}2016のセッションで紹介されていた機能もいくつか盛り込まれています。 Release Bonanza! Elasticsearch, Graph, Shield, Watcher, Marvel, Logstash 2.3, Beats 1.2, and Kibana 4.5 are Now A
![[速報]Elastic Stackの新バージョンがリリースされました（Elasticsearch2.3、Logstash2.3、Kibana4.5、Beats1.2） | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/c9d78bc0df52ac310a3ab9aef46179df48f5ad8a/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F02%2Felastic-e1455952289818.png)
※4/6 その後調べた情報などを記事末尾に追記 前提となるニーズ サーバの負荷情報とか、アクセス状況のような KPI を取得・保存し、可視化(参照してグラフ化)したい。 リアルタイム性が要求される。5分以上前のデータしか見れませんみたいなのはお呼びでない。 古いデータはそんなに精度は気にしないけど、ロングスパンで俯瞰して見れたら便利。 最近はビッグデータ環境の時系列データ解析もビジネスではけっこうニーズがありそうだけど、そっちはもう少し要求が多そう。 ここでは考えないことにする。 選択肢になりそうなもの 古きよき RRDtool Elasticsearch + Kibana Graphite + Grafana InfluxDB + Grafana 等 Zabbix 他に、現実的には SaaS に任せるという手段もあるだろうけど、そう言うと話が終わってしまいそうなので、ここでは考えないこと
$ docker-machine create --driver virtualbox dev Creating CA: /Users/moriyasu/.docker/machine/certs/ca.pem Creating client certificate: /Users/moriyasu/.docker/machine/certs/cert.pem Running pre-create checks... Creating machine... (dev) Creating VirtualBox VM... (dev) Creating SSH key... (dev) Starting VM... Waiting for machine to be running, this may take a few minutes... Machine is running, wait
目次 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しました。 エ
はじめに 藤本です。 AWS LambdaがPythonに対応してから色々なことを試しています。 概要 ELBのアクセスログはS3に出力することが可能です。5分なり、1時間なりで定期的にS3にログファイルが作成されます。S3に集約することは簡単でもS3に出力されたファイルはAPIによるアクセスが必要、ログファイルが細かく分割されていることもあり、可読性の面においては優れていません。 そこでAWSではログを管理できるサービスとしてCloudWatch LogsやAmazon Elasticsearch Serviceを用意しています。Amazon Elasticsearch Serviceに関してはAWSのGithubでS3 -> AWS Lambda -> Elasticsearchの流れとなるソースコードが公開されています。ありがたい！これにより簡単にログデータを取り込むことが可能です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
