- PR -

異常終了の判断方法

1|2 次のページへ»
投稿者投稿内容
jojo
会議室デビュー日: 2007/03/19
投稿数: 16
投稿日時: 2007-04-05 10:40
お世話になります。

.NetFramework2.0(VB)を使ったアプリケーションで、
そのアプリケーションが異常終了したかどうかを、
検知するプログラムを考えています。

また、その異常終了というのは、通常の例外処理で検知
できないようなエラー(例えば、タスクマネージャから
プロセスを強制的に中断された場合）
を想定してます。イベントログを調べる事は想定していません。

構想としてあるのは、

１．その異常終了を検知したいアプリケーションの
　プロセス、あるいはスレッドが特定し、その情報を
　データベースに書き込む
　
２．異常終了を検知するプログラムは、今PC上で
　実行中のプロセス、あるいはスレッドの一覧の中から、
　検知したいプロセス、あるいはスレッド(=DBに書き込まれている)
　があるかどうかを調べる。

のようなプログラムを想定しています。
あくまで、これは一つの構想であり、
別の方法で検知可能なのであれば、それでも
全く構いません。

実現方法等を調べているのですが、
実際にどのようにコーディングしたらよいのか、
あるいはどのようなライブラリを使うと良いのか
が分かりません。

どういった方法が実用上考えられるでしょうか？
ご教授いただきたく、よろしくお願いします。 m(_ _)m

よねＫＥＮ
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2007-04-05 10:58
質問を読んでいろいろと疑問が沸きました。

1. 異常検知して(その結果を利用して)何をしたいのでしょうか？
→異常検知をすること自体は本質的な目的ではないはずです。
よりよい解決策を模索するには最終的な目的を明記した方がよいです。
2. .NET2.0製アプリケーションとはjojoさんのところで作ったアプリですか？
→ないと思うけど、異常検知を行う汎用的なツールを開発しているとかだと
異常検知対象のアプリ側をいじれないので。
3. どういうタイミングで検知したいのでしょうか？
→なんとなくリアルタイムに判断したいようにも取れますが、
実際はどうでしょうか。
4. システム的に見て、異常終了と正常終了の判断基準は何でしょうか？
→ここは今悩まれている部分の一部かもしれませんが、検討中の案では、
正常終了とどう区別するのか不明でしたので。

さて、1.〜4.の答えによるので、はずしているかもしれませんが、
検知対象のアプリ側がいじれるとしての案です。

起動ログと終了ログ、必要に応じてその間の操作ログをファイルなどに
出力するようにしておければ、そのファイルを確認すれば、
異常終了したかどうかは判定できると思います。

リアルタイムに異常終了が発生していないかを判断したいなら、
ハートビートを使って判断できると思います。
開始の合図と終了の合図、そして開始と終了の間は、
一定の感覚で今生きているぞ！という合図を送り続けます。
合図の送り方はファイルやDBに何か書き込むとか、
サーバーに何か通信するとか、いろいろな方法が考えられると思います。
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市（は俺も含めてロクな人間が住んでないよｗ）
投稿日時: 2007-04-05 11:09
これって監視系のアプリケーションをべつに作るってこと？
そりゃ変な話だな。起動した側で面倒を見るべきでしょ。終了コードとかで。
間接的に起動させてくれれば終了コードで判定に一票。
YASUYOKA
ベテラン
会議室デビュー日: 2007/03/19
投稿数: 71
投稿日時: 2007-04-05 11:29
引用:

ぶさいくろうさんの書き込み (2007-04-05 11:09) より:
これって監視系のアプリケーションをべつに作るってこと？


スクラッチで製造するよりは、プロセス監視系の製品を導入
することをお勧めしますよね。 > 元質問者殿
#有償で結構高価ですが、それなりの効果はあります。

jojo
会議室デビュー日: 2007/03/19
投稿数: 16
投稿日時: 2007-04-05 11:59
よねＫＥＮさま
ぶさいくろうさま
YASUYOKAさま

ご返答ありがとうございます。
長文で申し訳ありませんが、ご回答します。

>1. 異常検知して(その結果を利用して)何をしたいのでしょうか？
>→異常検知をすること自体は本質的な目的ではないはずです。
>よりよい解決策を模索するには最終的な目的を明記した方がよいです。

すみません、話をはしおりすぎました。

スマートクライアント型のシステム開発をしていまして、
クライアント-APサーバ-DBサーバでの構成です。

クライアント-APサーバ間はWebサービス、
APサーバ-DBサーバ間はADO.net
という想定です。

そのDBサーバ側で、長時間実行される処理があります。

処理の順番としては

1.ユーザ(クライアント)から長時間実行される処理の
　リクエストがある

2.予約情報が、予約確認テーブルに書き込まれる
　(この時点で、ユーザには処理予約が完了しました的なメッセージを返す)

3.DBサーバ側で、定期的に予約情報テーブルを見に行き、
　予約情報を確認後、その処理を行う。処理の進捗は、
　別途処理進捗テーブルに書き込む

4.ユーザ側では、その後の進捗は別途立ち上げるプログラム
　から、DBサーバの進捗テーブルを確認することで
　処理状況(処理開始待ち/進行中/処理完了)を判断する

という流れです。何を心配しているかというと、
プロセスが落ちるような異常処理があった場合に、現在の方法
では、ユーザからの進捗確認は「進行中」で止まって
しまいます。そこを、「異常終了しました」と表示させたい、ということです。



>2. .NET2.0製アプリケーションとはjojoさんのところで作ったアプリですか？
>→ないと思うけど、異常検知を行う汎用的なツールを開発しているとかだと
>異常検知対象のアプリ側をいじれないので。

私のところで作成する予定のアプリケーションになりますので、
これはいかようにもコーディング可能です。

>3. どういうタイミングで検知したいのでしょうか？
>→なんとなくリアルタイムに判断したいようにも取れますが、
>実際はどうでしょうか。

これは、クライアント側にある処理チェッカ
が処理の進捗を確認することを想定しています。
（定期的に見に行く想定です）


>4. システム的に見て、異常終了と正常終了の判断基準は何でしょうか？
>→ここは今悩まれている部分の一部かもしれませんが、検討中の案では、
>正常終了とどう区別するのか不明でしたので。

今回の件については
異常終了＝例外処理でキャッチできない終了(=プロセス強制終了が
　これに当たると思います)
正常終了＝本当の意味での正常終了＋例外処理でキャッチ可能なエラー
になります。

というのは、例外処理でキャッチできるエラーであれば、
異常終了というステータスを処理進捗テーブルに書き込む事が
可能になるから、という意味です。


>起動ログと終了ログ、必要に応じてその間の操作ログをファイルなどに
>出力するようにしておければ、そのファイルを確認すれば、
>異常終了したかどうかは判定できると思います。

上記方法は,プロセス強制終了などのケースを想定すると
ログに書くこと自体が困難という認識です。


>リアルタイムに異常終了が発生していないかを判断したいなら、
>ハートビートを使って判断できると思います。
>開始の合図と終了の合図、そして開始と終了の間は、
>一定の感覚で今生きているぞ！という合図を送り続けます。
>合図の送り方はファイルやDBに何か書き込むとか、
>サーバーに何か通信するとか、いろいろな方法が考えられると思います。

なるほど。ハートビートは使えるかもしれませんね。
但し、ハートビートは正常に動作していたとしても
一定間隔で本当に送信できるか？といった疑問はあります。
例えば非常に一つのステップが重たい処理があると、ハートビートは
一定間隔で送れなくなるような気もします。

別スレッドを作って、そこでハートビートを、、
という考え方もあると思いますが、スレッドが死ぬ(こんなことが
あるのかわかりませんが??)事がもしあれば
処理のスレッドだけ死んでハートビートだけ
生き残るといった場合に検知できないような気がします。


>これって監視系のアプリケーションをべつに作るってこと？
>そりゃ変な話だな。起動した側で面倒を見るべきでしょ。終了コードとかで。
>間接的に起動させてくれれば終了コードで判定に一票。

先ほどのよねKENさんへの回答と若干かぶりますが、
ユーザは別プロセスで進捗を確認することを想定しています。
今回想定している異常終了に関しては、終了コードを取得するのが難しいと
認識しています。

>スクラッチで製造するよりは、プロセス監視系の製品を導入
>することをお勧めしますよね。 > 元質問者殿
>#有償で結構高価ですが、それなりの効果はあります。

申し訳ありませんが、
プロジェクト的に、新規にソフトウェアを今から導入するのは
難しいと思われます。。



[ メッセージ編集済み 編集者: jojo 編集日時 2007-04-05 12:21 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2007-04-05 12:17
サービスで作って、異常終了してもサービスは再起動し、処理を継続あるいはステータスを変更出来るようにする。

その他、WIN32APIを調べるよろし。
シャットダウン前にくるメッセージとか、それをキャンセルする方法とか、あると思う。
_________________
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2007-04-05 12:50
引用:

jojoさんの書き込み (2007-04-05 11:59) より:
今回の件については
異常終了＝例外処理でキャッチできない終了(=プロセス強制終了が
　これに当たると思います)
正常終了＝本当の意味での正常終了＋例外処理でキャッチ可能なエラー
になります。

たとえば、よくお目にかかる例としては、IE などは、異常終了でプロセスが落ちると、それを検知してプロセスを再起動するようです。IE のプロセスを監視する別のプロセスがあるのでしょうか。良くは知りませんが。

引用:

jojoさんの書き込み (2007-04-05 11:59) より:
というのは、例外処理でキャッチできるエラーであれば、
異常終了というステータスを処理進捗テーブルに書き込む事が
可能になるから、という意味です。

ただ、今回は、プロセスの異常終了を検出するよりは、DB をポーリングしてもいつになってもステータスが変化しない、というイベントを捉えたほうが良いような気がします。(タイムアウトという概念を自分で実装することになります。)
なお、スレッドのタイトルにも書かれてはいることですが、なにを「異常」と判断するのかを、もっと明確にされたほうが良いと思います。たとえば、「異常」であることを判断するのか、「異常終了」したことを判断するのか、といったところを詰めたほうが良いと思います。

また、プロセスが「異常終了」したことを気にしていたら、ほかにもいろいろと信用できなくなってしまいますので、あるところで切り捨てないと、際限なく心配の種が広がってしまいます。LANが切れたらどうしよう、メモリーが不足したらどうしよう、などなど。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2007-04-05 13:29
実際に処理をおこなうプロセスは進捗テーブルへの挿入と更新はおこなうが、正常終了するまでコミットしない。進捗をモニタするプロセスは進捗テーブルをダーティリードする。

実際に処理をおこなうプロセスが異常終了した場合、つまりコミットせずにプロセスが終了した場合はトランザクションがロールバックされるため、進捗テーブルへレコードが挿入されていない状態に戻る。進捗をモニタするプロセスは進捗テーブルから対象レコードが取得できなかったら、処理プロセスが異常終了したと判断する。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）