タグ

*Fluentdに関するyamadarのブックマーク (5)

  • net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita

    Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 文中で Linux のコード/ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう(というかできません)。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ

    net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
    yamadar
    yamadar 2018/01/04
    Fluentdで推奨されてた設定なので、影響ある人は結構多そう
  • fluentdを導入しました&webサーバー上のagentが結構メモリを消費するよ - hito_asaの日記

    そこそこのトラフィックのあるWebサーバー上で、アプリケーションから出力されるいくつかのログファイルを収集するためにFluentdを導入しました。 セットアップはこんな感じ。 fluentdのバージョンは0.10.15, rvmが1.10.3, rubyが1.9.3p125 です。 Webサーバーは20台で、一番多いサーバーで800万req/dayくらいの規模です。 各Webサーバー上ではin_tailで3つのファイルをtailし、out_roundrobin & out_forwardで計4台の集計用サーバーに流して、そこでレコメンデーションやKPIの集計を行っています。 Webサーバー上のagentとして動くFluentdの設定ファイルはこんな感じ。 この3つのファイルは、それぞれdailyでローテートされてて、1日当たり 460万行、640万行、370万行くらいです。 起動は以下のス

    fluentdを導入しました&webサーバー上のagentが結構メモリを消費するよ - hito_asaの日記
    yamadar
    yamadar 2016/12/17
    監視するログファイルのサイズによってメモリ消費が増える
  • Fluentdの設定を考えるときはこんなかんじで考えると便利 - Qiita

    Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重

    Fluentdの設定を考えるときはこんなかんじで考えると便利 - Qiita
  • 今日から始めるfluentd × Elasticsearch × kibana - カジュアルな解析・高速化 - Eureka, Inc.

    目次 1. まえがき 2. pairsとシステム 3. kibana サンプルシステム構築 3.1 サンプルのサーバー構成例 3.2 fluentd 3.3 Elasticsearch 3.4 kibana 4. kibanaを使う 5. エウレカでの実際の活用事例 6. 〜終章〜 1. まえがき 1.1 対象者 気軽にデータ収集をしたいと思っている開発者 基的なLinuxコマンドの理解がある方 1.2 この記事を読んで分かること fluentd x Elasticsearch x kibana を用いたアクセスログの収集・計測方法 pairsのシステム概要 私の好きなアニメ pairs高速化チーム 1.3 この記事を読んでも分からないこと 格的な統計解析 恋人の作り方 1.4 自己紹介 はじめまして。サービス事業部の森川と申します。 エウレカには今年のはじめ頃にJoinしました。 エ

    今日から始めるfluentd × Elasticsearch × kibana - カジュアルな解析・高速化 - Eureka, Inc.
    yamadar
    yamadar 2015/01/09
    ログのビジュアライズ
  • ログ集計/時系列DB/可視化ツールの調査結果 - Qiita

    近年、自分の中で集計/可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計/可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ?」「Graphiteってなんじゃ?」「InfluxDBってなんじゃ?」 など、このツール達は一体何なんだろう…?というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか? というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の3つに分けられそうです。 ログ収集/集計 時系列DB(+API)の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu

    ログ集計/時系列DB/可視化ツールの調査結果 - Qiita
  • 1