monolog

monora log #=> ものろーぐ

Programming カテゴリのアーカイブ

Zabbix で収集したデータを Datadog へ投げる

Infrastructure Programming

こんにちは。これを書いているのは JST 4:30 ですが、最近は JST+0900で生きているので、昼間です。そろそろ夕方でしょうか。
最近の仕事の成果は Zabbix に投げ込む XML をエイヤで自動生成するような何か、もしくは SQL を生成する何かです。

成果物は kyontan/datadog-zabbix-history です。

長い前置き

ところで皆様は Datadog を使われていますでしょうか?
インフラ監視系の SaaS やソフトウェアというと、今挙げた Datadog を始め, Mackerel や Zabbix, Nagios, AWS Cloudwatch 等々、現状では様々なプロダクトが存在しています。最近だと Datadog や Prometheus の名前をよく見かける気がします。

そんな中最近、自分のバイト先では使われているのが Datadog です。サーバの監視なんかだと、 Integration の種類も多く、デフォルトで様々なメトリックが取れることや、ダッシュボードの見やすさなどがイケているかなと。
特に SaaS だと、バッファリングがあるにしてもメトリクスの抜け落ちや一時アクセスできなくなる問題などはあり、クリティカルなものを全部載せるわけにもいかず、ただ SaaS の恩恵は受けたいというのが正直なところでしょう。
(mackerel-agent のログを眺めているとたまに何故か 404 が返ってきていて笑います)

ただ、設定が複雑化したり、そもそも設定数が多くて移行がダルいというのが正直なところです。エイヤでやる体力があれば良いですが、ホスト数が増え、監視項目が万の単位であるとそれはそれは……

おそらく皆さんは Zabbix のアイテムやらなんやらを XML で書き出してごにょごにょしたり、それを Prometheus の設定にいい感じに変換する何かを書いたりされているかと存じます。そしてそんなコードは短いから/特定のドメインに特化しているからと公開せず、誰もが誰かは書いているだろうと思いながら書いていることでしょう。そうですよね?

今回ご紹介するのはそんなあるあるプロダクトです。やることは記事のタイトルに書いてありますね。

read more »

Permalink |

総資産を Dr.Wallet から Slack へポストするようにした

Programming

こんにちは。JST+11で生きているので昼です。
ところで最近は世界から10年遅れて Rails に入門したり、それとは関係なく Sinatra のアプリケーションに
RSpec を書いてテストの重要性を感じながら七夕に笹の葉ラプソディを見たりしています。10年前って単語がよく聞かれる今日このごろです。

皆さんはおそらく何らかのチームでのコミュニケーションに Slack を使っていて、総資産を Dr.Wallet で管理されていて (ここで読者の8割が脱落)、その総資産を逐次仲間に共有したいですよね! (残存者0)

で、やっぱり皆さんも共有したいでしょう、というわけで作りました。

read more »

Permalink |

SECCON 2016 Online CTF に参加しました (Write-up)

Programming

なんか直前に参加しない? と誘われたので今年もYouTube問題担当として参加しました。Team MMA で 700 Points, Rank: 107 (国内: 27) だったっぽいです。(暫定?)
あと500 Points で国内予選でしたね。先は長い

MMA は大学のサークルですが、前回のチーム overflow +αみたいな感じでした。主要メンバーが運営にいるし、新たに入ってきた後輩はなぜか別チームでやっていたので、謎です。

僕は VoIP (Forensics 100), Memory Analysis(Forensics 100), PNG over Telegraph (Crypto 300) を解きました。とりあえずメモです。

read more »

Permalink |

shotgun じゃなくて rerun を使おうという話

Programming

Ruby で Rack アプリケーションを書いているときに、コード変更したら自動的にサーバー再起動したいという話。

今までは shotgun でやっていたのだけれど、これは毎回リクエストする度に変更の有無に関係なくサーバーを立ち上げ直すので、遅いという欠点があった。
副次的な問題として、better_errors で REPL が無効になるという欠点があった。(レスポンスを返すとそのコンテキストを捨ててしまうから?)

ずっと前からどうにかならないかなーと思っていたのでググったら rerun というものを見つけた。
Rack とか関係なくもっと汎用的なやつで、ファイル変更検知してサーバー上げ直すぞ! みたいなプロダクトらしい。

入れたら下のような感じで使える。便利。

RACK_ENV=development rerun -- rackup -o 127.0.0.1

調子に乗って通知有効化するぞ! というノリで terminal-notifier を入れてみたらサーバーが上がらなくなった。何事かと思ったら tmux 上で使おうとすると一癖あるらしく、こういうIssue が立っていたので適当に読んだら解決した。

要するに、brew なりなんなりで、reattach-to-user-namespace をインストールして、.tmux.conf に下を書き加えるという話。

set -g default-command "which reattach-to-user-namespace > /dev/null && reattach-to-user-namespace -l $SHELL || $SHELL -l"

再起動に掛かる時間が体感で倍ぐらいになったけれど、better_errors使えることで圧倒的効率アップみたいなところがあるので、トータルで幸福度が向上した気がする。

Permalink |

Sinatra Modular-Application で configure が上書きされる問題の対処

Programming

Ruby の Siantra で、Modular-Application を書いていたら良く分からない挙動にぶち当たって気が付いたら朝になっていたのでメモ。

app.rb

require_relative "hoge"

class App < Sinatra::Base
  configure do
    disable :protection
  end

  use HogeRoutes
end

hoge.rb

class HogeRoutes < Sinatra::Base
  get "/" do
     ...
  end
end

みたいな事をしていた。
disable :protection をしているのにどうしても Rack::Protection が有効になるので、どうしてこうなるんだとあちこちのコードを追いかけたりした結果、HogeRoutes が App とは別にもう一度 session, protections 等のセットアップが行われるので、以下のように、 use HogeRoutes を configure より上に持ってくる必要があった。

app.rb

require_relative "hoge"

class App < Sinatra::Base
  use HogeRoutes

  configure do
    disable :protection
  end
end

HogeRoutes 内の configure で disable :protection とやってもいいが、こうするとクラスが増えた際にその分だけ書かないといけなくて大変。セッションみたいなアプリケーション全体で統一的な設定を持つ部分は親の App でやって良いんじゃないかと思う。

Permalink |

« 前ページへ 次ページへ »

« 前ページへ 次ページへ »