コンテナでログをどう取得すればいいの?そもそもどういうログがあるのか? ログの取得パターンから活用方法まで、 @prog893 が選定のためのヒントとサンプルアーキテクチャで紹介します。
出版されてから少し時間がたってしまったけど,「データ分析基盤入門」を読み終えた.ページ数が多く,持ち運ぶようなサイズではないので,家でちょこちょこ読み進める感じになってしまって,想定以上に時間がかかってしまった. データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化] 作者: 鈴木健太,吉田健太郎,大谷純,道井俊介出版社/メーカー: 技術評論社発売日: 2017/09/21メディア: 単行本(ソフトカバー)この商品を含むブログを見る はじめに 目次にも書いてある通り,「データ分析基盤」というテーマで Fluentd / Elasticsearch / Kibana の解説が詳細にまとまっている.さらに付録には Embulk と Digdag の解説もあり,このあたりの技術スタックに興味がある人にとって最高な一冊なのではないかなと思う.また,
The unsung heroes of log analysis are the log collectors. They are the hard-working daemons that run on servers to pull server metrics, parse loogs, and transport them to systems like Elasticsearch or PostgreSQL. While visualization tools like Kibana or re:dash bask in the glory, log collectors’s routing making it all possible. Here, we will pit the two of the most popular data collectors in the o
背景 webサービスを運用してるんですが、ログをもっと有効活用しようぜ!って話になり、とりあえず手元でfluentd+elasticsearch+kibanaを使って環境を作ってみました。 アプリが入ったサーバには極力負荷をかけたくないので、パース作業は別のサーバで行いました。そのへんでいい感じにまとまってる情報が見つからなかったので、備忘録を兼ねてメモ。 サーバ構成 アプリケーションサーバ(今回はmac) -> fluentdを入れてログの送信だけやらせる。 VM(ubuntu14.04) -> fluentd, elasticsearch, kibanaを入れてログのパース〜蓄積〜表示まで。実運用では変わるだろうけどまあ練習ということで。 ハマった点・困った点 1. アプリケーションサーバからログをそのまま送信するのってどうやるんや 2. 正規表現苦手なんだけど 3. parserプラ
TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく,データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます. Fluentdはイベントストリームを効率良く,またロバストに扱うことを目的に設計されています.そのため,独自の転送プロトコル(forwardプラグイン)を実装していますし,内部のイベントのハンドリングもそれに沿うようになっています.ただ,それによって相性の悪い操作とかもあります. Fluentdはバッファ機能を提供しており,これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています.が,あまりにも書き込み先が遅いなどの問題があると,バッファの制限を超えて
Googleがオープンソースとして公開したKubernetesは、コンテナ型仮想化ソフトウェアのDockerを管理するツールです。開発プロジェクトにはDocker、RedHat、IBM、VMware、マイクロソフトなど多数の企業が参加を表明しています。 Kubernetesは、複数のDockerコンテナにまとめてアプリケーションをデプロイし、設定を行い、稼働状況を監視、管理し、サービスへのトラフィックをルーティングするなど、クラスタとしてDockerを運用するための多くの機能を備えています。 このKubernetesで使われる標準のログ収集ツールとして、オープンソースのfluentdが採用されたことが明らかになりました。下記はそれを伝えるGoogle佐藤氏のツイート。 fluentdがKubernetesの標準ログコレクタに採用されたぜ!!! https://t.co/V8VDM4IE7e
// Tutorial //Elasticsearch, Fluentd, and Kibana: Open Source Log Search and Visualization An Article from Fluentd Overview Elasticsearch, Fluentd, and Kibana (EFK) allow you to collect, index, search, and visualize log data. This is a great alternative to the proprietary software Splunk, which lets you get started for free, but requires a paid license once the data volume increases. This tutorial
2014年8月8日、ログ収集や可視化を始めたいエンジニア必携の書籍が技術評論社より刊行されます。 本邦初公開となる、全編書き下ろしの特集で構成された本書を読むことで、ログ解析の有用性からログ収集、保存、可視化手法を習得できます。 私はこの第2特集「ログ収集ミドルウェアFluentd徹底攻略」の執筆を担当しました。 サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus) それでは、それぞれの特集について簡単に紹介したいと思います。 サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 特集1 ログ解析からはじめるサービス改善 (鈴木 健太) 第1特集では、ログを蓄積して解析する意義とは何か、コーヒーショップのECサイトを例に、データ分析のケーススタディと共に解説されています。 第1章 はじめに 第2章 サー
最近、Fluentd + ElasticSearch + Kibana 3 の構成でお試し運用を始めました。 すると下記のような事をやりたくなったが Apache アクセスログをURL毎に集計したい DB スロークエリログをクエリ毎に集計したい 単純に文字列のフィールドで pie/bar チャートなどを利用すると、期待を打ち砕かれる(打ち砕かれた) ふむふむ、遅いクエリーには select, where, from が多いのか.... orz 見事に単語毎に集計されてしまった。 どうもトークナイズを止めるには ElasticSearch の multi field を利用するのが良さそう。(Solr で言うと copy field?) fluentd + ElasticSearch + Kibana + logstash フォーマットを下記の構成で利用する場合 fluentd のタグは m
技評さんでログ解析のムック本を共著で執筆させていただきました。 サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus) 作者: 鈴木健太,吉田健太郎,大谷純,道井俊介出版社/メーカー: 技術評論社発売日: 2014/08/08メディア: 大型本この商品を含むブログを見る 発売は2014/8/8の予定です。テーマはログ収集と可視化です。表紙に載ってる通り、Fluentd、Elasticsearch、Kibanaを中心に据えた本となっています。 私は特集1の「サービス改善はログ解析から」を担当しました。サービスにおいて、なぜログ解析を行う必要があるのか。どのような選択肢があり、どのように方法を選択していけば良いのかといった観点から書きました。特にエンジニアとしてサービスを改善していくために、どのようにデータを活
近年、自分の中で集計/可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計/可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ?」「Graphiteってなんじゃ?」「InfluxDBってなんじゃ?」 など、このツール達は一体何なんだろう…?というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか? というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の3つに分けられそうです。 ログ収集/集計 時系列DB(+API)の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
普段はサーバのメトリクス可視化のために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
はじめに 先日お伝えしました通り、ELBのアクセスログが取得出来るようになったのですが、すぐさまfluent-plugin-elb-logというfluentプラグインがリリースされました。さすがfluentd界隈、対応が早いです。 ということで、今回はELBのアクセスログをfluentd経由でElasticsearchに取り込み、それをKibanaで表示したいと思います! セットアップ Elasticsearch Elasticsearchは最新のrpmパッケージを更新サイトから取得し、rpmコマンドでインストールします。 $ wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.noarch.rpm $ sudo rpm -ivh ./elasticsearch-1.
fluent-plugin-elasticsearchやKibanaのデフォルトであるlogstash形式では、年月日毎にインデックスを作成されて使われることを想定されています。 これは扱いやすいのですが万能では無く、次のような状況ではパフォーマンス的な観点で、このインデックスの粒度を変更することを検討すると良いケースがあります。 粒度を細かくしたいケース(時間単位) 日毎のインデックス作成では、elasticsearchに割り当てたメモリ量を超えてしまう 粒度を荒くしたいケース(週単位/月単位/年単位) 日毎のインデックス作成では容量が小さく、日常的に検索する範囲が複数のインデックスに渡るとき Kibanaは年月日以外の粒度(時間・日・週・月・年)にも対応していますので、変更することも容易です。これは次の2つの設定変更で適用できます。 ログ収集を行うElasticsearchへ流し込む、
fluent-plugin-geoip v0.0.4をリリースしました。 今回は主にGeoLiteCityデータベース参照パスの不備の修正とREADMEの加筆を行いました。 https://github.com/y-ken/fluent-plugin-geoip http://rubygems.org/gems/fluent-plugin-geoip 修正内容の説明に続けて、後半では次のお役立ちTipsの紹介も行います。 インストール時のTips Fluentd + ElasticSearch + Kibana v3 を使う際のTips 変更内容概要 v0.0.3とv0.0.4の修正差分より紹介します。 [不具合] GeoLiteCityデータベース参照パスの不備を修正 [改善] 過剰なログ出力の削除 [改善] Travis-CIを用いた自動テストへの対応 Tips紹介 ここで、ハマりやす
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く