GKE環境でfluentd + elasticsearch + kibanaでログ環境を構築してみる - Qiita
kind: ConfigMap apiVersion: v1 metadata: name: fluentd-es-config-v0.1.5 namespace: default labels: addonmanager.kubernetes.io/mode: Reconcile data: system.conf: |- <system> root_dir /tmp/fluentd-buffers/ </system> containers.input.conf: |- <source> @id fluentd-containers.log @type tail path /var/log/containers/*.log pos_file /var/log/es-containers.log.pos tag raw.kubernetes.* read_from_head true <
Kibana 6.2.0リリース記念 Vegaで遊ぼう - Qiita
概要 Kibana6.2.0がリリースされました。 https://www.elastic.co/blog/kibana-6-2-0-released We’ve made it easier for you to create interactive visualizations by adding support for Vega, a data visualization language. Now you can concentrate on the visualizations you need, and not on the integration plumbing and plugin maintenance. Vegaがサポートされました、と。 これまでVegaプラグインを別途入れる必要がありましたが、本体で出来ると素晴らしいですね。 まだExperimentalとあります
Sematext Logs | Cloud Log Management Service | Hosted ELK
Sematext Logs Cloud Log Management & analysisSecure & scalable monitoring and logging services. Fast, powerful search. No complex setup. Just answers. Hosted ELK as a Service More than log management. Sematext Logs is a fully managed ELK in the Cloud without Elasticsearch and infrastructure management or paying expensive consultants. Get all the benefits of an Elasticsearch API and Kibana without
Elastic Cloud: Hosted Elasticsearch, Hosted Search | Elastic
Search and analytics, data ingestion, and visualization – all at your fingertips.
RDS(MySQL) のスロークエリを EFK スタック + Docker で出来るだけ手軽に可視化する考察 - ようへいの日々精進XP
モチベーション RDS の勉強をしたい→スロークエリの設定を見てみよう RDS のスロークエリをお手軽に可視化出来ないものか Elasticsearch + Fluentd + Kibana(EFK スタック) を改めて勉強したい 実サービスへの影響を極力抑えたい 可視化する手間は極力省く ということで、Elasticsearch + fluentd + Kibana + docker-compose を利用することで、ほぼコマンド一発で可視化する環境は起動する環境を作ってみた。 github.com 参考 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html https://github.com/kenjiskywalker/fluent-plugin
時系列DBって結局どれがいいんだっけ #TSDB - weblog of key_amb
※4/6 その後調べた情報などを記事末尾に追記 前提となるニーズ サーバの負荷情報とか、アクセス状況のような KPI を取得・保存し、可視化(参照してグラフ化)したい。 リアルタイム性が要求される。5分以上前のデータしか見れませんみたいなのはお呼びでない。 古いデータはそんなに精度は気にしないけど、ロングスパンで俯瞰して見れたら便利。 最近はビッグデータ環境の時系列データ解析もビジネスではけっこうニーズがありそうだけど、そっちはもう少し要求が多そう。 ここでは考えないことにする。 選択肢になりそうなもの 古きよき RRDtool Elasticsearch + Kibana Graphite + Grafana InfluxDB + Grafana 等 Zabbix 他に、現実的には SaaS に任せるという手段もあるだろうけど、そう言うと話が終わってしまいそうなので、ここでは考えないこと
リアルタイムサーバリソースモニタをつくる[dstat => fluentd => Elasticsearch => Kibana] - Qiita
リアルタイムサーバリソースモニタをつくる[dstat => fluentd => Elasticsearch => Kibana]FluentddstatElasticsearchKibanaKibana4 目標 全く更地の状態、しかもfluentdもESもなんとなくしかわかってない状態から、どうにかKibanaでリソース監視Dashboardを作るまでこぎつける。 同じことをやっている記事はいっぱいあるので、fluentdとESをよくわかってない状態で始めようとして躓いたポイントを中心に手続き的に。 太字になってるところがわかりづらい点・注意を要する点・推奨する内容。 参考 公式: Fluent: http://docs.fluentd.org/articles/config-file ES: https://www.elastic.co/guide/en/elasticsearch/r
![リアルタイムサーバリソースモニタをつくる[dstat => fluentd => Elasticsearch => Kibana] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/36c5af39960811480c53306e6f0d02cdd5fe1fb4/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUUzJTgzJUFBJUUzJTgyJUEyJUUzJTgzJUFCJUUzJTgyJUJGJUUzJTgyJUE0JUUzJTgzJUEwJUUzJTgyJUI1JUUzJTgzJUJDJUUzJTgzJTkwJUUzJTgzJUFBJUUzJTgyJUJEJUUzJTgzJUJDJUUzJTgyJUI5JUUzJTgzJUEyJUUzJTgzJThCJUUzJTgyJUJGJUUzJTgyJTkyJUUzJTgxJUE0JUUzJTgxJThGJUUzJTgyJThCJTVCZHN0YXQlMjAlM0QlM0UlMjBmbHVlbnRkJTIwJTNEJTNFJTIwRWxhc3RpY3NlYXJjaCUyMCUzRCUzRSUyMEtpYmFuYSU1RCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MjhiYWNiM2Q1NjZlMTgwMWFjZTE2OGViNThmMmY0MWQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5bXRzencmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTI2ZDNkZDYyMTYwMDc2MjcxODRmOTI0MDliM2ViMjVj%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gRWxtLWpw%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dd2491f285c06d84899568aabc5dc246b)
シェルのヒストリをKibanaで可視化してみた - Qiita
はじめに いろいろデータ可視化の可能性を探っていると、とても興味を惹かれる記事を見つけました。 Vimでの作業をKibanaで可視化してみた VimのメトリクスをElasticsearchに投入する為にプラグインを作成されていて素直にすごいなぁと思いました。 ブラウザの閲覧履歴で人生の棚卸し（embulk + elasticsearch + kibanaで可視化） そこに抽出できる履歴データがあれば振り返りたくなりますよね。 昨年11月くらいからデータ可視化のためにEmbulk、Elasticsearch、Kibanaを少し触ってきて、ある程度使い方が分かってきましたので、おさらいを兼ねてシェルのヒストリファイルの可視化をしてみようと思います。 必要なもの（環境） そこそこ溜まっている タイムスタンプ付き のシェルヒストリファイル Embulk 0.8.8 Docker Elasticse
Go製のData Shipper Platform「Beats」が良さそうなので紹介してみる - Qiita
OSSコミュニティから提供されているBeatも数多くあります。 https://www.elastic.co/guide/en/beats/libbeat/current/community-beats.html 構成 Beatsは「libbeat」という共通機能（データ送信、設定管理、ロギング etc...）を提供するコンポーネントと データの種類に応じて収集・加工を担う個々のコンポーネント（上図でいうPacketbeatやTopbeat）から構成されます。 個々のBeatは1Beatにつき1実行ファイルの構成となります。 ユースケースに応じてBeatを自作することもできます。（後述） BeatsとLogstashの棲み分け elastic社のデータ収集ツールとしてはLogstashが存在しますが、Beatsとの棲み分けはどうなるのでしょうか？ 上図のとおり、「データの収集」はBeats
Kibana用途でElasticsearchを使う時の高負荷対策TIPS - Qiita
これは Elasticsearch Advent Calendar 2015 8日目の記事です。 ログの可視化ツールとしてKibanaを使っている中で、Elasticsearch運用として色々と得られた知見を書きたいと思います。 Elasticsearchは、ライトな環境だったら特にチューニングなく安定してますがある程度ドキュメント数が積まれてくると、色々苦労があるなという印象です。 ここに書かれているのは、事情がありシングル構成で頑張った話なので、クラスタ組んでスケールするとこんな悩みはないのかもです。 でも、ログは運用系に入るのでそんなにコストかけれるとこはないのではという個人的な所感。 ラインナップとしては、下記のような感じです。 Kibana経由で重たいクエリが投げられると負荷高すぎて泣いた話 高負荷対策として、fielddata_cacheをディスクに逃がす方法 fluentdの
elastalertでアプリの異常を自動検知して通知したい - Qiita
私のチームでは週２回、当番制でサービスのログをチェックして問題がないか確認しています こんな感じで当番の人に通知して当番をまわしています サービスのエラーログはelasticsearchとkibanaで可視化しているので、確認自体はさほど大変ではないのですが、問題が起きていない場合がほとんどで作業コストの方が大きく感じてしまいます... そのせいか、最近はみんなの妹への反応が薄いような気もします... エラーログの確認を自動化して異常があれば通知する そんな話をしていたら誰かに「elastalert」というツールを教えてもらいました elastalertは、Elasticsearchのインデックスをモニタリングして設定した条件とマッチした時にalertを通知するためのツールのようです 本家ドキュメント: https://elastalert.readthedocs.org/en/lates
Elasticプロダクトインストールまとめ（RedHat系） | DevelopersIO
はじめに 藤本です。 小ネタです。 先日、Elasticで多くのProductの新バージョンがリリースされました。 Elasticsearch 2.2.0, 2.1.2, and 1.7.5 released Kibana 4.4.0 is eye meltingly colorful Beats 1.1.0 & Winlogbeat released Logstash 2.2.0 and 2.1.2 released Elasticsearch for Apache Hadoop 2.2.0 and 2.1.3 released 先日、【新機能】ShieldがKibanaに対応しました、WinlogbeatでWindowsログモニタリングをエントリしました。 今回は地味なアップデートでKibanaがRPMファイル、DEBファイルでの提供を開始したことで、Elasticの各プロダクトがYu
elasticの「The Beats」でシステム監視をサクッと可視化する - Qiita
前回、nginx→fluentd→elasticsearch→kibanaでアクセスログを可視化したが、fluentdの設定やpluginを調べたり、kibanaの設定やら正直めんどくさかった。そこで「The Beats」。agentをインストールするだけでサクッと可視化できる。予想以上に便利だった。 以下の３つのBeatが正式に用意されていてる。 Topbeat topコマンドの様なものを可視化 Packetbeat ネットワークのアプリケーショントラフィックを可視化 Filebeat ログを直接またはLogstash経由でElasticsearchに転送 kibana Beats用のDashboardが用意されているのでインストールしておく。 # curl -L -O http://download.elastic.co/beats/dashboards/beats-dashboard
Elastic社のTopbeatに入門してみた - Qiita
はじめに Beatsと呼ばれるイベント特化型エージェントをElastic社が開発している。 Beats | Collect, Parse & Ship 最近出てきたプロダクトであり、あまり日本語の情報がない。公式のドキュメントにそってインストールしてみたら割りと簡単だったのでここに記すことにした。 Topbeat概要 TopbeatとはBeatsシリーズの中でもシステムメトリクスを主として収集するエージェントである。なお、現在のGAのバージョンは1.0.1である。 取得できる主な情報は以下の通りである。 システム全体の統計情報 プロセス毎の統計情報 ファイルシステムの統計情報 システム全体の統計情報 システム全体の統計情報としては以下の情報の取得が可能である。 ロードアベレージ: 1分、5分、15分の平均のロードの値の取得 各種CPU使用率: user, system, idle, IOw
Graylog ではじめるログ管理 - クックパッド開発者ブログ
こんにちは。インフラストラクチャー部 セキュリティグループの星 (@kani_b) です。 主に "セキュリティ" や "AWS" といったタグのつきそうなこと全般を担当しています。 Fluentd などのデータコレクタ、Kibana やその他 SaaS による可視化、Kafka, Kinesis, Spark などのストリーム処理といった様々な分野で「ログの処理」がホットですが、アプリケーションのログ (行動ログなど) に関する話題が多くを占めています。 そうしたログの他に重要なのが OS や各種ミドルウェアのシステムログです。これらはトラブルシューティングであったり、セキュリティ上の問題を見つけたり、といったことに使われますが、最低限 syslog でどこかに集約しているだけ、といった例をよく見かけます。 これらのログをきちんと検索可能にし、分析することで、今まで気づかなかったような問
Amazon Elasticsearch ServiceとFluentdで遊ぶ - サーバーワークスエンジニアブログ
カメラマン（ｒｙの竹永です。 秋になり、気温的にも湿度的にも良い具合に過ごしやすいがため良い感じに眠い日が続いています。 睡眠時間を稼ぐためにAmazon Elasticsearch Service(Amazon ES)を使って、Elasticsearchサーバーづくりをサボってみました。 前回のおさらい ElasticsearchとS3にApacheのログをつっこむ、Fluentd環境をつくりました。 良くも悪くもベタな構成ですが、ElasticsearchがEC2上で動いているのが気に喰わないので、Amazon ESで置き換えます。 とりあえずは立ち上げる 普通に立ち上げようと思ったら、AWS公式ブログを見れば一発です。 とはいえ、ここで説明しないと記事の長さがあまりにも短くなりそうなので、立ち上げまでの道のりを画像を交えて記録しておきます。 いつもどおりManagement Cons
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kibanaで秒間1万件のアクセスを可視化した話/nikkei-kibana-loganalyst2015