鎌倉goでもくもくと

2015/03/01 15:02

※ 商品のリンクをクリックして何かを購入すると私に少額の報酬が入ることがあります【広告表示】

鎌倉でgoの勉強会 があるというので、お邪魔してきました。

今回はもくもく会でした。会場と飲み物や食べ物を IICHI さんが用意してくれました(さらにtypesterさんが昼間っから一杯ひっかけつつピザを入手してきてくれた)。

もくもく会

goのAWS SDKを最近目にしていたので、CloudWatchのカスタムメトリクスをgoで投げてみようというのが目的です。

たいてい名前を考えているうちに数日経ってしまうので、参加を決めた後事前に少し準備をしてから邪魔しました。気持ちの良い土曜の午後に集中してもくもくできて非常に良かったです。

Erulolo https://github.com/tsuyukimakoto/erulolo

結果

時間内に目標は達しました。カテゴリも名前もカスタムなものができました。

カスタムメトリクス

過程

前置き

CloudWatchはVMの状態は取れますが、OSの状態は取れません。簡単に言えば、インスタンスに割り当てているCPUをどれだけ利用しているかは取れますが、インスタンス上のOSが割り当てられたディスクのうちどれだけ使っているかやロードアベレージがどのくらいになっているかといった情報は標準では取れません。

当然、インスタンスで実行するとよく使う統計情報をCloudWatchに登録するツール群は用意されていますので、それでまかなえるものは改めて作る必要はありません。…本来は。

監視するもの

  • 特定ファイルパス以下のファイルの状態変更数

    システムのファイルをインデックスして、定期的に変更がないかスキャンする仕組みがよく用いられていると思います。頻度によってはシステムの負荷がかかったりしそうなのと、backblazeのアプリが変更になかなか気づかないという経験から、inotifyでディレクトリを監視してみようと思い、inotifyを使ってみました。

    残念な参考
    
      $ cat /proc/sys/fs/inotify/max_user_watches
  • ディスクの利用状況

    ままですね。

いずれも結局システムコールを利用します。特に inotify を利用する golang.org/x/exp/inotify はエクスペリメンタルな状態に加え、linuxでしか動作しないため、go自体をよくわかっていない状態ではOSXでビルドできませんでした。go getで持ってきてくれないし。結局VMWare Fusion上のUbuntuでビルドしました。

他にもロードアベレージ等基本的な監視項目を追加していこうと考えています。

仕組み

EC2 のインスタンスから CloudWatch にデータを投げるだけですので、IAM の Role を EC2 インスタンスに割り当てて権限を付与します。 ユーザを作って接続時に Access Key や Secret Access Key を渡す(ないしは環境変数に設定しておく)より簡単でかつデプロイスクリプトにセキュアな情報も登場しないので良いです。

cloudwatch:PutMetricData 権限だけ Allow して policy を作り、その policy を割り当てた Role を作れば、あとはインスタンスの起動時にRoleをセットするだけです。接続時にはからのクレデンシャルをセットしておけば問題なくデータを投げられます。

ファイルの変更監視のところ

最初、無限ループの作法が分からず、単純にforの中で time.Sleep をしてみましたが、CPUを10%以上持っていってしまいました。

inotifyはディレクトリを監視下に置くようですが、手元のubuntuでユーザの最大監視数を確認してみたら 8192 でした。現実的なのか否か…。

作成・変更後クローズ・削除、を監視対象にし、変更があった時点でカウントアップをしておき、一定時間に1度データを投げてカウントをリセットしておくという愚直な感じで書いています。ディレクトリが作られたら監視対象に追加するとか細かいところはまだです。

設定ファイル

ググったらTOMLというのが良いというブログが出てきたので鵜呑みにしてみました。

以下のような感じで設定ファイルが書けました(難しかった)。

config.toml

  [buoy]
  targets = ["/home/makoto", "/tmp"]
  ignoreExtensions = [".swp", ".swpx", ".LOCK"]
  ignoreDotDirectory = true

ファイル構成

こういうフィアル構成にする良いよん、というのがあるのだけれど、なんというかホント?という感じがあります。

以下のURL自体がパッケージになって、その下に .go のスクリプトファイルがあると良いようなのだけれど、裸でスクリプトファイルが置いてある感じあってすごくむずむずしています。

置く場所 https://github.com/tsuyukimakoto/erulolo

パッケージ github.com/tsuyukimakoto/erulolo

プロジェクトのツリーは以下のような感じになって、config.tomlがVCSの管理対象になってないのが現状。はて?

  .
  ├── README.txt
  ├── bin
  │   └── erulolo
  ├── config.tml
  ├── doc
  │   └── design.graffle
  ├── pkg
  └── src
       ├── github.com
       │   ├── BurntSushi
       │   │   └── toml
       │   ├── awslabs
       │   │   └── aws-sdk-go
       │   ├── tsuyukimakoto
       │   │   └── erulolo ← この中でgit initする
       │   │       ├── LICENSE
       │   │       ├── README.md
       │   │       ├── buoy.go
       │   │       ├── erulolo.go
       │   │       └── swellwatch.go
       │   └── vaughan0
       │       └── go-ini
       └── golang.org
           └── x
               └── exp
                   ├── inotify

鎌倉は夜が早く、お酒を出す食べ物屋さんも21時ころには閉まってしまうので、1軒目はお魚料理の尾崎にて日本酒をいただきつつ刺身やブリカマを、2軒目はブルールームにてクラフトビールをいただきつつピザを。

反省

ingressの話ばかりしてしまってごめんなさい。

ピントが合わない合わないとうるさくてごめんなさい。

ブリカマ ピントが合わない

Prev Entry

Next Entry