Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
Dogstatsd で Datadog にカスタムメトリクスを送る方法 〜Fluentd との連携を添えて〜 · takus's blog
Datadog というシステム監視 SaaS のネタです。 先週の木曜に「Datadog でカスタムメトリクス送るの面倒じゃない？どうやってるの？」とある人に質問されたので、 自分が知ってる Dogstatsd を使う方法をシェアします。 これはあるサービスの Nginx のアクセスログとエラーログを、 Fluentd 経由で Datadog にカスタムメトリクスとして送って可視化した例になっていて、 それぞれ、 左上: ステータスコード別の集計グラフ 右上: 今日・昨日・一週間前のレスポンスタイムグラフ 左下: Fluentd の タグ毎の流量 右下: Fluentd の ホスト毎の流量 といったグラフになっています。このポストではこんなグラフを作る方法を説明します。 Dogstatsd とは？ 唐突に Dogstatsd というものが出てきますが、カスタムメトリクスを送る場合はコイツを
fluentdで集約したerror_logをslackに流すと捗る - UNIX的なアレ
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
Fluentdの設定を考えるときはこんなかんじで考えると便利 - Qiita
Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
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
fluentdと定番プラグインのインストール
fluentdと定番プラグインのインストール：今さら聞けないfluentd～クラウド時代のログ管理入門（2）（1/2 ページ） 前回の記事「増えるログ、多様化するログをどう効率的に運用するか」では、fluentdの大まかなアーキテクチャについてご紹介しました。第2回では、fluentdがどういったものであるかをもう少し具体的に理解するために、実際の利用までの流れを紹介します。 fluentdの使い方 fluentdを利用するには、各サーバーにfluentdをインストールし、どのプラグインを使って処理を行うかについての設定が必要になります。 インストール手順 fluentdはさまざまな方法でインストールできます。例えば、 rpmパッケージによるインストール（CentOS、Red Hat Enterprise LinuxなどのOS向け） debパッケージによるインストール（Ubuntu、Deb
S3とFluentdを用いた効率的なログ管理 | SmartNews開発者ブログ
ゴクロの大平です。 私にとって一番大事で替えの効かないミュージシャンはさだまさしさんですが、私にとってクラウドコンピューティングのサービスの中で一番大事で替えが効かないサービスはS3です。 多種多様なAPIを用いて柔軟にファイルの操作が出来る事や、”99.999999999％”と謳われている高い耐障害性、S3にあるデータをElastic MapReduceやRedshiftなどを用いて手軽にデータ解析を行える基盤が提供されていることなど、あまりに便利すぎてS3の代替となるサービスを探しだすのが難しい状態です。 もちろん多くのAWSユーザーが同じようにS3の便利さを享受していると思いますし、インターネット上でも多くのブログ等でその魅力が語られています。その中で本記事は既に存在する記事と似たような内容を書いてしまうかもしれませんが、弊社なりのS3の使い方についてご紹介したいと思います。 なお
FluentdとRiakの話 - After Coding
Fluentdは、Ruby製のログコレクタだ。コードは公開されている。 様々なログを構造化して一元管理することができ、収集と解析へのハードルを大きく下げてくれる。 インストールもプラグイン開発も簡単。日本語の資料も多い。 その資料も様々あるが、プラグインを見るならこれが最良だと思う。必要な情報がよくまとまっており、必読といえる。 Big Data入門に見せかけたFluentd入門 from Keisuke Takahashi データの確実な転送を実現するバッファ機能については、池田大輔さんのブログが詳しい。さて、Fluentdはデータを収集してくれるが、保存はしてくれない。 永続化にはデータベースが必要だ。 そこで、Riak。 Basho社がスポンサードするErlang製分散型KVS。これもOSSだが、契約によって商用サービスが受けられる。 これがまたエッジ立ちまくってて
Fluentdがよくわからなかった話
The document discusses the Fluentd logging system. It includes an explanation of how Fluentd buffers and queues log data before outputting it. The emit method is used to add log data to a chunk, and if the chunk limit is reached a new chunk is created and added to the queue. Once data is in the queue it can be output by the configured plugin.Read less
何故、fluentdなのか？ - プログラマでありたい
最近、fluentdという言葉を聞くことが多いと思います。fluentdは、それぞれのサーバからログを収集し集約する為のアプリケーションです。fluentdは「Log everything in JSON」を合言葉に、全てのログをJSON形式で扱います。また一緒に聞くキーワードとしては、大規模とかリアルタイムとかがあると思います。この時点で関係ないやと思って、興味を失った人も多いと思います。しかし、今後のログ管理は、fluentdが主流になるか解りませんが、同様の集約するフレームワークが中心になると思います。 何故、fluentdが必要か？ まずはオンプレミスの世界から見て行きましょう。ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。 次にAutoScalingを使わないAWSの世界です。これも同様に、ログはサーバーにたまり、管理者はサーバにログ
走れfluentd | quipped
fluentdというソフトウェアがある。読者の多くは聞いたこともないソフトウェアだろう。そりゃそうだ。AndroidとかiOSとかWindowsのように、消費者の目に毎日さらされるものとは違い、日夜静かにデータセンターで動いているソフトウェアだ。 このfluentdは、もともと古橋貞之くんが、自分がはじめた会社のサービスの一部で必要となり書いたものだが、この1年半ほどで瞬く間に広まり、今では日本中のウェブサービスで導入されている。どのくらい広まっているのかと言うと、もし読者が今日 はてブをチェックしたり クックパッドでレシピを探したり NAVERまとめを見てゲラゲラ笑ったり GREEのサービスで遊んだり ライブドアニュースで蒼井優の動向を探ったり1 したなら、どこかでfluentdの恩恵を受けているということになる。 ちなみにこの古橋くん、ゆとり世代のダメダメなピチピチな25歳の若者で、ど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluentdによる大規模キュー設計