さくらのクラウド「シンプル監視」の有料・無料判定の実装について

# 企画の人って、時にさらりと難しいこと言うんですよねｗ

監視対象がさくらのIPなら無料にしたいとか。気持ちはわかるけどｗ

あ、去年11月くらいから思いつきで作り始めた監視機能が、先日無事にリリースされました。

[さくらのクラウドニュース：「シンプル監視」提供開始のお知らせ](http://cloud-news.sakura.ad.jp/2016/01/14/simplemonitor-release/)

※ 開発やリリース準備に携わった皆さま、お疲れ様でした m(__)m

# 「シンプル監視」これは何か？

いわゆる**「外形監視」**に特化した監視機能になっていて、pingやhttpなどのパラメータを登録するだけで、異常を検知した時にメールやSlackで通知されます。

![simple-watch2b.png](https://qiita-image-store.s3.amazonaws.com/0/108990/aab27c16-a5ab-d64d-b0de-b911186c3707.png)


**「Slack対応」と言うだけでちょっとナウイ感じがするんで、実装がんばりました。**

監視先が弊社のIPアドレスの場合、無料でご利用できますので、**是非ともバリバリ監視しちゃってください！**

実はこれ、中身は**nagiosそのもの**で、お客様がコンパネで設定された監視パラメータを集約して、nagiosのconfigに落としこんでるだけなんですね。

**たったそんだけ**なのに、結構な反響をいただいて嬉しい限りではありますｗ

# 監視対象が無料になる「さくらのIP」って何？

以前バックボーン運用してたんで、自社で運用しているIPアドレスもいろんな種類があるの分かってました。

自社のPA(Provider-aggregatable)は当然対象とするにしても、固定系ローミングのアドレスどうするか？お客さん持ち込みのアドレスどうするか？など、判定基準を個々に設けたい希望はありました。

一方、最近では、[IPアドレス移転の制度で流入出が激しく](https://www.nic.ad.jp/ja/ip/transfer/ipv4-log.html)、IPアドレスブロックをちまちま管理できないという事情もありました。

で、悩んだあげく、落とし所として**「自社ASからインターネットに広告している経路に含まれているアドレス」**を対象とすることにしました。

※ AS = Autonomous Systemの略。インターネットの経路交換プロトコルBGPにおける組織識別単位。

# Looking Glassを参照するかIRRを参照するか？

Looking Glassとは、バックボーンで今受信しているBGPの経路情報をWebインターフェイスなどで公開しているサイトのことです。

弊社もコチラでLooking Glassを公開しています → http://bgp4.jp/

実態に則すならば、BGPの経路をリアルタイムに反映したLooking Glassがよさそうでしたが、可用性、安定性、継続性の観点から若干不安があり、IRRを参照することにしました。

IRR(Internet Routing Registory)とは、インターネット全体(もしくは一部)の経路情報が登録されているデータベースで世界的に参照されるものです。[詳しくはこちら](https://www.nic.ad.jp/ja/newsletter/No27/100.html)

インターネット黎明期から存在する[RADB](http://www.radb.net/)や、日本国内ではJPNICさんが運用されている[JPIRR](https://www.nic.ad.jp/ja/ip/irr/index.html)がメジャーどころです。**この2つを参照しておけば間違いないです(キリ)。**

検索はwhoisコマンドを用いて以下のように行います。

```
$ whois -h jpirr.nic.ad.jp 61.211.224.2
[Querying jpirr.nic.ad.jp]
[jpirr.nic.ad.jp]
route:      61.211.224.0/20
descr:      SAKURA-B (4/TOKYO)
            SAKURA Internet // EAST JAPAN BACKBONE
            1-8-15 Kyutaro-cho, Chuo
            Osaka 541-0056, Japan
origin:     AS9370
remarks:    SAKURA-CIDR-4
notify:     peer@sakura.ad.jp
mnt-by:     MAINT-AS7684
changed:    peer@sakura.ad.jp 20150801
source:     JPIRR
```

このoriginフィールドが広報元ASを表しています。弊社の場合、

- 東京 AS9370
- 大阪 AS9371
- 石狩 AS7684

の3つのASを運用していますので、これにマッチするものを自社のIPアドレスとみなすことにします。

# 実際の判定ルーチン

まずJPIRRを参照し、検索に失敗した場合やデータが存在しない場合のみRADBを参照します。
実際のコードは以下のような感じになりました。古い人間なんでいつもperlで書いてますorz

```perl
sub is_sakura_ipaddr {
    my ($addr) = @_;

    my @irrs = ('jpirr.nic.ad.jp', 'whois.radb.net');
    my @myas = (9370, 9371, 7684);

    die "whois command not found" unless (-x '/usr/bin/whois');

    foreach $irr (@irrs) {
        my $is_myas = 0;
        my $got_origin = 0;

        my $cmd = "/usr/bin/whois -h $irr $addr";

        open(WHOIS, "$cmd |") or die "can't open $cmd";
        while(<WHOIS>) {
            chomp;
            if (/^origin:\s+AS(\d+)/) {
                $got_origin = 1;
                if (grep($1 eq $_, @myas)) {
                    $is_myas = 1;
                }
            }
        }
        close(WHOIS);

        return $is_myas if ($got_origin);
    }

    # Origin ASがない場合はBad Requestとする
    &bad_request_exit("監視対象のIPアドレス($addr)が不正です");
}
```

# ところで

外形監視ではなく、**メトリックベースの監視**は、[はてなさんのMackerel（マカレル）](https://mackerel.io/ja/)がめちゃくちゃ良くできています。同じもの作ってもかなわないなーと思ったんでそっちには手を出さず、うまく棲み分けしてみた感じですｗ