はじめに ログ集約・可視化・検索ツールとしてはELKスタックを利用するケースが多いが、これをLokiに置き換えることでより軽量にログを集約することができるようになる。 Grafana Lab社が開発したLokiは、ログのストリームに対してタグ付けし保存する仕組みを持つ。Prometheusと親和性がたかく、水平展開、高可用性、マルチテナントが可能。 構成 各クライアントからのsyslogは514/udpポートで送信される。これをrsyslogデーモンで受け5514/tcpポートへ転送する。fluentdは5514/tcpポートで受信したsyslogをさらにlokiへ転送する。 +------------------------------------------------+ | | | +---------+ | +--------+ 514/udp | | | | | client +
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
こんにちは、SUUMOスマホサイトの開発チームに所属しているエンジニアの上野です。 今回は、リアルタイムログ解析基盤を紹介します。 背景 皆様はwebサーバログ監視（アクセスログ・エラーログなど）をどのように行われているでしょうか？ スーモスマホサイトでは、アクセス数増加に伴いサーバ台数が増え、csshX地こんにちは、SUUMOスマホサイトの開発チームに所属しているエンジニアの上野です。 今回は、リアルタイムログ解析基盤を紹介します。 背景 皆様はwebサーバログ監視（アクセスログ・エラーログなど）をどのように行われているでしょうか？ スーモスマホサイトでは、アクセス数増加に伴いサーバ台数が増え、 csshX 地獄に陥りました。（以下の図のような状態のことです。） ログの確認が必要になった際に、この csshX を使用して秘伝のワンライナーで確認したい部分をtailして抽出していましたが
fluentdを使う時にまず知っておいたほうがよさそうなこと はじめに 朝からElasticsearchへのデータの投げ込み方を考えていました。 データベースやメッセージキューなどにデータを投げ込んでおいて、ニアリアルなバッチでElasticsearchに投げ込むよりも、fluentdを使う方が圧倒的に簡単で信頼性が高いものができますね。自分で作りこむのがバカらしくなりますね。 ということで、fluentd利用時に気を付けておきたいことについて調べてみました。内容は公式ドキュメントの内容をベースに自身で調べたことを追記しています。公式ドキュメントへのリンクも貼ってありますので適宜そちらをご覧いただければと。 環境 CentOS6.7 td-agent 0.12.19 Ruby2.2.2（リストアスクリプトで利用） Fluent-Logger(0.5.1) Elasticsearch2.1.
この記事は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にアクセスログを転送する Shadow Proxy アクセスログをもとにステージングのアプリに
去年のJANOGで別の方が発表された内容とダダ被りではあるものの，折角なのでメモ程度に書いておく． 概要 データセンタネットワークやバックボーンネットワークの運用をやっていると，インターネットに出入りするトラフィックの内訳 (どのISP向けのトラフィックが多いのか，どの回線にトラフィックが乗っているか，等) を見たいことがよくある NetFlowをNorikraで解析し，その結果をGrowthForecastに流し込むと，トラフィックの内訳をそこそこ手軽に見ることができる 定常的なモニタリング用途以外に，突発的なトラブルシューティングにも使えていろいろ便利 背景 自前でAS (Autonomous System) を運用している事業者では，トラフィックのコントロールの観点から，「どのAS向けのトラフィックがどのくらいあるのか」「このASとはどの回線を使って通信しているか」といった情報を知り
大学外にポートが空いている研究室のサーバに対して，不正なSSHのアクセスが結構来ています． 今回は以下のステップで，不正アクセス元の国をKibana mapで可視化してみました． fluentdでSSHのログから不正アクセスのIPアドレスを解析 GeoIPを使ってIPアドレスから国を特定 Elasticsearchにログを収集 Kibanaのmap panelを使って可視化 GeoIPとは サイトアクセス者の位置情報を取得するGeoIP | SourceForge.JP Magazineより引用． GeoIPとは、IPアドレスを国、都市、インターネットサービスプロバイダ(ISP)にマッピングしたデータベース群である。 そうしたデータとともにC、PHP、Javaその他いくつかの言語を使ってデータベースにアクセスするためのLGPLライセンスのAPIも用意されている。 fluentdでSSHログ
これは Elasticsearch Advent Calendar 2014 22日目の記事です。 今回は、プロダクション環境で、流行りのFluentd+Elasticsearch+Kibanaでログ可視化というのを数ヶ月やった中で苦労した点とかはまった点を書いてみます。 というか、書き終えて思うとこれからやる人はここに気をつけた方がいいというような内容になってしまったので、既に運用されている方にはあまり役に立たないかもです。。 内容は、大きく下記3つです。 ①集計(検索)の条件を考えてtemplateでnot_analyzeを指定しておく ②スキーマ変更があるindexは、日単位でindex作るべし ③数値型フィールドの罠(Fluentd寄りの話) 前提として、この流れで収集しているのは下記4パターンのログ達。 ・Apache accesslog ・Apache errorlog ・Ap
リアルタイム集計・可視化環境(Norikra+Kibana4+Elasticsearch+Fluentd+Nginx)をfig一発で気楽に立ち上げる。ElasticsearchDockerNorikraKibanafig このエントリーはドワンゴアドベントカレンダー17日目のエントリーです。 ストリーム処理エンジンのNorikraについて、最近聞くことが増えてきました。 使ってみたい方は結構いるのではないでしょうか。 とは言え、「ストリーム処理を試してみたい、環境構築してやってみよう」と思っても、JRuby入れてNorikra入れて、fluentd入れてNorikraとのin/outの連携して、集計結果を格納する為にElasticsearch構築して、Kibanaから見れるようにして、認証機構や改廃の機構も入れて...あ、ストリームソースも用意しなきゃ...となって、そこそこ手間が掛かりま
はじめに 世間的には「fluentdで集計 ≒ Norikra!!!!!」という流れで、それに対して一石を投じる気のかけらも私には無いわけですが、Norikraを用いるまでもない軽微な処理を実行する場合fluentdのプラグイン単体で処理を完結したいケースもあり、そしてNorikraが若干重厚に映るケースもあります（JRuby!! Esper!!!） ということで、集計が行えるようなfluentd pluginについてまとめてみます。チョイスは僕の独断と偏見です。 ユースケース fluentdの基本的なユースケースは、inputとして入力をしたデータをoutput先にrelayする、というものです。そして集計処理は、多くの場合output先のシステム内、もしくはシステムに蓄積されたデータを用いて別のシステムを用いて行う事が多いと思います。 (ex. HDFSに保存したログデータをHiveを
どーも、れもんです。みなさんNorikra使ってますか? えっ使ってない? まぁストリーム集計処理っていうのがなかなか使いどころ難しいですものねー。よっぽど速報値が必要な場面じゃないと出番がないし、ぼくもインストールしたけどほぼ使ってないという今日この頃です。 ということで! 今回はNorikraを使うとっかかりとして、最近リリースしたサービスのユニークユーザ数をリアルタイムに出したいなぁというお題をNorikraでやってみることにしました。 もともとそのサービスではネイティブアプリにGoogle Analytics SDKが入っててそれを使えば直近5分のリアルタイムユニークユーザ数は見えているのですが、サーバ側でもそれを計測したいということで、そこをNorikraでやってみることにしました。 理由は、よく出来たアプリだと幾つか画面を遷移していても通信しなくてよいように作られていて、クライ
Fluentdの公式ドキュメントにloggingのページがあるんですが，まだ英語しかなく，運用の話を聞いてるとここに書いてあることで解決出来るケースがいくつかあったので，とりあえず日本語で記事にしておきます． プラグイン毎のログレベル 昔のFluentdはグローバルに一つしかログレベルを設定出来なかったんですが，今ならプラグイン毎に設定出来ます．プラグインが対応している必要がありますが，まぁ今時のプラグインや広くつかわれているやつはほとんど対応していると思います． in_tailプラグインはログにマッチしない行があったらwarnでメッセージを出しますが，そういうbrokenな行があることが分かっていてログを出さずに無視して欲しい，というような場合に有効です． その他にも，あるプラグインだけデバッグモードで走らせたい，みたいなことが出来るようになります． ログのスタックトレースの抑制 Flu
2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、
Fluentdにおけるネットワークごしデータ転送プラグインといえば forward が組み込みであるし、通信路を暗号化したければ secure-forward がある。 しかしこれらFluentdのネットワーク転送プラグインは基本的に全て送信元から送信先に対してプッシュする形になっており、ネットワーク接続も送信元から送信先に対して行うことになっている。このため送信先のFluentdがNAT下にある場合やファイアウォールで保護された場所にある場合、もしくはダイヤルアップ接続……は、まあ今は無いだろうけど、例えば移動するデバイス上にある場合など、こういったときにはうまくデータの転送を行う構成がとれない。 なぜこういう状況、つまりプッシュ型で転送を行うプラグインばかりなのかというと、FluentdのBuffer pluginの仕組みによる。細かく設計上の話をあれこれしてもアレだし面倒くさいので省
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
