タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめまして、Azuma（@azuma_alvin）です。現在大学院の1年生で、2024年2月から4ヶ月間ミラティブのインフラチームにインターンとして参加しました。普段はインフラやMLOpsといった領域に興味があり、最近はVim環境の整備がマイブームです。 本記事では、ログ基盤をFluentdからFluent Bitへ部分移行した経緯とその2種類の監視ツールの実装についてお話しします。 記事の最後に、インターンから見たインフラチームの特徴と私が4ヶ月間で学んだことを紹介しています。興味がある方は末尾までスクロールしてぜひご覧ください。 1. 背景と目的 2. ミラティブのログ基盤について 3. ログ欠損の原因調査 Fluentdのバッファリングの仕組み fsnotifyを用いたバッファリングの観察 負荷試験 日付時刻フォーマットとワイルドカードによるログ欠損 ログ保存とサーバータイムスタン
こんにちは！ シェルフィー株式会社で SRE を担当している石田です。 弊社では、本番のワークロードにて Fluent Bit を使っております。 今回、Fluent Bitの処理について理解を深めたので記事を書いてみました。 世界中で使われているとても有名なミドルウェアなので、参考になればとても嬉しいです。 はじめに 弊社では、ECS on Fargate で稼働しているバッチジョブのログをサイドカーコンテナ（Fluent Bit）を使い Datadog に連携しています。 ログのサイズが 16 KB 以上ある場合、shim-logger の仕様により、そのログは分割されてしまうため、 Fluent Bitにて分割されたログの再結合処理を行う必要性があります。 この点についてはDeNAさんの記事がわかりやすいので、詳細はそちらを参考にしてもらえたらと思います。 AWS ECS on Fa
モノタロウのプラットフォームエンジニアリング部門 コンテナ基盤グループの宋 明起です。 私たちは、アプリケーション開発者からコンテナシステムの認知負荷を取り除き、アプリ開発に専念できるコンテナ基盤の構築と基盤を改善し、開発者はより楽に、より安全にアプリケーションのデプロイと運用できるように支援しています。 背景 基本設計 方針 構成 サンプル モニタリング サンプル 障害 障害1. Memory overflowエラーが発生 障害2. 大量のログが欠損になっている (refresh_interval) 障害3. まだ一部ログが欠損になっている (Prestop) [FAQ] 背景 モノタロウでは以下の記事にあるようにバックエンドのAPIをコンテナ化から始め様々なレイヤーの様々なアプリケーションをEKSの上で運用しています。 EKSコンテナ移行のトラブル事例：ALBの設定とPodのライフサイ
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
こんにちは。バクラク事業部Platform Engineering部DevOpsチームの@civitaspoです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、この記事ではAWS FireLensに関する情報をクイズ形式でお届けします。 みなさんはAWS FireLensを使っていますか？弊社ではAmazon ECS上にアプリケーションをホスティングしており、AWS FireLensを利用してログ収集・ログ送信を行っています。AWS FireLensは非常に便利です。一方、AWS FireLensは奥が深い挙動をすることもあります。この記事ではそんなAWS FireLensを深く理解するための情報をクイズ形式でお届けしてみることにしました。僕が知る限りの情報を詰め込んでみたのでAWS FireLensを深く理解したい方に届けばいいなと思います。 AWS FireLe
rain deploy時のパラメータ指定。VPC ID、サブネットIDはご自身の環境に合わせ変更してください。 rain deploy ./fargateWithFirelens.yml fargateWithFirelens-stack --params \ AppName=webapp,\ ClusterName=cluster,\ DesiredCount=1,\ Environment=test,\ ImageNameFirelens=public.ecr.aws/aws-observability/aws-for-fluent-bit:latest,\ ImageNameWebApp=public.ecr.aws/nginx/nginx:latest,\ ProjectName=minimum,\ PublicSubnet1=subnet-043566448c316b46a,\
これは クラウドワークス アドベントカレンダー 24日目の記事です。前日は 畑中 さんの制作会社出身のデザイナーが事業会社に入って感じた５つの悩み事でした。事業会社とデザイン制作会社の違いから生まれる悩みをどう解決したかが伝わる記事でした。 クラウドワークスSREチームの @kangaechu です。最近はM1 Macを購入しました。M1 Macはアプリケーションの対応状況がまだまだなので、Goをソースからクロスコンパイルするなど、今までやったことがないことができてちょっと楽しいです。でももう少しネイティブのアプリが揃うと嬉しいな。 アドベントカレンダーはSREチームに入ってからの2年間にチームでやってきたことに続き、2つめのエントリとなります。前回の記事で、Docker化したシステムの一つとしてfluentd（ログ基盤）を挙げました。ここではそのログ基盤についての詳細を書いていきます。
本検証利用した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}\
こんにちは、電通国際情報サービス デジタルイノベーション1部の加世です。 今回は「FluentBitを利用したログルーティング」を進める際に、「FluentBitについて理解する」ことを目的とした記事となっております。 具体的なFluentBitの使い所や設計を考える前段階として、本記事を参考にしていただければと思います。 Fluent Bitについて Fluent Bitの特徴 検証環境と処理フローについて Fluent Bit設計前の準備 データパイプラインの理解 データの構造化について まとめ Fluent Bitについて FluentBitは、データ（メトリクス、ログ、それ以外の生情報など）をInput情報として収集し、加工処理したうえで任意の転送先に転送します。 クラウドサービスプロバイダを利用するうえでは、既に「システム」から「サービス」に転送する仕組みを用意していることが多い
こんにちは、つくぼし(tsukuboshi0755)です! 皆さんはECS(Fargate)のログドライバーにFireLensを用いた事はありますでしょうか？ FireLensを使用する事で、カスタマイズ次第で柔軟なコンテナログルーティングを実現できるため、非常に便利です。 しかし実際に触ってみると、ログルーティング設定のベースとなっているFluent Bitのタグの仕組みが、思ったより難しいと感じるかもしれません。(私も理解するのに結構苦労してます。。。) そこで今回は、Fluent Bitにおけるタグの仕組みの観点から、FireLensを用いたログルーティングの設定方法についてまとめてみたいと思います！ Fluent Bitにおけるタグとは そもそもFluent Bitにおけるタグとは、どのようなものでしょうか？ Fluent Bitの公式ドキュメントでは、以下の通り説明があります。
Amazon ECS では、AWS Fargate と Amazon EC2 の両方について、AWS for Fluent Bit によるマルチラインロギングを完全にサポートしました。AWS Fluent Bit は、高速かつ軽量なログフォワーダーでオープンソースプロジェクトである Fluent Bit の AWS ディストリビューションです。Amazon ECS ユーザーはこの機能を使用して、AWS Fargate または Amazon EC2 で実行中のコンテナ化されたアプリケーションによって生成された部分的なログメッセージを 1 つのメッセージに再結合し、トラブルシューティングや分析を簡単に行えます。 コンテナ化されたアプリケーションの場合、ベストプラクティスは運用システムの標準出力 (stdout や stderr など) にログを送信することです。AWS Fargate コンテナ
以下のAWSブログで説明されている文章が何を示しているのか、AWS FargateとFireLens（Fluent Bit）を使って調べました。調べてわかったことはFluent Bitの設定ファイルとECSのタスク定義の関連性を把握しておくとトラブルシュート時に役にたちそうです。 オプションのユーザー提供の設定。ユーザーが独自の設定ファイルを指定した場合、include ディレクティブを使用して、生成された設定ファイルにインポートします。 引用: 詳解 FireLens – Amazon ECS タスクで高度なログルーティングを実現する機能を深く知る | Amazon Web Services ブログ まとめ ユーザ独自の設定ファイルは /fluent-bit/etc/fluent-bit.confから呼び出される /fluent-bit/etc/fluent-bit.confの設定内容は
AWS FireLensをfluent-bitで組み合わせてログを取得・整形した時の知見を覚え書きの形でまとめます。 今回は、Nginx、uWSGIの二つのコンテナから取得するログをいい感じにAthenaで見れるようにすることが目標。 前提として、Fargate上で、サイドカー構成でNginxのコンテナとfluent-bitのコンテナを一つのTask内で動かすものとします。 いい感じとは、 Nginxのアクセスログの内容がkey-value形式のjsonで表示できる ヘルスチェックのログなどいらないやつはS3にまで送られずにfluent-bit側で弾かれている エラーログはすぐに見たいのでS3だけでなくdatadog/cloudwatchにも送る こんな感じのを目指す。 この記事ではNginxだけについて書きます。後は同じようなやり方で簡単に追加できると思うので。 ##fluent-bit
CX事業部Delivery部の新澤です。 ECSでは、FireLens(AWS for Fluent Bit)を利用したカスタムログルーティングを行う設定をする際、FireLensで自動生成される設定ファイルに加えて、自分で作成したカスタム設定ファイルを指定することが可能です。 カスタム設定ファイルの指定方法には、S3バケットに設定ファイルを設置してファイルのARNを指定するs3方式と、コンテナイメージをビルドする際にカスタム設定ファイルをイメージにコピーして、ファイルパスを指定するfile方式の2通りがあります。 しかし、Fargateでのカスタム設定ファイルの指定については、公式ドキュメントにて AWS Fargate でホストされるタスクは、file 設定ファイルタイプのみをサポートします。 と記載されています。 そのため、今まではFargateでカスタム設定ファイルを利用する際は自
SREチームの左サイドバック @kenzo0107 です。 今回は ECS コンテナログから特定のリクエストによるログを抽出し、 Athena でクエリ捜査できる様にした話です。 コンテナログから特定リクエストによるログを抽出する目的 以下への一助としたい為に実装しました。 アプリケーションの改善となるデータの集計 問題発生時の調査 コンテナログはどのように出力されるか ECS コンテナログを JSON 形式で出力すると以下の様になります。 { "source":"stdout", "log":"{\"method\":\"GET\",\"path\":\"/sre/boshuchu\",\"format\":\"html\",\"controller\":\"SRE::BoshuchuController\",\"action\":\"show\",\"status\":200,\"du
みなさん、こんにちは！ 福岡オフィスの青柳です。 Amazon ECSのカスタムログルーティング機能である「FireLens」では、Fluent Bitをプラグインと共に使うことで、様々なサービスに対してログを転送することができます。 その中でも、AWSの下記サービスはログ転送先としてよく使われるのではないでしょうか。 CloudWatch Logs Kinesis Data Firehose Kinesis Data Streams 実は、Fluent Bitで上記サービスと連係するプラグインを利用する場合、ちょっとした注意点があります。 知っている人にとっては何ということはない話ですが、知らないと気付かずに「損」をしてしまいます。 タスク定義の書き方、どうしてますか？ 上に挙げた3つのプラグインは、AWSドキュメントに設定例として掲載されていますし、ググると設定サンプルも見つかります。
最近、ECS環境を構築する機会に恵まれました。当初はDockerのログドライバにawslogsを 指定してログをCloudWatch Logsに配信したのですが、このやり方には問題がありました。 ログストリームに複数行のログが１行ずつ蓄積されていくことです。 例えば、Railsの開発をしているとき下記のログを確認しながら開発を進めていくと思いますが、これらが1行ずつログストリームに配信されてしまいます。これでは不具合が発生した際、詳細を把握するのが困難になります。 Started GET "/" for 172.21.0.1 at 2021-12-31 12:30:46 +0000 Cannot render console from 172.21.0.1! Allowed networks: 127.0.0.0/127.255.255.255, ::1 Processing by Wel
CloudWatch Logsを知る エラーメッセージ内のキーワードを個別に確認します。 PutLogEvents APIとは CloudWatch LogsのログストリームにログイベントをアップロードできるAPIです。 PutLogEvents - Amazon CloudWatch Logs Fluent BitからCloudWatch Logsへログを送るのに利用されていました。 ThrottlingException Rate exceededとは 一定時間内に受信可能なAPIリクエスト数を制限しています。その制限値を超過したことを示しています。 一般的にスロットリングエラーを回避するには、APIリクエスト頻度を減らす、APIリクエストの間隔をずらす（同時実行数を減らす）、いい感じの間隔で再試行する（Exponential Backoff）などがあげられます。 今回はどこの制限値を
TL;DR Amazon Linux 2023 で Fluent Bit を使って CloudWatch Logs にログ転送していたところ、メモリ使用量が上昇し続けていた 原因は systemd input プラグインがJournalログを全読み込みし続けていたため Read_From_Tail と Max_Entries を設定することで、メモリ使用量の増加が解消された tail input には storage.type filesystem を使ってメモリ圧迫も回避した 環境 EC2(Amazon Linux 2023) EC2 は毎朝08:00に起動して、20:00に停止 fluent-bit をインストールしてAmazon Linux 2023 の Journalを CloudWatchLogs へ転送 問題
こんにちは、Яeiです。 今回は現役エンジニアである私がFluent Bitって何だという話についてまとめたいと思います。 最近巷で良く聞くFluent Bitと呼ばれるものがありますが、そもそもこれって何なのか調査しましたのでシェア致します。 最後はdocker-composeを用いたサンプルも用意しましたので見てみて下さい。 Fluent Bit 概要は公式サイトに分かりやすく書かれておりますので興味のある方は一読しておくとよいでしょう。 参考 fluentbitfluentbit また、各種ドキュメントは以下公式資料に詳しく書かれておりますのでこちらを参考にしてもらえればと思います。 参考 Fluent Bit ドキュメント 概要 Fluent Bitとは、 アプリケーションから出力されたログファイルや標準出力ログなどのデータを収集し、フィルタリングして複数の宛先に送信できるツールと
この記事はBeeX Advent Calendar 2020の12/12の記事です。 EKSのデータプレーンをどう選ぶか考えたとき、個人的にはFargateを積極的に使いたいところですが、まだ制限も多くて要件にフィットしない場合もあります。 そんな時に選択肢として挙がるManaged Node Groupですが、ReInvent2020でSpotインスタンスの利用できる機能が発表されたり、また使いやすくなったと感じています。 ここではそんな、Managed Node Groupで展開したEC2ノードのランタイムセキュリティをチェックする方法としてFalcoを使う手順を書いていきます。 概要としては以下の図の通りです。 Falcoは何か公式のドキュメントから引用します。 Falcoは実行時にカーネルからのLinuxシステムコールを解析し、強力なルールエンジンに対してストリームをアサートします
Capturing logs at scale with Fluent Bit and Amazon EKS | Amazon Web Services
Containers Capturing logs at scale with Fluent Bit and Amazon EKS Earlier this year, AWS support engineers noticed an uptick in customers experiencing Kubernetes API server slowness with their Amazon Elastic Kubernetes Service (Amazon EKS) clusters. Seasoned Kubernetes users know that a slow Kubernetes API server is often indicative of a large, overloaded cluster or a malfunctioning controller. On
本文 こんにちは、スタメンの松谷です。 最近、Ruby on Railsアプリケーション環境をECSへ移行しましたが、ログ管理には FireLens for Amazon ECS (以下FireLens)という仕組みを利用しました。 この記事ではFireLensについて説明し、実際の要件にどのように対応したのかを共有します。 FireLens とは FireLensは2019年にリリースされたECSのログ管理機構で、ECSで管理しているコンテナの loging driver に awsfirelens を指定することで、サイドカーコンテナとして Fluentd または Fluent Bit を起動し、メインコンテナからログを転送することができます。 FireLensの登場前は、ECSで管理しているコンテナの loging driver に awslogs を指定することで、標準出力を Cl
ECS, Fargateのカスタムログルーティングでよく名前を見聞きするFireLens FireLnesはFluent Bitや、Fluentdを簡単に起動できる仕組みそのものです。Fluent Bit、Fluendでできることは、たとえばエラーログは即時確認したいからCloudWatch Logsへ送り、すべてのログはS3バケットに長期保存したいとか、ヘルスチェックのログは保存しないといったログ周りのあれこれ。ログの保存先の選択や、ログを見て振り分けの判定するために必要なのは主にFluent Bitか、Fluentdでの設定です。 カスタムログルーティングするにはFluent Bitか、Fluendの知識が重要になってきます。 検証環境 下記リンクで作成したFargateの環境を利用して検証します。新しいFireLens（Fluent Bit）のイメージを作成しECRへプッシュしてから
こんにちは id:cohalz です。はてなブックマークのチームではWebアプリケーションのアクセスログを取るためにnginxを入れてCloudWatch Logsに送り、障害時などにCloudWatch Logs Insightsを使って分析を行うというフローが主流となっています。 しかし全リクエストのアクセスログを送るにはCloudWatch Logsの費用は高く、特に安定していてリクエストが多いようなサービスに関しては費用対効果を考えCloudWatch Logsに流すこと自体をやめてしまうこともありました。 そういった状況を解決するために、CloudWatch Logsにはエラーや時間の掛かっているリクエストのみが送られるような仕組みを導入し、費用を抑えつつ障害対応に必要なデータを集められるようにしました。 Fluent BitのLuaプラグインを使う はてなではログのフィルタリン
AlphaDrive、NewsPicks兼務でエンジニアしている大場です。 最近はNewsPicks Webの新基盤開発を行っています。 新基盤はNext.jsで開発していてAWSのFargateで構築しているのですが、このFargate上で取得したログをS3、New Relicに送るためにFluent Bitを導入しました。 今回はローカルでの実行・確認方法と、導入の過程で問題になったことを紹介します！ Fluent Bit とは ローカル実行・確認方法 イメージの選択 設定ファイルの準備 デバッグ用の設定を追加する 動作確認 ltsv形式のログを展開する Stream Processorを使う その他の設定について Fluent Bitで導入の過程でハマったこと S3 プラグインでgzip圧縮時に Content-Encoding: gzip が固定 S3オブジェクト内のデータを正確に
今回はログの収集と分析に焦点を当てます。 いつの時代もアプリケーションが出力するログは、障害解析やアクセス/証跡管理に欠かせません。 マイクロサービスのような分散アーキテクチャを採用した場合、1つのアプリケーションは複数のサービスで構成されることになります。 このため、管理対象ログファイルの数は以前と比較すると飛躍的に多くなり、ファイルレベルでなく、全体のログを一元管理するためのバックエンドサービスは不可欠と言えます。 また、スケーラビリティや可用性を備えた構成にすると、サービスのインスタンス数は頻繁に増減し、それに伴って収集対象のログファイルも変わっていくことになります。 このような状況では、静的にログファイルを管理することは不可能に近く、動的に管理対象のログを検出・収集する仕組みも必要となります。 Kubernetesを実行基盤としたアプリケーションを考えてみましょう。 コンテナのロー
Kinesis Data Firehose と Fluent Bit for Amazon EKS on AWS Fargate によるサードパーティーへのログ送信 | Amazon Web Services
Amazon Web Services ブログ Kinesis Data Firehose と Fluent Bit for Amazon EKS on AWS Fargate によるサードパーティーへのログ送信 この記事は Shipping logs to third-parties with Kinesis Data Firehose and Fluent Bit for Amazon EKS on AWS Fargate (記事公開日: 2022 年 4 月 20 日) を翻訳したものです。 AWS Fargate は EKS クラスターで Pod を動作させるためのキャパシティをオンデマンドで提供するテクノロジーです。Fargate は EC2 インスタンスの管理を必要とせずにコンテナアプリケーションを実行できるようにすることで、より手のかからない体験を提供します。AWS Farg
概要 今回は、EC2で稼働している弊社のアプリケーションログをCloudWatch Logsへ集約しました。 その中で調査したツールの比較や、設定方法について紹介します。 背景 弊社の主要なアプリケーションは2台のEC2で稼働しています。 これまではエラーを調査する際、 EC2（A）にsshで接続してログファイルをgrepして探し、 該当エラーがない場合はEC2（B）にsshして... とそれぞれのインスタンスを行き来することになり、調査に時間がかかっていました。 そこで、アプリケーションログをCloudWatch Logsに集約することでログを一元管理し、ブラウザからエラー調査ができるようにする必要がありました。 各ツールの比較 FireLens ECSの場合使用可能。今回は通常のEC2なので候補から外れました。 なぜ単に Fluentd や Fluent Bit を推奨しないのですか？
やりたいこと ECS Fargateで動いているRailsのアプリケーションログをFirelens(カスタマイズしたfluent-bitのイメージ)を使ってCloudWatchと2つのFirehoseにそれぞれ送りたい。 ①ECS Fargate -> Firehose -> S3 (foo_log) -> Glue -> Athena ②ECS Fargate -> Firehose -> S3 (bar_log) -> Glue -> Athena ③ECS Fargate -> CloudWatch (全てのログ) にログを送りたいという想定。 (fooとbarはある特定の条件のログのみを抽出したいという意) 構成図 今回は青い部分の作業手順をまとめます。 作業手順 リソース作成 CloudWatchと2つのFirehoseに送るようにfluent-bitイメージをカスタマイズする
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Fargate が AWS for Fluent Bit によるマルチラインロギングの完全サポートを開始