「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
[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](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a77b081e14c8d61a2e80498092f8ffb9b60da03/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Fterraform-eyecatch.png)
AWS Startup Tech Meetup #3: かんたんコンテナロギング選手権
コンテナでログをどう取得すればいいの？そもそもどういうログがあるのか？ ログの取得パターンから活用方法まで、 @prog893 が選定のためのヒントとサンプルアーキテクチャで紹介します。
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
ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG
こんにちは、SRE部MA基盤チームの谷口（case-k）です。私達のチームでは、データ連携基盤の開発・運用をしています。 データ基盤には大きく分けて2種類あり、日次でデータ連携してるものとリアルタイムにデータ連携しているものがあります。本記事ではリアルタイムデータ連携基盤についてご紹介します。 既存のデータ連携基盤の紹介 リアルタイムデータ連携基盤の紹介 なぜ必要なのか 活用事例の紹介 データ連携の仕組みと課題 リプレイス後のリアルタイムデータ連携基盤 SQL Serverの差分データの取り方を検討 アーキテクチャ概要と処理の流れ Fluentdのプラグインを使った差分データの取得 Dataflowでメッセージの重複を排除 Dataflowで動的にBigQueryの各テーブルに出力 Pub/Subのメッセージ管理 イベントログ収集基盤 個人情報の取り扱い ビルド・デプロイ戦略 監視 データ
軽量な Go 製カラムナフォーマット変換ツール columnify を作った話 - Repro Tech Blog
こんにちは。業務委託として SRE チームのお手伝いをしている @syucream です。 本記事では Repro にて開発した、 Go 製のカラムナフォーマットへのデータ変換ツール columnify について、開発背景や技術的な取り組みを紹介します。 なぜカラムナフォーマットか？ ことのおこり 事業がスケールすると共に扱うログの量が増えることは、喜ばしい反面さまざまな悩みをもたらします。その中でも顕著なものの一つとしてコストの問題が挙げられます。 膨大なログデータはログに対するストレージ料金を増大させると共に、分析や可視化に際してクエリで求められるコンピュートのコストも無視できなくなっていきます。 近頃 Repro でもコンテナのログの管理においてこの問題が顕著になってきました。Repro のバックエンドシステムは ECS 上のコンテナで実現され、ログの閲覧・管理のため外部のログ収集サ
k8sハニーポットとログ出力の話 - エムスリーテックブログ
本記事はエムスリー Advent Calendar 2019 - Qiitaの24日目の記事です。 こんにちは。エムスリーエンジニアリンググループの木村です。 業務ではBIRというチームでアンケートシステムの開発をやっています。 今回は個人的に構築しているk8sハニーポットシステムとそこで生じたログ出力の問題について話をしようと思います。 ハニーポット まずハニーポットとは何かですが、一言でいうとインターネットからの攻撃を敢えて受けるサーバです。 通常通用されるサーバでは、ファイアーウォールやアンチマルウェアソフトウェアを利用して攻撃を防御し、サービスを安定して運用することが求められますが、ハニーポットはその逆です。 敢えて攻撃を受け、それを記録することによりネットワーク上でどのような攻撃が流行しているのか、その手口などを観測・分析することが目的になります。 ネットワーク構成 現在の私の自
The Next Chapter - トレジャーデータ（Treasure Data）
本日皆様に、私たちトレジャーデータがArm社の一員に加わるという発表をお知らせできることを大変うれしく思っています。 私たちと、これまで私たちを支えてくださったお客様とで紡いできた物語に加わる、半導体技術とIoTサービスにおけるリーディングカンパニーであるArm社とトレジャーデータのコラボレーションによって描き出される未来の一端、次なる章を、ここで私からお伝えいたします。 データの活用が人々を幸せにする2011年に遡らせてください。私は太田一樹と古橋貞之をアメリカに連れ、3人でトレジャーデータを創業しました。 当時の私たちは、トレジャーデータのコアとなるビジョンとミッションをどう具現化させるかの議論に夢中になっていました。どうやって「テクノロジーと人間の関係性を根本から変容させる」かということ。 「データの活用が人々を幸せにする」という信念のもと私たちが企てていたのは、データが新しい通貨と
Web Developer も知っておきたい Kubernetes における Sidecar Pattern と Ambassador Pattern - スタディサプリ Product Team Blog
Site Reliability Engineering チームの @yuya-takeyama です。 年末年始頃は React Native でのアプリ開発をやっていた気がしますが、「スキルを Web 開発から SRE の領域まで広げたい」という以前からの私自身の思いと、「Kubernetes による Microservices 基盤を作っていくメンバーがもっと必要」「Microservices を技術面だけでなく組織面でも Production Ready な形でやっていく上で Developer と SRE のつなぎ役が必要」という会社の状況が一致したので、異動して AWS, Kubernetes または MongoDB などと向き合っています。 3 行でまとめ Sidecar Pattern はアプリケーションのコンテナから再利用可能な部分をもう一つのコンテナとして切り出すパター
Kafka/Fluentd/Sparkを用いたデータ分析基盤の運用話 by ペンギン愛好家 さん - niconare
新宿Geek Lounge#4 分析基盤Meetup ver2での発表資料です。 https://shinjuku-geek-lounge.connpass.com/event/83127/
2017年12月7日 「Fluentd v1.0」がリリース、マルチプロセス、Windowsサポート、700以上のプラグイン | gihyo.jp
Linux Daily Topics 2017年12月7日「Fluentd v1.0」がリリース、マルチプロセス、Windowsサポート、700以上のプラグイン 12月6日（米国時間）、米テキサス州オースティンで開催中の「KubeCon + CloudNativeCon」（主催: The Linux Foundation）の会場において「Fluentd v1.0」がリリースされた。米Treasure DataのファウンダーでFluentdの開発者である古橋貞之氏も自身のTwitterでv1.0のローンチを明らかにしている。 Fluentd v1.0 - Cloud Native Computing Foundation Did you see so many amazing news from Fluentd...!? Fluentd 1.0 is released! #CloudN
Fluentd / Embulk / Elasticsearch / Digdag を学ぶのに最高な「データ分析基盤構築入門」を読んだ - kakakakakku blog
出版されてから少し時間がたってしまったけど，「データ分析基盤入門」を読み終えた．ページ数が多く，持ち運ぶようなサイズではないので，家でちょこちょこ読み進める感じになってしまって，想定以上に時間がかかってしまった． データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化] 作者: 鈴木健太,吉田健太郎,大谷純,道井俊介出版社/メーカー: 技術評論社発売日: 2017/09/21メディア: 単行本（ソフトカバー）この商品を含むブログを見る はじめに 目次にも書いてある通り，「データ分析基盤」というテーマで Fluentd / Elasticsearch / Kibana の解説が詳細にまとまっている．さらに付録には Embulk と Digdag の解説もあり，このあたりの技術スタックに興味がある人にとって最高な一冊なのではないかなと思う．また，
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
Fluentd vs Logstash: A Comparison of Log Collectors | Logz.io
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
fluentd+elasticsearch+kibanaの環境を構築してみた - ssossanの日記
背景 webサービスを運用してるんですが、ログをもっと有効活用しようぜ！って話になり、とりあえず手元でfluentd+elasticsearch+kibanaを使って環境を作ってみました。 アプリが入ったサーバには極力負荷をかけたくないので、パース作業は別のサーバで行いました。そのへんでいい感じにまとまってる情報が見つからなかったので、備忘録を兼ねてメモ。 サーバ構成 アプリケーションサーバ(今回はmac) -> fluentdを入れてログの送信だけやらせる。 VM(ubuntu14.04) -> fluentd, elasticsearch, kibanaを入れてログのパース〜蓄積〜表示まで。実運用では変わるだろうけどまあ練習ということで。 ハマった点・困った点 1. アプリケーションサーバからログをそのまま送信するのってどうやるんや 2. 正規表現苦手なんだけど 3. parserプラ
バッチ処理、ジョブ管理について書いてみる - wyukawa's diary
僕はHive, Pythonでバッチ処理を書いてAzkabanでジョブ管理するシステムを構築、運用した経験が2年ほどあるので今日はバッチ処理、ジョブ管理について書いてみようと思います。 僕の経験上Hadoop特有の部分、例えばテスト環境が作りづらいとかバッチサーバーはジョブをsubmitするだけなので負荷はそんなにかからないとか、はあるけれど割と汎用的なのではないかと思います。そもそもバッチ処理、ジョブ管理について書かれたものはほとんど見た事がないので参考になれば嬉しいし、こういう良い方法もあるよ！とかあれば是非ブログ等に書いてほしいと思っております。 最初に言っておくとバッチ処理、ジョブ管理において重要なのは障害時のリカバリのしやすさです。正常時はまあいいでしょ。 なので例えば引数に日付を持てないようなバッチ書いたら辛いですし、LL言語で書く方がコンパイル、パッケージングとか楽です。CP
Fluentdの現実装のPros/Cons - Go ahead!
TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます． Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります． Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OSSのデータ収集ツール「Fluentd」に任意コマンド実行などの脆弱性（JVN） | ScanNetSecurity
lestrrat-go/fluent-clientの紹介
fluentdでログが欠損する可能性を考える : sonots:blog
