システム稼働状況ページを作った

Service status osa-p.net を作った話。

元々、zabbixでシステムの状況はモニタリングしているのだが、それを外部に公開する仕組みを用意していなかった。zabbixのページをそのまま公開したくなかったので、必要な情報だけ抽出して表示できる仕組みが欲しかった。


SNSでつぶやいてみると

UptimeRobotというサービスを紹介してもらえた。

早速設定してみたところ、格好良い稼働状況ページが出来上がったのだが、うちのシステム上、ウェブサーバとデータベースが分離しており、データベースを使う処理は動かないが、ウェブサーバだけで完結する処理は動くという状況があり得て、その表示がしにくいなと感じた。

そこで、やはり自前で処理を作るかと、ついでに使ったことのなかったVueも試しに取り入れてみた。普段仕事でもまだまだjQueryを使うことが多く、また思い付いたサービスを個人で作るときにも早く公開したくて慣れているjQueryを使ってしまうことが多い。今回は急ぐものでもなかったので、サンプル程度しか動かしたことのなかったVueを使ってみた。といっても、やはりサンプルの継ぎはぎではあるのだけど。

処理自体は問題無くできて、さて公開するかというところで問題があった。
稼働状況ページは、自分が管理しているシステムの中で動かしてしまうと、一緒に落ちたときに肝心の状況が見えなくなってしまうので、公開ページは別のサービスで動かしたかった。まず最初に選んだのがS3で、ここでは静的サイトを公開する情報も整っていたので簡単に設定して公開。あとはネームサーバとして使っているCloudflareでCNAMEを張ってやれば動くだろうと考えていた。

実際に公開してみたところ、httpでは繋がるのだが、httpsでは接続ができなかった。S3の公開では、「https://S3ドメイン/バケット名/」だとhttpsが使えるのだが「https://バケット名.s3ドメイン」ではhttpsが使えない。Cloudflare側でHTTP Proxyを有効にしていたら、オリジンサーバーがhttpでも使えたような記憶があったのだけど、どうも上手く行かないので間にCloudFrontを挟んでhttpsでも繋がるようになった。

しかし別の問題が発生した。ページの作りとしては、zabbixから出力したSLAの情報をS3に5分毎にアップロードし、静的ページ側でそれを読み込んで表示する。CloudFrontは読み込んだ情報をキャッシュしてしまうので、いつまでも古い情報が表示されてしまうのだ。もちろんCloudFrontの設定にも用意されているので、TTLの設定を5分にしてみたり、クエリが付いていたらキャッシュしない設定にしたり、キャッシュをクリアしてみたりしたのだが、どうにも解消できなかった。

結局Netlifyで静的ページ部分を配信しつつ、データはS3から読み込むという仕組みで解決した。このやり方ならGitHub Pagesでも大丈夫だろうが、最初すべてをGitHub Pagesで配信しようと考えてしまい、5分毎にコミットとプッシュをしたら怒られそうだなと思って頭の中からGitHubを使うことを取り除いてしまっていた。

ひとまず大枠の仕組みが完成したので、これを応用して、zabbixに入力したメンテナンス情報を各サービスで表示したり、自動でメンテモードに切り替えたりもできるだろう。今はデータベースを止めるメンテナンスがあるときに、各サービスのcronを止めたり、フラグを立てたりと手動で処理してアクセスが止んだのを確認してから作業したりしているので、この辺りも自動化してしまいたいと考えている。

マストドンのフォロー状態可視化ツール「フォローリンク」

Mastodon 2 Advent Calendar 2017の2日目です。
昨日はナツキさんのマストポータルについてでした。

トゥートでの発表はしていたのですが、自分のブログでは書いていなかったので、改めて紹介します。
マストドンでのフォロー・被フォロー状態を可視化するツール「フォローリンク」を作りました。



昔、mixiGraphという友達状態を表示するソフトが有り、あれはWindowsやMac上で動作するソフトでしたが、こちらはブラウザ上で動作します。
ただし、ひたすらに重たいです。
画面上に表示されるアカウントが1000アカウントを越えるぐらいから重たくなってくるかと思います。

表示するアカウントの関係として

• 相互フォローだけ見る
• フォローだけ見る
• 被フォローだけ見る
• フォローだけ見る（相互フォローを除く）
• 被フォローだけ見る （相互フォローを除く）
• フォロー・被フォローを見る

が有りますので、フォローしていない被フォローの中から、新しくフォローしてみたい人を探すという使い方も可能です。


内部的な話もしておきましょう。
フォローリンクの表示処理自体はJavaScriptでSVGを操作して行っています。D3.jsのForceグラフ機能を使って座標計算を行っています。この処理がCPUを使い切って重たいのです。
計算処理部分だけをWeb Workerとして切り出し、ブラウザのUIスレッドと分けることでフリーズしたような重さを避けることができるのですが・・・。フォローリンクでは、随時表示アカウントの追加などが行われます。
その他ドラッグしてアカウントの表示場所を移動させたり、何かと計算中でも外部からの変更が行われます。
このため、計算用スレッドとのやり取りが多くなり、現状の処理をちょろっと書き換えただけでWeb Workerに切り出すのは難しそうだという考えになりました。
たぶん、Web Workerで計算部分だけ切り出すなら、WebGLとかでGPUに計算させた方がもっと効率よさそうだな、とか。

そしてサーバ側。フォロー情報については、フォローリンクのサーバでキャッシュをしています。これは複数の人が同じアカウントの情報を見ようとしたときに、個別にマストドンインスタンスへフォロー情報を取りに行くとインスタンス側へ負荷をかけてしまうため、その対策としてキャッシュを持っています。
マストドンのフォローページをjson形式で要求することで、ブラウザに表示するHTML形式より少ない転送量で、またプログラムで処理しやすい形式として取得することができます。フォロー情報は少しずつ変わっていくと思いますので、24時間キャッシュが残るようにしています。
このjson形式での取得がGNU SocialやPleromaが現在対応していないため、マストドンだけの対応となっています。

他にも便利そうな機能があれば追加したいと思っていますので、なにか要望があれば @osapon@mstdn.nere9.help まで連絡ください！

追伸1 ITmediaにも記事にしていただきました。
マストドンのフォロー状態を可視化する「フォローリンク」

追伸2 他のマストドンアドベントカレンダーも楽しみですね。
Mastodon Advent Calendar 2017（Adventar）
Mastodon 2 Advent Calendar 2017（これ）
Mastodon Advent Calendar 2017（Qiita）
mstdn.jp Advent Calendar 2017
knzk.me Advent Calendar 2017
nico.friends Advent Calendar 2017
ますとどんちほーりれーマンガ Advent Calendar 2017

手作業クローラーチューニングをするときの話（クローラー／Webスクレイピング Advent Calendar 2015）

クローラー／Webスクレイピング Advent Calendar 2015の4日目です。

スクレイピングを自動で行ってくるサービスも最近増えてきました。
kimonolabsやimport ioなど。
APIが用意されているサービスを使うと、もうスクレイピングする処理を書くのは嫌になってきます。
しかし、お客さんの都合だったりシステムの仕様として、スクレイピングが避けられなくなったとき、やはり昔ながらの方法でスクレイピングを行うことになります。

よくある仕様として、以下のようなものがあると思います。

• データが存在しない場合はエラーとしない。
• しかしデータが取得できなかった場合はエラーとしたい。

ここまでなら、データの取得だけテストしておけば、あとは一度取得したデータが取れなくなった場合にエラーとすれば上手く行きそうです。
ここにもう一つ仕様が入ってきたときに、話がややこしくなります。

• それまでデータが取得できていた場合でも、データが存在しなくなる場合がある。

データが取得できないときはエラーとするのに、データが取得できなくなることもあるという、矛盾したような仕様です。
データが取得できないパターンとして

• 本当にデータが存在しない
• デザインが変わって正規表現などにひっかからない

がありますが、この二つをどうやって区別し、後者の場合にエラーとするか。
人間の目で確認すれば、「デザインが変わった」なんてことは簡単に分かるのですが、プログラムではデータ付近以外のHTMLは普段から無視するものなので、なかなか分かりません。
またデータ部分以外のHTMLも確認箇所とすると、データは取得できているのに軽微なデザイン変更でもエラーとなってしまう場合があります。

人間の目と脳ってすごいですねと感心しますが、コンピュータにも人間の目のようにデザイン変更を検知させることができます。
そう、HTMLのデザイン担当とも言えるCSSです。
CSSファイルも普段から取得しておき、最後にデータが取得できたときから、データが取得できなくなった段階でファイルのハッシュ値に変更でも有れば、それはデザインが変更されたと認識可能です。
CSSファイルが普段から変更される場合は、データ付近のデザイン定義だけを抜き出してハッシュ化しておくのも方法の一つでしょう。

少なくとも、デザインが変更されたタイミングでデータが取得できないのとCSSが変更されるのは相関があるはずです。
これでデータが取得できなくなってから慌ててデバッグを開始する必要もなくなりますね。

PHPのxpathでends-withを使う

注釈：この記事はQiitaにわたしが投稿していた記事を、自分のブログへ移動させたものです。
PHPのDOMXPathでends-withを使い、属性の末尾が指定の文字列で終わるオブジェクトを取得しようとしたら、エラーになった。どうやら対応していないらしい。
しかし、DOMXPathには、自前の関数を定義できるという素敵機能というか、気持ち悪い機能というか。

DOMXPath( )でxpathオブジェクトを作った後、

function ends_with($node, $value){
    return substr($node[0]->nodeValue,-strlen($value))==$value;
}
$xpath->registerNamespace("php", "http://php.net/xpath");
$xpath->registerPHPFunctions("ends_with");

$nodes = $xpath->evaluate( "//li/a[php:function('ends_with',@href,'/')]" );

こんな感じで登録して、使用できます。
いやー、便利。
しかしstarts-withに対応してるんだから、ends-withも対応しておいてよ。

PHPでスクレイピング

注釈：この記事はQiitaにわたしが投稿していた記事を、自分のブログへ移動させたものです。
PHPでスクレイピングの記事が投稿されていたので、自分のやり方をメモ。

$body = file_get_contents( $url );
//$body = mb_convert_encoding($body, 'UTF-8', 'sjis-win'); // 文字コードが違えば

// HTMLが間違っている場合があるので、tidyを通して綺麗にする。
$tidy_obj = new tidy;
$tidy_obj->parseString( $body, array(), 'utf8');
$tidy_obj->cleanRepair();
$body = $tidy_obj->html();
unset( $tidy_obj );

// 分解
$dom = new DOMDocument;
$dom->encoding = 'UTF-8';
$dom->preserveWhiteSpace = false;
$dom->loadHTML( $body );
$xpath = new DOMXPath( $dom );
unset( $dom );

$nodes = $xpath->evaluate( "//div[@class='category']/div/p/a" );

という感じ。
HTMLが間違っていると、DOMDocumentが正しく認識できないときがあるので、tidyを通して綺麗にするのがポイント。
あとはxpathで、取りたいオブジェクトを引っ張ってこられる。

URL表示を簡略化させつつ、コピー＆ペーストに対応

注釈：この記事はQiitaにわたしが投稿していた記事を、自分のブログへ移動させたものです。
Twitterのソースを見ると分かるのですが、ふぁぼるっくにも同様の実装をしてあるので、そのときのやり方をメモしておきます。

Twitterなどで
「ふぁぼるっく bit.ly/favl... よろしく」
という表示があるのに、コピペすると
「ふぁぼるっく http://bit.ly/favlook ... よろしく」
となる。

隠れていた文字はいったいどこから！

これは

http://
bit.ly/favl
ook
 …

というタグを書いて、非表示にしたいところinvisibleクラスに

.invisible {
    font-size: 0;
    line-height: 0;
}

というCSSを適用します。
サイズと高さをゼロにするのがポイント、display:noneとか、それ系だと、そこに存在しないことになっちゃうので、コピペしたときにクリップボードへ格納されないのです。

PostgreSQLで実行中のクエリー一覧を取得

注釈：この記事はQiitaにわたしが投稿していた記事を、自分のブログへ移動させたものです。
pgAdminIIIで同様の機能があるのですが、ロック一覧を取得するのに凄い時間が掛かってしまい、まともにウィンドウが開かなくなったので、実行中のクエリーを取得するSQLを書いてみました。

このSQLを呼び出すシェルスクリプトを用意し、コマンドラインから実行できるようにしています。
アプリケーション名をトリムしているので、お好みに合わせて調整してください。

\pset columns 0;
\pset border 0;
\pset format 'wrapped'
SELECT
  procpid AS "PID"
, to_char(start,'MM/DD HH24:MI') AS "開始時間"
, to_char(now() - start,'DD HH24:MI') AS "実行時間"
, usename "user"
, substr(application_name, 1, 10) as "name"
, client_addr "IP"
, regexp_replace(current_query,'\(\r\n|\r|\n|\t\)',' ','g') AS "クエリー"
FROM (
    SELECT
      S.pid AS procpid
    , S.query_start AS start
    , S.usename
    , S.application_name
    , S.client_addr
    , S.query AS current_query
    FROM (
      SELECT *
      FROM pg_stat_activity
      WHERE state <> 'idle'
    ) AS S
) AS S
WHERE current_query <> ''
AND current_query NOT LIKE '%DISCARD ALL%'
ORDER BY
  "実行時間" DESC
, "PID";

PHP_Archive_Creator続き

先日書いた、PHP_Archive_Creatorの件。
PHP-usersのメーリス（最近の若い人は、メーリングリストのことをメーリスって呼ぶらしいですよ！）に投げてみた。

そしたら、go-pearで使われているphar形式と、phar拡張モジュールでできるphar形式は別物とのこと。
そして、PHP_Archive_Creatorでつくったpharファイルは、go-pearと同じ形式なのでした。

phar拡張モジュールは、次のバージョンあたりから本体に取り込まれるという話も出ているので、そうなると、ますます展開が面倒になる。
レンタルサーバなどでは、実質展開できないことにもなる。

うーん、pharはまだ手を出さない方が良いな。と判断して、zip形式で配布することにしたのでした。

PHP_Archive_Creator

とある要件で、複数のファイルを配布する必要が出てきた。
作業の都合上、PHPでインストーラを作れば便利なんじゃないかねと思い、そういえば、Pearのインストーラって、go-pear.pharだったよなと思い出した。

phar形式という、先頭に展開処理があって、後ろのほうにアーカイブがくっついている形式だ。
自己解凍ファイルと言えば解りやすいかも。

んで、pharファイルはどうやって作ろうか、と調べてみると、peclでpharモジュールを入れて、自前でアーカイブを作るページが出てきた。
うーん、やりたいことはgo-pear.pharみたいなことなんだよなぁ。

もう少し調べていると、pearのほうに、PHP_Archive_Creatorというのを見つけた。
アーカイブの作成から、最初に起動するphpファイルの指定まで出来るらしい。
これはすばらしい。

早速、アーカイブの作成処理を書いてみた。
addFile("./install_process.php", "index.php");

//stock( $phar, INSTALL_SOURCE );

// 保存するpharファイル名
$phar->savePhar("install.php");

function stock( &$phar, $dir_name ) {

foreach ( glob( $dir_name . '/*' ) as $filename ) {

$stockname = str_replace( INSTALL_SOURCE . '/', '', $filename );

print $stockname . "\n";
$phar->addFile( $filename, $stockname );
}

}
?>
そして実行すると、install.phpのできあがり。

しかし、これをブラウザから呼び出してみると、思いっきりPHPソースが表示された。
拡張子PHPの他のファイルはちゃんと実行されるのに。
さくらインターネットや@pagesにアップしてみたら、ちゃんと実行された。

ということは、開発環境のサーバが問題らしい。
ファイルの形式がおかしいにしても、拡張子PHPなんだから実行しようとしてくれたっていいのに、そこへも行き着いていない模様。
Apacheのエラーログもなにも出ず、アクセスログにHTTPステータス200が記録される。

一日ぐらい、あれやこれや試してみたんだけど、どうにも原因が分からないので、PHP-usersに投げる。

PEARって、PHP4向けなのかな

今日は昼から図書館のサーバが落ちたままなので、サイトで公開しているスクリプト群がエラーを吐いていた。
図書館サーバから情報を引っ張ってくるのは、PHPの標準で使えるfile_get_contents()を使っていたんだけど、エラーのトラップが出来ないのね。
んで、PEARのHTTP_Requestを使うことにする。
早速変更してみたら、エラーでまくり。
PHP5でワーニング扱いになるオブジェクトの生成参照とか、静的宣言されてない関数を静的に使おうとするとかあたりが引っかかるっぽい。
スクリプトは弊社製PHPフレームワーク上で動いているので、そのへんの警告も全部トラップされてしまって、全然動かない。

結局、一時的にSTRICTは無視するようにしたりして回避。
PEARの中でも、両対応の物もあったりするんだけど、まだまだPHP4向けのままなのかねぇ。
もうPHP4もサポート終わってるし、PHP5も5.2まで出てるというのに。
開発者の方には頑張って欲しいと他力本願（自分で開発に加わるほどリソース空いてないっす）。

PHP5対応

借りているレンタルサーバがPHP4とPHP5のどちらかを選択が出来るようになりました。
とりあえずPEARとjpgraph関連の処理で引っかかる部分がありましたが、それぞれ書き換え・差し替えて対応。
これでPHP5への切り替えが完了。

VisualStudio2005

とりあえず、MFCはちょっとずつ慣れつつ。
C自体が久々なので、なんとなくしっくりこないなぁ。
クラスの循環参照（AがBを参照、BがAを参照）をしたくて、クラスのヘッダファイルでお互いをインクルードしあったらコンパイルが通らない。
#pragma onceをつけててもダメなんか。
結局A.hはB.hをインクルードしつつ、B.hはLPVOID型でポインタだけ持って、B.cppでA.hをインクルードするようにして使う直前にキャストする方向で解決。

あとリソースエディタでダイアログをいじっているのですが、保存した後、必ず最後の「#endif」が「#endi」に書き換わってしまうんだけど、何でだろう？毎回コンパイルエラーでうんざり。
毎回ビルドの前に「f」を書き足しているのですが、ビルド前イベントとかに「f」を書き足すスクリプトでも書けばいいのかね。
バグなんだろうけど、ググってみても話題になってる雰囲気はないし。

仕事で詰まり中

VisualC++が使えると言っても、SDKとMFCは全くべつものだと思うのです。
わたしはSDKはがんがん使うけど、MFCは全く触ったことがないんだよなぁ。
今回初めてクラスウィザード開いたけど、クラスをガシガシ継承していくような使い方をしたことがないから訳ワカメ。

Ethna

仕事の案件でEthnaっていうPHPのフレームワークを使っているのですが…。
うーむ、なんか使いにくいなぁ。
自社のフレームワークは有るものの顧客の要望でEthnaを使っているのですが、なにかと不便というか、いけてない感があります。
たぶんレンダリングエンジンにSmartyを使っている（顧客がSmartyが分かる）からという理由なんだと思いますが。

「それはどうなん？」というやっつけ仕様な部分が多々。
なにぶん一番いけてないと思うのは、同じプロジェクトに属するクラスファイルが片っ端からインクルードされていく件。
複数人で開発したときに、誰か一人でも間違えて記述すると、関係者の他の画面でもエラーになって動かなくなってしまう。
それはどうなん？と。
全員ローカルで開発環境を作って、完成してからアップ？それはそれでリソース的にどうなんかなぁと思ったり。

PHPのHTMLパーサ

趣味で書いているプログラムがあるのですが、仕様上PHPで。
しかもHTMLを解析する必要があるので、HTMLパーサを探していたのですが、なかなかいいのが見つからない。
javascriptのDOMパーサみたいな動きをしてくれると便利なんだけどなぁ。
とりあえず、XML_HTMLSaxで自前のハンドラーを組み立てた。
パースしたいページに合わせてハンドラーを書かないといけないのが面倒ですな。
javascriptのgetElementsByName().innerHTMLは強力すぎる。