CentOS に ansible で mackerel-agent を雑にインストールする

先日 Raspberry Pi 2 に mackerel-agent をインストールしたので、ついでに CentOS 環境にもインストールした。

kheiakiyama.hateblo.jp

mackerel.io


CentOS

以下、プレイブック

---
- name: install mackerel-agent repo
  shell: |
    curl -fsSL https://mackerel.io/assets/files/scripts/setup-yum.sh | sh
  args:
    creates: /etc/mackerel-agent/mackerel-agent.conf

- name: install mackerel-agent
  yum: name=mackerel-agent state=latest

- name: mackerel-agent conf
  lineinfile: 
    dest=/etc/mackerel-agent/mackerel-agent.conf
    line='{{ item.line }}'
    regexp='{{ item.regexp }}'
  with_items:
    - { line: 'apikey="{{ mackerel_apikey }}"', regexp: '^apikey="{{ mackerel_apikey }}"' }
  notify: restart mackerel-agent

mackerel-agent の yum リポジトリの登録を /etc/mackerel-agent/mackerel-agent.conf でチェックするというのはいささか雑だが、雑にインストールする と断りを入れているのでよしとした。

Ansible徹底入門 クラウド時代の新しい構成管理の実現

Ansible徹底入門 クラウド時代の新しい構成管理の実現

RaspberryPi2 のセンサーで取得したメトリクスを Mackerel に出力する ansible プレイブック

はじめに

1月から東京に移住したが、実家においてきた RaspberryPi2 のメトリクスを見る手段がなかった。
メトリクスは RaspberryPi 内にしか蓄積しておらず、アラートだけ Slack & LINE で送っていた。

過去にやったことは以下の記事。


今回は東京からメトリクスを見れるようにするための取り組み。

最近 Mackerel Meetup #10 に参加した縁もあるので、Mackerel 使ってみましたよ、というだけの話。


実装

RaspberryPi2 いじるのは年に数回なので、構成を後から追えるようにするために、最初からではないのだが ansible でデプロイできるようにしている。
なので、以下プレイブックベースで書く。

ベースの処理

ここでは温度・湿度の記録部分しか書かないが、実際は見守りカメラの反応の有無も録っているため、 yml を分けてある。
role でディレクトリ管理してなくて雑な運用。

main.yml

- hosts: pi
  sudo: yes
  vars:
    colon: ':'
  tasks:
    - include: tasks/base.yml
    - include: tasks/temperature.yml
  handlers:
    - name: restart mackerel-agent
      service: name=mackerel-agent state=restarted

hosts

[pi]
xxx.xxx.xxx.xxx

[pi:vars]
ansible_connection=paramiko
ansible_ssh_user=pi
ansible_ssh_pass=xxxxxxx
ansible_sudo_pass=xxxxxxx
mackerel_apikey=xxxxxxxx

mackerel-agent のインストール

RaspberryPi2 では ARM 版のバイナリが必要なため、インストールした後にバイナリを上書きしている。
API Key も流し込む

tasks/base.yml

- name: install mackerel-agent
  shell: |
    curl -O https://mackerel.io/file/agent/deb/mackerel-agent_latest.all.deb
    dpkg -i mackerel-agent_latest.all.deb
    curl -LOk https://github.com/mackerelio/mackerel-agent/releases/download/v0.42.3/mackerel-agent_linux_arm.tar.gz
    tar zxf mackerel-agent_linux_arm.tar.gz
    cp mackerel-agent_linux_arm/mackerel-agent /usr/bin
  args:
    creates: /etc/mackerel-agent/mackerel-agent.conf

- name: mackerel-agent conf
  lineinfile: 
    dest=/etc/mackerel-agent/mackerel-agent.conf
    line='{{ item.line }}'
    regexp='{{ item.regexp }}'
  with_items:
    - { line: 'apikey="{{ mackerel_apikey }}"', regexp: '^apikey="{{ mackerel_apikey }}"' }
  notify: restart mackerel-agent

温度・湿度のメトリクス取得

公式ドキュメントを読めばわかるとおり、mackerel-agent.conf にコマンドを書いて、コマンド内でメトリクスを標準出力に出せば完了。

ホストのカスタムメトリックを投稿する - Mackerel ヘルプ

tasks/temperature.yml

- name: mackerel temperature plugin
  copy: 
    src=mackerel-temperature.sh
    dest=/home/pi/mackerel-temperature.sh
    mode=755

- name: mackerel humidity plugin
  copy: 
    src=mackerel-humidity.sh
    dest=/home/pi/mackerel-humidity.sh
    mode=755

- name: mackerel-agent conf
  lineinfile: 
    dest=/etc/mackerel-agent/mackerel-agent.conf
    line='{{ item.line }}'
    regexp='{{ item.regexp }}'
  with_items:
    - { line: '[plugin.metrics.temperature]', regexp: '^\[plugin.metrics.temperature\]' }
    - { line: 'command = "/home/pi/mackerel-temperature.sh"', regexp: '^command = "/home/pi/mackerel-temperature.sh"' }
    - { line: '[plugin.metrics.humidity]', regexp: '^\[plugin.metrics.humidity\]' }
    - { line: 'command = "/home/pi/mackerel-humidity.sh"', regexp: '^command = "/home/pi/mackerel-humidity.sh"' }
  notify: restart mackerel-agent

自分の場合は以下のサンプルコードをそのまま利用しているので、センサーからの取得処理は実装方法や RaspberryPi のピン番号によって異なる。

https://github.com/adafruit/Adafruit_Python_DHT

files/mackerel-humidity.sh

#!/bin/bash

name="humidity.raspberrypi"
humidity=`/home/pi/Adafruit_Python_DHT/examples/Adahumit.py 22 4`
date=`env TZ=JST date +%s`

echo -e "${name}\t${humidity}\t${date}"

files/mackerel-temperature.sh

#!/bin/bash

name="temperature.raspberrypi"
temperature=`/home/pi/Adafruit_Python_DHT/examples/Adatemp.py 22 4`
date=`env TZ=JST date +%s`

echo -e "${name}\t${temperature}\t${date}"

mackerel 画面

左から湿度、見守りカメラの反応、温度となっている。

f:id:khei-fuji:20170430145710p:plain

センサーの負荷の問題か、mackerel-agent のタイムアウトが短いためか、取得に失敗することがときどきあり、グラフがぶつ切りになってしまっている。
このあたりはもうちょっと時間があるときに調べたい。

感想

認証を考慮して情報を見える化する場として、Mackerel のような SaaS はありがたい。
(フリー版で事足りてしまうので、Mackerel のビジネス的には貢献できないが・・)

1年くらい運用していて Raspberry Pi の問題は無線LANの再接続くらいしか起きていなかったが、Mackerel によって RaspberryPi ホストも監視できるようになったので、より運用しやすい状況が作れたのでよかった。


Amazon のマーケットプレイスに不審なくらい価格を下げた出品者が続出している

今さらだけど PS4 の Horizon の評判がいいので、Amazon で価格を調べていたところ、タイトルの通りのことが起きていた。
他のサイトで見た感じ、新品では ¥5,000〜¥6,500 の価格設定がされていた。


[2017 4/22 20:48]
¥1,800 で出品する新規出品者


[2017 4/23 8:10]
直近のフィードバックでは送られてこないといったコメントがついていた出品者


[2017 4/23 12:27]
新品の出品
f:id:khei-fuji:20170423122955p:plain


[2017 4/23 12:27]
中古の出品
f:id:khei-fuji:20170423123000p:plain


だんだんリアルな出品者になってきてるが、直近のフィードバックが何年も前だったりで、安値をつけているアカウントは全て怪しく見える。
こういったことがここ数日の間に起きている模様。
PS4 の他のソフトでも起きている。
Amazonマーケットプレイス利用が若干怖くなった。


昨日(4/22) の時点で業者名で検索すると、以下のブログに行き着いた。
堂山后子 Kimiko Doyamaとは何者なのか? | ギリギリバサラ GIRIGIRI BASARA | ギリギリバサラ GIRIGIRI BASARA

最近始まった現象なのかもしれない。


ざっと以下のURLに目を通した限りでは、配送されない場合はまずは出品者に連絡してダメならAmazonに泣きつけば保証してくれるっぽい。(条件にもよる。あと手間がかかる)

Amazon.co.jp ヘルプ: Amazonマーケットプレイス保証


上に書いたように、まずは出品者に連絡したうえで Amazon に問い合わせることで、たぶん Amazon が問題を把握して対処してくれるはずなので、届かなかったというトラブルがあれば適切に問い合わせを行うのがよさそう。


あとは何年も前にマーケットプレイス出品者側で使っていた立場で書くと、自動で最安値に合わせる機能とかがあったので、おかしな安値の価格に合わせてしまう業者を誰かが狙っているという可能性もあるかもしれない。


もしこれがマーケットプレイスのアカウント乗っ取りによるものだとすると、しばらく使われていないマーケットプレイスアカウントのパスワードリセットや停止処置などが今後入ることになるかもしれない。


何にせよよくわからないことになっている。

謙遜は美徳だがチャンスは逃げる

なんかエモいことを書きたい気分なので。
タイトルで言いたいことは終わった。
以下、蛇足。


日本人は謙遜するのが美徳、みたいなところがある。
コミュニケーション上それはすごく共感する。


ただ、一方で、「こういう機会があるんだけど、どう?」みたいな誘いを誰かに言われたときにそれをやってしまうと、大きな機会損失になってしまう。


断り文句として使う場合は構わない。
スキル不足や遠慮で謙遜を使うと、それを乗り越えたときに得られたであろう経験がどれほど大きかったことか。


声を掛ける側はスキル不足かもしれないということは多少想定している。
なんだったら失敗して、それが糧になればいいくらいに思ってることもある。


迷ったらやってみる、というのを信条としたい。
ただ、時間は有限だ。


プレゼン資料ドリブン

先日、AzureMachineLearning のハンズオンイベントをスピーカーとして行った。

【Azure Machine Learning ハンズオン入門】実践からはじめる機械学習 - connpass

イベントについては会社のブログに書くとして、プレゼンの準備をどのようにしたかについて書く。

3/28 20:56 追記。
会社のブログに書きました。

blog.isao.co.jp

以下、前提

  • 準備はじめたのは3週間前
  • Azure はそれなりに知ってる
  • Azure Machine Learning について名前だけ知ってる状態からスタート
  • この手のイベントのスピーカー経験はなし
  • 社内でスピーカーやる経験は何度かある


やったこと

プレゼン資料作成

早速ブログエントリのタイトル回収。
ここからはじめた。

以下のように大まかな格子を考えた。

  • アイスブレイクとしての自己紹介(40歳以上ではない)
  • 概要説明
  • ハンズオン
  • 多少の解説
  • まとめ

この時点で埋まったのは最初の自己紹介だけ。
「ゼロから学ぶ Deep Learning」でくじけた自分でも Azure Machine Learning は使えます、って流れで紹介することだけ決めた。


connpass のページを公開すると、その日のうちに定員20人に対して34人参加が入る。
この時期の機械学習系のイベントは集客力が恐ろしい。
まだ白紙のスライドなのに。

30周年セールで衝動買いした ファイナルファンタジー X/X-2 HD Remaster をやってる場合ではない。
ベベルで足止め。

情報収集

メインとなるハンズオン部分や関わる技術概要を埋めるための情報収集

  • 公式ドキュメントを漁る
  • 公式のチュートリアルを試す
  • Qiita や個人ブログを中心にやってみた系の記事をあさる

最初にググってまわるのは効率悪くて、公式から追うのがベター。
特に MS は翻訳はアレなことがあっても最近ドキュメントが読みやすくタメになる。
検索にヒットする記事は1年前の記事ですら陳腐化してる可能性があるし、そもそも質が低いものが多い。

10日前の時点で満足度6割の資料ができあがる。
最低限開催できるだろうというレベル。

これで七曜の武器集めが再開できる。

校生・ビルドアップ

試行錯誤で完成度を高めていくフェーズ。

  • 資料全体を見て整合性チェック
  • 自分でリハーサル
  • 社内リハーサル
  • 他のイベントに参加する

効果的なのは社内リハーサルと他のイベントに参加したことだった。
視点漏れが減るのと、コンテンツの不足が補われた。
協力いただいた方々、ありがとうございました。

この頃、とれとれチョコボで0秒切りを達成して、無事ティーダの武器が限界突破を果たす。
プレゼンで玉砕して死んでも後悔はない。

本番について

割愛

考察

プレゼン資料ドリブンは議事録ドリブンに似ていて、必要なアウトプットを最短経路で生み出してる感あってよかった。
機械学習は闇雲に調べるとキリがないジャンルなので、伝えたいこと言いたいことにフォーカスして下調べできたのが大きい。
ただ、早い段階で伝えたいことを確定させてしまうことで、結論ありきにならないようにしないといけないという点はある。
バランス感覚が必要。

スケジュール感としてはギリギリまで資料作ってる、という状態にならず、早い段階で開催できる状態が見えたのもよい。

ふと思い返せばブログ駆動開発することもたまにある。
最終的にこういうアウトプットを出すために今やっていっているのだ、という認識があるとモチベーションになってよい。

進捗

スフィア盤埋めとルールーの雷避けが残ってる。
前者は作業なのでやる気がない。

雷避けは2年前にバズった記事で機械学習で自動化してる方がいたことを思い出した。
FF10の雷除けを自動化した話 - panchiga's blog

たまたまとはいえ機械学習という話でつながってくるとは。。
投資がかさむので気が向いたらチャレンジしたい。

Productivity Engineering − Forkwell Meetup #4 行ってきた

【増枠!】Productivity Engineering − Forkwell Meetup #4 - connpass

上記イベントに行ってきた。
発表で響いた点のまとめ。

クックパッドにおけるモバイルアプリ開発の工夫 クックパッド @ichiko_revjune

  • 機能ごとに開発チームを分割
    チーム内にデザイナー、エンジニアがいる
  • リリースサイクルは2〜4week

実装

  • 意図したとおりに実装できていること
  • 効果が計測できること

方法

  • 朝会
    増員に伴いチャットで行うようにした結果、他社への関心が薄れ、実装した機能のコンフリクトが生じて計測が正しく動かなかった
    そこでキックオフを行うようにした
  • キックオフ(開発初期段階)
    対象はディレクタ、デザイナ、エンジニア
    大きな変更を共有
  • 確認会(リリース前)
    UI/UX の一貫性を確認

Effective Retrospective アトラクタ @ryuzee

  • ふりかえりの目的
    「もっとうまくできるように」はみんな知ってる
    「仕事を急停止する」あまり知られてない。立ち止まって考える余裕を保つ
  • 心理的安全性をつくる
  • テクニック
    開始時に全員に口を開いてもらうと主体的参加度が上がりやすい
    施策は自分が実行者となってやる、くらいのものを少しだけ選んだほうがよい
    いっぱい採用してもどうせやらない

自己言及的なチームをつくる GMOペパボ @june29

  • 今日より明日をちょっとよくしたい
  • 自分たちを変えるのは自分たちでしかできない

Make Jenkins Great Again サイボウズ @miyajan

  • 2.0 よい

最速で価値を提供する ネクスト @masamichi

  • 価値を高めるためにも、品質の共通認識をつくる必要がある
    品質の仕様化、言語化
    具体的には速度=レスポンスタイムやセキュリティ=脆弱性診断結果など
  • 待ち時間や手戻りをなくす
    そのための情報共有ツール, CI, CD

ペアプログラミングの使いどころ タワーズ・クエスト @t_wada

  • How 考えを声出す、もしくは紙やホワイトボードに書く
  • When メンバージョインしたとき、新機能実装、週1
  • Why タスクは完了してこそ意味がある。並行作業で仕掛かりを増やすより1つずつ完了させる
    教育的側面、スキル伝授

Q&A

  • 開発環境が人によって異なるのでは?
    開発環境の好みよりもチームの成功が大事だよね
  • ペアにしかノウハウが残らないのでは?
    モブプログラミング
  • 上級者にメリットがないのでは?
    教えることで知識の整理ができる

最後に

プログラマが知るべき97のこと

プログラマが知るべき97のこと

微分積分?何それ?Azure Machine Learning を使って実践から入る機械学習

はじめに

機械学習、流行ってますね。
流行りに飛びつくのはシャクだが、少しは理解を深めたい。
しかし流行りに乗じて本を買っても数学などの基礎部分でつまずいてあきらめていた。 そんな自分にも機械学習を始められた。
そう、Azure ならね。

想定する読み手

  • 機械学習に興味がある
  • 地道に数学を学ぶモチベーションが維持できない
  • 動くプロダクトを早く見たい
  • 学習コストを低く機械学習を始めたい
  • 「ゼロから作るDeep Learning」を途中で挫折した

検証をはじめる前に

前提知識

さっそく手を動かしたいところだが、ちょっとだけこれを読んでほしい

一般的に機械学習で必要な手順は以下のとおり

  1. 題材を決める
  2. 元となるデータを用意する
  3. モデルを作成する(モデル=AI と思ってくれていい)
  4. 結果を確認し、必要があればモデルを修正する
  5. 4 を繰り返す

大事なのは1と2だ。
いきなり手を動かすにはデータがないといけない。
Azure Machine Learning にもいくつかサンプルデータが用意されている

自分にはピンとくるものがなく、英語も読みたくないし、複雑なものは理解しづらいので自分で準備した。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday.csv

日本の祝日かどうかを50年分出力したデータ。
人間もプログラムも読みやすいようにしたつもり。

github.com

上記プログラムで出力した。

Azureサブスクリプションを用意する

メールアドレスがあれば下のリンクから始められる。

azure.microsoft.com

正直 Azure はこのアカウント周りが非常にわかりづらく、最初のハードルになりやすい。


ログインに必要なのは Microsoft アカウントで、既存のメルアドから作成できる。
Azure のリソースを管理する単位が Azure サブスクリプションで、この単位で請求が来る。


登録にクレジットカードが必要になるが、有料の支払いをオンにしない限りは勝手に決済されることはない。
(ただしこの設定は一度オンにするともう戻せないので注意)
無料のクレジットがついているので、ちょっと試すくらいなら十分ペイできるはず。

Azure Machine Learning Studio で検証

モデル(experiment)の作成

いよいよ本題。
とはいえ説明することは特にない。

↓に大変よくできたドキュメントがある。

docs.microsoft.com

ドキュメントは日本語だが Machine Learning Studio が英語だと混乱しがちだが、ほとんどつまづくことはないはず。
ポチポチするだけで結果が出て来るのはよい。


ということでドキュメント読みながらポチポチ進めるだけなので、途中経過は飛ばす。


以下はデータをフィルタせず、アルゴリズムにランダムフォレスト(Multiclass Decision Forest) を使ってみた結果。

f:id:khei-fuji:20170304152419p:plain

そこそこの正答率が出ている。
誤答している箇所をピックアップしてみる。

  • 2030/1/13 祝日ではないが祝日扱い
  • 2004/10/11 祝日だが祝日でない扱い

成人の日や体育の日は第2月曜となっているため、傾向が見えにくいのだろう。

国民の祝日 - Wikipedia


そもそもインプットしているデータに「曜日」や「第2週」という概念がない。
このへんを与えれば改善するだろうか。

ということでデータセット自体を作り変えてみたのがこちら。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday-with-dayofweek.csv

曜日と第何週かをデータに追記した。


ロジックは特に変えずに出した結果。

f:id:khei-fuji:20170304160915p:plain

かなり改善している。
今回はデータセット自体を自分で用意したのでデータセットを置き換えたが、本来は Data Transformation で加工する。
データの型の特徴を正しく認識されるように加工してあげる必要があることがわかった。

あとは春分秋分の日あたりに間違いが見られるが、アルゴリズムの取捨選択でどうにかならない気がする。


本来、自分で実装できることを機械学習に頼るべきではなく、規則性の見えないこと・表現できないことをやってくれるもの、という位置づけで考えておくのがいいのだろう。
今回は機械学習を理解するために人間が理解できるものを例にして取り上げた。

デプロイ

こうして作成したモデルは簡単に WebService にデプロイできる。

f:id:khei-fuji:20170305122555p:plain

WebAPI で公開されるので後は既存のサービスから呼び出すだけ。
Bot 連携程度なら AzureFunctions 使っておけばいい。


API のドキュメントも生成されている。
Swagger フォーマットはもうスタンダードになりつつあるるのだろうか。

f:id:khei-fuji:20170305122925p:plain

認証は下の画面にある Key を Header に含めるだけ。

f:id:khei-fuji:20170305123024p:plain

デプロイされたAPIトランザクション数とコンピューティング時間の従量課金となっている。

料金 - Machine Learning | Microsoft Azure


今回は AzureFunction で毎朝 API コールして結果を Slack に流すようにしてみた。 本題ではないので詳細は省く。

f:id:khei-fuji:20170305124202p:plain

3/5(日) は祝日ではないけど休日ですね。。
英語力が足りてない。

まとめ

研究者みたいに学問として学ぶのが苦にならない人は数学を着実に学び直すのはいいと思う。
しかし専門職でもない自分が、機械学習に大量の学習コストを割くという判断はしづらい。
Azure Machine Learning のように短時間でお手軽に触れるテクノロジーをうまく活用してやっていきたい。


機械学習そのものについては、これをとっかかりにしてもう少し複雑なことをやらせてみたい。
やりたいことはあるが、試行錯誤そのものよりもデータ集めるのが大変なのでどうするか迷う。

さわってわかる機械学習 Azure Macine Learning 実践ガイド

さわってわかる機械学習 Azure Macine Learning 実践ガイド