並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 68件

新着順 人気順

fluentdの検索結果1 - 40 件 / 68件

fluentdに関するエントリは68件あります。 ログaws運用 などが関連タグです。 人気エントリには 『あと2時間でElastiCacheのメモリが枯渇!そのときあなたは何をしますか?』などがあります。
  • あと2時間でElastiCacheのメモリが枯渇!そのときあなたは何をしますか?

    突然ですが... あなたは、あるゲームプロジェクトの本番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか? はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクトの本番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし

      あと2時間でElastiCacheのメモリが枯渇!そのときあなたは何をしますか?
    • あんどぅ on Twitter: "本番運用するといずれ誰もがたどり着く、公式ドキュメントには書かれてないログ管理の現実解が資料化されていてすばらしい そう、CloudWatch LogsにはDev環境 or ERRORの場合のみ飛ばすFluentdの設定をすることで利便性と料金のバランスをとるのである これは公式ドキュメントにすべき https://t.co/RE4FmPCpJX"

        あんどぅ on Twitter: "本番運用するといずれ誰もがたどり着く、公式ドキュメントには書かれてないログ管理の現実解が資料化されていてすばらしい そう、CloudWatch LogsにはDev環境 or ERRORの場合のみ飛ばすFluentdの設定をすることで利便性と料金のバランスをとるのである これは公式ドキュメントにすべき https://t.co/RE4FmPCpJX"
      • コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita

        課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可

          コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
        • 秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog

          こんにちは!スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です

            秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog
          • これからのZOZOを支える ログ収集基盤を設計した話 / Log collection infrastructure to support ZOZO in the future

            これからのZOZOを支える ログ収集基盤を設計した話 / Log collection infrastructure to support ZOZO in the future

              これからのZOZOを支える ログ収集基盤を設計した話 / Log collection infrastructure to support ZOZO in the future
            • LINEユーザー8300万人を対象とするアンケートを1週間で開発するには? コロナ禍におけるLINEの施策とフロントエンド開発

              2020年6月17日に行われたイベント「UIT meetup vol.9『The new normal for frontend』」に、LINE株式会社のフロントエンドエンジニアであるChanghee Kim氏が登壇しました。「コロナ禍、私たちにできたこと」という講演タイトルで、新型コロナ対策のための全国調査を行った際のフロントエンド開発について紹介しました。講演資料はこちら コロナ禍での仕事の変化 Changhee Kim氏:それでは「コロナ禍、私たちにできたこと」というタイトルで発表させていただきます。まず自己紹介ですが、Kim Changhee(キム・チャンフィ)と申します。LINEでは2018年からフロントエンドエンジニアとして働いています。 LINEではたくさんの外国籍社員が働いています。私もその1人で、韓国出身のエンジニアです。ふだんはLINE公式アカウントの管理画面アプリを開

                LINEユーザー8300万人を対象とするアンケートを1週間で開発するには? コロナ禍におけるLINEの施策とフロントエンド開発
              • ログ基盤の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をFluent Bitに移行して監視ツールを実装した話 - Mirrativ Tech Blog
                • AWS Startup Tech Meetup #3: かんたんコンテナロギング選手権

                  コンテナでログをどう取得すればいいの?そもそもどういうログがあるのか? ログの取得パターンから活用方法まで、 @prog893 が選定のためのヒントとサンプルアーキテクチャで紹介します。

                    AWS Startup Tech Meetup #3: かんたんコンテナロギング選手権
                  • 「Fluentd実践入門」を10月8日に出版します - たごもりすメモ

                    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実践入門」を10月8日に出版します - たごもりすメモ
                    • 大規模システムにおける5つのログ転送パターン

                      成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。

                        大規模システムにおける5つのログ転送パターン
                      • ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG

                        こんにちは、SRE部MA基盤チームの谷口(case-k)です。私達のチームでは、データ連携基盤の開発・運用をしています。 データ基盤には大きく分けて2種類あり、日次でデータ連携してるものとリアルタイムにデータ連携しているものがあります。本記事ではリアルタイムデータ連携基盤についてご紹介します。 既存のデータ連携基盤の紹介 リアルタイムデータ連携基盤の紹介 なぜ必要なのか 活用事例の紹介 データ連携の仕組みと課題 リプレイス後のリアルタイムデータ連携基盤 SQL Serverの差分データの取り方を検討 アーキテクチャ概要と処理の流れ Fluentdのプラグインを使った差分データの取得 Dataflowでメッセージの重複を排除 Dataflowで動的にBigQueryの各テーブルに出力 Pub/Subのメッセージ管理 イベントログ収集基盤 個人情報の取り扱い ビルド・デプロイ戦略 監視 データ

                          ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG
                        • IIJ飯田橋オフィスでDFSはどれくらいおきているのか? | IIJ Engineers Blog

                          Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント! 応募期間は2019/11/29~2019/12/31まで。詳細はこちらをご覧ください。 今すぐツイートするならこちら→ フォローもお忘れなく! 【IIJ 2019 TECHアドベントカレンダー 12/14(土)の記事です】 こんにちは、IIJ 金子です。 本日は、無線LAN 5GHz帯でのDFSの発生状況を可視化してみようというお話をします。 はじめに 無線LANを運用していると気になるのは、外来レーダー波により引き起こされるDFS、そしてそれに起因してAPが行うチャネルの移動です。 「今自分がいる場所で、無線LANのDFSを引き起こすようなレーダーはどれくらい打ち込まれているのかしら?」とそんな疑問がふと沸いてきたので、ものは試しにと実際に測ってみることにしました。 無線LANとDFSについて

                            IIJ飯田橋オフィスでDFSはどれくらいおきているのか? | IIJ Engineers Blog
                          • Fluent Bit の低レイヤーに飛び込んでみて、わかったこと

                            こんにちは! シェルフィー株式会社で SRE を担当している石田です。 弊社では、本番のワークロードにて Fluent Bit を使っております。 今回、Fluent Bitの処理について理解を深めたので記事を書いてみました。 世界中で使われているとても有名なミドルウェアなので、参考になればとても嬉しいです。 はじめに 弊社では、ECS on Fargate で稼働しているバッチジョブのログをサイドカーコンテナ(Fluent Bit)を使い Datadog に連携しています。 ログのサイズが 16 KB 以上ある場合、shim-logger の仕様により、そのログは分割されてしまうため、 Fluent Bitにて分割されたログの再結合処理を行う必要性があります。 この点についてはDeNAさんの記事がわかりやすいので、詳細はそちらを参考にしてもらえたらと思います。 AWS ECS on Fa

                              Fluent Bit の低レイヤーに飛び込んでみて、わかったこと
                            • Dockerのログ収集方法の調査 - Qiita

                              すべてのログは標準出力・標準エラー出力に出力 ・Dockerのlogging driver ・ログの集約がしづらい ・Fluentdに転送設定 コンテナ起動時に既にFluentdが死んでいる場合、コンテナが起動できない など。詳細は以下のサイトを参照 Dockerコンテナ上のログ集約に関するまとめ Dockerのlogging driver: それぞれの特徴と使いどころ(json-file, syslog, journald, fluentd) 対象のログ リアルタイムに出力されるログが対象 ・Fluentd / fluentd-ui ・FluentBit ・Filebeat ・Logstash 既にあるログが対象 ・Embulk Fluentdのバッチ版Embulk(エンバルク)のまとめ Docker-composeを使ってEmbulk,Elasticsearch,Kibana環境を構築

                                Dockerのログ収集方法の調査 - Qiita
                              • 高速データ収集ツール『Fluentd』の開発体制強化 - クリアコード

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

                                  高速データ収集ツール『Fluentd』の開発体制強化 - クリアコード
                                • 大規模LBaaSプロジェクトの成長期に体験した2つの問題

                                  こんにちは、LINEのプライベートクラウドサービスであるVerdaのLoad Balancer as a Service (LBaaS) のチームでTech Leadをしている早川です。このエントリでは私が2019年4月にLINEに入社してからの約2年半で体験した大規模LBaaSならではの興味深い問題をピックアップしてご紹介します。 Verda LBaaSについて VerdaのLBaaSは2016年ごろに稼働を開始したVerdaの中でも比較的歴史が長いサービスです。当時のLINEではハードウェアのアプライアンス製品を用いて提供されていたロードバランサのサービスを置き換える目的で開発されました。特徴としては実際にユーザのトラフィックを受けるいわゆるデータプレーンと呼ばれるコンポーネントも含めて全てがソフトウェアで実装されているということが挙げられます。 中でも個人的に気に入っているのは、L4

                                    大規模LBaaSプロジェクトの成長期に体験した2つの問題
                                  • Grafana + Loki + Fluentdで実装するSyslogサーバー

                                    はじめに ログ集約・可視化・検索ツールとしてはELKスタックを利用するケースが多いが、これをLokiに置き換えることでより軽量にログを集約することができるようになる。 Grafana Lab社が開発したLokiは、ログのストリームに対してタグ付けし保存する仕組みを持つ。Prometheusと親和性がたかく、水平展開、高可用性、マルチテナントが可能。 構成 各クライアントからのsyslogは514/udpポートで送信される。これをrsyslogデーモンで受け5514/tcpポートへ転送する。fluentdは5514/tcpポートで受信したsyslogをさらにlokiへ転送する。 +------------------------------------------------+ | | | +---------+ | +--------+ 514/udp | | | | | client +

                                      Grafana + Loki + Fluentdで実装するSyslogサーバー
                                    • [アップデート] ECS/Fargateでログ出力先をカスタマイズできる「FireLens」機能がリリースされました | DevelopersIO

                                      ECS/Fargateタスクのログ出力先をカスタマイズ (ルーティング) できる「FireLens」機能が正式リリースされましたので、試してみました。 みなさん、こんにちは! AWS事業本部の青柳@福岡オフィスです。 ECS/Fargateタスクのログ出力先をカスタマイズ(ルーティング)できる「FireLens」機能が AWS Containers Roadmap の リポジトリ でプレビューされていましたが、先日、正式リリースされました。 まだドキュメントが日本語化されていませんが、英語版ドキュメントの内容に沿って試してみました。 Custom Log Routing - Amazon ECS 従来の「CloudWatch Logs」へのログ出力 まず、従来の「CloudWatch Logs」へのログ出力を行ってみます。 全体の構成は下図のようになります。 ECSクラスターやALBの設定

                                        [アップデート] ECS/Fargateでログ出力先をカスタマイズできる「FireLens」機能がリリースされました | DevelopersIO
                                      • SREチームに入ってからの2年間にチームでやってきたこと - クラウドワークス エンジニアブログ

                                        この記事はクラウドワークス アドベントカレンダー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チームに入ってからの2年間にチームでやってきたこと - クラウドワークス エンジニアブログ
                                        • 軽量な Go 製カラムナフォーマット変換ツール columnify を作った話 - Repro Tech Blog

                                          こんにちは。業務委託として SRE チームのお手伝いをしている @syucream です。 本記事では Repro にて開発した、 Go 製のカラムナフォーマットへのデータ変換ツール columnify について、開発背景や技術的な取り組みを紹介します。 なぜカラムナフォーマットか? ことのおこり 事業がスケールすると共に扱うログの量が増えることは、喜ばしい反面さまざまな悩みをもたらします。その中でも顕著なものの一つとしてコストの問題が挙げられます。 膨大なログデータはログに対するストレージ料金を増大させると共に、分析や可視化に際してクエリで求められるコンピュートのコストも無視できなくなっていきます。 近頃 Repro でもコンテナのログの管理においてこの問題が顕著になってきました。Repro のバックエンドシステムは ECS 上のコンテナで実現され、ログの閲覧・管理のため外部のログ収集サ

                                            軽量な Go 製カラムナフォーマット変換ツール columnify を作った話 - Repro Tech Blog
                                          • KinesisとLambdaでつくるServerlessなログ基盤 @ AWS DevDay Tokyo 2019 [C-2]

                                            本セッションでは、弊社にて複数サービスで導入しているAWSのマネージドサービス (Lambda、CloudWatch Logs、Kinesis Data Streams、S3、Elasticsearch Service) を活用したServerlessなログ基盤の構成について紹介する。自前でログ基盤を管理しているが管理コストなど課題を感じている人や、コンテナ活用時のロギング構成の設計に悩んでいる人をターゲットにしている。 / / 現在のログ基盤の構成に至るまでの経緯(過去に試行錯誤した10以上の構成パターン)、設計思想(保守性、高信頼性、コスト削減、拡張性)について紹介する。 / / タップル誕生やCROSSMEをはじめとした実際に運用中のサービスを事例に、サービス用件ごとに合わせたロギング構成を解説する。また、2年半の期間で様々な構成を運用をしてきた事によって得られた知見について話す。ロ

                                              KinesisとLambdaでつくるServerlessなログ基盤 @ AWS DevDay Tokyo 2019 [C-2]
                                            • Fluentd 集約ノードのオートスケール - クックパッド開発者ブログ

                                              こんにちは、技術部 SRE グループ アルバイトの小川です。この記事では、クックパッドでコンテナログの処理に利用している Fluentd ノードのオートスケール対応について紹介します。 クックパッドでは Amazon ECS を用いてコンテナ化されたアプリケーションをデプロイしています。クックパッドでの ECS の利用については過去の記事をご覧ください。 ECS 上で動くコンテナのログを閲覧するために、標準的には Amazon CloudWatch Logs を利用する方法があります。しかし、クックパッドではログ量やコストの問題で CloudWatch Logs は利用せず、独自のログ配送基盤を構築して運用しています。具体的には、ECS のコンテナインスタンスで実行している Fluentd から複数の Amazon EC2 インスタンスで構成される Fluentd 集約ノードにログを転送し

                                                Fluentd 集約ノードのオートスケール - クックパッド開発者ブログ
                                              • ECSのログ管理にFirelensを導入してみた - Gunosy Tech Blog

                                                はじめに こんにちは。SRE部の板谷(@SItaya5)です。 Gunosyでは様々なプロダクトでECS(Amazon Elastic Container Service)を使用してタスクを実行しています。 ECSの起動タイプにはEC2とFargateの2種類がありますが、どちらのタイプも混在しています。 ログの送信先としては、主にPapertrailというサービスを使用しています。 しかし、Fargateで実行しているタスクに関しては、ログの送信先(Log Driver)に選択の余地がなく、Cloudwatch Logs一択でした。 そのため、EC2で実行しているタスクのログはPapertrailに送信されていましたが、一方のFargateで実行しているタスクはCloudwatch Logsに送信せざるを得ませんでした。 このように起動タイプ毎にログの送信先が分かれており、管理が煩雑にな

                                                  ECSのログ管理にFirelensを導入してみた - Gunosy Tech Blog
                                                • 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
                                                  • 俺たちは絶対にKubernetes上の分析ログを欠損させたくないんだっ...!!その対策としてのfluent-pvc-operatorを紹介🐥 - Qiita

                                                    俺たちは絶対にKubernetes上の分析ログを欠損させたくないんだっ...!!その対策としてのfluent-pvc-operatorを紹介🐥kubernetes この記事はZOZO Advent Calendar 2021に出したかったけど既に枠が埋まっていたので野良で出した記事です。 はじめに こんにちは。絶対にKubernetes上の分析ログを欠損させたくない@civitaspoです。今年は社内のログ収集基盤構築プロジェクトでfluent-pvc-operatorというKubernetes Operatorを作りました。この記事ではfluent-pvc-operatorが解決する課題、及び機能や使い方について紹介したいと思います。 なお、この記事ではfluent-pvc-operatorの説明に集中するため、ログ収集基盤構築プロジェクトの全体像等には触れません。プロジェクトの全体像

                                                      俺たちは絶対にKubernetes上の分析ログを欠損させたくないんだっ...!!その対策としてのfluent-pvc-operatorを紹介🐥 - Qiita
                                                    • [Terraform]ECS FargateでFireLensを使って複数サービスにログ出力する | DevelopersIO

                                                      こんにちは!コンサル部の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サービスに

                                                        [Terraform]ECS FargateでFireLensを使って複数サービスにログ出力する | DevelopersIO
                                                      • 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

                                                          Fluentd実践入門 ──統合ログ基盤のためのデータ収集ツール
                                                        • Fluentdのプラグインを作ってBigQueryにログを挿入するコストを1/3にした話 - pixiv inside

                                                          こんにちは。 機械学習チームにてレコメンドの改善を行っているgumigumi4fです。 この記事では、Fluentdにて収集したログをBigQueryに挿入する際に使用しているプラグインを置き換えることによって、高スループットかつ低コストを実現した話について紹介します。 背景 pixivではアクセスログやアプリケーションログ等をBigQueryに収集し、分析できるような仕組みを構築しています。 BigQueryへアクセスログを挿入する際はFluentdとそのプラグインであるfluent-plugin-bigqueryを用いて直接BigQueryへ書き込むようになっていたのですが、その際にログ欠損が起こることが問題となっていました。 ログの欠損はピークタイムで発生しており、そのピークタイムのログの流量は概ね毎秒30000logとかなり多く、実際Fluentdのworkerプロセスが1work

                                                            Fluentdのプラグインを作ってBigQueryにログを挿入するコストを1/3にした話 - pixiv inside
                                                          • AWS Fargate now fully supports multiline logging powered by AWS for Fluent Bit

                                                            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

                                                              AWS Fargate now fully supports multiline logging powered by AWS for Fluent Bit
                                                            • 詳解 FireLens – Amazon ECS タスクで高度なログルーティングを実現する機能を深く知る | Amazon Web Services

                                                              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

                                                                詳解 FireLens – Amazon ECS タスクで高度なログルーティングを実現する機能を深く知る | Amazon Web Services
                                                              • 何問わかるかな?AWS FireLens(Fluent Bit利用版)クイズ!!! - LayerX エンジニアブログ

                                                                こんにちは。バクラク事業部Platform Engineering部DevOpsチームの@civitaspoです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、この記事ではAWS FireLensに関する情報をクイズ形式でお届けします。 みなさんはAWS FireLensを使っていますか?弊社ではAmazon ECS上にアプリケーションをホスティングしており、AWS FireLensを利用してログ収集・ログ送信を行っています。AWS FireLensは非常に便利です。一方、AWS FireLensは奥が深い挙動をすることもあります。この記事ではそんなAWS FireLensを深く理解するための情報をクイズ形式でお届けしてみることにしました。僕が知る限りの情報を詰め込んでみたのでAWS FireLensを深く理解したい方に届けばいいなと思います。 AWS FireLe

                                                                  何問わかるかな?AWS FireLens(Fluent Bit利用版)クイズ!!! - LayerX エンジニアブログ
                                                                • k8sハニーポットとログ出力の話 - エムスリーテックブログ

                                                                  本記事はエムスリー Advent Calendar 2019 - Qiitaの24日目の記事です。 こんにちは。エムスリーエンジニアリンググループの木村です。 業務ではBIRというチームでアンケートシステムの開発をやっています。 今回は個人的に構築しているk8sハニーポットシステムとそこで生じたログ出力の問題について話をしようと思います。 ハニーポット まずハニーポットとは何かですが、一言でいうとインターネットからの攻撃を敢えて受けるサーバです。 通常通用されるサーバでは、ファイアーウォールやアンチマルウェアソフトウェアを利用して攻撃を防御し、サービスを安定して運用することが求められますが、ハニーポットはその逆です。 敢えて攻撃を受け、それを記録することによりネットワーク上でどのような攻撃が流行しているのか、その手口などを観測・分析することが目的になります。 ネットワーク構成 現在の私の自

                                                                    k8sハニーポットとログ出力の話 - エムスリーテックブログ
                                                                  • 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

                                                                      WindowsにFluentdをインストールしてS3にデータ転送して、管理用の設定も追加 - YOMON8.NET
                                                                    • 300GB/day出力されるログ基盤をFluent Bit + Fargate + NLBで再構築したら、エンジニアの作業効率が上がった - クラウドワークス エンジニアブログ

                                                                      これは クラウドワークス アドベントカレンダー 24日目の記事です。前日は 畑中 さんの制作会社出身のデザイナーが事業会社に入って感じた5つの悩み事でした。事業会社とデザイン制作会社の違いから生まれる悩みをどう解決したかが伝わる記事でした。 クラウドワークスSREチームの @kangaechu です。最近はM1 Macを購入しました。M1 Macはアプリケーションの対応状況がまだまだなので、Goをソースからクロスコンパイルするなど、今までやったことがないことができてちょっと楽しいです。でももう少しネイティブのアプリが揃うと嬉しいな。 アドベントカレンダーはSREチームに入ってからの2年間にチームでやってきたことに続き、2つめのエントリとなります。前回の記事で、Docker化したシステムの一つとしてfluentd(ログ基盤)を挙げました。ここではそのログ基盤についての詳細を書いていきます。

                                                                        300GB/day出力されるログ基盤をFluent Bit + Fargate + NLBで再構築したら、エンジニアの作業効率が上がった - クラウドワークス エンジニアブログ
                                                                      • FireLensでログ転送するときは依存関係とHealthcheckを設定しないとログを取りこぼすことがある

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

                                                                          FireLensでログ転送するときは依存関係とHealthcheckを設定しないとログを取りこぼすことがある
                                                                        • 【AWS Data Lake】ニアリアルタイムデータ分析環境・スピードレイヤを構築してみた(ハンズオン1) | DevelopersIO

                                                                          こんにちは。DA事業本部の春田です。 管理のしやすさや拡張性の高さで注目を集めている、次世代のデータ分析基盤Data Lakeについて、ハンズオンにトライしてみました。 Datalake Handson 本記事では、Lab1~Lab3のニアリアルタイムデータ分析環境(スピードレイヤ)を構築していきます。 Lab1: はじめの準備 Lab1: はじめの準備 はじめにハンズオン共通で使用するVPC、EC2、IAM Roleを設定していきます。まずEC2で使用するキーペアを作成します。 上で作成したキーペア datalake-handson-haruta を用いて、CloudFormationからEC2インスタンスを作成します。 EC2の構築が完了したら、 datalake-handson-haruta の公開鍵でSSHログインし、 /root/es-demo/testapp.log にログが吐

                                                                            【AWS Data Lake】ニアリアルタイムデータ分析環境・スピードレイヤを構築してみた(ハンズオン1) | DevelopersIO
                                                                          • 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 v1.15.0リリース -- YAML形式サポートなどの新機能とin_tailの不具合修正 - 2022-07-05 - ククログ
                                                                            • Fluentdのflush_mode immediateはいつ使うのか - たごもりすメモ

                                                                              Fluentd実践入門をあらためて手元でぱらぱらやってたら、しまった! この話をどこかにちょっとでも書こうと思ってたのに忘れてた! という話が出てきたので、忘れないうちに書いて放流する。 flush_modeとはなにか FluentdのOutputプラグインには<buffer>セクションで指定できるflush_modeというパラメータがあって、これはOutputプラグインがどういう基準でバッファ内のデータを書き出す(writeメソッドを呼ぶ)かという戦略をコントロールする。有効な値はdefault、immediate、interval、lazyの4つ。 ただし多くのケースでこのパラメータは明示的には指定されていないはず。というのも、デフォルト値であるところのdefaultの場合には、<buffer>セクションに指定されている他のパラメータ((と、例外的に<buffer>セクションの外側に指

                                                                                Fluentdのflush_mode immediateはいつ使うのか - たごもりすメモ
                                                                              • 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
                                                                                • Athenaを使ったデータ処理基盤の設計 - Speee DEVELOPER BLOG

                                                                                  こんにちは。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

                                                                                    Athenaを使ったデータ処理基盤の設計 - Speee DEVELOPER BLOG

                                                                                  新着記事