自分のところでは、社内の様々なログをfluentdで集めているのだけど、それらをElasticsearchに入れて、Kibanaで見えるようした話を書いてみる. Fluentd, Elasticsearch, Kibanaな組み合わせは既に多くの人が使ってるし、ブログ等の記事も沢山ある. けど、いくつか 引っ掛かった点などもあるので、それらを書き留めて置こうと思う. 要件 fluentdでストリームで集めてるログを、リアルタイムに近い鮮度でKibanaで見たい. 見たい、というのは検索したり、集計・可視化したり、ということ Kibanaでは短期(2日とか)のログが見えれば良い 規模感的には、ログの種類(=fluentdのtag数)が200くらい、流量はピークで2万メッセージ/秒くらい. が、実際には最も流量の多いログは除いたので、この半分〜3分の1くらいの流量 10shard/index

はじめに fluentdからKafkaにデータ送信する際に、気にしておくべきfluentd側のチューニングポイントのまとめです。 fluent-plugin-kafkaのBufferedOutput前提です。 最初にデータが送信される際の流れを簡単に説明した後、チューニングポイントについて記載します。 使用ソフトウェアとバージョン kafka 0.10 fluentd v0.12 fluent-kafka-plugin(BufferdOutput) v0.57 Kafkaへ送信される流れ BufferedOutputプラグインではレコードはchunkと呼ばれる単位に区切られてバッファリングされます。 以下の記事にBufferedOutputの処理の流れが纏められており、参考になります。 本記事ではchunkがキューに入った後、Kafkaに送信されるにあたりどのような処理が行われるかについて

はじめに fluentdでログ監視して特定の文字列を検知したらSlackに通知するのを試してみたメモです。 背景として、以下でauditdでファイル改竄検知したらシスログに出すのを検証してました。 auditdでLinuxのファイル改竄検知を行う これをfluentd経由で特定の文字列をgrepで見つけてSlackに通知しようという算段です。 Slackの通知にはsowawa/fluent-plugin-slackを使いました。 またSlackに通知するのに、大量のエラーメッセージがバーストすると実運用上困るので、 fujiwara/fluent-plugin-suppressを利用して、一定時間あたりの連続投稿に制限をかけてみました。 稼働確認したのは以下の環境です。 Amazon Linux 2015.09 td-agent-2.3.1-0.el2015.x86_64 fluentd:

最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En

fluentdを導入時にまず知っておいたほうがよさそうなこと（インストール、監視、HA構成、チューニングなど）CentOSFluentdElasticsearchtd-agent fluentdを使う時にまず知っておいたほうがよさそうなこと はじめに 朝からElasticsearchへのデータの投げ込み方を考えていました。 データベースやメッセージキューなどにデータを投げ込んでおいて、ニアリアルなバッチでElasticsearchに投げ込むよりも、fluentdを使う方が圧倒的に簡単で信頼性が高いものができますね。自分で作りこむのがバカらしくなりますね。 ということで、fluentd利用時に気を付けておきたいことについて調べてみました。内容は公式ドキュメントの内容をベースに自身で調べたことを追記しています。公式ドキュメントへのリンクも貼ってありますので適宜そちらをご覧いただければと。 環境

Fluentd v0.12.16でプラグインの設定をコマンドラインから確認する方法 クリアコードさんのブログで既に書かれてますが，fluentdはv0.12.16から，プラグインの各パラメータを定義するconfig_paramに説明が付与できるようになってます．今だと二つ付与する方法があります．以下はout_stdoutのoutput_typeの例です． :descオプション config_param :output_type, :default => 'json', :desc => 'Output format.(json,hash)'

Fluentd v0.12 がリリースされました。git log を見るに v0.10.1 がリリースされたのは 2011/10/16 とのことなので、３年越しのメジャーバージョンアップとなりました。自分が Fluentd の開発に携わってから初ですね。感慨深い。 Fluentd v0.12 には Fluentd v0.12 is Released で言及されているように、今まであった Input プラグイン、Output プラグインに加えて、Filter プラグイン という仕組みが追加されています。本記事ではその使い方、および作り方を解説します。 2014/12/30更新 v0.12.2 で filter メソッドで nil を返すとメッセージを削れるようになったので記事を修正。cf. #515 合わせて v0.12.2 で、Filter プラグインのテストヘルパーが追加されたのでテスト

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重

This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ

// 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

近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu

開発合宿でDevOps界隈やモニタリング界隈で流行りのツールを組み合わせてBlue Green Deploymentできる何かを作りました。 同じチームで開発したid:shiba_yu36 先生やid:wtatsuru 先生が既にブログを書いてますが、自分の視点で書いてみます。（13/12/24追記: より詳細な内容が新規に書かれたのでリンク先を入れ替えました） Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; Docker コンテナにアプリケーションを立てて Graphite でいい感じに可視化するまで - wtatsuru's blog 僕は主に、各ツールから得られる情報をまとめて管理し、デプロイを実行するデプロイ管理ツールを作成していましたので、それについて書きます。 普段は運用の修行をして

Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転