こんにちは、LINEのプライベートクラウドサービスであるVerdaのLoad Balancer as a Service (LBaaS) のチームでTech Leadをしている早川です。このエントリでは私が2019年4月にLINEに入社してからの約2年半で体験した大規模LBaaSならではの興味深い問題をピックアップしてご紹介します。 Verda LBaaSについて VerdaのLBaaSは2016年ごろに稼働を開始したVerdaの中でも比較的歴史が長いサービスです。当時のLINEではハードウェアのアプライアンス製品を用いて提供されていたロードバランサのサービスを置き換える目的で開発されました。特徴としては実際にユーザのトラフィックを受けるいわゆるデータプレーンと呼ばれるコンポーネントも含めて全てがソフトウェアで実装されているということが挙げられます。 中でも個人的に気に入っているのは、L4
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 1.0のリリースに合わせてトレジャーデータのデベロッパーにインタビューを実施し、「黒子のような存在になりたい」という背景を訊いた。 CNCF(Cloud Native Computing Foundation)配下のログ収集のためのオープンソースソフトウェアであるFluentdは、2017年にバージョン1.0がリリースされた。記念すべき1.0というマイルストーンを達成したFluentdのデベロッパーにしてトレジャーデータ株式会社のシニアソフトウェアエンジニア、中川真宏氏にインタビューを行った。 まずリリース1.0の発表ということで1.0とそれ以前のバージョンの違いなどについて教えてください。 ツイッターなどでも誤解されている方を見かけますが、実は0.14と1.0で中身は何も変わっていないんですね。Fluentdは、0.12という最も広く使われているバージョンと最新の0.14
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 を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ?」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ!」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
この記事はQuipperのテックブログに書いた以下の記事の日本語版での要約です。 http://quipper.github.io/2015/11/11/introducing-shadow-proxy.html Shadow Proxyとは? 本番のHTTPリクエストから同等のリクエストをステージング環境に適用するための仕組みです。主な目的は、2年以上の運用で肥大化したMongoDBに対するindexの追加/削除/つけ忘れなどを事前に検証・検知するためです。 構成 Fluentdが大活躍しています。 Reverse Proxy Log AggregatorにNginxのアクセスログを転送する Log Aggregator S3(バックアップ),BigQuery(調査用),Shadow Proxyにアクセスログを転送する アクセスログをもとにステージングのアプリにHTTPリクエストを送信す
I recently needed to completely automate deploying a full ELK/EFK stack and clients and didn’t find anything that suited my needs so I wrote the playbooks for this in Ansible. This was my first real foray into automation with Ansible, hope it’s useful to others. What is ELK? ELK is an acronym for an extremely useful stack of log aggregation and datastore utilities for centralized log management a
Hi users! We have released Fluentd version 0.14.0, which is the first release of major version 0.14, including many improvements and new APIs. This post shows some of major changes. See ChangeLog for the full list of changes. Windows support Fluentd v0.14 core supports Windows environment! Process management layer of Fluentd v0.14.0 was rewritten with ServerEngine to make it possible to spawn proc
nginx Advent Calendar 2015 7日目 兼 fluentd Advent Calendar 2015 6日目のエントリです。 nginx-lua (https://github.com/openresty/lua-nginx-module) から fluentd にログを送信する方法を紹介します。 Lua から fluentd へログを送信するライブラリとして fluent-logger-lua というものがありますが、これは LuaSocket ライブラリを使用しているため nginx-lua では使いづらいので、ngx.socket.tcp を使用して自前で送信してみましょう。 fluentd の forward protocol は3パターンの入力フォーマットがあるのですが、一番単純なフォーマットは [tag, time, event] の形式で、この形に Me
The unsung heroes of log analysis are the log collectors. They are the hard-working daemons that run on servers to pull server metrics, parse loogs, and transport them to systems like Elasticsearch or PostgreSQL. While visualization tools like Kibana or re:dash bask in the glory, log collectors’s routing making it all possible. Here, we will pit the two of the most popular data collectors in the o
原稿の執筆が一段落して心に余裕が出てきた@cubicdaiyaです。 今回はサーバを運用しているとありがちなページキャッシュに関する問題とメルカリのアプローチについて解説します。 Fluentdによるログ転送 話は変わりますが、メルカリの各サーバ上ではプログラムが吐いたログデータをKibanaやNorikraといった各種コンポーネントに転送するためにFluentdが稼働しています。各ログデータは原則単一のファイルに追記されてFluentdのtailプラグインによって各所に転送されていきます。 ログデータのサイズはまちまちで、1日で数GB程度のログデータもあれば数十GB以上のログデータもあります。 ページキャッシュと巨大なログファイル 各サーバに吐かれるログデータのサイズはサーバに搭載されているメモリのサイズと比べると1日分だけでもかなりの量になります。そして、このように絶えず書き込まれる巨
Collecting All Docker Logs with Fluentd Last modified: August 18, 2019 Logging in the Age of Docker and Containers Just in case you have been offline for the last two years, Docker is an open platform for distributed apps for developers and sysadmins. By turning your software into containers, Docker lets cross-functional teams ship and run apps across platforms seamlessly. If you are interested in
Norikra meetup #2でNorikraをログ解析に使うというごくごく一般的な内容の発表をしてきました。主催の@tagomorisさん、会場を提供頂いた:DeNAさん、皆様ありがとうございました。1年前に導入を検討し始めて、別に特段変わったこともしてないし、すごくヘビーに使っている訳でもないので、ゆるくまとめようとおもったらかなり時間余ってしまいました…… speakerdeck.com 最初MongoDBのcapped collectionに入れていたのが、Elasticsearch/Kibanaが流行してElasticsearchが全文検索以外に使われ出したり、ログ解析のトレンドはすごい勢いで変わってきているように感じます。Stream processingを行う方法にはFluentdのプラグインを用いる方法がありましたが、使っているfluent.confの中にfluent-
This document provides an overview of Fluentd, an open source data collector. It discusses the key features of Fluentd including structured logging, reliable forwarding, and a pluggable architecture. The document then summarizes the architectures and new features of different Fluentd versions, including v0.10, v0.12, and the upcoming v0.14 and v1 releases. It also discusses Fluentd's ecosystem and
https://atnd.org/events/65969 Norikraをつかいたいなーという気持ちを主張するためにとりあえずmeetupに参加してきた。 画面黄色かった だいたいみんな監視系で使ってた だいたいみんなSPOFで困ってた Gunosyさんは処理量もあってか冗長化してたもよう やっぱ便利そう 使いたい AWS Summitからのはしごだったのでさすがに疲れた。。。 メルカリでのNorikraの活用、Mackerelを添えて メルカリでのNorikraの活用、 Mackerelを添えて from Masahiro Nagano kazeburoさん Mercari いかに早くスムーズにサイクルを回すか Zabb....? いいことはいっぱい 煩雑だしめんどくさい DevとOpsで情報を共有 MetricsをDevと共有 これを何とかするのに、fluentd経由でkibana
Norikra meetup #2でLTをしてきました。LTといいつつ時間に余裕があったので15分以上しゃべっていたような… atnd.org 発表資料はこちらです。 speakerdeck.com Norikraで不正アクセスの兆候があるアクセスログを検知して、検知次第IPアドレスをmemcachedに突っ込んでそれをもとにアクセスをブロックする、というネタでした。 ログの流し込みが詰まった場合に誤爆しないように、結果のtimestampに1分以上の間隔があった場合は max(time) - min(time) で補正するとか、クエリに後処理で使うための定数を埋め込んでおくことでクエリごとに挙動を調整しやすくするとか、そんなかんじの細かい工夫をしています。 あと皆さん気になっていたNorikraの冗長化ですが、active-standby構成であればすぐできる気はします。 うちはいまst
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く