ＭＴ４用ＥＡ開発時代 － サーバ障害／プロセス障害対応と、共通部品「ahfw」Ver1.02リリース

さて前回は、予想外にOrderSend()で「ERR_NO_RESULT」が返却されたため、原因調査と対処方法を検討したところまで書きました。今回は、前回の対処方法を反映した共通部品「ahfw」のリリースのお知らせと、「サーバ障害」と「プロセス障害」の対応方法について検討している様子を書いてみたいと思います。

まずは、前回記事の検討結果を反映した共通部品「ahfw」ベータ版Ver1.02リリースのお知らせです。
＃前回はVer1.01

【共通部品「ahfw」ベータ版バージョンアップ（Ver1.02）のお知らせ】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

●ダウンロード

　以下の共通部品「ahfw」ダウンロード用ＨＰから、ダウンロードしてください。

　→　「MT4用EA開発用共通部品「ａｈｆｗ」」

　　　

●Ver1.02（前回リリースからの差分）

　・修正内容は、OrderSend()/OrderClose()/OrderDelete()で「ERR_NO_RESULT」を検出した
　　際のエラー制御。
　・今回ＥＡ開発にあたって、ソース修正が必要な箇所はありません。

　　新しい[ahfw.mqh」を「include」フォルダにコピーし、リコンパイルするだけでＯＫです。

　・ドキュメントは、仕様変更に伴うメール通知メッセージが主な変更点です。

　・その他のドキュメント修正箇所は、上記ＨＰで参照ください。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

さて、本題。

以前、プロセス障害とサーバ障害対応について当初検討していた方式だと、今のＭＴ４の構成ではダメという内容のブログ記事を書いてました。まずは内容のおさらい。

【障害対策でダメだった理由／見直す方向の方式】（再掲）

－－－－－－－－－－－－－－－－－－－－－－－－

１．ＭＴ４プロセス障害

　　まず、複数のＭＴ４を起動していたら、どのＭＴ４が落ちたのかわからない。

　　なので、どのＭＴ４を再起動していいのかわからない。。

　　あと落ち方も、ダイアログが出て停止してしまったら、プロセス自身は生きてるので、

　　「tasklist」を使ったやり方だとわからない。

２．トレードサーバ長時間通信障害

　　これも、上記「１．」と同様の事が言えて、「netstat -b」だと結局デモ用ＭＴで

　　障害が発生したのか、ライブ用ＭＴ４で障害が発生したのかわからない。

　　＃わかったところで、自宅にいなければ対処できないけど。。

３．ネットワーク障害

　　そもそもトレードサーバとの通信以前に、インターネットに接続できなくなったケース。

　　これは以前の通り、Messengerを起動しておいて、携帯から確認する方法。

　　考慮漏れは無かったけど、方式自体が今一歩。

－－－－－－－－－－－－－－－－－－－－－－－－

今回の記事では、上記「１．」と「２．」に対する対策についてです。

まず打開策のきっかけとなったのは、以下の２つのブログ記事

【参考ブログ記事】

－－－－－－－－－－－－－－－－－－－－－－－－－－－

１．「とあるMetaTraderの備忘秘録」－ Tick更新を待たずに定期的にEA を呼び出す。

２．「とあるMetaTraderの備忘秘録」－ 「システム異常の詳細」からMT4を自動復帰させる

－－－－－－－－－－－－－－－－－－－－－－－－－－－

まずは前述「１．ＭＴ４プロセス障害」に関する検討から。

【ＭＴ４プロセス障害への対応】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

そもそも、前述参考ブログ「２．」に書かれていた、異常発生時にダイアログが出るというパターン
を実は全く想定していなかった。＃なので記事を見つけれて良かった。。。

改めて、ＭＴ４プロセス障害のパターンを洗い出して見ると。

１．プロセス障害パターンの洗い出し

　　Ａ．ＭＴ４が固まってしまう

　　Ｂ．ＭＴ４が勝手に異常終了してしまう

　　Ｃ．前述の通り、異常ダイアログが表示される

次に、ＭＴ４プロセス障害が発生したらどうする予定かというと。

２．ＭＴ４プロセス障害発生時の動作

　　基本的にＭＴ４のプロセス障害検出時は、ＭＴ４を再起動。

　　でも、ＭＴ４が落ちたことには理由があるはずで、ＭＴ４再起動が延々を続いてしまう

　　可能性がある。もしそうなった場合、同じＰＣに同居している他のＭＴ４にも悪影響を

　　与えかねないので、再起動回数の上限値を決めて、それ以上になったら再起動をしない

　　様にする事で対処。今のところ３回を予定。

　　

　　●パターン毎の動作

　　　・ＭＴ４が異常終了しないパターン（上記「Ａ．」／「Ｃ．」の場合）

　　　　検出時にＭＴ４を強制終了させて、ＭＴ４を再起動

　　　・ＭＴ４が異常終了するパターン（上記「Ｂ．」の場合）

　　　　検出時にＭＴ４を起動

　　　・共通次項

　　　　異常検出後のＭＴ４起動は最大回数を決めて、それ以上発生したら、

　　　　ＭＴ４起動はさせない。ただし、手動で意図的にＭＴ４を停止させた場合も、

　　　　ＭＴ４は起動させない。

３．ＭＴ４プロセス異常検出方式の検討

　　そもそもの大方針は、前述参考ブログ「１．」を参考にすることにした。

　　つまり、start()関数内で定期的にループして、基本的にはstart()関数を抜けない。

　　そして、ループの中で障害対応用ロジックを動かすというもの。

　　うーん。これは思いつかなかった！

それでは、上記プロセス障害のパターン毎に対応策

４．プロセス障害パターン毎の処理方式

　　Ａ．「ＭＴ４が固まってしまう」

　　　　実際発生したことないので、よくわかんないんだけど以下の方式にしてみることにした。

　　　　１．ＭＴ４の監視用ＥＡで定期的に監視用のファイルを更新する

　　　　２．上記監視用ファイルのタイムスタンプを定期的にチェックする監視用プログラムを

　　　　　　別に作って、一定時間更新されなければ、ＭＴ４が固まったという判断をする

　　　　３．ＭＴ４が固まったと判定されれば、監視用プログラムから強制終了させる

　　　　４．強制終了させた場合は、ＭＴ４を起動する。

　　Ｂ．「ＭＴ４が勝手に異常終了」

　　　　これも実は未体験。だけど、Windowsコマンドの「taskkill /F -PID [プロセスＩＤ]」で

　　　　発生させることができる。　これへの対策は、以下の様な感じ。

　　　　１．監視用ＥＡで、ＭＴ４終了時は監視用ファイルの中身を消す。

　　　　２．上記「Ａ．」で登場する監視用プログラムから、ＭＴ４を起動する。

　　　　　　→WindowsAPIの「CreateProcess」を使用

　　　　３．上記「CreateProcess」で取得したハンドルを元に、「WaitForSingleObject」

　　　　　　を実行し、結果がプロセス終了となるまで待つ。

　　　　４．プロセス終了を検出したら、監視用ファイルのサイズを確認し、サイズがゼロ

　　　　　　でなければ、異常終了と判定し、ＭＴ４を起動する。

　　Ｃ．「異常ダイアログが表示」

　　　　正直、このパターンが一番苦労した。事象を発生させるのは、参考ブログ「２．」で

　　　　書いてある方法。最初このブログ記事を見た時は、ダイアログ表示後、ＭＴ４が固まって

　　　　しまうだろうから、前述「Ａ．」の方式で大丈夫と思ってた。

　　　　でも、実際やってみると違ってて、監視用ＥＡは動き続けてた。なので前述「Ａ．」の

　　　　方式では検出できない。

　　　　で色々考えた挙句、ちょっと汚いけど、ＭＴ４ルートウィンドウを親に持つポップアップ

　　　　ウィンドウを取得し、そのウィンドウのタイトルに、"システム異常の詳細"という

　　　　文字列が含まれていた場合は異常と見なす事にした。

　　　　そして、異常と判断した場合は、監視ファイルの更新を止める事により、前述「Ａ．」

　　　　の仕組みで強制終了される事になって、その後の流れは同じ。

４．その他

　　ここまでの方式は実際やってみて、とりあえず動作確認まではいった。

　　それでも課題はまだ残ってるので、検討してみた。

　　１．スレッド障害に対応できない

　　　　要は、上記「Ｃ．異常ダイアログが表示」の通り、１つのスレッドで障害が発生しても、

　　　　他のスレッドには影響が及ばない様になっているっぽい。裏を返すと、スレッド個別の

　　　　障害が発生した場合は、検出できない。以下、対策案。

　　　　・各ＥＡでティックデータ受信した時に、時刻を大域変数に格納する。

　　　　　ティックデータ受信後処理に成功したら大域変数をゼロにする。

　　　　　監視用ＥＡで、該当時刻から一定時間経っているのを検出したら、スレッド障害と判断する。

　　２．メール通知してない

　　　　本当はコマンドラインベースのメール送信フリーソフトを使って、通知しようと

　　　　して、２つのメールソフトを見繕ったけど、ＳＭＴＰ認証ロジックが入ってな

　　　　かった。でも、次に試した以下のソフトだと上手くいった。

　　　　→　「メール送信コマンド (WinMailCmd)」

　　　　　　　

　　　　なので、プロセス障害時はこれを使ってメール通知する事に。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　　　　

次は、サーバ長時間障害に関して。

【サーバ長時間障害検出の検討】　　　　

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

まず想定している障害は、サーバが長時間（５分程度？）ダウンしている状態。この場合、ティックデータ受信されないので、普通にしているとＥＡでは気付かない。なので、サーバ長時間障害が発生した場合は、メール通知したい。

異常検出メールを受信しても、ＦＸ業者に電話

するぐらいしかないんですけど。。。

検出方法は、これも基本的には参考ブログ「１．」のアイデアを流用して、start()開始後（つまり最初にティックデータ受信後）IsConnected()チェックをループするという方式。なので、前述の【ＭＴ４プロセス障害への対応】で登場する監視ＥＡで、IsConnected()をチェックし、Ｎ秒間隔で連続何回IsConnected()がFALSEであれば、メール通知するという仕組み。

該当ブログには、同じ目的の以下の記事があるけど、違う方式を取ることにした。

・「とあるMetaTraderの備忘秘録」－ EAでリアルタイム時計を作り、回線切断を警告する。

　　

前述の参考ブログ「１．」／上記ブログとの今回の違いは、時刻差は使わずに、IsConnected()だけを使うのかという点。じゃあなぜ、せっかく有識者が検討した方式を、そのまま流用しないのか？

根性がねじ曲がってるから

それもあるけど、本当はIsConnected()だけで十分じゃないかなぁぐらいの理由。

時刻差をチェックしない場合のデメリットは、ティックデータ受信用セッションは死んでて、
オーダ操作用セッションは生きている場合に検出できないかもしれない点。
＃２つのセッションの使い分けはあくまで仮説。。

でも、「netstat -b」で見てると、ＭＴ４からの接続先ＩＰアドレスとポート番号は

同じなので、ことセッションという観点では、トレードサーバ側が長時間停止した場合は、

２つのセッションがどっちも切れてると思うから大丈夫じゃないかなと。

＃間欠障害だと片方だけってのもあると思うんですけど。。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

そして今回の記事を実現する為に、具体的にどういう構造にしようとしているかという話

【プロセス障害／サーバ障害監視部品構成図】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

今作ってるこの部品を絵にしてみると以下の様な感じ。
※青色の部分が作ったところ。 

●補足説明
　・ＭＴ４を起動する時は、バッチファイルから、ＭＴ４起動用プロセスを起動して、そこからさらに
　　ＭＴ４を起動する。ＭＴ４には、監視用ＥＡをトレードで使わないチャートに貼り付けておく。

　・今回わざわざ起動バッチファイルを分離したかと言うと、メール送信はフリーソフトを使う
　　予定だけど、人（むしろ環境？）によって好みが分かれるはずなので、バッチファイルにした方が
　　汎用性が高い様な気がしたから。

　・「ＭＴ４起動／監視プロセス」はＶＣ＋＋２０１０Ｅｘｐｒｅｓｓで作ったコマンドタイプ

　　のプログラムなので画面なし。画面を用意してないのは、２つ理由がある。

　　　→　今回使ったＶＣ＋＋２０１０はＥｘｐｒｅｓｓ版という無償バージョンを使ってる。これで

　　　　　画面付のアプリを作ると、利用者は別途２つのＭＳのモジュールをインストールしないといけ

　　　　　ないっぽい。配布するにはちょっと不適切。

　　　→　ここ１０数年ＶＣ＋＋使った事なくて、画面制御するプログラム組むのに時間がかかる。

　　　　　＃また勉強しなきゃいけないし。。大体、Windowsのプログラミング自体が久しぶり。。

これに、スレッド障害検出機能と、メール通知機能を追加したら、方式もまたちょっと変わるかもしれないし、本格的にはまだ動作させてないので、方式も動かしてるうちに変わってくるかも。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

今日のブログは結局、

他人のフンドシで

相撲を取ってる状態。。

許してくださいm(__)m

そして、許しを請いながら「FXシステムトレード初心者奮闘記」の「ＭＴ４用ＥＡ開発時代」は、今回記事のプログラムを作りながら、どこかに向かうのでした。

＃まだデモ口座上ＥＡのstart()排他処理したままの状態や。。。ぼちぼち外さないと。。。