erlangでfluentdクライアントのOTPアプリケーションを実装した - 備忘録、はじめました。
はじめに アプリケーションにログ、データを集めたりするのにしばしば利用される Fluentd というソフトウェアのクライアントをErlang/OTPで実装した話です。 本家のerlangのfluentdのクライアント の実装を眺めていて、 gen_eventで実装されていたため、過負荷や障害時などを考慮したい場合はひと工夫を入れる必要がありそうと思い、 今回本家と異なるビヘイビアで実装してみました。 何故gen_event使わなかったのか？ 結論から言うと、別システムにデータを送信するようなケースでのgen_eventの利用は避けたかったからです。 何故避けたのかという説明をするために、簡単にgen_eventの話をします。 gen_eventは一つのイベントマネージャーと0個以上のイベントハンドラーで構成され、 マネージャーにメッセージを送信する(notify, sync_notify関
fluent-logger-elixirのはなし - Qiita
# イベントマネージャを作成 iex(1)> :gen_event.start {:local, :your_logger} {:ok, #PID<0.65.0>} # ハンドラを追加、hostとportは省略可 iex(2)> Fluent.add(:your_logger, "myapp", host: "localhost", port: 24224) :ok # メッセージをポスト iex(3)> Fluent.post(:your_logger, "access", [status: 200, agent: "foo"]) :ok # 2013-12-01 21:42:52 +0900 myapp.access: {"status":200,"agent":"foo"}
LogZoom, a fast and lightweight substitute for Logstash
Today, we at PacketZoom are proud to release our open source tool LogZoom, a fast, lightweight, and reliable log data indexer written in Go. If you've ever considered using Logstash, Fluentd, or some other tool for log aggregation, you may want to consider using LogZoom instead. Here are a number of resources for getting up and running with LogZoom: Home page Binary release for Ubuntu 14.04 Exampl
fluentdとシステム設計の小ネタ - たごもりすメモ
あるいは http://yugui.jp/articles/879 へのreply。 システム監視をfluentdに統合してしまうべきか否か システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。 それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。 Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく
fluentdを勉強中 - 世界線航跡蔵
最近はlog collectionというと fluentd が話題らしいというので、少し触り始めている。 多少は分かってきたように思うので理解したことと、理解できていないところをまとめてみようと思う。 fluentdとは何か オフィシャルサイトには"tool to collect events and log"と書いてある。 要するに、サーバー群から継続的に情報を吸い上げるための仕組みを提供するdaemonである。 この「情報をかき集める」という枠組みは今時のサーバーサイドでは頻出パターンだ。 データベースサーバ、アプリケーションサーバー、フロントエンドキャッシュサーバー, ...と役割分担をするのが普通だし、 アプリケーションサーバーだって負荷分散のために複数インスタンスを持つのが当たり前だ。 そしてこれらサーバー群をきちんと管理するためには様々な情報をかき集めてきて一カ所に保存したり集
OSSとしてのEmbulkにTreasure Dataはどのように関わっているのか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? OSSとしてのEmbulkにTreasure Dataはどのように関わっているのか Embulk Advent Calendar 2015の1日目の投稿になります。 今年の9月にSoftware EngineerとしてTreasure Data(以下TD)に入社していた赤間(@oreradio)です。 最近はData Connector(後述)などの開発でJava/Rubyを書いています。 さて、OSSのバルクロードツールであるEmbulkが公開されて約1年が経ちました。 並列・分散処理、リトライ、リジューム等をサポートする プラガブル
Boost.Logとfluentdで始めるログ活用術
コンテナを突き破れ！！ ～コンテナセキュリティ入門基礎の基礎～（Kubernetes Novice Tokyo #11 発表資料）
DMMゲームのログ解析~ログ収集と解析の概要~ - DMM.comラボエンジニアブログ
現在オンラインゲームのバックエンド、KPIシステムを担当していますマサヨシです。 今回のブログでは【DMMオンラインゲームで実際に実装しているログとKPI】に関して3回にわたってご紹介致します。 DMMオンラインゲームでは、これまではオンラインゲームのプロジェクトごとに行っていたログの収集方法を統一し、プロジェクトに依存しない基本KPI機能とゲーム独自のKPI機能を実装するためのフレームワークを開発しましたのでその事例をもとにご紹介します。 ログ収集、解析の概要 まず、オンラインゲームのログ収集の全体像をご紹介します。 オンラインゲームのログ収集ではApacheやnginx、PHPのログをfluentdで収集しています。 fluentdに集めたログをHadoopの分散処理システムに保存し、HiveやImpalaで解析をする流れになっています。 ご存知の方も多いと思いますが、HiveとはHD
株式会社ミクシィを退職しました。そして・・・ - ○○おねえさんのつぶやき
数日前にどなたかがポストなさった退職 Advent Calendarに、私も16日目のエントリとして勝手に参加させて頂いています、鈴木理恵子です（笑）。 ここ1ヶ月ほどフィリピンのセブ島に滞在したりシリコンバレー巡りをしていたので感づいた方もいらっしゃると思いますが、昨日、2013/12/15をもって株式会社ミクシィを退職しました。 2010/12/16に入社をしたので、ぴったりちょうど3年間ミクシィに在籍していました。 ミクシィで担当したこと この3年間は一貫してプラットフォーム開発に携わっていました。 mixiはアプリプロバイダー様や個人ディベロッパ様向けにアプリプラットフォームを提供しています。そしてmixi内にあるリソースを利用したソーシャルなアプリやゲームでユーザー様に楽しんで頂いています。 私はこのアプリプラットフォームを開発・管理を担当する部署に所属していました。 具体的には
おねえさんが、センサー + Raspberry Pi + fluentd + Treasure Data + αで自宅の揺れを検知＆分析してみるよ① - ○○おねえさんのつぶやき
タイトル通り、センサー + Raspberry Pi + fluentd + Treasure Data + 様々なプロダクトを組み合わせて、自宅が揺れる原因を分析してみるお話です♪ 長丁場になりそうなので、これから数回に分けて綴っていこうと思います。 第1回の今回は、揺れ分析をはじめた理由、やりたいこと、システム構成についてお話します。 はじめた理由 実は・・自宅マンション周辺の大規模工事が終わった頃から、毎日ふとした時に自宅が揺れています！ 震度１～２くらいかな？と思ってYahoo!の地震情報を確認してみるのですが、地震は起きていません。 天井から吊してあるパネルも揺れるので、気のせいではないはずなのに。。 管理会社に問い合わせてみましたが、「よくわからないですねー」と素っ気ない返事しか返ってきません。 むむむっ、結構重要な問題だと思うんだけどー＞＜。 揺れの原因によっては引っ越しも考
Norikra+FluentdでDoS攻撃をブロックする仕組みを作ってみた ｜ Developers.IO
Norikraとは Norikraとはリアルタイム集計プロダクトです。イベントストリームに対してSQLライクな言語で処理を書くことが出来ます。 例えば、ApacheのアクセスログをNorikraに流し込み、1分あたりのアクセス数やレスポンスタイムの最大値をリアルタイムに集計することが出来ます。 Norikraの利用例は作者であるtagomorisさんのブログで紹介があります。 今回は、Norikraを使ってDoS攻撃をブロックする仕組みを作ってみました。 DoS攻撃ブロックの仕組み アクセス元はApacheのアクセスログから取得し、ログの受け渡しにはFluentdを利用しました。 ブロックの手順は以下のようになります。 アクセスログをFluentdのin_tailプラグインで取得。 Fluentdのout_norikraプラグインで、アクセスログをNorikraに流し込み。 Norikra
Fluentdが流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
たごもりすメモ
TL;DR 「例のランキング」と言われるようになってしまったエンジニアが選ぶ"開発者体験が良い"イメージのある企業ランキングですが、これをどう解釈すればいいか、企業側、採用側としてどう考えればいいかについて、自分なりの意見があるけどXの話とかであまり見ないので書いてみようと思った。 開発者体験とは、本質として「開発者個人の期待と現実のギャップ」である しかし開発者個人の期待というものは人によって千差万別だから、 "開発者体験が良い" は人によって求めるものが違いすぎているし、外部の人が評価できるものでもない ただし 「"開発者体験が良さそう"というイメージ」については、期待と現実のギャップをコントロールできているように外部に見えている、という指標として有用かもしれない Disclosure 筆者はさくらインターネット株式会社で勤務しており、かつ、採用関連の活動にはこの1年弱のあいだ、それな
#fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場
前に自分で書いた fluentdのためのプラグインをイチから書く手順 - tagomorisのメモ置き場 はたいへん重宝していたのだが、書いたすこし後になって実は現在すでに bundle gem コマンドを使うやりかたが良さそうだということがわかってしまったがばたばたしてて移行してなかった。 で、またひとつプラグインを書くことにしたのでついでに bundle を使った手順をざっくりまとめておく。以下のエントリをたいへん参考にさせてもらった。 T-POINTを取得するスクリプトをGistから移動, Bundlerを使ったGem作成メモ (自分用) - ただのにっき(2012-02-18) 準備とディレクトリツリーの作成 bundler は必要なので、なにはなくとも入れておこう。 gem install bundler そしてプラグイン用ディレクトリツリーを作成する。今回は DataCount
[Smalltalk] Nagareリリースしました
RSSRSS - 投稿RSS - コメント Planet Smalltalkエラーが発生しました。フィードがダウンしているようです。あとでもう一度やり直してみてください。 https://bsky.app/profile/mumez.bsky.social Nagareという新たなログ用ライブラリを作成しました。 http://code.google.com/p/nagare-logger/ すでにSmalltalk界ではいろいとなロガーがありますが、Nagareはfluentdを前提にするというところが特徴です。 これによって Nagare本体のAPIをシンプルに保つ ログのローテイト、ログの出力先などはfluentdまかせ 構造化したデータのロギングをサポート JSONをロギングできるfluentdの機能を享受 といった利点を得ています。 現在のところSqueak, Pharo, Vi
![[Smalltalk] Nagareリリースしました](https://cdn-ak-scissors.b.st-hatena.com/image/square/8d71ff5111e05619a10d29bb40d7aebaa75c8fbc/height=288;version=1;width=512/https%3A%2F%2Fs0.wp.com%2Fi%2Fblank.jpg)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Search
ビッグデータの収集基盤「Fluentd」と「Embulk」のサポートサービス、NTTデータが提供
fluentdでつくる監視系 - Qiita
GitHub - termoshtt/boost_log_sample: Sample codes for Boost.Log
usefulstuff.io