FluentdでバッファつきOutputPluginを使うときのデフォルト値 - たごもりすメモ
なんか自分で docs.fluentd.org へのpatchを書いてて混乱してきたのでまとめる。コードを読んでも関係する設定値がいくつものモジュールに分散しており、完全に把握することが困難である。具体的には、この組合せを記憶だけで答えられる fluentd コミッタはおそらく一人もいない。 概要 対象は BufferedOutput および TimeSlicedOutput を継承している output plugin の全て*1。out_forward, out_exec や out_exec_filter も含まれる。 基本的にはいくつかの設定により flush をするタイミングを制御するパラメータ一式、およびflush対象となるデータのチャンクを溜めておく量の上限を決めることとなる。fluentd をうっかり試したときに「アイエエエ、fluent-cat してみたんだけど、設定したと
Windowsオンリーの環境でサーバーステータスをfluentd + Elasticsearch + Kibana で収集・可視化する - Qiita
Windowsオンリーの環境でサーバーステータスをfluentd + Elasticsearch + Kibana で収集・可視化するWindowsFluentdElasticsearch 0. 前書き Windows サーバーのステータス情報を収集し、ある意味鉄板となっているfluentd + Elasticsearch + Kibanaによる可視化をWindows オンリーで実現します。 目指す構成はこんな感じです。 下記投稿をElasticsearch + Kibanaで実現するイメージに近いですね。 "WindowsのCPU使用率/空きメモリ量ログを fluentd で転送して、GrowthForecastでグラフ化" ただし、集めるカウンターをちょっと変更し、もう少し現実的なサーバーのパフォーマンスチェックをおこないましょう。Microsoft Technetの記事 "サーバーの
ELB経由のfluentd Aggregatorを安定化するためにやった3つの対策 - Qiita
この記事はリクルートライフスタイル Advent Calendar 2016の2日目の記事です。 はじめに 弊社ではログ収集にfluentd v0.12を主に使っており、システム自体はAWS上に構築しています。 fluentdのAggregatorには、ノードの追加がしやすいように負荷分散にELBを使う構成にしています。 ここ最近までは、複数のサービスからのログを1つのELBで受け、各Aggregatorノードで処理するという構成をとっていました。 ただログが増えてくると安定性に問題が出てきたため、その際に対策として行ったことについてまとめます。 やったこと 1. コネクション数とログ量のアンバランスを解消する fluentdのsecure-forward output pluginは、コネクションを切らずにログを送り続けます。 またELBは最もコネクション数が少ないノードへ接続を行う負荷
Fluentular: a Fluentd regular expression editor
Regular Expression Test String Custom Time Format (See also ruby document; strptime) Example (Apache) Regular expression: ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$ Time Format: %d/%b/%Y:%H:%M:%S %z
fluentdでSSL通信とS3に置く設定 - Qiita
運用はじまって動いてるのでまあ大丈夫そうということで可能な範囲でタイトルどおりの備忘録を失礼します。 構成 [S3]←syslog←[clients]→accesslog→[log-server]→[elasticsearch] ↑←[external-log-server]←accesslog←[external-clients] ざっくりいうとこんなかんじ。 SSL関連の設定 <store> type forest subtype secure_forward <template> self_hostname log-hoge-mng shared_key hogehoge secure yes ca_cert_path /etc/td-agent/hogehoge.cacrt # enable_strict_verification yes buffer_path /opt/hoge
fluent-plugin-secure-forwardと戯れた話 | GREE Engineering
こちらのエントリーは「GREE Advent Calendar 2015 14日目」の記事です。 こんにちは、データエンジニアリングチームの山田です。6日目の記事の長谷川、田畠とともにグリーの分析基盤を良くする仕事をしています。主にデータ収集周りを担当しており、fluentdとはいつの間にか2年を超える付き合いとなりました。 さて今回は、fluent-plugin-secure-forwardについてつらつらと紹介していきたいと思います。 fluent-plugin-secure-forward(以下secure-forward)は、SSL/TLSを利用しセキュアにデータ転送を行うためのfluentd pluginです。fluentdにデフォルトで含まれているノード間を転送するためのforward plugin(以下forward)は転送時に暗号化などを行っていないため、インターネットを通
fluent-plugin-secure-forwardの脆弱性とアップデートのお知らせ - たごもりすメモ
(追記 5/29 13:15) この更新の際、設定ファイルの shared_key についても変更されることをお勧めします。また変更をいくつか追加した v0.3.2 をリリースしましたので、このバージョンをお使いください。 これは v0.2.x を使用していたときに shared_key_digest を(あるいはshared_keyそのものを)攻撃者に入手されていた場合、認証情報をリプレイ送信されることで攻撃者が input plugin に接続できてしまう可能性があるためです。 深刻度は高くありませんが、念のため shared_key の変更をお勧めします。 また v0.3.2 は認証プロトコルに input plugin から送信するナンスをひとつ増やし、この種の攻撃可能性を排除するための変更を含んでいます。 (追記ここまで) fluent-plugin-secure-forward
fluentd 復習（2）〜 fluentd-plugin-secure-forward を利用したセキュアなログデータ転送〜 | iret.media
ども、 cloudpack の かっぱ (@inokara) です。 はじめに fluentd 復習シリーズ第二弾。fluentd-plugin-secure-forward をざっくりと試してみたい。 参考 tagomoris/fluent-plugin-secure-forward · GitHub Fluentd message forwarding with authentication and encryption fluent-plugin-secure-forwardを試してみた – MakeitSmart! fluent-plugin-secure-forward について 機能 fluent-plugin-secure-forward は以下のような機能を提供する。 SSL によるセキュアなデータ転送（自己証明書利用可能） 共有鍵を利用した認証によるデータ転送 ユーザー名
Fluentd&Kinesis&Lambdaによる柔軟で高可用性なログ収集基盤の構築 - Qiita
概要 Fluentdによるログ収集基盤を、Lambda&Kinesisを利用した形で構成を変更したので、その時のメモ。 先に一言で感想を述べるのであれば、巷の噂通り、Kinesis&Lambdaは素敵でした。 Fluentd Aggregatorが抱える問題点 ログデータをFluentdのForwarder & Aggregatorを経由し、S3とRedshiftに保存するような構成でしたが、Aggregatorは冗長化しづらくボトルネックとなっていました。 ログ収集に求める要件 ログ収集の構成を改善するにあたり、先に挙げた目の前の問題点を解決するのは勿論ですが、他にも様々な要件があり、大別すると以下4つ。 信頼性: データをロスなく収集することができる。 安定性: ログ量に関係なく安定的なパフォーマンスを維持できる。 冗長性: 安全かつ簡単にスケーリングが可能 汎用性: 複数ログを複数サ
Kinesis Producer Library(KPL)とfluentdとLambdaを連携してKinesisのスループットを上げる | DevelopersIO
Kinesis Producer Library(KPL)とfluentdとLambdaを連携してKinesisのスループットを上げる 2016/06/03(金)のAWS Summit Tokyo 2016でクックパッド株式会社の星さんが「秒間数万のログをいい感じにするアーキテクチャ」という発表をされました。 クックパッドのログ収集基盤が Fluentd や Amazon Kinesis Streams や Redshift を活用していい感じするアーキテクチャが参考になった方は非常に多いと思います(あの規模のサービスに関わるかはともかく)。 発表の中でKinesis Producer Library(以下 KPL)を使ってログ数多すぎ問題を解決したことが語られていました。 個人的には、Kinesis Streams のシャード数を増やせばどうにかなるレベルのサービスしか担当したことがない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/kazegusuri/fluent-plugin-bufferize/blob/master/README.md
Windows server の apache ログを fluentd で S3 にアップロードする | STAY KOBE
syslog Parser Plugin | Fluentd
RailsのログをFluentdでtailしてslackへ通知 - Qiita
Big Data入門に見せかけたFluentd入門