事業サービス会社の開発部門での出来事

前回からのつづきです。

刺激が欲しくてCodeIQという転職サイトを使って、いわゆるWeb屋DMM.comラボに転職しました。

https://dmm-corp.com/company/labo/dmm-corp.com

が、今にして思うとWeb屋とはちょっと違ったかもしれないです。 結構大きな組織で、無数のサービスを保守、開発しているので、配属部署に寄りますね。

はじめの1年は、DMM.makeのサービスの保守、新規開発を行っていました。

つぎの1年は、DMM.makeの中でもロボット事業というアグレッシブな領域で、ロボットの代理店商売の舞台裏でエンジニアリングしていました。

さいごの半年は、DMM.makeの主要サービスをオンプレミスからクラウド（AWS）へ移行していたら終わっていました。

Mackerel Day で少ししゃべった話です。

中小SI企業での出来事

前回からつづきます。

かなりユニークな経歴をへて、株式会社ネッツというIT企業に就職しました。

www.nets-web.co.jp

勉強会なりでしゃべるときの自己紹介では、名前を出さずにSI孫請け（直請けもしていましたが）と表現することが多いです。

そういった場所ではSI業界の会社は大手でもそれほど名前が通っていない（多分自分も上場企業ですら分からないです）ですから、大体こういうところで仕事していました、といったニュアンスです。

7年ほど勤めました。

エンジニア定年に思うこと

本日、IT業界で俗にエンジニア定年と言われている35歳になりました。

結構なオッサンになったものです。

さて、定年を迎えてみて感じるのは、全然定年じゃないなぁ、という実感です。

自分は自分を中の上のエンジニアと位置付けているのですが、その辺も交えてエンジニア定年についてそれを迎えた時点で所感をメモしておきたいと思います。

就職までの出来事

自分は、非常にユニークな人間だと思います。

これは、文字通り一意であるという意味で、同じような履歴（書）を持っているエンジニアはおそらくこの世に居ないでしょう。

丁度エンジニア定年を迎え、そろそろ半生という時期になって、あんまりポジティブではない履歴も自分の中ではある程度笑って思い出せるようになってきたので、軽くでもたな卸ししておこうと思う次第です。

とはいえ、全然書けないこともあるわけですが。

Metrin と mkr コマンドでCloudWatchのメトリックをMackerelのサービスメトリックとして投げる

RDS Aurora にはインスタンス毎の情報のほかに、クラスタ毎に割り当てられているストレージボリュームに関する情報がある。

これは、現在のMackerelのAWSインテグレーションでは収集されない。 （2017/10/13現在、多分）

が、収集しておきたい情報なのでサービスメトリックとして投稿したい。

が、CloudWatchのAPI結果の整形だとか、Lambdaとか、よく知らない&面倒くさい。

と、Google検索をさまよっていたら Metrin という素晴らしいツールを作ってらっしゃる方がいらっしゃったので使わせていただいた。

Metrinとmkrが動作するように設定されている環境ならこれだけで飛んでいく、素晴らしい汎用性に感動した。

metrin \
  --region ap-northeast-1 \
  --namespace AWS/RDS \
  --metric-name VolumeBytesUsed \
  --dimension DbClusterIdentifier:$clustername \
  --dimension EngineName:aurora \
  --statistic Maximum \
  --start-time -3600 \
  print --last-value-only \
  | mkr throw -s $servicename

# DbClusterIdentifier+EngineName:auroraのメトリックには以下があるようだ
# - VolumeBytesUsed
# - VolumeReadIOPs
# - VolumeWriteIOPs

こちらのQiita記事で知った。

qiita.com

リポジトリやバイナリの配布はGitHub。

github.com

Mackerel Day #mackerelio

本日開催されたMackerel Dayで社内で「アプリケーションエンジニアがMackerelで楽しく監視構成している事例」（長い）を少ししゃべってきました。

mackerelio.connpass.com

発表時のスライドはどこに上げるのか？　など社内で確認することを完全に忘れていたので公開していないのですが、なるべく早めに共有したいと思っています。

この記事では小並感を垂れ流します。

追記：公開しました。

アプリケーションエンジニアがMackerelで楽しく監視構成している事例 from Keiko Nishioka

www.slideshare.net

PHPからMackerelにサービスメトリックを投げる

細かいことはいいから proc_open で mkr コマンドを使えばいいんじゃないかな。

投げる = mkrコマンドでサービスメトリックを投げるときのコマンドが throw

<?php
$time = time();
$metoric = <<<_EOT_
metoric-name-1 {$value1} {$time}
metoric-name-2 {$value1} {$time}

_EOT_;

// http://php.net/manual/ja/function.proc-open.php
$cmd = 'mkr throw -s service-name ';

$descriptorspec = array(
    0 => array("pipe", "r"),
    1 => array("pipe", "w"),
);

$process = proc_open($cmd, $descriptorspec, $pipes);

if (is_resource($process)) {
    fwrite($pipes[0], $metoric);
    fclose($pipes[0]);

    $output = stream_get_contents($pipes[1]);
    fclose($pipes[1]);

    $return_value = proc_close($process);
    // XXX コマンドの成否？　眠いから今度 return value を見るよ
    //Log::info('mkr throw result...'.$output);
} else {
    //Log::error('can not open process.');
}

mackerel-agent もいれば batch の実行ユーザは root だし、余裕だったぜ。

※ヤンキーな実装は自己責任でお願いします。

追記

極秘情報によると、PHPクライアントは誕生間近とのことです！

github.com

時間と心の余裕があったらやりたいAPIをPRしたいという思いはある。

追記２

超極秘情報によると、その誕生間近のクライアントでのサービスメトリック投稿の事例もあるようです！！

github.com

俺は寝たい（AM1:40）

追記３

私はmkrコマンドを無理やりたたけば、API_KEYのことを考えなくてよいという利点があることにに気が付いた。

（AM1:46）