【解決済み】未解決メモ:ebで使用されているAMIでlogrotateのエラーが出る

※2015.11.14追記
今日新しいebアプリケーション(AMIは同じ)作って試してみたら、hourlyオプションが無くなってた・・
Release Notes見ても載ってないんで、一時的なものだったかもしれない・・
んー・・・
今のやつは新環境作ってswapするかな・・


概要

とあるサービスのeb再構築で使用しているEC2で、root宛にこんなエラーメールが来る。

/etc/cron.hourly/cron.logrotate.elasticbeanstalk.httpd.conf:

error: /etc/logrotate.elasticbeanstalk.hourly/logrotate.elasticbeanstalk.httpd.conf:2 unknown option 'hourly' -- ignoring line

postfix+sesでメール飛ぶようにしているので、毎時こんなメールが来て鬱陶しい。
止めたい。

AMI

使っているAMIはこちら
ami-e6b322e6(aws-elasticbeanstalk-amzn-2015.03.0.x86_64-php56-hvm-201509181935)

最新っぽいものを選んだ。

調査-1

まずはこのAMIを使って、EC2インスタンスを立てて確認する。
結果:logrotate.elasticbeanstalk.httpd.conf自体が存在しない。
eb側で作っているのだろう。

調査-2

メッセージのとおりだけど、logrotate.elasticbeanstalk.httpd.confにはhourlyってオプションが記載されてる。

で、logrotate + hourlyでぐぐってみたら、
3.8.5からhourly対応したみたいで。

cf. タイトルとか決めてないけどこのままでもいいかもしんない: logrotateでnginxのログを1時間ごとにローテートをする

このAMIのlogroateは3.7.8なので、アップデートしたらいいのかと思い、
yum updateをしてみるがバージョンは変わらず。
yum list logrotateしても3.7.8-17.13.amzn1しか出てこない。

別のrepoからアップデートしないといけないの?


ここで調査を止めて、logrotate.elasticbeanstalk.httpd.confのhourlyを削除して対処する。

実稼働までに再度調査して、ダメそうなら別のAMIを使うかな・・
みんなこのAMI使ってないのかな・・?

AWS Lambda + PhantomJSでサイト監視(簡易版)

休み中にサイトが死んでてアレコレあって、楽に監視できないかなーと。
Zabbixとかいろいろあるけど、そこまでガッツリじゃなくてもいいんだよなーと。 404や500になってたら通知が来てくれればいいかなーと。
ついでに画面キャプチャもあるとうれしいなーと。
ただ、稼働中のサーバーには何もインストールしたくないなーと。
PhantomJSやらCasperJS使えばできるのは分かるんだけど、そのためにEC2とか立てたくないなーと。
Lambdaでどうにかできないかなーと思って探したらありました。

github.com

本当にありがとうございます。

   
で、クローンして作ったのがこれ。
元のソースに少し付け足しただけなんだけど・・

github.com

AWS Lambda上でPhantomJSを動かし、
チェック対象のサイトが200以外を返したら、
画面キャプチャを撮ってメールで送信するやつ。

EventSourceにここを指定して動かしている。 alestic.com

日本語が化けてるとかソースが汚いとかいろいろあるけど、
同じことやろうとしている人がいるだろうなと思うので晒しておく
((((;゚Д゚))))ガクガクブルブル

PepperくんがJoinした

ついに来ましたPepperくん。

f:id:tnaototo:20150911232121j:plain

まずはChoregrapheで触ってみよう。
何させたら面白いかな・・?

Deep Learningハンズオン勉強会 に行ってきた

先日、このイベントに行ってきた。

mashupawards.doorkeeper.jp

内容が素晴らしくて、ひとりでやってた時のもやもやが晴れた気がした。
単語の読み方も正しいのが聴けたし(^^)

 
で、そのスライドがもう神。
ホント、そのままやればできちゃうので!
これは前回のスライドみたいです。

次回もぜひ参加したい!


で、本題はここから。
このスライドに沿って、手持ちの画像データを分類してみようと。
すると、lmdbの中身を見る時にエラーが・・

$ python read_lmdb.py

Traceback (most recent call last):
  File "read_lmdb.py", line 13, in <module>
    data = caffe.io.datum_to_array(datum)
  File "/home/ubuntu/caffe/python/caffe/io.py", line 85, in datum_to_array
    datum.channels, datum.height, datum.width)
ValueError: total size of new array must be unchanged

んー
配列の総要素数を変更しようとしてエラーになっているみたいで、 いろいろ試すもダメ。
ソースを見たらここを通らなくても良さそうなので、コメントアウトしたらエラーは出なくなった。

・・が、その次の平均画像作成時にエラーがorz

$ build/tools/compute_image_mean -backend=lmdb examples/hoge/hoge_train_lmdb examples/hoge/mean.binaryproto

F0909 08:59:59.850615 14784 compute_image_mean.cpp:76] Check failed: size_in_datum == data_size (2304 vs. 3072) Incorrect data field size 2304
*** Check failure stack trace: ***
    @     0x7f45f278bdaa  (unknown)
    @     0x7f45f278bce4  (unknown)
    @     0x7f45f278b6e6  (unknown)
    @     0x7f45f278e687  (unknown)
    @           0x4022b1  main
    @     0x7f45f199aec5  (unknown)
    @           0x40243a  (unknown)
    @              (nil)  (unknown)
Aborted (core dumped)

あれこれ試した結果、
画像を正規化する時のリサイズが縦横比を保持しちゃってて、
32x32になっていなかった・・(;´Д`)

これで強制リサイズ

$ mogrify -geometry 32x32! */*.jpg

リサイズ後に試したらエラーは解消して、学習モデル作成までできたー(゚∀゚)

 

正解率がとっても低いんで、これからゴニョゴニョ調整してみよう。
どうなるのか楽しみだわー

AWS CLIでInvalid JSON: No JSON object could be decoded

PHP7ベータ版でWordPressを動かしてみよう | PRESSMAN*Tech を参考にスポットインスタンスを立ち上げようとしたらこんなエラーが。

Error parsing parameter 'cli-input-json': Invalid JSON: No JSON object could be decoded JSON received: ec2_spot.json

実行したコマンドはコレ。

$ aws ec2 request-spot-instances --cli-input-json ec2_spot.json

 

・・・

そう。
file:// が抜けてたというお話orz
下のように追加したらちゃんと立ち上がった。

$ aws ec2 request-spot-instances --cli-input-json file://ec2_spot.json

YAPC::Asia Tokyo 2015 に行ってきた!

今年でラストということなので、いろんなものを放り投げて行ってきた!

yapcasia.org

Day 1

飛行機の関係で午後から参加。
「ビッグサイトから○○までは○時間!」 | YAPC::Asia Tokyo 2015 のおかげで迷わずに済んだ。
わかりやすくてホント助った〜(^^)

HTTP/2時代のウェブサイト設計

・・から観たかったけど、間に合わずorz

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜

はてなブログの開発話。
オブジェクト指向やDDDとか、実際にやってきたことを聴けたのがよかった。
コピペの話や定期的に発せられる「最高」がステキだったw
ユビキタス言語のくだりはうちもちゃんとやろうと思った。

Yet Another Perl Cooking

自分が一番楽しかったのがコレ。
Nomikuが届かない、とろ火の定義がわからない、ビニールが焦げるなどなど、おもしろポイント満載だったw
ただ、おもしろ要素だけじゃなく、Nomiku届かないからとRaspberry Piで自作したのは凄いなと。
Chefをリアルワールドにって発想が素晴らしいと思った。

esa.io - 趣味から育てたWebサービスで生きていく

今年の Hackers Champloo に来ていただいていたera.ioさん。
Bug Fixタイムアタックってのは驚いた。
雑なコードにならないのかなぁ・・

Lightning Talks Day 1

まさにお祭りって感じで楽しかった!
障害対応術のLT時に実際の障害通知があったり、LTの準備中だけ喋る人が出てきたりと、息つく間もない60分だったw
で、一番沸いた(と思う)のがコレ。

隣の人達がざわついてたので、修正頑張ってくださいと祈ってました(^^;)

Day 2

ISUCONの勝ち方

ISUCON自体は知らなかったけど、チューニング系が聴けそうだったので参加。
analyze_apache_logsやpt-query-digest、iftopは聴いたこと無かったんで、勉強不足を痛感。
「心にいつもB+Treeを」
楽しそうなので、うちもチームで出てみたいなと。

我々はどのように冗長化を失敗したのか

こういう失敗事例を聴けるのは貴重だなと。
hostsは上からなめて最初のものをすぐに返すってのは知らなかったorz
道具への理解と責任のくだりはホントそうだなと頷くばかり。

ランチセッションの1つ前

ランチセッションB付近で待機。
Day 1の経験から、普通にトークを聞いた後だと入れないと確信。
ま、弁当云々より、位置情報関連技術の話が聴きたくて・・

ランチセッションB

駅メモで使用されている位置情報技術について。
座標のランク関数とかとってもわかりやすかった。
GeoHex便利そうなんで、ぜひ使ってみたい(うちにそんな案件あるのか知らないけど)
お弁当もありがとうございました!(何だかんだで、ちゃっかり頂きましたw)

データ分析基盤を支える技術

用語は聞いたことあるけど・・みたいなデータ分析基盤の話が聴けて勉強になった。
SQLは大事ってのと、データ分析基盤は自前でやるもんじゃないってのはわかりましたww

   

ここでタイムアップ・・
YAPCあるあるの歓声を聞きつつ、泣く泣く空港へ・・・

その他

Network

ちょこちょこ繋がらないこともあったけど、この規模でこの安定性って凄いと思った。
CONBUさん凄すぎる!
おかげで快適に過ごせました。ありがとうございました!
カンファレンスネットワークの作り方 - YAPC::Asia Tokyo 2015 も聴きたかったな・・

移動

ちゃんとスケジューリングしないと部屋に入れもしないw
ネズミの国みたいだなとww

空港

トータルで1時間半遅延orz
YAPCあるあるの直前までいたのになー
同じトラックだったのになー
使用機に雷落ちるとかー

まとめ

YAPC::Asia Tokyo 2015 楽しかった!
ホント、エンジニアのお祭りって感じで居心地がよかった。(特にDay 1のLT大会)
エンジニアとして負けないよう修行せねば。

f:id:tnaototo:20150827224532j:plain

f:id:tnaototo:20150827224855j:plain

f:id:tnaototo:20150827224621j:plain

無限コーヒー
ありがとうございました!
f:id:tnaototo:20150827225011j:plain

f:id:tnaototo:20150827230604j:plain

いいアイデア思いついたら

まさにこれ。
すぐ動く癖があるので、肝に銘じておこう・・

周囲を見渡しても同様のサービスがなく、「これは世界初なんです!」と勢いよく持ち込む前に「なぜそれがなかったのか」「それが欲しいのは自分(似た境遇の人数人)だけではないのか」という自問自答する時間と心の余裕は持ちたいものです。

引用元:2015年Q2に「死亡した」スタートアップ12社の理由 - THE BRIDGE(ザ・ブリッジ)