100以上のサービス監視

これはコメントでなければなりませんが、少し長いです。

監視できるフリーソフトウェアパッケージが多すぎることを考えると、これは問題を解決する奇妙な方法のようです。

規模の問題があります（規模の問題は常に存在しますが、より適切なプラットフォームを使用すると、これらの問題は数倍になる可能性があります）。たとえば、各インスタンスが応答するのに1秒以上かかるとどうなりますか？機能的な問題があります。ウォッチウィンドウを定義する方法、問題を知らせる方法、監視したいが通知しないウィンドウはどうですか？介入の効果を測定するために記録をどのように管理しますか？ ...

結局、モニタリングプラットフォームで実行されます。早く始めるほど、今後は痛みが少なくなります。

スクリプトも必要なく、ポーリングも必要ありません。 systemdは、デバイスが失敗したときに何かを開始する方法をすでに知っています。このOnFailure=ガイドラインをお読みください。たとえば、カールを使用してエラーユニット名でRESTエンドポイントを呼び出すなど、ワンタイムサービスを簡単に定義できます。

これを行う方法はいくつかあります。既存のモニタリングソリューションを使用するか、より基本的なソリューションを構築するかを選択できます。時間と労力を投資する価値があるかどうかを判断するには、市場調査を行い、ソリューションを他の要件に合わせて一般化できるかどうかを確認します。

個人的には、デモ目的でPrometheus + Grafana + Alert Managerを選択しますが、これは事前の経験があり、すでにこれらのツールを使用しているためです。

簡単に言えば、APIエンドポイントを公開するのがアイデアです。あなたのアプリケーションに所定のポート（いわゆるプロメテウス）から輸出業者）。その後、Prometheusインスタンスはエンドポイント（「ターゲット」）に接続し、次のものを取得します。索引定期的に（デフォルトは通常15秒）

GoまたはPythonを使用している場合は、アプリケーションにエクスポートを簡単に含めることができます。したがって、使用する技術スタックによって異なります。

後で役に立つかもしれませんが、今は指標に興味がないかもしれません。ただし、アラートマネージャを使用すると、特定の時間または接続試行後にエンドポイントが応答しなくなったときにアラートを受信できます。これは通常、デバイスにアクセスできないか、エンドポイントがクラッシュしたことを意味します。あなたが欲しいと思います。

1つの利点は次のとおりです。歴史また。したがって、問題が発生した時期を知ると（ログに関連付けられて）、問題を簡単に追跡できます。

アーキテクチャで許可されている場合は、監視に別のデバイスを使用するのが合理的です。ここでのアイデアは、外部プロキシにサービスを調査（プール）させることです。失敗したサービスが常に通知（プッシュ）を送信し、正常に中断される可能性はありません。

しかし、あなたのサービスが内部的に実際に何をしているのかを知ることは興味深いでしょう。つまり、失敗が何を意味するのか、目的の結果がどのように見えるべきかを定義します。サービスがHTTPクエリに応答しても、必ずしも期待どおりに機能するわけではありません。これは、インターネットアクセス、ファイルアクセス、またはその他の機能などの特定の機能によって異なります。指標が便利な場所です。

たとえば、Webサーバーのエクスポートは、送信されたバイトや提供されたページなどの指標の累積および平均データを返します。数字の一部がゼロに落ちると、どこかに問題があると思われる可能性があります。結局、Webサーバーは正常に動作しますが、アップストリームネットワークの中断によってアクセスできなくなり、指標が中断される可能性があります。

APIエンドポイントを持つのは楽しいですが、単に「起こりました」と言うよりも、実際に役立つ情報を提供する場合ははるかに面白いでしょう。