タグ

fluentdに関するmapk0yのブックマーク (121)

  • FireLensでログ転送するときは依存関係とHealthcheckを設定しないとログを取りこぼすことがある

    三行で FireLens を使うことで ECS で稼働するアプリケーションのログ転送を簡単に実装できる しかし、ドキュメントに記載されている設定例をそのまま利用しただけでは実はログの取りこぼしがあった ログの取りこぼしを防ぐためにコンテナ間の依存関係とHealthcheckの設定を行った FireLens とは FireLens を簡単に言うと、「ECS のタスク定義の記述だけで Fluent Bit / Fluentd を使ったログ転送用のサイドカーコンテナが利用できる機能」でしょうか。 FireLens という個別のサービスやソフトウェアが存在するわけでは無いようです。 詳細は以下を参照ください。 症状 私が関わったとあるサービスでは ECS を使ってアプリケーションを稼働させていて、アプリケーションのログは FireLens により Fluent Bit を使ってログ転送を行っていま

    FireLensでログ転送するときは依存関係とHealthcheckを設定しないとログを取りこぼすことがある
  • FireLens(Fluent Bit)でエラーログだけはCloudWatch Logsへ、すべてのログはS3バケットへ保存を実現する設定例 | DevelopersIO

    検証利用したFargateのCloudFormationテンプレート、FireLensのDockerfileなどは以下に置いてあります。タスクロールなどは必要に応じて確認してください。 Fargate一式 FireLensのDockerfile 設定ファイル 以下のFluent Bitの設定ファイルを作成しました。 extra.conf [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}\

    FireLens(Fluent Bit)でエラーログだけはCloudWatch Logsへ、すべてのログはS3バケットへ保存を実現する設定例 | DevelopersIO
  • Changing permissons of out_file · Issue #138 · fluent/fluentd

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    Changing permissons of out_file · Issue #138 · fluent/fluentd
  • 高速データ収集ツール『Fluentd』の開発体制強化 - クリアコード

    株式会社クリアコード(社:埼玉県所沢市、以下クリアコード)は日、オープンソースソフトウェア『Fluentd』プロジェクトの開発・メンテナンスにおいて、トレジャーデータ株式会社(社:東京都千代田区、以下トレジャーデータ社)が担当していた活動を引き継ぎ、開発体制を強化することをお知らせします。 『Fluentd』は2011年にトレジャーデータ社によって開発の始まったオープンソースソフトウェア(以下OSS)プロジェクトで、クリアコードは2015年9月から同プロジェクトに参加。コミュニティサポート、プラグインのメンテナンスといった活動を開始し、以降『Fluentd』体の不具合修正、機能拡張、ドキュメント整備など活動範囲を拡大してきました。法人向けの各種サービスも提供しており、トレジャーデータ社と協働で、トレジャーデータ社の顧客に対する『Fluentd』の導入支援等も行っています。また、20

    高速データ収集ツール『Fluentd』の開発体制強化 - クリアコード
  • OSSにコントリビュートしてログ収集基盤におけるCloud Pub/Subのリージョン間通信費用を削減した話 - ZOZO TECH BLOG

    こんにちはSRE部の川津です。ZOZOTOWNにおけるログ収集基盤の開発を進めています。開発を進めていく中でCloud Pub/Subのリージョン間費用を削減できる部分が見つかりました。 今回、OSSであるfluent-plugin-gcloud-pubsub-customにコントリビュートした結果、Cloud Pub/Subのリージョン間費用を削減できました。その事例を、ログ収集基盤開発の経緯と実装要件を踏まえて紹介します。 目次 目次 ログ収集基盤の紹介 開発経緯 フロントエンドのログしか取得できない BigQuery ExportはSLAを担保されていない リアルタイムにログを保存できない 実装要件 ログ送信側の環境に依存しない共通の仕組みで実装する 転送されるログの量に応じてオートスケールする構成にする 送られてくるログをロストしない リアルタイムにログが保存される インフラ構成

    OSSにコントリビュートしてログ収集基盤におけるCloud Pub/Subのリージョン間通信費用を削減した話 - ZOZO TECH BLOG
    mapk0y
    mapk0y 2021/04/13
    説明されている構成は Fluentd が東京で Bigquery は US の場合なんだとおもうけど、最終的になんでネットワークコストが抑えれるかがわからなかった。
  • Fluent Bit による集中コンテナロギング | Amazon Web Services

    Amazon Web Services ブログ Fluent Bit による集中コンテナロギング 投稿は Wesley Pettit と Michael Hausenblas による寄稿を翻訳したものです AWS はビルダーのために作られています。ビルダーは常に最適化の方法を模索し、それはアプリケーションのロギングにも当てはまります。全てのログの重要性が同等ということはありません。あるログはリアルタイムの分析を必要とし、他のログは必要となった時に分析が行えるよう単に長期間保管しておくことを必要としたります。それ故に AWS とパートナーが提供する様々なストレージや分析のツールに容易にログをルーティングできることが重要です。 そこで私たちは Fluent Bit をサポートし、コンテナ化されたアプリケーションから AWS やパートナーのログ保存ソリューション、ログ分析ソリューションへのログ

    Fluent Bit による集中コンテナロギング | Amazon Web Services
  • 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)を経由し

    NLB + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象を解消した話 - Repro Tech Blog
  • Fluentd v1.0

    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 v1.0
  • Fluentd 入門 〜運用に必要な基礎知識〜

    最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ?」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ!」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En

    Fluentd 入門 〜運用に必要な基礎知識〜
  • Cybozu Meetup #6 サイボウズのサービスを支えるログ基盤

    Kazuyuki Honda @hakobera オンプレだと Kafka は順当としても、Fluentd で at least once が難しいってなんだろう?Go で自前で書いた理由と実装方法が知りたい twitter.com/ueokande/statu… 2017-07-25 22:17:21 wyukawa @wyukawa Kafkaへのログ転送 初めはFluentdでKafkaへ転送してたが、 at least onceを満たすことが難しいと判明し転送エージェントをGoで実装とのことらしいけど、詳細が知りたいな。マルチプロセスの管理が面倒になってGoで実装したとかならまだわかるんだけど。 2017-07-26 00:57:41

    Cybozu Meetup #6 サイボウズのサービスを支えるログ基盤
  • KafkaからTreasure DataにブリッジするDocker Compose - Qiita

    td-agentコンテナとKafka Consumerコンテナを使いKafkaからTreasure DataへブリッジするDocker Composeサービスを起動します。別のポストではPySpark Streamingのウィンドウ集計した結果をKafkaのトピックに出力するコードを書きました。このストリーム処理はデータパイプラインの前処理やエンリッチメントに相当します。後続にビッグデータのバッチ処理を想定してTreasure Dataに保存します。 $ tree -a . ├── docker-compose.yml ├── .env ├── .gitignore ├── kafka-bridge │   ├── Dockerfile │   ├── fluentd-consumer.properties │   └── log4j.properties └── td-agent2 ├─

    KafkaからTreasure DataにブリッジするDocker Compose - Qiita
  • docker + fluentd + Elasticsearch + kibana4 で構築するお手軽NetFlowアナライザ - Qiita

    docker + fluentd + Elasticsearch + kibana4 で構築するお手軽NetFlowアナライザFluentdElasticsearchDockerKibanadocker-compose この記事は慶應義塾大学SFC村井&徳田研 Advent Calendar 2015 の13日目の記事です。 はじめに 慶應義塾大学湘南藤沢キャンパス(SFC)では毎年11月にOpen Research Forumというイベントを開催しています。 すごくざっくり説明すると、日頃学生が取り組んでいる研究についての発表会みたいなものです。 私が専攻している情報工学分野の他にも国際政治や環境問題、脳科学、建築、言語コミュニケーションなどといった分野について、日ごろ学生が取り組んでいる内容についてのポスターセッションを行ったり、制作物を展示したりしています。 次年度以降も開催されると

    docker + fluentd + Elasticsearch + kibana4 で構築するお手軽NetFlowアナライザ - Qiita
  • Fluent Loggerの信頼性を高めるには - 2017-04-28 - ククログ

    はじめに Fluentdにログを送る方法として、Fluent Loggerを使う方法があります。 RubyJavaにはそれぞれfluent-logger-rubyやfluent-logger-javaなどのFluent Loggerがあり、よくメンテナンスされています。 この記事ではFluent Loggerを使ってFluentd v0.12またはv0.14にログを送信する時にどのようにするとより確実にログ転送ができるようになるかを解説します。 最小構成のFluent_Loggerを作成するには では最小構成のFluent Loggerはどのような仕様に基づき実装されるべきかを解説しました。この記事はその続編です。 確実にログを送るには 確実にログを送るにはエラーが起きた時にそのエラーを回復する手段を提供されていることが必要です。 ログが送れたことをFluent Logger側で検出する

    Fluent Loggerの信頼性を高めるには - 2017-04-28 - ククログ
  • メルカリのデータ分析基盤 / mercari data analysis infrastructure

    Handling a tremendous amount of images with Fastly / Yamagoya Traverse 2020

    メルカリのデータ分析基盤 / mercari data analysis infrastructure
  • docker fluentd logging driver の基礎的な設定 - Qiita

    docker container では、コンテナ内の何かしらのプログラムが標準出力 (strout) や標準エラー (stderr) に出力した内容を docker logs コマンドで取得することができます。 しかし能動的に取得しいにいくだけでなく、何かしら別の方法で forward をしてくれると助かることもあります。 docker では logging driver という機構で、stdout / stderr に出力された内容を指定された方法で forward する仕組みがあります。 サポートされている logging driver の種類については以下公式ドキュメントを参照ください。 そのうち、この記事では fluentd logging driver についてのみ触れます。 overview fluentd logging driver は、上述の logging driver

    docker fluentd logging driver の基礎的な設定 - Qiita
  • Fluentd with Docker で知っておきたいこと - Qiita

    前振り DockerDocker-compose、Fluentd力が無さ過ぎて苦労したので、苦労したことのまとめ。 その1 プラグインのインストール プラグインのインストールをするのなら、docker-compose.ymlとDockerfileの両方を使用する docker-compose.yml で build オプションを指定すると使用するDockerfileを指定できる 公式の説明でも使用されている docker-compose.ymlからみた相対パスでfluentdディレクトリを指定するにはbuild: ./fluentdとする プラグインのインストールは、gem install fluent-plugin-datacounterでOK。 td-agent-gem installもあるけど、Dockerでやるときに若干困った。 RUN ["gem", "install", "f

    Fluentd with Docker で知っておきたいこと - Qiita
    mapk0y
    mapk0y 2017/04/09
    logging driver としての fluentd ではなくて、driver 使わなかったり、ログを受けたりするための fluentd の場合のお話
  • dockerのfluentd logging driverで集約したログをs3に蓄積する - Qiita

    dockerの勉強のため、実例で学ぶDockerハンズオンの構成をベースに、aws上で動かしてみた。 s3のbucketを用意 ログファイル書き込み先のaws s3 bucketを作成、access keyとsecret keyを取得。 参考:https://joppot.info/2014/06/14/1621 Docker Hubにimageを登録 Dockerfileを作成してGitHubにpush。 Docker HubでAutomated Buildを作成してimageを登録。 GitHubの1リポジトリ上に3種のDockerfileを置いたため、Automated Buildは3つ作成した。 https://hub.docker.com/r/khwada/nginx/ https://hub.docker.com/r/khwada/sinatra/ https://hub.do

    dockerのfluentd logging driverで集約したログをs3に蓄積する - Qiita
  • CloudNativeCon Europe 2017に行ってきた&しゃべってきた - たごもりすメモ

    うぎゃあ、これ今年の初エントリなのか。なんてこった。 で、FluentdがめでたくCNCF (Cloud Native Computing Foundation)に加わって初めてのCloudNativeConなので、Treasure DataのOSSチームで都合のつく人みんなで参加してきたというやつ。前夜祭的なところで同僚の Eduardo がKeynoteをやったり、Fluentd Salonという枠がつくられてFluentd関連の話をしたり。 自分はそれとは別にTalk proposalを出していて通っていたので、それを話しに行く、というのが個人的には最大の目的。 しゃべってきた セッションはカンファレンス2日目、全体でいちばん最後の時間枠。正直話すのが終わるまで気が抜けないからあんま好きじゃないんだけど、とりあえず、やるだけはやった。けっこう多い人が来てくれて席がぜんぶ埋まる(70人

    CloudNativeCon Europe 2017に行ってきた&しゃべってきた - たごもりすメモ
  • Fluentd+Elasticsearch+Kibanaで作るログ基盤の概要と構築方法

    システム障害の原因調査や、稼働状況の確認のためにログの中身を確認することがよくあります。しかし、ログが大量に出力されていたり、複数の場所に分散して出力されていたりすると、それを確認するために多くの手間と時間がかかってしまいます。 これらの課題解決の方法として、ここ最近主流となっているのが、複数のOSS(オープンソースソフトウェア)ツールを組み合わせてログの収集や検索、可視化ができる基盤(ログ基盤)を構築することです。 その中で特に代表的なものが、「Fluentd」(ログの集約)、「Elasticsearch」(ログの検索)、「Kibana」(ログの可視化)であり、連載では、これらのログ基盤を実現するツールについて、構築方法や利用方法、実際の案件で使ったときの事例、さらにはログ基盤に関連する最新の情報を紹介していきます。 連載第1回の稿では、Fluentd、Elasticsearch、K

    Fluentd+Elasticsearch+Kibanaで作るログ基盤の概要と構築方法
  • Fluent-Bit v0.11 リリース - 一寸先は/dev/null

    Fluent-Bit v0.11 が2017/03にリリースされました。今回のリリースはかなりすごいですよ! http://fluentbit.io/download/ おおまかなTopic in_tail Plugin (ログをはじめとするファイルの各行を収集) in_disk Plugin (ストレージへの Read/Write アクセスサイズを収集) in_proc Plugin (特定プロセスのメモリ使用量やfd消費数を収集) out_file Plugin (ファイルへの出力) Filter Plugin Parser out_forward に Secure forward mode追加 in_memの書式がfree(1)っぽくなりました あたりでしょうか。他にも色々と新機能がありますので詳しくは公式のリリースノートを参照ください。 Fluent Bit v0.11.0 - R

    Fluent-Bit v0.11 リリース - 一寸先は/dev/null