Fluentdの監視 ~ mackerel-plugin-fluentdを読み解く - そーだいなるらくがき帳
この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の18日目です。 qiita.com soudai.hatenablog.com それでは18日目は mackerel-plugin-fluentd です。 mackerel-plugin-fluentdはデータの収集と送信、そしてバッファリングをいい感じにしてくれる Fluentd 専用プラグインです。 Fluentdって何？って人は id:tagomoris さんの記事がめちゃめちゃわかりやすいです。 読んだ多分使いたくなるので是非読みましょう。 Fluentd はデータのやりとりを管理するソフトウェアだ。デーモンとして動作する。今のところはLinux上での動作が主に想定されている*1 tagomoris.hatenablog.com github.com ちなみにこの記事のFluentdのバージョンは下記のと
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
実運用の障害対応時間比較に見るFluentd＋Elasticsearch＋Kibanaのログ管理基盤の効果
実運用の障害対応時間比較に見るFluentd＋Elasticsearch＋Kibanaのログ管理基盤の効果：実運用が分かる、OSSでログ管理入門（2）（1/2 ページ） ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介します。 ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する本連載「実運用が分かる、OSSでログ管理入門」。第1回では一般的なFluentd、Kibana、Elasticsearchを用いたログ管理基盤の概要、導入方法を紹介しました。 第2回では実案件を事例とし、ログ管理基盤の有用性を紹介します。なお、
Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法
システム障害の原因調査や、稼働状況の確認のためにログの中身を確認することがよくあります。しかし、ログが大量に出力されていたり、複数の場所に分散して出力されていたりすると、それを確認するために多くの手間と時間がかかってしまいます。 これらの課題解決の方法として、ここ最近主流となっているのが、複数のOSS（オープンソースソフトウェア）ツールを組み合わせてログの収集や検索、可視化ができる基盤（ログ基盤）を構築することです。 その中で特に代表的なものが、「Fluentd」（ログの集約）、「Elasticsearch」（ログの検索）、「Kibana」（ログの可視化）であり、本連載では、これらのログ基盤を実現するツールについて、構築方法や利用方法、実際の案件で使ったときの事例、さらにはログ基盤に関連する最新の情報を紹介していきます。 連載第1回の本稿では、Fluentd、Elasticsearch、K
fluentd での forward plugin の適当すぎる使い方に気をつけよう - えいのうにっき
fluentd の conf を新たに追加して restart しようと思ったら、下記のようなエラーが出てプロセスが死んでしまった。 [info]: listening fluent socket on 0.0.0.0:24224 [info]: listening fluent socket on 0.0.0.0:24224 [error]: unexpected error error_class=Errno::EADDRINUSE error= #<Errno::EADDRINUSE: Address already in use - bind(2) for "0.0.0.0" port 24224> 原因としては、下記のような source ディレクティブを、 <source> type forward </source> 既にある別の conf で定義しているのに、今回追加しよう
意図せず fluentd のバージョンが 0.14 系になってしまったら - えいのうにっき
いま、ちょっとしたサーバのセットアップを行っているんだけど、そこで少しハマってしまったのでメモとして残しておく。 ↓のようなコマンド（公式ページにも記載されているもの）で td-agent のバージョン2系（fluentd は 0.12系のはず）をインストールしているにも関わらず、 $ curl -L http://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh セットアップを終えて起動させた td-agent のログを見ていると↓のようなエラーがでていて、 2017-02-19 13:04:02 +0900 [error]: #0 [nginx_forest] failed to configure/start sub output copy: Unable to activate fluent-plugin-b
SlowQuery を検知して Explain で解析し Slack へ通知 - 長生村本郷Engineers'Blog
以下に移行しました。 kenzo0107.github.io
松江市でOSSの話をした & Fluentd meetup をやった - たごもりすメモ
なんか最近プレゼンテーションやった話しかエントリに書いていない……。。。 それはともかく、しまねOSS協議会というところから周年記念講演で話さないかというお誘いがありまして、お受けしたので島根県松江市で話してきた。せっかくRuby City Matsueに行くことだしついでにイベントやってこようということで Fluentd meetup in Matsue もやることになり、そんなわけでふたつ発表してきた。 第106回オープンソースサロン・総会記念講演 第106回オープンソースサロン・総会記念講演 | しまねOSS協議会 OS4 しまねOSS協議会ということで、オープンソースソフトウェアの話。 Open Source Software, Distributed Systems, Database as a Cloud Service from SATOSHI TAGOMORI というか、ト
logback で出すログを強制的に１行にして収集しやすく・運用しやすくする - Qiita
Java のスタックトレースや、使うライブラリによっては改行つきでログ出力したりで、１つの意味をもつログが複数行に吐き出されることがありますが、それだと収集しづらいので、強制的に１行にしておくと、fluentd などのログ収集ツールで収集しやすく・運用しやすくなります。 開発時に参照するコンソールにはヒューマンリーダブルなログがよいですが、本番でファイルに出力するログは１行にしてしまい、運用時のログの参照はなんらかのツールを介して行う、というのがよいのではないかと思います。 最近の fluentd の in_tail は複数行のパースに対応しているが format multiline とし、開始行のパターンを正規表現で書いたりしてがんばって設定することで対応はできます。 が、ちょっと書きづらい。 そこで logback のフォーマット定義で対応してみる 例えば、 <appender ...
Fluentd v0.14.0 をリリースした & Fluentd meetup 2016 Summer をやってしゃべってきた - たごもりすメモ
最近めっきり対外的なアウトプットが減っていたのは、ぜんぶこいつのコードを書きまくってたからです。すごい書いた。 Fluentd v0.14.0 has been released | Fluentd ということで出ました、Fluentd v0.14.0。だいぶいろいろ良くなってるはずだけど、そのあたりはこれからv0.14対応プラグインが増えてきたりすると分かってくるかなと思う。ユーザにとっても嬉しい変更が山盛りです。 で、まずそのことをアピールしなければならんということで、Fluentd meetupではがっつりとしゃべってきた。 Fluentd meetup 2016 Summer - dots. [ドッツ] Fluentd v0.14 Plugin API Details from SATOSHI TAGOMORI 元々45分の予定だったのに90分弱くらいしゃべってしまったらしい。すま
投機実行とOut of Orderはつよいというはなし - なるせにっき
fluentdな人達と話していると定期的にRubyのオブジェクト生成が遅いとdisられます。 本質的にしょうがない部分もあるんですが、それにしても遅い部分も結構あるので、おもむろにperf statとperf recordを取ってみましょう。 % sudo perf stat -d ./miniruby -e'GC.disable;i=1000000;while (i-=1)>0;Hash.new;end' Performance counter stats for './miniruby -eGC.disable;i=1000000;while (i-=1)>0;Hash.new;end': 467.629812 task-clock (msec) # 0.993 CPUs utilized 19 context-switches # 0.041 K/sec 2 cpu-migratio
fluentdでつくる監視系 - Qiita
いつもアプリケーションの開発ばかりで、まじめに監視系を考えたことがなかったので、 fluentdを中心にした監視系を作ってみた。 前提 複数台のアプリケーションサーバ 一台のログ収集サーバ ログにはエラーログとアクセスログの大きく2種類を用意する エラーログは更に複数のレベルでファイル単位にわかれている fatal error warn アプリケーションサーバとログ収集サーバは同一ネットワーク上にある やりたいこと メールで来ても絶対に気がつかない自信がある。 異常の側から教えてくれる仕組みを目指す。 fatalログが出た場合は、電話による通知を行う 全てのエラーログはchatツールに出力する ログのバックアップ ログの分析・可視化 この記事では1, 2, 3についてまとめる。 構築 fluentdのインストール 公式のドキュメントが一番わかり易い。 Installation | Flue
いまさらだけど、Nginx が出力したアクセスログ（ltsv形式）を fluentd 経由で BigQuery に送ってみたよ - えいのうにっき
前回の いまさらだけど fluentd に入門した - えいのうにっき に引き続き、「いまさら fluentd」シリーズ（？）。 blog.a-know.me 事例としてはめちゃくちゃありそうなこの組み合わせ、「自分的にかゆいところ」に手が届いてるかんじの記事がないような気がしたので、それを少しでも増やすことができれば、という思いで、書いてみる。 nginx のアクセスログの形式を ltsv 形式にする まずはこれから。 そのために nginx の conf に手を加える必要がある。たとえばこんな↓かんじかな。 log_format ltsv "local_time:$time_local" "\thost:$remote_addr" "\tforwardedfor:$http_x_forwarded_for" "\treq:$request" "\tstatus:$status" "\t
fluentdのプラグインの各パラメータの説明 - Qiita
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をsystemdで管理する - matetsuだもんで
6日目が少々反則的な内容となってしまいましたが、きにせず7日目行きたいと思います。今日は仕事からの帰りが遅かったので書き始めから日付を超えているというミラクル。もう、時間を気にせず書けます。 と、前置きはこれくらいにして本題に入りたいと思います。いままでのガッツリな感じ（？）とは異なり、時間の関係でサラッとしたネタです。参考にさせていただいたのはRHELやSystemdやDockerの説明では知らない人はいないであろう中井さんの下記サイトです。 enakai00.hatenablog.com ログ収集をする場合にはデファクトスタンダードとなっているであろうfluentdをCentOS7などのSystemdなディストリビューションで起動/停止の管理をしたい場合の設定方法です。といっても、ひとまず動かしてみたレベルなので、問題もあるかもしれません。 通常はtd-agentをRPMからインストー
fluent-plugin-bigqueryでログの書き込みが痕跡なく欠損するケースがある問題 - s_tajima:TechBlog
fluent-plugin-bigqueryを使ってBigQueryにStreaming Insertでログを書き込む時に、 痕跡なくログが欠損するケースがあるのでは? という話です。 fluent-plugin-bigqueryでのログの書き込み処理/エラー処理はこのようになっています。 res.success? がtrueであればエラーはなく書き込みが成功しているという想定。 falseの時にはレスポンスのjsonのerrorエラーの中身を見て、ログを吐くなどのエラー処理をするようです。 res = client().execute( api_method: @bq.tabledata.insert_all, parameters: { 'projectId' => @project, 'datasetId' => @dataset, 'tableId' => table_id, },
Fluentdのfilter_grepの設定で少しはまった。 - ふり返る暇なんて無いね
fluentd 0.12.15 の話です。 結論から言うとFluentdのfilter_grepが、keyの後にスペース1個しか許容してくれません。 なので、下記のようにそろえるために、スペースを余分に入れると、意図しない正規表現になってしまいます。 <filter fluent.info> type grep exclude1 message (?:^out_forest plants new output|adding rewrite_tag_filter rule) </filter> 正しくはこう。 <filter fluent.info> type grep exclude1 message (?:^out_forest plants new output|adding rewrite_tag_filter rule) </filter> ソース的にはこのあたりで、スペース一個で
fluentd+elasticsearch+kibanaの環境を構築してみた - ssossanの日記
背景 webサービスを運用してるんですが、ログをもっと有効活用しようぜ！って話になり、とりあえず手元でfluentd+elasticsearch+kibanaを使って環境を作ってみました。 アプリが入ったサーバには極力負荷をかけたくないので、パース作業は別のサーバで行いました。そのへんでいい感じにまとまってる情報が見つからなかったので、備忘録を兼ねてメモ。 サーバ構成 アプリケーションサーバ(今回はmac) -> fluentdを入れてログの送信だけやらせる。 VM(ubuntu14.04) -> fluentd, elasticsearch, kibanaを入れてログのパース〜蓄積〜表示まで。実運用では変わるだろうけどまあ練習ということで。 ハマった点・困った点 1. アプリケーションサーバからログをそのまま送信するのってどうやるんや 2. 正規表現苦手なんだけど 3. parserプラ
Kubernetes管理サービスGoogle Container Engine、Google Container Registryの概要と使い方、Fluentdによるログ監視
数多く台頭しているDockerの運用管理に関する製品／サービスの特長、使い方を徹底解説する本特集「Docker運用管理製品／サービス大全」。今回は、Google Container Engine（GKE）や、グーグル独自のDockerリポジトリであるGoogle Container Registryの概要と使い方を解説します。 内容は、2015年6月の記事執筆時のもので、GKEのバージョン「アルファ」です。なお環境構築手順の紹介で扱うDocker自体のバージョンは1.6を使っています。 GKEは、グーグルが提供するDockerオーケストレーションツールのSaaSです。VMインスタンスでDocker Engineが動作するホストを構築し、ネットワークの負荷分散でロードバランシングを行います。 またGKEは、Kubernetesの管理サービスですので、Kubernetesについて知らない方は前
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfluxDB の概要 - sonots
