� K�SV
OSS紹介アドベントカレンダー の14日目の記事です。 Fluentd の 公式 Go 版 Logger である fluent-logger-golang はこのように使うのがよさそう、という使い方をまとめてみました。 元々社内で書いておいたドキュメントを編集したものです。 github.com 前提のユースケース Webアプリケーション(APIサーバ) を Go で書いていて、そこから何らかのログを Fluentd に送信したい。 config のお勧めオプション Timeout : Connect に対するタイムアウト。デフォルト3秒なのでそのままでよさそう WriteTimeout : 書き込みのタイムアウト。デフォルトだとずっと待ってしまうので 3 秒とか? BufferLimit : デフォルト 8MB これを超えると捨てられてしまう。送る流量によって調整が必要 MaxRetry
Logging is a critical component on production environments that allow us to perform monitoring and data analysis. While applications runs at scale, the Logging layer also needs to scale and year over year we see new challenges that needs to be solved from different angles such as parsing, performance, log enrichment (metadata), filtering and so on. Fluentd was born to solve Logging problems as a w
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
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
Lobiチームの長田です。 あらゆるWebサービスがそうであるように、Lobiでも日々大量のログが出力されています。 今回はこのログをどのように集約・解析しているかを紹介します。 TL;DR アクセスログ・アプリログなど、毎秒10000行以上のログが生成されている Fluentdを使用しログを集約 consul serviceを利用した集約サーバーの冗長化 ログ中のイベント検知・集約にはNorikraを使用 アクセスログの各種解析にはAmazon Redshiftを利用 ログの集約 ログ収集エージェント Lobiではログの集約にFluentdを利用しています。 Fluentd | Open Source Data Collector | Unified Logging Layer ログファイルの集約にはfluent-agent-hydraを、Perlアプリケーション内からのログ送信にはFl
イベント名：Fluentd Meetup 2016 Summer 開催日時：2016-06-01(月) 会場：イベント＆コミュニティスペース dots. 約1年ぶりに開催された Fluentd Meetup に参加してきました。今回は、5月31日にリリースされたメジャーバージョンアップの v0.14 について、ユーザ向けの機能紹介から、プラグイン開発者向けの深い話まで、盛りだくさんの内容でした。自分でプラグインを書くくらい、Fluentd をヘビーに使う人向けのイベントという感じで、どの話も面白かったです。 最近、私は Fluentd を使う機会が全然なかったこともあって、「Fluentd も機能的には枯れてきて、そろそろ新機能もあまりないだろう」と思っていたのですが、まだこんなに改善の余地があったのか……とちょっと驚きました。個人的には、古橋さんの講演で将来の構想として出てきた、Kafk
問題があったのでfluentdでsigdumpを使いstactraceしてmackerel-client-rubyにPRした話 July 8, 2016 みんなのネットワーク環境が安定しているのか.. 我々の世界線にノイズが混在してしまっているのか… それを調べるすべはないが、下記のような問題があった。 mackerelで突然グラフが表示されなくなる そのグラフを表示しているのはfluent-plugin-mackerelを利用してfluentd経由で作成している そのtd-agentは再起動しようとするとTimeout errorになる ということで怪奇現象を解決する為にやったことをメモ 愚直にtd-agentの再起動を試みてみる [watashi@example-host ~]$ [watashi@example-host ~]$ [watashi@example-host ~]$ s
OSSのログ収集管理ツールFluentdを用いてログを統合管理している場合の懸念点として、ログの収集漏れが考えられます。 Fluentdでは、バッファ機能を活用することでログを収集漏れすることなく確実に収集することができます。 このバッファ機能のメカニズムを理解すべく動作検証した結果を紹介します。対象とするFluentdのバージョンは0.10.30です。 Fluentdとは Ruby実装のOSSのログ収集管理ツールです。 Fluentdは、Input、Buffer、Outputの3つのコンポーネントで実現されています。 様々な場所からログを収集、JSON形式に変換し(Input)、蓄積(Buffer)、様々な出力先にデータ出力(Output)します。 例として、あるサーバ(server01)のApacheのアクセスログを別のサーバ(server02)内にファイルとして出力する場合
td-agent-aws-billing.conf � �=V `� �=V # # AWS TOTAL Billing information # <source> type cloudwatch tag cloudwatch-billing.amount cw_endpoint monitoring.us-east-1.amazonaws.com namespace AWS/Billing metric_name EstimatedCharges dimensions_name Currency dimensions_value USD statistics Average interval 7200 period 21600 delayed_start true </source> # # AWS cloudfront Service Billing information # <
ApacheのアクセスログをLTSV形式にしたいと思った方に是非お伝えしたい、 私がハマった落とし穴とその対処方法、その後にApacheとFluentdの設定サンプルを紹介します。 以下に1つでも該当するものがあれば、LTSVの導入メリットは高いでしょう。 テクニカルな正規表現のメンテナンスに疲れた awk等のテキスト整形ツールで加工や集計を容易に行いたい ログ収集ツールFluentdを使ってリアルタイム集計などを行いたい 落とし穴 その１「request_first_line」 一般的なApacheの設定ファイルhttpd.confでは、デフォルトで以下の設定が行われています。 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined このLogFormatStringをそのままLT
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、鈴木カズです。 社内向けの監視システム構築のため、StormやKafkaを利用して開発を行っていました。 そのときの経験をもとに、まずStormによる実際のシステムがどんなものかということを紹介し、KafkaSpoutの処理内容、カスタマイズ方法、Stormのメッセージ処理などを説明したいと思います。 読者としては、StormやKafkaについて興味があり記事を読んだりしたことがあるがもう少し具体的な話を知りたい方、これから開発予定があるような方を想定しています。 StormとKafka Stormは簡単に言うと、リアルタイムに流れてくる大量のデータを処理するための分散システムです。Twitterのメッセージの分析など
本番環境で動いているFluentdのin_forwardに何が流れているのかを知りたい、けど設定を触りたくない…みたいな場合に流れているタグやレコードを見る方法です。特にFluentdに限った話ではないですが、備忘録として書いておきます。 1. tcpdumpでキャプチャ 調べたいサーバ上で、tcpdumpを使ってパケットキャプチャを取ります。in_forwardのポート番号などを指定してキャプチャします。 $ sudo tcpdump -i eth0 -w fluentd.pcap port 24224 and tcp 2. tcptraceでTCPストリームのデータだけ吐き出す tcptraceは-eオプションを渡すと、TCPストリームごとのデータをファイルに吐いてくれるのでこれを利用します。なお、tcptraceはHomebrewやaptで入ると思います。 $ tcptrace -e
December 12, 2014 sshを利用していると招かれざる客の来訪が多い。 また、サーバに不必要にログインしている関係者がいないか 把握しつづけるのも難しい。 今回はfluentdを利用して簡単にログイン周りの通知をSlackに流してみる。 準備 /var/log/secureはパーミッションが厳しいので y-kenさんのブログを参考にパーミッションを変更する必要があります。 Fluentdでsyslogを取り込むための権限設定（CentOS 5&6両対応） - Y-Ken Studio SlackのAPIがバージョンアップしてリアルタイム性を持つようになった。 A new Slack API: The inevitable rise of the bots Bots 個人的にはリアルタイム性よりも private roomでもhubotが利用できるようになったのいうのがアツい。
GREE Advent Calendar 2015 の23日目担当の上竹です。普段はアプライアンスLB やネットワークの構築/運用をしております。 概要 バックボーンネットワークを設計運用していると、実際どのようなトラフィックがどのくらい流れているか中身を知りたい(見たい)ことがよくあります。 どのISP からどの回線へどのくらい流入があるのかだったり、どんなAS からどのくらいアクセスがきているか、これら様々な情報を正しく把握することは、Transit 回線やIX 回線をコントロールし今後のネットワーク戦略を考えるうえで非常に有益です。 また、昨今我々を悩ましているDDoS 対策の第一歩として、今流れているトラフィックをまず"知る"ということが必要だと思います。 そこで、今回ネットワークの見える化を、「NetFlow」、「Fluentd + ElasticSearch + Kibana」
Fluentd v0.12 には Fluentd v0.12 is Released で言及されているように、「ラベル」という機能が追加されています。本記事ではラベル機能の使い方、またラベル機能に対応するためにプラグインを改修する方法について解説します。 概説 このラベルという機能は、「内部ルーティングするのに add_tag_prefix したり remove_tag_prefix したり、タグ設計するのめんどくさい！！」という声にお答えして追加されたものです。 ラベル機能を使う事によって、タグを改変することなく、内部ルーティングすることができるようになります。 ラベル機能の導入によって、以下のような利点が生まれていると思います。 タグをいじることが(ほとんど)なくなったので、オリジナルのタグ情報を保てるようになった。 Fluentd 本体がサポートする機能なので、プラグイン作者が個別に
toyama0919/fluent-plugin-http_shadowというShadow Proxyっぽいことを簡単にやるプラグインを作りました。 production環境で半年くらい動かしてたのでメモしときます。 「Fluentd Meetup 2015 夏」で実際のユースケースを発表しました。 Shadow Proxyサーバとは Shadow Proxyサーバについては以下がわかりやすいです。 気軽なMySQLバージョンアップ - まめ畑 Go言語を含む複数種類の言語により実装されたソフトウェアのベンチマーク - Qiita 実装としては以下のようなものが公開されています。 cookpad/kage lestrrat/p5-Geest kentaro/delta 本番のリクエストをそのままバックエンドにあるサーバーに複製して送信するのですが、アプリケーションの規模が大きくなればなるほ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く