私たちのジョブの中には、HTTPやTCPなどのヘルスチェックでは監視できないプロセスを実行するタスクがあります。通常、これは一部のタスクを処理する非同期ワーカーに適用されます。 プロセスがどのように実行されているかを把握するための本当に良い方法はありませんが、これまで、プロセスがianitor
またはconsul-announcer
ているかどうかを監視してきました。 遊牧民に移行している間、遊牧民がこれを除くすべてのヘルスチェックを処理できるようにすることができました。 プロセスの状態を監視するためにTTLベースのヘルスチェックを使用する「監視」にプロセスをラップする必要があります。 そのようなヘルスチェックをNomadに追加できるかどうか疑問に思っています。
@dadgar優先度の観点からこれを上げることができますか? Nomadは、現時点では認識していないプロセスに関連するチェックを削除しているため、TTLを手動で追加してハートビートを設定することはできません。
私の好ましい実装は、ハートビートできるttlチェックIDを公開するサービス関連のenv補間トークンです。 私がやろうとしていたのは、サービスIDを手動で作成し、関連するチェックを登録することでした。
暫定として、多分ちょうどTTLチェックは、同期から無視されるだろうか? それは必ずしも何も壊さないような気がします。
とりあえず、Nomadのサービス登録を使わないようにしなければならないと思います(これは残念です)。
これが拡張機能としてマークされている理由がわかりません。 私の遊牧民の仕事は、(私のコード内で)サービスとして自分自身を登録し、それらのサービスに関連付けられた小切手を登録しています。 (私のコード内)。 nomadがガベージコレクションサイクルを実行すると、サービス/チェックの登録を解除することを決定します。 遊牧民にそれをする権利を与えるものは何ですか? 私の仕事がそれ自体の外部のサービスを登録している場合はどうなりますか(この仕事はたまたまそれ自体を登録しています)? 私にはバグのようです。
編集:これは、service-nameまたはservice-idをnomaddefaultsに設定した場合にのみ発生します。
2019年にこれを強化します。より良いヘルスチェックを必要とする長時間実行デーモンがたくさんあります。 現在、これらはhttpポートを開くことができませんが、調査中です。 TTLチェックが役立つ場合があります。
最も参考になるコメント
@dadgar優先度の観点からこれを上げることができますか? Nomadは、現時点では認識していないプロセスに関連するチェックを削除しているため、TTLを手動で追加してハートビートを設定することはできません。
私の好ましい実装は、ハートビートできるttlチェックIDを公開するサービス関連のenv補間トークンです。 私がやろうとしていたのは、サービスIDを手動で作成し、関連するチェックを登録することでした。
暫定として、多分ちょうどTTLチェックは、同期から無視されるだろうか? それは必ずしも何も壊さないような気がします。
とりあえず、Nomadのサービス登録を使わないようにしなければならないと思います(これは残念です)。