fluentdでログが欠損する可能性を考える : sonots:blog
多種多様なログをFluentd-Elasticsearch-Kibanaしたメモ - Tech Notes
自分のところでは、社内の様々なログをfluentdで集めているのだけど、それらをElasticsearchに入れて、Kibanaで見えるようした話を書いてみる. Fluentd, Elasticsearch, Kibanaな組み合わせは既に多くの人が使ってるし、ブログ等の記事も沢山ある. けど、いくつか 引っ掛かった点などもあるので、それらを書き留めて置こうと思う. 要件 fluentdでストリームで集めてるログを、リアルタイムに近い鮮度でKibanaで見たい. 見たい、というのは検索したり、集計・可視化したり、ということ Kibanaでは短期(2日とか)のログが見えれば良い 規模感的には、ログの種類(=fluentdのtag数)が200くらい、流量はピークで2万メッセージ/秒くらい. が、実際には最も流量の多いログは除いたので、この半分〜3分の1くらいの流量 10shard/index
Apacheログをfluentdで読み出してelasticsearchに転送する流れをdockerでシミュレートするハンズオン - Qiita
Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 5 User www-data Group www-data HostnameLookups Off LogLevel warn LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_core_module modules/mod_authn_core.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_user_module modules/m
Fluentd+Elasticsearch+Kibanaによるサーバログの可視化 - Qiita
先日FluentdMeetup＠六本木に出席したのもあり、実環境で実験君しようと思いました。 会社でMaillinglistServerを構築しており、その運用を検討する必要がありました。 ApachelogやMaillog、syslog等のサーバ情報を１か所に集約して、 見たい時に見やすい形でみたい。 まさに、Fluentd+Elasticsearch+Kibanaではないですか。 流行りでもありますし。 そのため、以下のフェーズに分けて実験君開始です。 実験君のフェーズ Fluentd+Elasticsearch+Kibanaのサーバ構築 ローカル環境におけるFluentd動作確認作業(nginxlog) サーバ間接続におけるFluentd動作確認作業(apachelog) サーバ間接続におけるサーバログの収集(maillog) Kibana画面のUI向上とElasticsearchサ
ELBのアクセスログをfluentd(fluent-plugin-elb-access-log)+Elasticsearch+kibanaで可視化する - Qiita
$sed -e 's/:[0-9][0-9]\.[0-9][0-9][0-9][0-9][0-9][0-9]Z//g' access.log |awk -F " " '{ print $1,$8; }'| sort | uniq -c のようなコマンドを作って解析しても良いのですが、色々面倒なので、よくあるツール群を使って可視化します。 構成 Amazon Linux AMI 2015.03 (HVM)(S3へのRead権限を持ったIAMRoleが設定されていること) td-agent-2.2.0-0.x86_64 ElasticSearch-1.4.5 nginx-1.6.2-1.23.amzn1.x86_64 Kibana3.1.2 なお、ELBのアクセスログは事前に有効にしておくこと。 参考 ELBのアクセスログをfluent-plugin-elb-logを使ってkibanaで表示す
FluentdでWEBサーバからログを送る | システムガーディアン株式会社
タグ 保湿RTX1210VagrantVirtualBoxAnsibleLarabelClamAVCentOS7SWX2200ゆるいハッキング大会RTX1100MySQLPlesk12おりょりょんNFSPostfix基板修理linux 入門atomゆるいハッキングDrupalVisual Studio 2017RabbitMQMVCAsteriskベンチマークBINDGitMastodonwindows10GeoIPApacheAWS S3AWS CLIFuelPHPVulsH2OSSHFSAWS EFSZabbixRDPELBロードバランサsshバックアップ負荷分散AWS EBSCybozu Office10ElasticsearchSWX2300LogstashKibanaLaravelKubernetes仕事猫現場猫ゆるいハッキングセミナーALBDNSConoHa Vlanデッドロッ
FluetndでApacheのアクセスログを集約する - okochangの馬鹿でありがとう
こんにちは＠oko_changです。 すでに色々な方がまとめていますが、やっぱり自分なりにブログにまとめたほうが覚えやすいので今回はfluentdについて書きます。 Fluentdとは？ こちらを見るのがやはり早いですかね。 環境 どちらもCentOS 6.5を使用しています。 今回はFluentdを使ってローカルのファイルに保存しつつ、転送先にも保存するまで確認します。 転送元環境 インストール前 Fluentdについては色々な方がブログとかでもまとめているので、そちらを参考になりますが、公式ドキュメントもとても充実していました。 ここにFluentdをインストール前にするべき事が記載されていますので、設定します。 ※limits.confとsysctl.confにそれぞれ追記する # vi /etc/security/limits.conf root soft nofile 65536
fluentdをインストールしてRailsのログを見やすくする（前編） - Qiita
環境 Ruby on RailsがセットアップされているCentOS 6.5 参考 fluentdでapacheログを収集する CentOS 6.5 (Vagrant)に fluentd + elasticsearch + kibana をセットアップする fluentdでrails logをtailで直接取得する方法 gemを使ってcentosにfluentdサーバを構築する いまさらだけど fluentd に入門した 手順 fluentdをセットアップ vagrantに接続する（vagrant環境の構築、vagrant upは別途行っているものとする） $ vagrant ssh gem installでfluentdをインストールする $ gem install fluentd --no-ri --no-rdoc インストールされたか確認する $ fluentd まだconfigを作
fluentd × Elasticsearch × kibanaによるアクセスログ解析 - Qiita
概要 fluentdでログ転送＆収集を行い、 Elasticsearchでデータを保存し、 kibanaでデータの可視化を行う。 サーバー構成 APIサーバー（複数台） 【nginx】→【fluentd】→ログ収集サーバーへ転送 ログ集約サーバー（兼 解析サーバー） APIサーバーから転送→【fluentd】→【Elasticsearch】⇔【kibana】 サーバー設定 APIサーバー log_format ltsv 'time:$time_iso8601\t' 'remote_addr:$remote_addr\t' 'request:$request\t' 'request_method:$request_method\t' 'request_length:$request_length\t' 'request_uri:$request_uri\t' 'uri:$uri\t' 'qu
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
Mackerel と fluentd でサービスの状態を可視化する - Hatena Developer Blog
この記事ははてなエンジニアアドベントカレンダー2014の9日目です。 こんにちは、はてなアプリケーションエンジニアの id:hatz48 です。 今日は Mackerel と fluentd を利用してサービスの状態(レスポンスタイムやステータスコードのレートなど)を可視化するために、自分のチームで行っている方法を紹介します。 Mackerel とは Mackerel ははてなで提供しているサーバー管理ツールです。 mackerel-agent をインストールするだけで簡単にホストの基本的な情報(loadavg, cpu使用率など)を可視化・監視することが出来ます。基本的な情報の他にも、plugin を使うことでカスタムメトリックを取ったり、APIを使うことでホストに紐づかないメトリックも収集することができます。plugin, API の詳細はこちらからどうぞ ミドルウェアのメトリック可視
EC2のログをfluentdを使ってタグ情報を利用したフォルダ構成でS3にアップロードする - Qiita
オートスケール環境ではEC2の起動、停止が動的に行われるのでログ(syslogやアプリ、ミドルウェア)を外部に出す必要があります。 やり方として S3にアップロード CloudWatchLogsを使う ログサーバーに転送 などが一般的だと思います。 S3にアップロードする方法を考えた場合、どのようなフォルダ構成でアップロードするかは結構大切なことだと思います。(探しずらいとあとで大変) また、本番環境、検証環境などがある場合、どこにどうおくかをEC2のタグの情報を利用して考えたい場合もあると思います。 そこで今回はEC2のログをfluentdを使ってmetadataやタグ情報を利用したフォルダ構成でS3にアップロードすることをやってみました。 今回の例では/var/log/messagesをS3に以下の構成でアップロードするようにしてみました。 Bucket │ ├-Env(product
柔軟なログ収集を可能にする「fluentd」入門 | さくらのナレッジ
複数台のサーバーやクラウド環境を組み合わせてのサービス運用においては、ログの収集方法に工夫が必要となる。こういった場合に有用なのが、さまざまなログの収集手段を提供するfluentdだ。今回はfluentdのアーキテクチャやそのインストール/設定方法、基礎的な設定例などを紹介する。 さまざまな方法でログを収集できるfluentd 今回紹介するfluentdは、Treasure Dataが開発するログ収集管理ツールだ（図1）。オープンソースで公開されており、Linuxや各種UNIXで動作する。 図1 fluentdのWebサイト ログ収集のためのソフトウェアとしてはsyslogdやsyslog-ngなどが有名だが、fluentdがこれらと異なる点としては、以下が挙げられる。 さまざまなソースからのイベントをさまざまな媒体に出力できる fluentdの大きな特徴としては、ログの収集方法やログの記
実例で学ぶDockerハンズオン - Qiita
この記事はCAMPHOR- Advent Calender 2015 22日目の記事です。 こんにちはkohey18です！(｀･ω･´)ゞ 学生時代はCAMPHOR-の4期代表として頑張ってから上京して今に至ります(｀･ω･´)ゞ この一年、インフラエンジニアとして業務でDockerを触る機会がたくさんあり、その中でインフラエンジニアだけでなく、サーバサイドエンジニアもアプリのエンジニアももっとDockerを手元で触ってもらってDocker力があるとどんだけ楽だろうか。。。と思うことが多々あり、週末なり時間のあるときに試して欲しいDockerハンズオンをまとめておこうと思いました。 週末とかで試してみて、「あぁなるほど」と思って貰えればと思います。 対象者 Docker初心者よりちょい上(一応初心者もわかるようにDockerfileの書き方から書いています) とりあえずDockerをローカ
WindowsのCPU使用率/空きメモリ量ログを fluentd で転送して、GrowthForecastでグラフ化 - Qiita
WindowsのCPU使用率/空きメモリ量ログを fluentd で転送して、GrowthForecastでグラフ化RubyWindowsFluentdgrowthforecast 0.前書き WindowsのCPU使用率/空きメモリ量のログを、fluentd で転送し、GrowthForecastでグラフ化します。 Windowsの監視におけるfluentdのユースケースとしてはフォワーダーとしてnxlogを使うパターンが紹介されています。 http://docs.fluentd.org/ja/articles/windows が、 ここではあえてfluentdのWindowsブランチを使って直接fluentdがログを読み、そのままGrowthforを使うことにチャレンジしてみます 。 目指す構成はこんな感じ。 CPU使用率/空きメモリ量の取得には、Windowsに標準添付されている t
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
「BigQueryは120億行を5秒でフルスキャン可能」は本当か？ 先日、kaheiさんがGoogle BigQuery（Googleクラウドの大規模クエリサービス）について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。（Fluentd Meetupでの）プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる（これ、記憶がちょっとあいまい。もう少しかかったかも）。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
そろそろFluentd v11についてひとこと言っておくか - Go ahead!
リリースは永遠にされません！ 日本では色々なところでv11の噂がまことしやかに囁かれていますが， 俺がメインメンテナである限りv11がリリースされることはないので，諦めてv0.10.xを使ってください！ 以下まじめな話になります． v11が生まれた背景と現状 v11が生まれたのは1年以上前です．背景には，v10と呼ばれる今のバージョンがプロトタイプを兼ねたリリースであり， 「利用者のフィードバックを取り込んで，ダメな所をガッツリ書き換えて互換性を壊してメジャーバージョンアップや！」という流れがありました． しかし，v10は十分に柔軟でかつパフォーマンスも発揮しており，コミッタ陣はそれほどモチベーションがあったわけではありません． また，プラグインによって解決出来た問題も多く，v11が生まれた時ほどユーザから「v11が欲しい！」という要望は聞かれなくなりました． 当たり前ですが，ユーザからの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluentdのお勧めシステム構成パターン
Fluentd ソースコード完全解説 at RubyKaigi2014 : sonots:blog
