あんどぅ on Twitter: "本番運用するといずれ誰もがたどり着く、公式ドキュメントには書かれてないログ管理の現実解が資料化されていてすばらしい そう、CloudWatch LogsにはDev環境 or ERRORの場合のみ飛ばすFluentdの設定をすることで利便性と料金のバランスをとるのである これは公式ドキュメントにすべき https://t.co/RE4FmPCpJX"
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
ログ基盤のFluentdをFluent Bitに移行して監視ツールを実装した話 - Mirrativ Tech Blog
はじめまして、Azuma（@azuma_alvin）です。現在大学院の1年生で、2024年2月から4ヶ月間ミラティブのインフラチームにインターンとして参加しました。普段はインフラやMLOpsといった領域に興味があり、最近はVim環境の整備がマイブームです。 本記事では、ログ基盤をFluentdからFluent Bitへ部分移行した経緯とその2種類の監視ツールの実装についてお話しします。 記事の最後に、インターンから見たインフラチームの特徴と私が4ヶ月間で学んだことを紹介しています。興味がある方は末尾までスクロールしてぜひご覧ください。 1. 背景と目的 2. ミラティブのログ基盤について 3. ログ欠損の原因調査 Fluentdのバッファリングの仕組み fsnotifyを用いたバッファリングの観察 負荷試験 日付時刻フォーマットとワイルドカードによるログ欠損 ログ保存とサーバータイムスタン
Fluentd実践入門 Fluentdの現バージョン(v1.15)について世界で一番詳しい本です。というか、Fluentdそのものだけについての、おそらく世界で唯一の技術書です。 出版社は技術評論社です。電子版もGihyo.jpやKindleはじめ各社で出ます。買ってね! gihyo.jp TL;DR 発売日は10月8日です 一部書店ではちょっと早く9月末に並ぶかも 電子版は発売日よりちょっと前に出るかも1 544ページ、Fluentd本体については考えられる限り盛り込みました Fluentdをなんとなく使っている人が確信を持って使えるようになれるはず 組込みプラグインの頻出用法、本番環境での運用ノウハウ、プラグイン開発からテストなどまで エコシステム的な部分についてはカバーできていません Kubernetes上での運用やFluent Bitとの組み合わせとか AWS FireLensやG
「私たちのログ配送、コストかかりすぎ？」fluentdのログ配送に関するコスト削減に取り組んだお話 - freee Developers Hub
はじめに こんにちは！freee のPlatform Engineerをやっているyamaです。 私の所属するCloudGovernance（CGov）チームでは主にAWS関連の権限やコストの統制・可視化・最適化などを行っています。 私は主にコスト統制をメインに担当しています。 この記事はfreee Advent Calendar 2025の7日目になります！ 今回はfreeeにおけるコスト最適化において大きな成果のあった、「fluentdのログ配送に関するコスト削減」についてご紹介いたします。 背景 CGovチームではAWSのコスト可視化・最適化を進めており、AWSのコストを定期的に確認しています。 ある日、AWSのコストエクスプローラを確認していたところログに関連するS3バケットコストの内訳に違和感を覚えました。何気なしにグラフにしてみたところ以下のようになりました。 グラフからもわか
株式会社クリアコード（本社：埼玉県所沢市、以下クリアコード）は本日、オープンソースソフトウェア『Fluentd』プロジェクトの開発・メンテナンスにおいて、トレジャーデータ株式会社（本社：東京都千代田区、以下トレジャーデータ社）が担当していた活動を引き継ぎ、開発体制を強化することをお知らせします。 『Fluentd』は2011年にトレジャーデータ社によって開発の始まったオープンソースソフトウェア（以下OSS）プロジェクトで、クリアコードは2015年9月から同プロジェクトに参加。コミュニティサポート、プラグインのメンテナンスといった活動を開始し、以降『Fluentd』本体の不具合修正、機能拡張、ドキュメント整備など活動範囲を拡大してきました。法人向けの各種サービスも提供しており、トレジャーデータ社と協働で、トレジャーデータ社の顧客に対する『Fluentd』の導入支援等も行っています。また、20
こんにちは、技術部 SRE グループ アルバイトの小川です。この記事では、クックパッドでコンテナログの処理に利用している Fluentd ノードのオートスケール対応について紹介します。 クックパッドでは Amazon ECS を用いてコンテナ化されたアプリケーションをデプロイしています。クックパッドでの ECS の利用については過去の記事をご覧ください。 ECS 上で動くコンテナのログを閲覧するために、標準的には Amazon CloudWatch Logs を利用する方法があります。しかし、クックパッドではログ量やコストの問題で CloudWatch Logs は利用せず、独自のログ配送基盤を構築して運用しています。具体的には、ECS のコンテナインスタンスで実行している Fluentd から複数の Amazon EC2 インスタンスで構成される Fluentd 集約ノードにログを転送し
概要 本書は、Fluentdについて網羅的に解説した書籍です。 Fluentdは、ログやそのほかのデータの収集および集約、転送、変換、保存を実現するためのソフトウェアです。すでに多くのユーザーに利用されているほか、Kubernetes環境におけるデファクトスタンダードなログ収集方法として扱われています。そのため、AWS、GCPおよびAzureといったクラウド環境においても標準的なツールとして使われています。 本書は、Fluentdがデータをどのように処理しているかから、内部構造やプラグイン機構の詳細、プラグインの開発方法までを網羅的に記述しています。筆者はFluentdの初期からのユーザーであり、Fluentdの主開発者の一人でもあるため、ユーザーとして必要な事項を開発者の視点から解説できているはずです。 目次 はじめに 謝辞 本書の読み進め方 本書の前提知識 対象バージョン 動作環境 サ
Fluentdのプラグインを作ってBigQueryにログを挿入するコストを1/3にした話 - pixiv inside
こんにちは。 機械学習チームにてレコメンドの改善を行っているgumigumi4fです。 この記事では、Fluentdにて収集したログをBigQueryに挿入する際に使用しているプラグインを置き換えることによって、高スループットかつ低コストを実現した話について紹介します。 背景 pixivではアクセスログやアプリケーションログ等をBigQueryに収集し、分析できるような仕組みを構築しています。 BigQueryへアクセスログを挿入する際はFluentdとそのプラグインであるfluent-plugin-bigqueryを用いて直接BigQueryへ書き込むようになっていたのですが、その際にログ欠損が起こることが問題となっていました。 ログの欠損はピークタイムで発生しており、そのピークタイムのログの流量は概ね毎秒30000logとかなり多く、実際Fluentdのworkerプロセスが1work
Fluentd v1.15.0リリース -- YAML形式サポートなどの新機能とin_tailの不具合修正 - 2022-07-05 - ククログ
2022年6月29日にFluentdの最新版となるv1.15.0をリリースしました。 クリアコードはFluentdの開発に参加し、リリースを含めたメンテナンス作業を行っています。 今回はv1.15.0で追加された新機能を中心に紹介します。 CHANGELOG リリースアナウンス Fluentd v1.15.0の新機能 YAML形式の設定をサポート Fluentdの設定ファイルは、Apacheのhttpd.confの形式を模して、ディレクティブから成る形式を用いていました。 従来のFluentdの設定ファイルについて Apache HTTP サーバの設定ファイルについて 一方で以前から、YAMLやJSONなどのより一般的な形式を使いたいという声も挙がっていました。 Issue#554 本バージョンから、Kubernetesとの親和性を考慮して、YAML形式の設定ファイルも使用できるようになり
Fluentd実践入門をあらためて手元でぱらぱらやってたら、しまった! この話をどこかにちょっとでも書こうと思ってたのに忘れてた! という話が出てきたので、忘れないうちに書いて放流する。 flush_modeとはなにか FluentdのOutputプラグインには<buffer>セクションで指定できるflush_modeというパラメータがあって、これはOutputプラグインがどういう基準でバッファ内のデータを書き出す(writeメソッドを呼ぶ)かという戦略をコントロールする。有効な値はdefault、immediate、interval、lazyの4つ。 ただし多くのケースでこのパラメータは明示的には指定されていないはず。というのも、デフォルト値であるところのdefaultの場合には、<buffer>セクションに指定されている他のパラメータ((と、例外的に<buffer>セクションの外側に指
こんにちは、インフラチームテックリードの櫻井です。 今回はFluentdプラグインの暴走によってサーバーのストレージが枯渇しかけた話について紹介したいと思います。 アラート通知は突然に とある土曜日の夕方ごろ、1件のアラート通知がスマホに届きました。 “Filesystem % 90.19% > 90%” どうやら本番環境のバッチサーバーのストレージ使用率が90%を超えてしまったようです。 直近のストレージ使用量の推移を見てみると、朝の10時ごろからものすごいペースで増え続けており、あと30分ほどでストレージが枯渇してしまうという状況でした。 あいにく私は当時私用で外出中だったため手元にPCがなく、Slackで他のメンバーに助けを求めました。 するとちょうどPHPerKaigi 2024に参加中だったCTOの金子がこれに気づき、原因となっていたログファイルの削除などの対応をすることで、なん
構想は半年ほど前？ここ一ヶ月ほど集中して開発に取り組んでいた、Fluentd向けApache Arrowプラグインがようやく動くようになったので、今回はこちらのモジュールについてご紹介します。 そもそもPG-Stromは、IoT/M2M領域で大量に発生するデータを高速に処理できますというのがセールスポイントで、GPU-Direct SQLはじめ、各種の機能によってそれを実現しているワケですが、実際に運用する際には、発生したデータを『どうやってSQLで処理できるようDBにインポートするか？』という問題があります。 例えば、PostgreSQLに一行ずつINSERTするというのも一つの解です。ただし、単純なI/Oに比べると、DBへの書き込みはどうしても処理ボトルネックになりがちです。 そこで、大量に収集するログデータを、少ない時間ロスで（つまり一時ファイルに保存したデータを再度DBにインポート
概要 Fluentdで障害設計をする上でバッファリングの概念は切っても切り離せません。 本記事では、ドキュメントだけでは拾いきれないものも踏まえ、 Fluentdのバッファリングで抑えておくべき情報を体系的にまとめます。 バッファリングとは？ Fluentdではログをバッファリングしてまとめて送信するための仕組みが用意されています。 これは下記のような用途に用いることができます。 送信先がダウンしていたときに一時的に保管しておく 送信先のキャパシティに合わせて送信流量を制限する Fluentdにはメモリ上、もしくは永続化ディスク上にバッファを保管しておく仕組みが用意されています。 バッファの構造 バッファの構造は下記のようになっています。 引用: https://docs.fluentd.org/buffer Output Pluginごとに一つバッファ領域を持っており「stage」と「q
うちの会社では複数あるサーバのログ集約に Fluentd を使っている。 サーバが多数あってもログファイルが1個のサーバに集まっていればログを確認するときに便利だ。 いままではなんとなく見よう見まねで使っていたが、ここいらで一つ本家ドキュメントを読んでおこう。 ここだな… https://docs.fluentd.org/ Fluentd とは ログ集約と配布をやってくれるミドルウェア。 複数のサーバでそれぞれ出力されるログを1台のサーバに集めてくれて便利。わざわざたくさんあるサーバにssh使ってログを見に行かなくて良い。 多様な入力と出力の機能や、フィルタリングや、バッファリングの機能がある。 それぞれプラグインがあって、どこと繋げるとか抽出の機能を外付けできる。 拡張性 設定でよく見かける 24224 ポートは forward というプラグインのデフォルトのポートだ。これはfluent
Amazon ECSでFluentdを動かすときの設定をSystems Managerパラメータストアに込める | DevelopersIO
ども、ゲストのNTT東日本の大瀧です。 OSSのログコレクタFluentdを動かすときに、外部から設定を取得したいときはありませんか。Amazon ECSのコンテナ環境で外部から設定を取得する方法はいくつかありますが、今回は設定をSystems Managerパラメータストアから読み込む構成をご紹介します。ちなみに、別のブログ記事でADOT Collectorの設定をSystems Managerパラメータストアから読み込む様子を見てFluentdでもやりたいなぁと思った次第でした。 構成のポイント Fluentdの設定はfluentd.confファイルに書き、それを読み込むのが一般的です。一方でDockerコンテナでのファイル読み込みは、ホストのボリュームをマウントするかdocker buildでカスタムイメージをビルドする際にコピーすることになり、コンテナイメージのポータビリティに課題
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで坂本大将氏が、LINEのプライベートクラウド「Verda」でログ収集する上でのポイントについて共有しました。後半は「Managed Fluentd Cluster」の導入について。前半はこちら。 Managed Fluentd Clusterの導入まず複数のチームが、自分たちのログ設定を我々のManaged Fluentd Clusterに適用することを想定してみます。 あるチームが設定を適用する時に他のチームも同じように適用しようとすると、コンフリクトが発生する可能性があります。またあるチームが設定的に間違っている設定を適用しようとした時に、Fluentdのプロセスが壊れてしまってダウンタイムが発生してしま
Kubernetesは、コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステムですが、昨今はこの分野におけるデファクトスタンダードの地位を確立したかに見えます。Kubernetesによってもたらされた、モノリシックなアプリケーションからマイクロサービスへのシフトは、動的な環境を当たり前のものとして、より素早い展開を可能にした反面、アプリケーションとそれを支えるインフラストラクチャーの監視をより複雑にしています。幸いなことに、Elasticのテクノロジーは、古くはELK Stackと呼ばれた時代から、最近はElastic Observabilityとして、ITインフラやアプリケーションの監視ソリューションとして、幅広く利用されて来ました。Elastic Observablityを利用することで、Kubernetes
本記事について Fluentdは機能としてはシンプルですが、 高負荷環境で安定的に運用するためにはある程度の知識が求められます。 そこで、本記事ではそれなりにログ流量の高い環境下で私が考慮した観点をまとめました。 本記事では、KubernetesでFluentdの信頼性を担保するための3つの観点に加え、 「高負荷時の安定運用」に焦点を当て、 負荷分散 適切なモニタリング トラブルシューティングとチューニング の3つの観点について整理しています。 前提となるアーキテクチャ アーキテクチャとしては実際に私が構築した図の構成を前提とします。 アーキテクチャの特徴 1つのKubernetesクラスタに、FluentdがForwarderとAggregatorという2つのロールで存在しています。 Forwarder DaemonSetでデプロイされる 各コンテナの出力ログをあつめ、Aggregato
Fluentdのバッファリングで抑えておくべき大事なポイント - Enjoy Architecting
概要 Fluentdで障害設計をする上でバッファリングの概念は切っても切り離せません。 本記事では、ドキュメントだけでは拾いきれないものも踏まえ、 Fluentdのバッファリングで抑えておくべき情報を体系的にまとめます。 バッファリングとは？ Fluentdではログをバッファリングしてまとめて送信するための仕組みが用意されています。 これは下記のような用途に用いることができます。 送信先がダウンしていたときに一時的に保管しておく 送信先のキャパシティに合わせて送信流量を制限する Fluentdにはメモリ上、もしくは永続化ディスク上にバッファを保管しておく仕組みが用意されています。 バッファの構造 バッファの構造は下記のようになっています。 引用: https://docs.fluentd.org/buffer Output Pluginごとに一つバッファ領域を持っており「stage」と「q
こんにちは、やまなかです。 Fluentd は、さまざまなシステムのログを集約し、分析や転送を行うことができるツールです。 Fluentd (td-agent) とは？ Fluentd (td-agent) とは、さまざまなシステムに散らばっているログデータを収集、集約して、分析を行ったり、DBなどにログデータを転送することができるツールです。Elasticsearch（検索エンジン）や kibana（データ可視化ツール）と組み合わせることでログを可視化することもできます。すべての機能がプラグインで実装されていることが特徴的で、柔軟な運用が可能です。 Fluentd は、Ruby gem で提供されています。Ruby やいくつかのプラグインが同梱されている安定版の「td-agent」としても提供されています。両者の挙動は同じため、ひとまずは違いを気にする必要はありませんが、気になる方は公
本文の内容は、2022年6月23日にCarlos Adiegoが投稿したブログ(https://sysdig.com/blog/fluentd-monitoring/)を元に日本語に翻訳・再構成した内容となっております。 Fluentdは、Kubernetesのログアグリゲーションに広く使われているオープンソースのデータコレクターです。PrometheusでFluentdを監視し、トラブルシューティングを行うことは、ログ収集や監視システムに影響を与える潜在的な問題を特定するために、本当に重要なことです。 この記事では、Fluentd のドキュメントにある監視の推奨事項に従って、Prometheus を使って Fluentd の監視を開始する方法を学びます。また、Fluentd の最も一般的な問題と、そのトラブルシューティングの方法についても説明します。 Prometheusのメトリクスを公
Fluentd実践入門を読み終えた
昨年にFluentd実践入門を@tagomorisさんに献本いただいていたのですが、色々とバタバタしていたこともあり、ようやく読み終えました。 Fluentdを使い始める方にも使ってみたけれど、プラグインの機能が足りず痒い所に手が届かないけれどどのように拡張したら良いかわからない・・・。と言う初級者にも中級者にも刺さる書籍となっていました。Fluentdを開発していてもBufferありのアウトプットプラグイン(Buffered Output Plugin)のチューニングの仕方とかコードだけ追っていても若干怪しいことがあるので、大変参考になりました。 いくつかの章はクリアコードの社員としてメンテナンスをしていた時に特に力を入れて開発していた機能の紹介もあり、懐かしみながら読めました。 TLSに関係するところではcert_logical_store_nameと言う私が開発しました、そしてそのた
はじめに この記事はInner Resourceのエンジニア勉強会の資料を社外向けに公開したものです。 著者のFluentdの経験としてはKibanaでログ可視化くらいで止まっていたので、Fluent Bitやログ検索にGrafana Lokiを使用した場合の構成例なども調べてまとめてみました。 Fluentdとは？ Fluentd（フルエントディー）はオープンソースのログ収集管理ツールやデータコレクターと呼ばれるソフトウェア。Fluentdの大部分はRubyで実装されており、パフォーマンスに関わる部分のみCで実装されています。 Fluent Bitとの違い Fluentdの兄弟プロジェクトとしてFluent Bitというソフトウェアも存在します。 Fluent Bitは全てCで実装されているのが特徴で、Fluentdよりも軽量でパフォーマンスが優れているためIoT/組み込みやK8s等のコ
FluentdをDockerで試してみる
Fluentdって何？ オープンソースのデータコレクター（収集）です。 JSONを利用したロギング 500以上プラグインがある リソースも少ない https://www.fluentd.org/architecture 日本人が元を作成していて、日本語の資料も多いです。 とりあえず、Dockerで試してみる。(ダラダラと試していくのでご了承ください。) ダラダラと試してみる。 Fluentdサーバの公式のイメージ 公式から探すと下記が公式イメージらしい とりあえず起動するだけなら下記でOK 利用するポート：-p 24224:24224 -p 24224:24224/udp 利用するディレクトリ：-v /data:/fluentd/log (この時点の推測だと、このフォルダにログ情報のJSONが吐き出されると思う…) docker run -d -p 24224:24224 -p 24224
ECS の Daemon サービスで動かしている Fluentd を Logging Driver の接続先にすると Draining 時にコンテナが終了しないことがある問題とその対策
標題のとおり、ECS の daemon サービスで動かしている Fluentd を logging driver の接続先にすると、draining 時に Docker container with fluentd logging driver never stops if it can’t connect to fluentd · Issue #44511 · moby/moby で言及している問題が起きて、Fluentd が復活しない限り、logging driver で Fluentd を利用しているコンテナが無限に生き続けることになります。 本エントリーでは問題の再現方法と対策について解説します。 Issue についての解説 どうしてコンテナが終了しないかについての自分なりの仮説はコメントに書いたとおりです。 次のように 3 つの goroutine が関係していそうです。 gor
AWS上の fluentd から BigQuery への認証に Workload Identity を利用する - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
この記事では、AWS の EC2 や ECS 上で動作する fluentd から Workload Identity を利用してBigQueryにログを送る方法を紹介します。 背景 AWS から BigQuery にアクセスする際、従来はサービスアカウントキーを利用して認証を行なっていました。しかし、サービスアカウントキーは厳重な管理が必要です。これに対して、Workload Identity を利用すれば、管理が必要なキー自体をなくすことができ、運用の手間を軽減することができます。 先日 googleauth gem 1.5 がリリースされ、Ruby からも AWS からのWorkload Identity による認証をすることが可能になりました。 rubygems.org 早速これを利用して、AWS上のEC2やECSで動作する fluentd から BigQuery にデータ送信する際
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Fluentd実践入門」を10月8日に出版します - たごもりすメモ
高速データ収集ツール『Fluentd』の開発体制強化 - クリアコード
Fluentd 集約ノードのオートスケール - クックパッド開発者ブログ
Fluentd実践入門 | 技術評論社
Fluentdのflush_mode immediateはいつ使うのか - たごもりすメモ
Fluentdプラグインの暴走でストレージが枯渇しかけた話 | PR TIMES 開発者ブログ
Amazon.co.jp: Fluentd実践入門 ── 統合ログ基盤のためのデータ収集ツール (WEB+DB PRESS plus): 田籠聡: 本
Fluentd向けApache Arrowプラグインについて - KaiGaiの俺メモ
Fluentdのバッファリングで抑えておくべき大事なポイント
Fluentd の Docker のサンプルを動かしてみた話 - GMO Research & AI Tech Blog
信頼性の高いログ収集のために「Managed Fluentd Cluster」を導入 LINEのプライベートクラウドにおけるログ管理のアイデア | ログミーBusiness
Elastic StackをPrometheusとFluentdと組み合わせてKubernetesを監視する
高負荷環境でFluentdを安定運用するための3つの観点
初心者でもわかる！Fluentdとは？SIOS Tech Lab
Prometheusを使ったFluentdの監視とトラブルシュートを行う方法 | Sysdig
Fluentd(Fluent Bit)の特徴と代表的な構成例を紹介
anond.hatelabo.jp
norimakichan.hatenablog.com
anond.hatelabo.jp
toyokeizai.net
plentyofquality.net
ranobedou.com