1 - 40 件 / 43件
突然ですが... あなたは、あるゲームプロジェクトの本番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか? はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクトの本番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし
課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可
はじめまして、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
はじめに TROCCO では ETL ジョブや、dbt 連携、ワークフローなど、様々なジョブで実行ログをリアルタイムで見ることができます。 これによりエラー時のトラブルシュートをスムーズに行うことができます。 そして、この実行ログですが、DB にあるジョブのレコードの1カラムに書き込まれていました。 このように TROCCO の実行ログの表示機能は、データベースのアンチパターンの上に成り立っています。 ログデータは TEXT 型で DB に保存されているためサイズが大きく、また TROCCO の成長に応じてジョブ数は増えるため、ログデータもサービスの成長とともに無限に成長してしまいます。 おかげさまでアカウント数は増加の一方であり、それに伴い DDL が遅くなったり、また SELECT のパフォーマンスも当然落ちるため、INDEX に気をつけたりする必要がありました。 SRE ではこれに課
こんにちは! シェルフィー株式会社で SRE を担当している石田です。 弊社では、本番のワークロードにて Fluent Bit を使っております。 今回、Fluent Bitの処理について理解を深めたので記事を書いてみました。 世界中で使われているとても有名なミドルウェアなので、参考になればとても嬉しいです。 はじめに 弊社では、ECS on Fargate で稼働しているバッチジョブのログをサイドカーコンテナ(Fluent Bit)を使い Datadog に連携しています。 ログのサイズが 16 KB 以上ある場合、shim-logger の仕様により、そのログは分割されてしまうため、 Fluent Bitにて分割されたログの再結合処理を行う必要性があります。 この点についてはDeNAさんの記事がわかりやすいので、詳細はそちらを参考にしてもらえたらと思います。 AWS ECS on Fa
株式会社クリアコード(本社:埼玉県所沢市、以下クリアコード)は本日、オープンソースソフトウェア『Fluentd』プロジェクトの開発・メンテナンスにおいて、トレジャーデータ株式会社(本社:東京都千代田区、以下トレジャーデータ社)が担当していた活動を引き継ぎ、開発体制を強化することをお知らせします。 『Fluentd』は2011年にトレジャーデータ社によって開発の始まったオープンソースソフトウェア(以下OSS)プロジェクトで、クリアコードは2015年9月から同プロジェクトに参加。コミュニティサポート、プラグインのメンテナンスといった活動を開始し、以降『Fluentd』本体の不具合修正、機能拡張、ドキュメント整備など活動範囲を拡大してきました。法人向けの各種サービスも提供しており、トレジャーデータ社と協働で、トレジャーデータ社の顧客に対する『Fluentd』の導入支援等も行っています。また、20
こんにちは、LINEのプライベートクラウドサービスであるVerdaのLoad Balancer as a Service (LBaaS) のチームでTech Leadをしている早川です。このエントリでは私が2019年4月にLINEに入社してからの約2年半で体験した大規模LBaaSならではの興味深い問題をピックアップしてご紹介します。 Verda LBaaSについて VerdaのLBaaSは2016年ごろに稼働を開始したVerdaの中でも比較的歴史が長いサービスです。当時のLINEではハードウェアのアプライアンス製品を用いて提供されていたロードバランサのサービスを置き換える目的で開発されました。特徴としては実際にユーザのトラフィックを受けるいわゆるデータプレーンと呼ばれるコンポーネントも含めて全てがソフトウェアで実装されているということが挙げられます。 中でも個人的に気に入っているのは、L4
はじめに ログ集約・可視化・検索ツールとしてはELKスタックを利用するケースが多いが、これをLokiに置き換えることでより軽量にログを集約することができるようになる。 Grafana Lab社が開発したLokiは、ログのストリームに対してタグ付けし保存する仕組みを持つ。Prometheusと親和性がたかく、水平展開、高可用性、マルチテナントが可能。 構成 各クライアントからのsyslogは514/udpポートで送信される。これをrsyslogデーモンで受け5514/tcpポートへ転送する。fluentdは5514/tcpポートで受信したsyslogをさらにlokiへ転送する。 +------------------------------------------------+ | | | +---------+ | +--------+ 514/udp | | | | | client +
リトライの設定 デフォルトでは Retry_Limit 1 なのでoutput失敗時に1回だけリトライしてそこでも失敗すると捨ててしまう https://docs.fluentbit.io/manual/administration/scheduling-and-retries バッファの設定 デフォルトでは on memory なので停止すると停止時に output できなかったログが消える https://docs.fluentbit.io/manual/administration/buffering-and-storage https://docs.fluentbit.io/manual/administration/backpressure tail posision の指定 どこまで読み取ったかを記録して再開できるようにしておく https://docs.fluentbit.i
この記事はクラウドワークス アドベントカレンダー6日目の記事です。 前日の記事は@bugfireのgithub-script は便利でした。GitHub Actionsでのちょっとした作業が捗りますね! SREチームの@kangaechuです。 気がつくと入社から2年が経ちました。2年前のAdvent Calendarでは ぴよぴよSREという記事を書くくらい何もわかっていませんでしたが、ようやく自分なりに動けるようになってきました。 この記事ではcrowdworks.jpのSREチームで、この2年間でどのようなことをやっていたのかを振り返ります。 SREチームの範囲は幅広く、いろいろなことをやっていました。今回はDocker化とTerraformの2つの取り組みについてご紹介します。 なんで1年じゃなく2年かって?去年はaws-vault についてのあれこれを書いたからだよ。 Docke
こんにちは、技術部 SRE グループ アルバイトの小川です。この記事では、クックパッドでコンテナログの処理に利用している Fluentd ノードのオートスケール対応について紹介します。 クックパッドでは Amazon ECS を用いてコンテナ化されたアプリケーションをデプロイしています。クックパッドでの ECS の利用については過去の記事をご覧ください。 ECS 上で動くコンテナのログを閲覧するために、標準的には Amazon CloudWatch Logs を利用する方法があります。しかし、クックパッドではログ量やコストの問題で CloudWatch Logs は利用せず、独自のログ配送基盤を構築して運用しています。具体的には、ECS のコンテナインスタンスで実行している Fluentd から複数の Amazon EC2 インスタンスで構成される Fluentd 集約ノードにログを転送し
こんにちはSRE部の川津です。ZOZOTOWNにおけるログ収集基盤の開発を進めています。開発を進めていく中でCloud Pub/Subのリージョン間費用を削減できる部分が見つかりました。 今回、OSSであるfluent-plugin-gcloud-pubsub-customにコントリビュートした結果、Cloud Pub/Subのリージョン間費用を削減できました。その事例を、ログ収集基盤開発の経緯と実装要件を踏まえて紹介します。 目次 目次 ログ収集基盤の紹介 開発経緯 フロントエンドのログしか取得できない BigQuery ExportはSLAを担保されていない リアルタイムにログを保存できない 実装要件 ログ送信側の環境に依存しない共通の仕組みで実装する 転送されるログの量に応じてオートスケールする構成にする 送られてくるログをロストしない リアルタイムにログが保存される インフラ構成
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はZOZO Advent Calendar 2021に出したかったけど既に枠が埋まっていたので野良で出した記事です。 はじめに こんにちは。絶対にKubernetes上の分析ログを欠損させたくない@civitaspoです。今年は社内のログ収集基盤構築プロジェクトでfluent-pvc-operatorというKubernetes Operatorを作りました。この記事ではfluent-pvc-operatorが解決する課題、及び機能や使い方について紹介したいと思います。 なお、この記事ではfluent-pvc-operatorの説
こんにちは!コンサル部のinomaso(@inomasosan)です。 ECS FargateでFireLensからCloudWatch LogsやKinesis Data Firehoseへのログ出力を、Terraformでコード化したので紹介します。 検証にあたり、弊社の以下ブログを参考にしました。 そもそもFireLensって何? FireLensは、複数のAWSサービスやAWSパートナーネットワーク(Datadog等)にログ出力することができます。 ECSタスク定義でサイドカーとして起動し、他のコンテナからログドライバーとして使用します。 コンテナイメージにはFluentdとFluent Bitを選択可能です。 今回の検証では、リソース使用率が低く、ログルータに推奨されているFluent Bitを使用します。 2021年11月6日時点でFluent Bitでは、以下のAWSサービスに
概要 本書は、Fluentdについて網羅的に解説した書籍です。 Fluentdは、ログやそのほかのデータの収集および集約、転送、変換、保存を実現するためのソフトウェアです。すでに多くのユーザーに利用されているほか、Kubernetes環境におけるデファクトスタンダードなログ収集方法として扱われています。そのため、AWS、GCPおよびAzureといったクラウド環境においても標準的なツールとして使われています。 本書は、Fluentdがデータをどのように処理しているかから、内部構造やプラグイン機構の詳細、プラグインの開発方法までを網羅的に記述しています。筆者はFluentdの初期からのユーザーであり、Fluentdの主開発者の一人でもあるため、ユーザーとして必要な事項を開発者の視点から解説できているはずです。 目次 はじめに 謝辞 本書の読み進め方 本書の前提知識 対象バージョン 動作環境 サ
こんにちは。 機械学習チームにてレコメンドの改善を行っているgumigumi4fです。 この記事では、Fluentdにて収集したログをBigQueryに挿入する際に使用しているプラグインを置き換えることによって、高スループットかつ低コストを実現した話について紹介します。 背景 pixivではアクセスログやアプリケーションログ等をBigQueryに収集し、分析できるような仕組みを構築しています。 BigQueryへアクセスログを挿入する際はFluentdとそのプラグインであるfluent-plugin-bigqueryを用いて直接BigQueryへ書き込むようになっていたのですが、その際にログ欠損が起こることが問題となっていました。 ログの欠損はピークタイムで発生しており、そのピークタイムのログの流量は概ね毎秒30000logとかなり多く、実際Fluentdのworkerプロセスが1work
Amazon ECS now fully supports multiline logging powered by AWS for Fluent Bit for both AWS Fargate and Amazon EC2. AWS Fluent Bit is an AWS distribution of the open-source project Fluent Bit, a fast and a lightweight log forwarder. Amazon ECS users can use this feature to re-combine partial log messages produced by your containerized applications running on AWS Fargate or Amazon EC2 into a single
Amazon Web Services ブログ 詳解 FireLens – Amazon ECS タスクで高度なログルーティングを実現する機能を深く知る この記事は Under the hood: FireLens for Amazon ECS Task (記事公開日: 2019 年 11 月 18 日) を翻訳したものです。 2019 年 11 月、Amazon ECS は FireLens によるカスタムログルーティングのサポートを発表しました。FireLens によって、人気の高いオープンソースのロギングプロジェクトである Fluentd や Fluent Bit を簡単に使用することができ、さまざまな AWS サービスやパートナーの宛先にログを送信することができます。 この記事では、私たちがなぜ、どのようにして FireLens を作ったのか、詳しく説明します。また、私が Fire
こんにちは。バクラク事業部Platform Engineering部DevOpsチームの@civitaspoです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、この記事ではAWS FireLensに関する情報をクイズ形式でお届けします。 みなさんはAWS FireLensを使っていますか?弊社ではAmazon ECS上にアプリケーションをホスティングしており、AWS FireLensを利用してログ収集・ログ送信を行っています。AWS FireLensは非常に便利です。一方、AWS FireLensは奥が深い挙動をすることもあります。この記事ではそんなAWS FireLensを深く理解するための情報をクイズ形式でお届けしてみることにしました。僕が知る限りの情報を詰め込んでみたのでAWS FireLensを深く理解したい方に届けばいいなと思います。 AWS FireLe
これは クラウドワークス アドベントカレンダー 24日目の記事です。前日は 畑中 さんの制作会社出身のデザイナーが事業会社に入って感じた5つの悩み事でした。事業会社とデザイン制作会社の違いから生まれる悩みをどう解決したかが伝わる記事でした。 クラウドワークスSREチームの @kangaechu です。最近はM1 Macを購入しました。M1 Macはアプリケーションの対応状況がまだまだなので、Goをソースからクロスコンパイルするなど、今までやったことがないことができてちょっと楽しいです。でももう少しネイティブのアプリが揃うと嬉しいな。 アドベントカレンダーはSREチームに入ってからの2年間にチームでやってきたことに続き、2つめのエントリとなります。前回の記事で、Docker化したシステムの一つとしてfluentd(ログ基盤)を挙げました。ここではそのログ基盤についての詳細を書いていきます。
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形式の設定ファイルも使用できるようになり
三行で FireLens を使うことで ECS で稼働するアプリケーションのログ転送を簡単に実装できる しかし、ドキュメントに記載されている設定例をそのまま利用しただけでは実はログの取りこぼしがあった ログの取りこぼしを防ぐためにコンテナ間の依存関係とHealthcheckの設定を行った FireLens とは FireLens を簡単に言うと、「ECS のタスク定義の記述だけで Fluent Bit / Fluentd を使ったログ転送用のサイドカーコンテナが利用できる機能」でしょうか。 FireLens という個別のサービスやソフトウェアが存在するわけでは無いようです。 詳細は以下を参照ください。 症状 私が関わったとあるサービスでは ECS を使ってアプリケーションを稼働させていて、アプリケーションのログは FireLens により Fluent Bit を使ってログ転送を行っていま
Fluentd実践入門をあらためて手元でぱらぱらやってたら、しまった! この話をどこかにちょっとでも書こうと思ってたのに忘れてた! という話が出てきたので、忘れないうちに書いて放流する。 flush_modeとはなにか FluentdのOutputプラグインには<buffer>セクションで指定できるflush_modeというパラメータがあって、これはOutputプラグインがどういう基準でバッファ内のデータを書き出す(writeメソッドを呼ぶ)かという戦略をコントロールする。有効な値はdefault、immediate、interval、lazyの4つ。 ただし多くのケースでこのパラメータは明示的には指定されていないはず。というのも、デフォルト値であるところのdefaultの場合には、<buffer>セクションに指定されている他のパラメータ((と、例外的に<buffer>セクションの外側に指
はじめに 最近Fluentdを使い始め、あまりの使い心地の良さに「ああ、最高だ」という気持ちになったため、素晴らしさを共有すべくこの記事を執筆することに致しました。一からFluentdを自分でやろうとすると中々手が出なかったり、「完全に理解した」という状態になるまで二日くらい掛かったりするので、それがこの記事を10分程度読むだけで200倍くらいの時間圧縮に繋がれば良いなと思います。少なくとも自分だけで一から学ぼうとするよりはるかに効率が良いと考えております。 Fluentdは高信頼性のデータ収集ソフトウェア Fluentdはオープンソースのデータ収集ソフトウェアで、多機能で、高速かつ信頼性高くデータ転送を行ってくれます。なぜ信頼性が高いのかというと、データ転送時に一時的にバッファーに情報を蓄積出来る機構を持っているため、障害が発生してもログの再送制御を行い欠損を防ぐことが出来るからなんです
本検証利用したFargateのCloudFormationテンプレート、FireLensのDockerfileなどは以下に置いてあります。タスクロールなどは必要に応じて確認してください。 Fargate一式 FireLensのDockerfile 設定ファイル 以下のFluent Bitの設定ファイルを作成しました。 [SERVICE] Flush 1 Grace 30 # ELBヘルスチェックログ除外 [FILTER] Name grep Match *-firelens-* Exclude log ^(?=.*ELB-HealthChecker\/2\.0).*$ # エラーログにタグ付け [FILTER] Name rewrite_tag Match *-firelens-* Rule $log (emerg|alert|crit|error|\s4\d{2}\s|\s5\d{2}\
こんにちは。UZOUのプロダクト開発をしているエンジニアの@kanga333です。 UZOUでは広告データの集計の一部にAmazon Athenaを採用しています。 この記事ではUZOUにおけるAthenaを使ったデータ処理基盤の設計について紹介したいと思います。 全体構成 データ処理基盤の全体構成は次のようになっています。 以後はそれぞれのコンポーネントについて順次紹介していきます。 FleuntdによるS3への集約 UZOUでは特にFluentdアグリゲータのような中継サーバは設けていません。広告配信サーバに常駐するFluentdがログを直接S3にプットしています。 以下はFluentdのS3 output部分の設定の一部抜粋です。 <buffer time> @type file timekey 60m </buffer> path example_table/dt=%Y%m%d/h
こんにちは、インフラチームテックリードの櫻井です。 今回はFluentdプラグインの暴走によってサーバーのストレージが枯渇しかけた話について紹介したいと思います。 アラート通知は突然に とある土曜日の夕方ごろ、1件のアラート通知がスマホに届きました。 "Filesystem % 90.19% > 90%" どうやら本番環境のバッチサーバーのストレージ使用率が90%を超えてしまったようです。 直近のストレージ使用量の推移を見てみると、朝の10時ごろからものすごいペースで増え続けており、あと30分ほどでストレージが枯渇してしまうという状況でした。 あいにく私は当時私用で外出中だったため手元にPCがなく、Slackで他のメンバーに助けを求めました。 するとちょうどPHPerKaigi 2024に参加中だったCTOの金子がこれに気づき、原因となっていたログファイルの削除などの対応をすることで、なん
概要 GKEなどを使えば自動的に標準出力のログが集計&集約され、Cloud Loggingなどを通して可視化されますが、 オンプレミス環境でKubernetesクラスタを構築する場合そうはいきません。 また単純なアプリケーションログの集計以外にも、 Kubernetesを使ってログ、データ集計をしている人はFluentdを運用しなくてはならない人は多いと思います。 本記事では、ログの集計、集約のデファクトスタンダードであるFluentdをKubernetes上に展開する上で、 信頼性を担保するための観点を整理します。 想定アーキテクチャ 想定アーキテクチャとしては現場でよく構築されている、図のような構成を用います。 アーキテクチャの特徴 クラスタに、FluentdがForwarderとAggregatorという2つのロールでそれぞれ存在しています。 Forwarder DaemonSetで
構想は半年ほど前?ここ一ヶ月ほど集中して開発に取り組んでいた、Fluentd向けApache Arrowプラグインがようやく動くようになったので、今回はこちらのモジュールについてご紹介します。 そもそもPG-Stromは、IoT/M2M領域で大量に発生するデータを高速に処理できますというのがセールスポイントで、GPU-Direct SQLはじめ、各種の機能によってそれを実現しているワケですが、実際に運用する際には、発生したデータを『どうやってSQLで処理できるようDBにインポートするか?』という問題があります。 例えば、PostgreSQLに一行ずつINSERTするというのも一つの解です。ただし、単純なI/Oに比べると、DBへの書き込みはどうしても処理ボトルネックになりがちです。 そこで、大量に収集するログデータを、少ない時間ロスで(つまり一時ファイルに保存したデータを再度DBにインポート
こんにちは、Яeiです。 今回は現役エンジニアである私がFluent Bitって何だという話についてまとめたいと思います。 最近巷で良く聞くFluent Bitと呼ばれるものがありますが、そもそもこれって何なのか調査しましたのでシェア致します。 最後はdocker-composeを用いたサンプルも用意しましたので見てみて下さい。 Fluent Bit 概要は公式サイトに分かりやすく書かれておりますので興味のある方は一読しておくとよいでしょう。 参考 fluentbitfluentbit また、各種ドキュメントは以下公式資料に詳しく書かれておりますのでこちらを参考にしてもらえればと思います。 参考 Fluent Bit ドキュメント 概要 Fluent Bitとは、 アプリケーションから出力されたログファイルや標準出力ログなどのデータを収集し、フィルタリングして複数の宛先に送信できるツールと
本記事について Fluentdは機能としてはシンプルですが、 高負荷環境で安定的に運用するためにはある程度の知識が求められます。 そこで、本記事ではそれなりにログ流量の高い環境下で私が考慮した観点をまとめました。 本記事では、KubernetesでFluentdの信頼性を担保するための3つの観点に加え、 「高負荷時の安定運用」に焦点を当て、 負荷分散 適切なモニタリング トラブルシューティングとチューニング の3つの観点について整理しています。 前提となるアーキテクチャ アーキテクチャとしては実際に私が構築した図の構成を前提とします。 アーキテクチャの特徴 1つのKubernetesクラスタに、FluentdがForwarderとAggregatorという2つのロールで存在しています。 Forwarder DaemonSetでデプロイされる 各コンテナの出力ログをあつめ、Aggregato
こんにちは、lyluckです。 ピクシブではオンプレミスKubernetes(以下、k8s)クラスターを運用しています。 既存アプリケーションのk8s移行は依然として進行中で、クラスターの規模は以前と比べて倍の20台程度になっています。 アプリケーションをk8s移行するには、アプリケーションログの転送機能も一緒にk8sへ移行する必要があります。 今回はk8sにおけるログ転送時のログ欠損を抑えるために取り組んだことを紹介します。 背景 k8s移行対象のアプリケーションには転送が必要なログを生み出すものがあります。 次の図のように、Fluentdがログをアプリケーションがあるサーバーとは別のサーバーへ転送しています。 左側のサーバーの中身すべてをk8sクラスター上で動かすにはFluentdもk8sクラスターへ移行する必要があります。 ログ転送のためのFluentd DaemonSetがあったの
概要 Fluentdで障害設計をする上でバッファリングの概念は切っても切り離せません。 本記事では、ドキュメントだけでは拾いきれないものも踏まえ、 Fluentdのバッファリングで抑えておくべき情報を体系的にまとめます。 バッファリングとは? Fluentdではログをバッファリングしてまとめて送信するための仕組みが用意されています。 これは下記のような用途に用いることができます。 送信先がダウンしていたときに一時的に保管しておく 送信先のキャパシティに合わせて送信流量を制限する Fluentdにはメモリ上、もしくは永続化ディスク上にバッファを保管しておく仕組みが用意されています。 バッファの構造 バッファの構造は下記のようになっています。 引用: https://docs.fluentd.org/buffer Output Pluginごとに一つバッファ領域を持っており「stage」と「q
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 ですが、コネクションにメッセージを書き込むところ
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
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く