Works東京エンジニア。Ruby,Go,たまにAWSとiOS。ゲーム音楽が好きです。連絡はTwitterかakata.onen@gmail.comまでこの広告は、90日以上更新していないブログに表示しています。GrafanaLightsailがかなりお得になったので、何か作ろうかなと思っているんですが、どんなサーバを可動させようにも「まずは監視だな」ということでこんな記事を書いてみました。サーバーはamazon-linux-2018.03.0を想定しています。今回はメトリクスの収集はアプリケーション用にstatsdとシステム用にcollectdを使います。他はデータストアにgraphiteをグラフ化にgrafanaをといった構成です。Imageがあって楽だったというのが一番の理由ですかね......(笑)statsdも入れてますが、今回の記事にstatsdの使い方等は一切書いておりません。アプリケーションよりも先にシステムのメトリクスだと思うので。Imageがあるのでこれで構成してしまい、collectdのみパッケージをインストールします。Imageがあるので使えばいいんですが、めんどくさいので今回はスルーしました。-dcollectdのインストールにはEPELリポジトリが必要なので同時に入れてしまいましょう。一部のプラグインはcollectdに同封されていないため、必要であれば適宜インストールしてください。diskすら入っていません。collectd-disk.x86_64プラグインが入っていないと、/var/log/messagesに以下のようなログが流れます。/usr/lib64/collectd次に/etc/collectd.confを編集します。write_graphiteプラグインと、追加したプラグインの記述をコメントアウトして、後は好みで設定してください。詳しいプラグインの設定方法は以下やGitHubに記述されています。Imageでaggregater用のstatsdがすでに起動しているので、モニターサーバーのシステムメトリックスはgraphiteに直接投げていますが、collectdのstatsdプラグイン使っても問題ないと思います。サービスを起動して、/var/log/messagesを確認しましょう。うまく設定できていなければ、エラーが出たり、メトリクスが取れなかったりします。start問題なければ、後はGrafanaでをグラフを作成すれば完成です。今回はモニターサーバの準備と、モニターサーバのシステムメトリックスにフォーカスしました。アプリケーションサーバを追加したら、同じようにstatsdやcollectdをインストールして、モニターサーバにデータを送信すればいいと思います。走り書きしてしまったので、間違っている点や分からない点がありましたらコメント等いただけると幸いです。String#unpackについて調べてみました。このあたりの認識がふわっとしてると、使うときに障害の種になるので要注意ですね。調べたつもりですが、間違えていたらスミマセン。unpackがふわっとします(僕はしました)多くの言語では、文字集合と文字コードを統一するUCS方式という多言語化手法が使われており、例えばPerlだと文字集合をUnicode、文字コードをUTF-8として統一しています。外から入ってくるバイト列は必ずUTF-8にエンコードし、外に出すときにまたエンコードするといった感じです。対してRubyのようなCSI方式では、文字列オブジェクト自体が自らの文字コード情報を持っています。文字列オブジェクトが持つ主な情報はバイト列と文字コードです。82なので上記のような結果になります。CSI方式では言語仕様の文字集合や文字コードに依存しないなど、それぞれの方式には得手不得手があるのですが、ここでは省略します。設計と実装String#unpack本題になりますが、String#unpackについてで、これは文字列オブジェクトが持つバイト列情報をテンプレート文字列(第一引数)に従って変換するメソッドです。出力結果は配列で返ってきますが、テンプレート文字列によっては一要素しか含みません。Array#pack続いて、Array#packについてです。これは逆にString#unpackメソッドとテンプレート文字列で表現可能な配列を文字列オブジェクトに戻せるメソッドです。本来、packの説明をベースにunpackはそれを戻すものみたいに言われてますが、個人的には文字列のほうが直感的かと思ったので、先にunpackを説明して、packはそれを戻すもとと解釈したほうが分かりやすかったです。130].pack("C*")"\xE3\x81\x82"ここで「話が違うぞ!!」と慌てる前に、まずは文字コードを確認するといいです。2.0以降の標準文字コードはUTF-8でしたが、packの返却値はどうやらASCII-8BITみたいですね。同じバイト列でも、文字コードが違うだけで見え方が変わっています。ちなみに、IOオブジェクトの標準外部エンコーディングはいい感じに設定されているので、上のコードはあえてpで出力してますが、普通にputsで出力すると、自分でUTF-8に戻さなくても出力結果はUTF-8(環境によりけり)になります。130].pack("C*").force_encoding("UTF-8")"あ"うまく戻りましたね。物事を理解するには深掘りするに限る。Ruby前々からちょこちょこ気になってたことだったので調べてみた。nodejsに辿り着くんですが、このコマンドでインストールされたバイナリはnodeじゃなくてnodejsになるのでいろんな所でちょっとメンドイ。directoryとなる。いうことで調べてみたところ、こちらもすぐに辿り着いた。conflict.要するに単に名前が被ってたからnode使えなかったってことみたい。iPhoneのカタカナ表記が「アイフォーン」になってるノリですね。LTSサーバにもRubyイメージにもnodeコマンドは入ってなかったので単純にリンクを通せば大丈夫です。/usr/bin/node備考Dockerならrubyとnodeでコンテナ分けたら解決するし、責務も明確になるしその方がいいかも。buildした方がいいかも。23:21NodeJSとnodejsコマンド・nodeコマンドの違いTweet広告を非表示にするもっと読むコメントを書く2018-09-03DockerHubにあるイメージのタグリストを出力するスクリプトDockerDockerHubにあるイメージのタグを検索するだけのスクリプト。searchだとそこまで分からないから便利。'.[]["name"]'jqコマンドに依存するので、便利だからこの際入れよう。関数化してbashrc(zshrc)に追加していればもっと便利。head"latest""1""1-onbuild""1-slim""1-wheezy""1.9""1.9-onbuild""1.9-slim""1.9-wheezy""1.9.3"短いけど終わり。gemを使うのが一般的なので、この記事はどうしてもスクリプトからgsutilを実行したい人向けです。SDKの一部としてgsutilをインストールした前提で書いていますが、スタンドアローンのgsutilを使用している方も同様に処理できると思います。gsutilのインストールがまだな人はここからどうぞ!(Pythonのバージョンには注意ね)認証gcloudだと別々の認証情報を使ったプロセスが並列したときに問題になりますし、.botoファイルだと細かい制御が難しいのでトップレベルの-oオプションを使うといいです。-oオプション使用することで.botoで設定できるような項目をコマンド単位で上書きできます。並列処理させる場合は、-mオプションに加えて、GSUtil:parallel_process_count,GSUtil:parallel_thread_countを上書きしてください。.-qオプションを指定することでアップロード中などのプログレスなどを非表示にできます。crontabなどで実行するときはこれも付けるといいです。.探せばいろいろありますがgcsはまだまだawsに比べて日本語情報が少ないですね。CacheRailsのフラグメントキャッシュでオンメモリを指定してたら、外部ミドルウェアを使うのと挙動が違ってハマったのでメモ。開発環境デフォルトのオンメモリは準備が楽ですが、本番でDalliとか使ってると混乱するので統一しておきたいですね。使われると思われるRails.cache.fetchの結果をそれぞれ見てみます。:foo=>"bar"}このようにオンメモリではキャッシュされた値に、その後の変更が適応されています。オンメモリだとrailsプロセスと同一のメモリ空間に保存されるため、ポインタのその後の変更も適応されているんだと思います。三回目の呼び出しまで適応されない理由はわかりませんが......(ドキュメントとかコードちゃんと読んだ人教えて!)結論あんまりオンメモリストア使うもんじゃないね。SDKがややこしかったのでまとめてみました。わかりやすく書いたつもりです。「間違っているぞー」とい点があればご指摘いただけると幸いです。OSやiOS)とそのバージョンごとに異なるSDKを用意しており、それぞれの端末には対応するSDKが事前に組み込まれています。これにより以下のようなメリットがあります。Target(配布ターゲット)開発者がソフトウェアの動作を保証する最も古いSDKのバージョンを表します。これ以上のSDK上では動作を保証する必要があるけど、これより古いSDK上ではクラッシュしても知りませんってことです。動作を保証する必要がないため、これ以下のバージョンで実装された機能にはがっつりと強リンク(機能がなければクラッシュする)が張られます。SDKソフトウェアのコンパイル時に基準とするSDKのバージョンを表します。これより新しいSDK上で定義された機能は使えません(コンパイルエラー)。このバージョンで廃止予定とされている機能はこれ以降のバージョンでは存在しない可能性があるためさっさと移行したほうがいいです。警告が出ると思います。廃止予定の機能さえ使用していなければ上位互換性はほぼ保証されます。コンパイル時により新しいSDKで定義された機能は使ってないし、廃止予定でない機能が急に消されることはない(はず)だからです。SDK以上の機能は廃止予定のものを使っていなければほぼ安全であるということがわかりました。これらのバージョン間で実装(変更)された機能に関してはユーザの端末に定義されているとは限りません。メソッドが追加されたり、挙動が変更されたりといろいろ考えられます。故に、これらの機能にはソースコード上で動的に変更が可能なように弱リンク(機能がなければヌルポになる)が張られ、機能が定義されているか事前に確認する必要があります。具体的な実装方法に関しては省きますが、参考URLにあるAppleの公式ドキュメントが一番まとまっていると思います。まとめまとめると、このあたりをきちんと守っていれば互換性に関しては問題ないと思います。