あんどぅ on Twitter: "本番運用するといずれ誰もがたどり着く、公式ドキュメントには書かれてないログ管理の現実解が資料化されていてすばらしい そう、CloudWatch LogsにはDev環境 or ERRORの場合のみ飛ばすFluentdの設定をすることで利便性と料金のバランスをとるのである これは公式ドキュメントにすべき https://t.co/RE4FmPCpJX"
NLB + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象を解消した話 - Repro Tech Blog
Repro インフラチーム (SRE + 分析基盤) の伊豆です。今回は、Repro のデータ収集基盤で私たちが遭遇した問題を紹介したいと思います。 具体的には、AWS Network Load Balancer(NLB) + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象に遭遇したので、その問題の調査記録と解決策を共有します。また、この問題を解消するにあたり Fluentd に PR を送ったのでそれの紹介もします。 https://github.com/fluent/fluentd/pull/2352 データ収集基盤の構成 Repro のデータ収集基盤はFlunetd High Availability Configをもとに構成され、大まかに次のようになっています。 SDK からアップロードされたデータは、転送用 Fluentd(log forwarders)を経由し
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』プロジェクトの開発・メンテナンスにおいて、トレジャーデータ株式会社（本社：東京都千代田区、以下トレジャーデータ社）が担当していた活動を引き継ぎ、開発体制を強化することをお知らせします。 『Fluentd』は2011年にトレジャーデータ社によって開発の始まったオープンソースソフトウェア（以下OSS）プロジェクトで、クリアコードは2015年9月から同プロジェクトに参加。コミュニティサポート、プラグインのメンテナンスといった活動を開始し、以降『Fluentd』本体の不具合修正、機能拡張、ドキュメント整備など活動範囲を拡大してきました。法人向けの各種サービスも提供しており、トレジャーデータ社と協働で、トレジャーデータ社の顧客に対する『Fluentd』の導入支援等も行っています。また、20
はじめに ログ集約・可視化・検索ツールとしてはELKスタックを利用するケースが多いが、これをLokiに置き換えることでより軽量にログを集約することができるようになる。 Grafana Lab社が開発したLokiは、ログのストリームに対してタグ付けし保存する仕組みを持つ。Prometheusと親和性がたかく、水平展開、高可用性、マルチテナントが可能。 構成 各クライアントからのsyslogは514/udpポートで送信される。これをrsyslogデーモンで受け5514/tcpポートへ転送する。fluentdは5514/tcpポートで受信したsyslogをさらにlokiへ転送する。 +------------------------------------------------+ | | | +---------+ | +--------+ 514/udp | | | | | client +
こんにちは、技術部 SRE グループ アルバイトの小川です。この記事では、クックパッドでコンテナログの処理に利用している Fluentd ノードのオートスケール対応について紹介します。 クックパッドでは Amazon ECS を用いてコンテナ化されたアプリケーションをデプロイしています。クックパッドでの ECS の利用については過去の記事をご覧ください。 ECS 上で動くコンテナのログを閲覧するために、標準的には Amazon CloudWatch Logs を利用する方法があります。しかし、クックパッドではログ量やコストの問題で CloudWatch Logs は利用せず、独自のログ配送基盤を構築して運用しています。具体的には、ECS のコンテナインスタンスで実行している Fluentd から複数の Amazon EC2 インスタンスで構成される Fluentd 集約ノードにログを転送し
2022年10月8日紙版発売 2022年10月6日電子版発売 田籠聡 著 A5判／544ページ 定価3,520円（本体3,200円＋税10%） ISBN 978-4-297-13109-8 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 本書は，Fluentdについて網羅的に解説した書籍です。 Fluentdは，ログやそのほかのデータの収集および集約，転送，変換，保存を実現するためのソフトウェアです。すでに多くのユーザーに利用されているほか，Kubernetes環境におけるデファクトスタンダードなログ収集方法として扱われています。そのため，AWS，GCPおよびAzu
WindowsにFluentdをインストールしてS3にデータ転送して、管理用の設定も追加 - YOMON8.NET
WindowsにFluentdを入れる機会があったのでまとめておきます。 td-agent(Fluentd)インストール td-agentダウンロード td-agentインストール プラグインのインストール ディレクトリ 設定例 設定ファイルの退避 設定ファイル Append用 Update用 Monitor用 AWSクレデンシャル 起動してテスト テストデータ準備 append(ファイル追記)の方のテスト。 update(ファイル更新)の方のテスト サービス化 管理用RPC API モニタリング 参考URL td-agent(Fluentd)インストール td-agentダウンロード 以下からmsiファイルをダウンロードしてWindowsに配置します。 本手順では td-agent-3.3.0-1-x64.msi を利用します。 https://td-agent-package-brow
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を使い始め、あまりの使い心地の良さに「ああ、最高だ」という気持ちになったため、素晴らしさを共有すべくこの記事を執筆することに致しました。一からFluentdを自分でやろうとすると中々手が出なかったり、「完全に理解した」という状態になるまで二日くらい掛かったりするので、それがこの記事を10分程度読むだけで200倍くらいの時間圧縮に繋がれば良いなと思います。少なくとも自分だけで一から学ぼうとするよりはるかに効率が良いと考えております。 Fluentdは高信頼性のデータ収集ソフトウェア Fluentdはオープンソースのデータ収集ソフトウェアで、多機能で、高速かつ信頼性高くデータ転送を行ってくれます。なぜ信頼性が高いのかというと、データ転送時に一時的にバッファーに情報を蓄積出来る機構を持っているため、障害が発生してもログの再送制御を行い欠損を防ぐことが出来るからなんです
概要 GKEなどを使えば自動的に標準出力のログが集計&集約され、Cloud Loggingなどを通して可視化されますが、 オンプレミス環境でKubernetesクラスタを構築する場合そうはいきません。 また単純なアプリケーションログの集計以外にも、 Kubernetesを使ってログ、データ集計をしている人はFluentdを運用しなくてはならない人は多いと思います。 本記事では、ログの集計、集約のデファクトスタンダードであるFluentdをKubernetes上に展開する上で、 信頼性を担保するための観点を整理します。 想定アーキテクチャ 想定アーキテクチャとしては現場でよく構築されている、図のような構成を用います。 アーキテクチャの特徴 クラスタに、FluentdがForwarderとAggregatorという2つのロールでそれぞれ存在しています。 Forwarder DaemonSetで
こんにちは、インフラチームテックリードの櫻井です。 今回はFluentdプラグインの暴走によってサーバーのストレージが枯渇しかけた話について紹介したいと思います。 アラート通知は突然に とある土曜日の夕方ごろ、1件のアラート通知がスマホに届きました。 “Filesystem % 90.19% > 90%” どうやら本番環境のバッチサーバーのストレージ使用率が90%を超えてしまったようです。 直近のストレージ使用量の推移を見てみると、朝の10時ごろからものすごいペースで増え続けており、あと30分ほどでストレージが枯渇してしまうという状況でした。 あいにく私は当時私用で外出中だったため手元にPCがなく、Slackで他のメンバーに助けを求めました。 するとちょうどPHPerKaigi 2024に参加中だったCTOの金子がこれに気づき、原因となっていたログファイルの削除などの対応をすることで、なん
こんにちは、臼田です。 fluentdの設定は自由度が高くて、逆にどうやるのが最適なのかなーと悩むことがよくあります。 今回は「apacheのログを出力したい」のような単体のログではなくて、「OSに保存されているいろんなログを(比較的)楽にS3に出力したい」という需要に答える設定を考えてみました。用途としてはとりあえずローカルの出力されているいろんなアプリログを拾ったりですとか、あとはコンプライアンス用件で細かい様々なログを全てS3に保管したいといったところが上げられると思います。 fluentdの設定値の役割についてもある程度解説しつつ、設定を紹介したいと思います。 なお、インストール方法などは省略します。公式ドキュメントなどをご参照ください。 いろんなログをまとめてS3に出力する設定 まず/etc/td-agent/td-agent.confの設定を共有します。 # read apac
Elasticsearchの最新版は7.xであることに、どういうわけか前回の記事を公開してから気づいたので、大慌てで書き直しをした。やっぱり本家のインストールガイドをきちんと読まないといけないよな、ということで改めてFlutentdでsyslogを集めてKibana7で閲覧する環境を整えてみる。 全体の構成はこんな感じだ。 受信サーバのインストール受信サーバはCPU2コア、4GBメモリ、20GBディスクのサーバを用意した。どれぐらいのスペックが適切なのかよくわからなかったので、適当に準備してみたというのが正直なところだ。これにCentOS7.xを新規に入れて、最新状態にupdateしたところから始める。 Elasticsearch7のインストール最初にyumのrepoファイルを作成する。手動で作成することになるので、コピペ用にバッチ風のテキストを用意しておこう。 cat <<EOL >/e
構想は半年ほど前？ここ一ヶ月ほど集中して開発に取り組んでいた、Fluentd向けApache Arrowプラグインがようやく動くようになったので、今回はこちらのモジュールについてご紹介します。 そもそもPG-Stromは、IoT/M2M領域で大量に発生するデータを高速に処理できますというのがセールスポイントで、GPU-Direct SQLはじめ、各種の機能によってそれを実現しているワケですが、実際に運用する際には、発生したデータを『どうやってSQLで処理できるようDBにインポートするか？』という問題があります。 例えば、PostgreSQLに一行ずつINSERTするというのも一つの解です。ただし、単純なI/Oに比べると、DBへの書き込みはどうしても処理ボトルネックになりがちです。 そこで、大量に収集するログデータを、少ない時間ロスで（つまり一時ファイルに保存したデータを再度DBにインポート
Kubernetes上でのFluentdを使ったログ収集について - Studyplus Engineering Blog
こんにちは。ご機嫌いかがでしょうか？ SREチームの栗山(id:shepherdMaster)です。 弊社ではKubernetesを導入するために着々と準備を進めております。 どんなシステム上でアプリケーションを動かすにせよ、ログ収集は必要になってきます。 Kubernetes上でログ収集をするために色々調べましたが実用的な情報があまり豊富ではなかったので、今回はKubernetes上でのログ収集、特にFluentdの設定について共有をしたいと思います。 なおまだ実運用は開始してないので今後細かい部分は変わるかもしれません。 ログ収集&ログ分析の構成 構成は以下にしました。 Fluentd + S3 + Amazon Athena 理由は以下です。 S3に保存すると非常に安い SQLでログを検索できるのは非常に便利 Fluentdの設定の柔軟性 既存のログ収集基盤がFluentd + S3
SREチームの竹田です。Tech Kayac Advent Calendar Migration Track 16日目の記事になります 弊社ではアプリケーションから出力されたログの集約管理ツールといえばfluentdほぼ一択になるでしょう。 プラグインやドキュメントも充実しており運用には欠かせない存在です。 「受信」「分類」「要素の置換/追加/削除」「転送」など様々な事をしてくれるのですが 、少々仕事をさせすぎてしまう傾向があります。 fluent-plugin-redshift 数年ほど前にリリースされたとあるサービスでログをRedshiftに投入したい要件がありました。 ログをfluentd経由でRedhshiftに投入したい場合fluent-plugin-redshiftを利用して投入することができます。 fluent-plugin-redshiftは内部で以下のようなことを行ってお
概要 Fluentdで障害設計をする上でバッファリングの概念は切っても切り離せません。 本記事では、ドキュメントだけでは拾いきれないものも踏まえ、 Fluentdのバッファリングで抑えておくべき情報を体系的にまとめます。 バッファリングとは？ Fluentdではログをバッファリングしてまとめて送信するための仕組みが用意されています。 これは下記のような用途に用いることができます。 送信先がダウンしていたときに一時的に保管しておく 送信先のキャパシティに合わせて送信流量を制限する Fluentdにはメモリ上、もしくは永続化ディスク上にバッファを保管しておく仕組みが用意されています。 バッファの構造 バッファの構造は下記のようになっています。 引用: https://docs.fluentd.org/buffer Output Pluginごとに一つバッファ領域を持っており「stage」と「q
ようやく fluentd v1.0 を最近触り始めている。極力ログを欠損させない形の設定がしたくて、 v0.12 の頃だと fluentdでログが欠損する可能性を考える - sonots:blog を参考にさせてもらっていたのだが、 v1.0 だとパラメーターが変更されている部分が多く、改めてどう設定するべきかを考えてみた。 前提 : 考慮するべきログ欠損ポイント まず前提として、 fluentd を使っていてログの欠損が発生し得るポイントを並べておく。以下、ログの送出元を forwarder 、集約先を aggregator と呼ぶ。 先の sonots 氏のエントリーを元に整理すると、基本的には aggregator 自身、もしくは forwarder - aggregator 間のネットワークに何らかのトラブルがあり、 fluentd が正常にログを送れなかった場合への対処が必要とな
うちの会社では複数あるサーバのログ集約に Fluentd を使っている。 サーバが多数あってもログファイルが1個のサーバに集まっていればログを確認するときに便利だ。 いままではなんとなく見よう見まねで使っていたが、ここいらで一つ本家ドキュメントを読んでおこう。 ここだな… https://docs.fluentd.org/ Fluentd とは ログ集約と配布をやってくれるミドルウェア。 複数のサーバでそれぞれ出力されるログを1台のサーバに集めてくれて便利。わざわざたくさんあるサーバにssh使ってログを見に行かなくて良い。 多様な入力と出力の機能や、フィルタリングや、バッファリングの機能がある。 それぞれプラグインがあって、どこと繋げるとか抽出の機能を外付けできる。 拡張性 設定でよく見かける 24224 ポートは forward というプラグインのデフォルトのポートだ。これはfluent
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで坂本大将氏が、LINEのプライベートクラウド「Verda」でログ収集する上でのポイントについて共有しました。後半は「Managed Fluentd Cluster」の導入について。前半はこちら。 Managed Fluentd Clusterの導入 まず複数のチームが、自分たちのログ設定を我々のManaged Fluentd Clusterに適用することを想定してみます。 あるチームが設定を適用する時に他のチームも同じように適用しようとすると、コンフリクトが発生する可能性があります。またあるチームが設定的に間違っている設定を適用しようとした時に、Fluentdのプロセスが壊れてしまってダウンタイムが発生してし
Amazon ECSでFluentdを動かすときの設定をSystems Managerパラメータストアに込める | DevelopersIO
ども、ゲストのNTT東日本の大瀧です。 OSSのログコレクタFluentdを動かすときに、外部から設定を取得したいときはありませんか。Amazon ECSのコンテナ環境で外部から設定を取得する方法はいくつかありますが、今回は設定をSystems Managerパラメータストアから読み込む構成をご紹介します。ちなみに、別のブログ記事でADOT Collectorの設定をSystems Managerパラメータストアから読み込む様子を見てFluentdでもやりたいなぁと思った次第でした。 構成のポイント Fluentdの設定はfluentd.confファイルに書き、それを読み込むのが一般的です。一方でDockerコンテナでのファイル読み込みは、ホストのボリュームをマウントするかdocker buildでカスタムイメージをビルドする際にコピーすることになり、コンテナイメージのポータビリティに課題
fluentdによる通知をRedash/Mackerelに移動させる - KAYAC engineers' blog
ログの監視と通知方法 SREチームの竹田です。Tech Kayac Advent Calendar Migration Track 5日目の記事になります アプリケーションの挙動を監視し、ある閾値を超えたときにだけ通知が欲しい時があります。 ある程度の障害は想定内として頻繁に起きているときにだけエスカレーションさせたい場合などです。 障害頻度の把握と通知を実現するために、アプリケーションからログをfluentdで集約し、fluent-plugin-grepcounterで一定の閾値を超えたら通知がいくような仕組みを作りました。 しかし運用していく中で以下のような問題がでてきました 閾値を変更する際にはfluentdの設定を変更する必要がある 通知のテストが難しい fluentdのバージョンアップに追随しにくい そこで、ログ集約と通知を分離することにしました。 fluentdはログの集約に専
本記事について Fluentdは機能としてはシンプルですが、 高負荷環境で安定的に運用するためにはある程度の知識が求められます。 そこで、本記事ではそれなりにログ流量の高い環境下で私が考慮した観点をまとめました。 本記事では、KubernetesでFluentdの信頼性を担保するための3つの観点に加え、 「高負荷時の安定運用」に焦点を当て、 負荷分散 適切なモニタリング トラブルシューティングとチューニング の3つの観点について整理しています。 前提となるアーキテクチャ アーキテクチャとしては実際に私が構築した図の構成を前提とします。 アーキテクチャの特徴 1つのKubernetesクラスタに、FluentdがForwarderとAggregatorという2つのロールで存在しています。 Forwarder DaemonSetでデプロイされる 各コンテナの出力ログをあつめ、Aggregato
fluentdはじめる - Qiita
fluentdについて 概要 fluentdとは、 fluentd は ログ集約ソフトウェア である 今回はdockerを用いて運用の実験を行なった。 検証1. fluentdの動作確認 目標 アプリケーションサーバとfluentdサーバの2つを使ってfluentdの機能を確かめる。 ファイル構造 |-- bottle_app | |-- app | |-- main.py <- メイン | |-- bottle.py | |-- views <- htmlファイル群 | |-- fluentd |-- config |-- fluent.conf # coding: utf-8 from bottle import template, route, run, request import urllib # htmlファイルを返す関数 @route('/') def login(): p
Fluentdのバッファリングで抑えておくべき大事なポイント - Enjoy Architecting
概要 Fluentdで障害設計をする上でバッファリングの概念は切っても切り離せません。 本記事では、ドキュメントだけでは拾いきれないものも踏まえ、 Fluentdのバッファリングで抑えておくべき情報を体系的にまとめます。 バッファリングとは？ Fluentdではログをバッファリングしてまとめて送信するための仕組みが用意されています。 これは下記のような用途に用いることができます。 送信先がダウンしていたときに一時的に保管しておく 送信先のキャパシティに合わせて送信流量を制限する Fluentdにはメモリ上、もしくは永続化ディスク上にバッファを保管しておく仕組みが用意されています。 バッファの構造 バッファの構造は下記のようになっています。 引用: https://docs.fluentd.org/buffer Output Pluginごとに一つバッファ領域を持っており「stage」と「q
Kubernetesは、コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステムですが、昨今はこの分野におけるデファクトスタンダードの地位を確立したかに見えます。Kubernetesによってもたらされた、モノリシックなアプリケーションからマイクロサービスへのシフトは、動的な環境を当たり前のものとして、より素早い展開を可能にした反面、アプリケーションとそれを支えるインフラストラクチャーの監視をより複雑にしています。幸いなことに、Elasticのテクノロジーは、古くはELK Stackと呼ばれた時代から、最近はElastic Observabilityとして、ITインフラやアプリケーションの監視ソリューションとして、幅広く利用されて来ました。Elastic Observablityを利用することで、Kubernetes
Amazon Linux 2から、常駐サービスはsystemdで扱われるようになりました。systemdで動かしているアプリケーションのログをfluentdに取り込んで、kibanaやらS3やらに流したいので方法を調べてみました。結論を先に言うと、fluent-plugin-systemdを使ってやりましょう。 systemdで動かしているサービスは、標準でjournaldに出力され、journalctlコマンドを使ってログを見ることができます。sshで繋いで見る分にはいいのですが、fluentdなどで収集して扱うにはどうすればいいかなと。今回はアプリケーションに手を入れられないケースで行ったので、アプリケーションに直接ファイルにログを吐く機構があれば、それを使ってファイルに出して、in_tailで読み込むのもありです。 ファイルに出してin_tailすれば良いのでは systemdで動作
Fluentd実践入門を読み終えた
昨年にFluentd実践入門を@tagomorisさんに献本いただいていたのですが、色々とバタバタしていたこともあり、ようやく読み終えました。 Fluentdを使い始める方にも使ってみたけれど、プラグインの機能が足りず痒い所に手が届かないけれどどのように拡張したら良いかわからない・・・。と言う初級者にも中級者にも刺さる書籍となっていました。Fluentdを開発していてもBufferありのアウトプットプラグイン(Buffered Output Plugin)のチューニングの仕方とかコードだけ追っていても若干怪しいことがあるので、大変参考になりました。 いくつかの章はクリアコードの社員としてメンテナンスをしていた時に特に力を入れて開発していた機能の紹介もあり、懐かしみながら読めました。 TLSに関係するところではcert_logical_store_nameと言う私が開発しました、そしてそのた
Fluentd aggregator を構成する際に、Route 53 や NLB を使うことで、forwarder では 1 つのエンドポイントを指定しつつ簡単に fluend の台数を増減させることができます。ところが、Docker で fluentd logging driver を使う際にそのエンドポイントを指定すると、一度コネクションが確立されるとずっとそのコネクションが使い回されるため、大量のログを吐くコンテナと接続された fluentd ホストだけが高負荷な状態が続くことになります。 この問題を解消するために FireLens を使ってみたという話です。 Fluentd logging driver の実装 Fluentd logging driver の実装は daemon/logger/fluentd/fluentd.go ですが、コネクションにメッセージを書き込むところ
TL;DR NewRelic でtd-agent のメトリクス(retry, buffer, ...)を監視する方法 概要 td-agent でEC2 インスタンス内のログをS3 へ転送していまして、そのtd-agent がちゃんと動いているかをNewRelic agent で監視する方法についてです。 ※ NewRelic でロギングを行う方法についてではなく、ロギングを行っているtd-agent をNewRelic で監視する方法についてです。 方法 やることとしてはNewRelic のnri-flex 機能を使用して、td-agent のメトリクスエンドポイントのJSON をそのままNewRelic へ転送を行います。 EC2 インスタンスの準備 AmazonLinux2 を立ててセッションマネージャ経由でssh してroot ユーザーで操作します。 本番はPacker なりImag
AWSで運用されている方がよくやるfluentdを使ったログのS3アップロードです。 手順ではApacheが動いているサーバと仮定して、以下ログをアップロードします。 /var/log/httpd/access_log /var/log/httpd/error_log /var/log/messages 前提条件 OS:AmazonLinux 2017-09 IAM Role設定済みであること。IAM Roleはインスタンスに割り当てるといいです。 バケット名:logs IAM Role設定例 S3の特定バケット（ログ保管）へアクセスする為のポリシー。 ※ バケット名は適宜書き換えのこと。 ※ Sidも適当な文字列へ書き換えること。（日時などへ） { "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt201803121612", "
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
本文の内容は、2022年6月23日にCarlos Adiegoが投稿したブログ(https://sysdig.com/blog/fluentd-monitoring/)を元に日本語に翻訳・再構成した内容となっております。 Fluentdは、Kubernetesのログアグリゲーションに広く使われているオープンソースのデータコレクターです。PrometheusでFluentdを監視し、トラブルシューティングを行うことは、ログ収集や監視システムに影響を与える潜在的な問題を特定するために、本当に重要なことです。 この記事では、Fluentd のドキュメントにある監視の推奨事項に従って、Prometheus を使って Fluentd の監視を開始する方法を学びます。また、Fluentd の最も一般的な問題と、そのトラブルシューティングの方法についても説明します。 Prometheusのメトリクスを公
Pascal〜Puree + ngx_lua + Fluentd + BigQueryでつくるメルカリのログ分析基盤〜 | メルカリエンジニアリング
エンジニアではなくプログラマと呼ばれたい@cubicdaiyaです。今回はメルカリのログ分析基盤のお話です。 メルカリにおけるログデータ分析 メルカリでは初期の頃からログデータの分析をサービスの成長にとって重要なタスクとして位置づけ、そのための基盤作りに取り組んできました。ログの種類はいくつかありますが、中でも代表的なのがアプリケーションサーバで出力されるアクセスログやアプリケーション固有のログです。これらのログはサイズが大きいので効率良くログデータを転送するための工夫が必要になります。そこで活躍するのがFluentdです。 大雑把に説明するとアプリケーションサーバで出力されたログはFluentdから最終的にBigQueryやTreasure Dataといったクラウドサービスに転送されます。(上記の図は非常に簡単に済ませていますが、実際にはログの中継やフィルタリングをするためのFluent
本番でWebアプリケーションを運用していると，様々なログを取り扱う必要がある．これはKubernetesでも同じで，Kubernetes上で動かしているコンテナのログも，何かしらの方法で集約してどこかに蓄えておいて，分析とか検索とかをしたくなる． こういう用途でまず思いつくのがfluentdで，fluentdはKubernetes用にDaemonSetを用意してくれている． github.com こいつを使えば，コンテナの標準出力に出てきたログは，すべてfluentdで拾えることになる． では，標準出力以外の，例えばファイルに吐き出すようなログはどうなるだろう？ こういったログを集めるためには，アプリケーションのコンテナのサイドカーとしてfluentdを動かし，ログファイルをVolumeMountすることでサイドカー側のfluentdにログファイルを読ませる，というようなことをする必要があ
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
topic buffering parameters flushing parameters retries parameters 公式ドキュメントを参照していますが、私の解釈が誤っている場合もあるため間違っていた場合はご指摘ください。 記事作成時点のfluentdの最新バージョンは1.2.2です。 主にbufferに関するパラメータは上記の三種類となります。 retryに関しては下記のページでも紹介しているので特にここでは記載しません。 参考： https://qiita.com/smith_30/items/1a8df503613f7e7e2904 https://qiita.com/tatsu-yam/items/bd7006e483f3b3c64309 また、buffer/chunk/flush/queue等の動作に関してもある程度上記で説明してくださっているので参考にしてみると良
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Fluentd実践入門」を10月8日に出版します - たごもりすメモ
高速データ収集ツール『Fluentd』の開発体制強化 - クリアコード
Grafana + Loki + Fluentdで実装するSyslogサーバー
Fluentd 集約ノードのオートスケール - クックパッド開発者ブログ
Fluentd実践入門 ──統合ログ基盤のためのデータ収集ツール
Fluentdのflush_mode immediateはいつ使うのか - たごもりすメモ
Fluentdはデータ収集ソフトウェア最強のツールである
KubernetesでFluentdの信頼性を担保するための3つの観点
Fluentdプラグインの暴走でストレージが枯渇しかけた話 | PR TIMES 開発者ブログ
fluentdでOSのいろんなログをまとめてS3に出力する設定考えてみた | DevelopersIO
Amazon.co.jp: Fluentd実践入門 ── 統合ログ基盤のためのデータ収集ツール (WEB+DB PRESS plus): 田籠聡: 本
Fluentd/Elasticsearch7/Kibana7でsyslogを管理してみる
Fluentd向けApache Arrowプラグインについて - KaiGaiの俺メモ
fluentdを使ったRedshiftへのログ投入方法の変遷 - KAYAC engineers' blog
Fluentdのバッファリングで抑えておくべき大事なポイント
fluentd 1.0 でログの欠損を防ぐ - chroju.dev
Fluentd の Docker のサンプルを動かしてみた話 - GMO RESEARCH Tech Blog
信頼性の高いログ収集のために「Managed Fluentd Cluster」を導入 LINEのプライベートクラウドにおけるログ管理のアイデア
高負荷環境でFluentdを安定運用するための3つの観点
Elastic StackをPrometheusとFluentdと組み合わせてKubernetesを監視する
systemdから出るjournalログをfluentdで扱う - 年中アイス
FireLens を使って fluentd logging driver 起因の fluentd の負荷を分散させる
_%25E3%2581%25AB%25E3%2583%25A1%25E3%2583%2588%25E3%2583%25AA%25E3%2582%25AF%25E3%2582%25B9%25E3%2582%2592%25E7%259B%25A3%25E8%25A6%2596%25E3%2581%2599%25E3%2582%258B)
NewRelic でtd-agent(fluentd) にメトリクスを監視する - y-ohgi's blog
AWSでFluentdを導入してS3にログアップロード - Qiita
Prometheusを使ったFluentdの監視とトラブルシュートを行う方法
PodにfluentdのSidecarを自動でinjectする - PartyIX
fluentdのbuffer周りで注意すべき点 - Qiita