私たちは象を部分的に食べます。 アプリケーションの健全性監視戦略と例

みなさん、こんにちは！

当社はソフトウェア開発とその後の技術サポートを行っております。 テクニカル サポートには、エラーを修正するだけでなく、アプリケーションのパフォーマンスを監視することも必要です。

たとえば、サービスの XNUMX つがクラッシュした場合、不満を抱いたユーザーがテクニカル サポートに連絡するのを待つのではなく、この問題を自動的に記録して解決を開始する必要があります。

私たちの会社は小規模で、アプリケーションを監視するための複雑なソリューションを研究して維持するためのリソースがありません。シンプルで効果的なソリューションを見つける必要がありました。

モニタリング戦略

アプリケーションの機能をチェックするのは簡単ではありません。このタスクは簡単ではなく、創造的であるとさえ言えるかもしれません。 複雑なマルチリンク システムを検証することは特に困難です。

どうやって象を食べることができますか？ 部分的にのみ！ 私たちはこのアプローチを使用してアプリケーションを監視します。

私たちのモニタリング戦略の本質:

アプリケーションをコンポーネントに分割します。
各コンポーネントのコントロール チェックを作成します。

すべての制御チェックがエラーなしで実行された場合、コンポーネントは動作しているとみなされます。 すべてのコンポーネントが機能している場合、アプリケーションは正常であるとみなされます。

したがって、あらゆるシステムをコンポーネントのツリーとして表すことができます。 複雑なコンポーネントはより単純なコンポーネントに分割されます。 単純なコンポーネントにはチェックが付いています。

ベンチマークは機能テストを実行することを目的としたものではなく、単体テストでもありません。 制御チェックでは、コンポーネントが現時点でどのように感じているか、機能するために必要なリソースがすべてあるかどうか、問題がないかどうかを確認する必要があります。

奇跡は起こりません。ほとんどのチェックは独自に開発する必要があります。 ただし、心配する必要はありません。ほとんどの場合、5 つのチェックには 10 ～ XNUMX 行のコードが必要ですが、任意のロジックを実装でき、チェックがどのように機能するかを明確に理解できるからです。

監視システム

アプリケーションをコンポーネントに分割し、コンポーネントごとにチェックを考えて実装したとします。しかし、これらのチェックの結果はどうすればよいでしょうか? チェックが失敗したかどうかをどうやって知ることができるでしょうか?

監視システムが必要になります。 彼女は次のタスクを実行します。

• テスト結果を受け取り、それを使用してコンポーネントのステータスを判断します。
  視覚的には、これはコンポーネント ツリーを強調表示しているように見えます。 機能的なコンポーネントは緑色に変わり、問題のあるコンポーネントは赤色に変わります。
• すぐに使用できる一般的なチェックを実行します。
  監視システム自体がいくつかのチェックを実行できます。 車輪を再発明する必要があるので、それを使用しましょう。 たとえば、Web サイトのページが開いているか、サーバーが ping を実行しているかを確認できます。
• 関係者に問題の通知を送信します。
• モニタリングデータの可視化、レポート、グラフ、統計の提供。

ASMOシステムの簡単な説明

例を挙げて説明するのが一番良いでしょう。 ASMO システムのパフォーマンスの監視がどのように行われるかを見てみましょう。

ASMO は自動気象支援システムです。 このシステムは、道路サービスの専門家が、道路をいつどこで除氷剤で処理する必要があるかを理解するのに役立ちます。 このシステムは道路管理ポイントからデータを収集します。 道路管制点は、気象観測所やビデオカメラなどの機器が設置されている道路上の場所です。 危険な状況を予測するために、システムは外部ソースから天気予報を受け取ります。

したがって、システムの構成は非常に一般的です。Web サイト、エージェント、機器です。 監視を始めましょう。

システムをコンポーネントに分割する

ASMO システムでは次のコンポーネントを区別できます。

1.個人アカウント
これはWebアプリケーションです。 少なくとも、アプリケーションがインターネット上で利用可能であることを確認する必要があります。

2. データベース
データベースにはレポート作成にとって重要なデータが保存されるため、データベースのバックアップが正常に作成されていることを確認する必要があります。

3. サーバー
サーバーとは、アプリケーションが実行されるハードウェアを意味します。 HDD、RAM、CPUの状態を確認する必要があります。

4. エージェント
これは、さまざまなタスクをスケジュールに従って実行する Windows サービスです。 少なくとも、サービスが実行中であることを確認する必要があります。

5. エージェントのタスク
エージェントが機能していることを知っているだけでは十分ではありません。 エージェントは動作する可能性がありますが、割り当てられたタスクを実行できない場合があります。 エージェント コンポーネントをタスクに分割し、各エージェント タスクが正常に動作するかどうかを確認してみましょう。

6. 道路管理ポイント (すべての MPC のコンテナ)
道路管理ポイントはたくさんあるので、すべての MPC を XNUMX つのコンポーネントに結合しましょう。 これにより、監視データの読み取りがより便利になります。 「ASMO システム」コンポーネントのステータスを表示すると、アプリケーション、ハードウェア、または最大制御システムのどこに問題があるかがすぐにわかります。

7. 道路規制点（上限は XNUMX つ）
この MPC 上のすべてのデバイスが保守可能であれば、このコンポーネントは保守可能であるとみなされます。

8. デバイス
これは、最大濃度限界で設置されたビデオカメラまたは気象観測所です。 デバイスが正常に動作していることを確認する必要があります。

監視システムでは、コンポーネント ツリーは次のようになります。

Webアプリケーションの監視

システムをコンポーネントに分割したので、各コンポーネントのチェックを考え出す必要があります。

Web アプリケーションを監視するには、次のチェックを使用します。

1. メインページの開き具合を確認する
このチェックは監視システムによって実行されます。 これを実行するには、ページ アドレス、予想される応答フラグメント、および最大要求実行時間を指定します。

2. ドメイン支払い期限の確認
非常に重要なチェックです。 ドメインが未払いのままであると、ユーザーはサイトを開けることができません。 問題の解決には数日かかる場合があります。理由は... DNS の変更はすぐには適用されません。

3. SSL証明書の確認
現在、ほとんどすべての Web サイトがアクセスに https プロトコルを使用しています。 プロトコルが正しく機能するには、有効な SSL 証明書が必要です。

以下は、監視システムの「個人アカウント」コンポーネントです。

上記のチェックはすべてほとんどのアプリケーションで機能し、コーディングは必要ありません。 あらゆる Web アプリケーションの監視を 5 分で開始できるため、これは非常に優れています。 以下に Web アプリケーションに対して実行できる追加のチェックを示しますが、その実装はより複雑でアプリケーション固有であるため、この記事では説明しません。

他に何を確認できますか?

Web アプリケーションをより完全に監視するには、次のチェックを実行できます。

• 期間ごとの JavaScript エラーの数
• 期間中のWebアプリケーション側（バックエンド）のエラー数
• 失敗した Web アプリケーション応答の数 (応答コード 404、500 など)
• 平均クエリ実行時間

Windows サービス (エージェント) の監視

ASMO システムでは、エージェントはタスク スケジューラの役割を果たし、スケジュールされたタスクをバックグラウンドで実行します。

すべてのエージェント タスクが正常に完了すると、エージェントは適切に動作しています。 エージェントを監視するには、そのタスクを監視する必要があることがわかりました。 したがって、「エージェント」コンポーネントをタスクに分割します。 タスクごとに、監視システム内に個別のコンポーネントを作成します。ここで、「エージェント」コンポーネントが「親」になります。

Agent コンポーネントを子コンポーネント (タスク) に分割します。

そこで、複雑なコンポーネントをいくつかの単純なコンポーネントに分割しました。 次に、単純なコンポーネントごとにチェックを作成する必要があります。 監視システムは子コンポーネントのステータスに基づいてそのステータスを独立して計算するため、親コンポーネント「エージェント」にはチェックが行われないことに注意してください。 つまり、すべてのタスクが正常に完了すると、エージェントは正常に実行されます。

ASMO システムには XNUMX を超えるタスクがありますが、各タスクに固有のチェックを作成する必要は本当にあるのでしょうか? もちろん、エージェントのタスクごとに独自の特別なチェックを考え出して実装すれば、制御はより良くなりますが、ほとんどの場合、ユニバーサル チェックを使用するだけで十分です。

ASMO システムはタスクのユニバーサル チェックのみを使用するため、システムのパフォーマンスを監視するにはこれで十分です。

進捗状況を確認中
最も簡単で効果的なチェックは実行チェックです。 このチェックでは、タスクがエラーなしで完了したことが検証されます。 すべてのタスクにこのチェックが付いています。

検証アルゴリズム

各タスクの実行後、タスクの実行が成功した場合は SUCCESS チェックの結果を監視システムに送信し、実行がエラーで完了した場合は ERROR を送信する必要があります。

このチェックでは、次の問題を検出できます。

1. タスクは実行されますが、エラーで失敗します。
2. タスクがフリーズしたなどして、実行が停止しました。

これらの問題がどのように解決されるかを詳しく見てみましょう。

問題 1 – タスクは実行されますが、エラーで失敗します。
以下は、タスクが実行されますが、14:00 から 16:00 の間に失敗するケースです。

この図は、タスクが失敗すると、すぐに監視システムに信号が送信され、監視システム内の対応するチェックのステータスがアラームになることを示しています。

監視システムでは、コンポーネントのステータスが検証ステータスに依存することに注意してください。 チェックのアラーム ステータスにより、すべての上位コンポーネントがアラームに変更されます。以下の図を参照してください。

問題 2 - タスクの実行が停止した (フリーズした)
監視システムはタスクが滞っていることをどのようにして理解するのでしょうか?

チェック結果の有効期限は、例えば１時間である。 1 時間が経過しても新しいテスト結果がない場合、監視システムはテスト ステータスをアラームに設定します。

上の写真は午後14時に消灯したものです。 00:15 に、監視システムはテスト結果 (00:14 から) が腐っていることを検出します。 関連時間 (00 時間) が経過しましたが、新しい結果はなく、チェックがアラーム ステータスに切り替わります。

16:00に照明が再び点灯し、プログラムはタスクを完了し、実行結果を監視システムに送信し、テストステータスは再び成功になります。

関連性チェック時間はどれくらいを使用すればよいですか?

関連時間はタスクの実行期間よりも長い必要があります。 関連時間をタスク実行期間の 2 ～ 3 倍に設定することをお勧めします。 これは、タスクに通常より時間がかかったり、誰かがプログラムをリロードしたりした場合などに、誤った通知を受け取ることを避けるために必要です。

進捗状況を確認中

ASMO システムには「予測のロード」タスクがあり、2 時間に XNUMX 回外部ソースから新しい予測をダウンロードしようとします。 新しい予測が外部システムに表示される正確な時間は不明ですが、これが XNUMX 日に XNUMX 回発生することが知られています。 数時間新しい予報がない場合は正常ですが、XNUMX 日以上新しい予報がない場合は、どこかで何かが壊れていることがわかります。 たとえば、外部予測システムのデータ形式が変更される可能性があるため、ASMO では新しい予測リリースが表示されません。

検証アルゴリズム

タスクは、進捗状況の取得 (新しい天気予報のダウンロード) に成功すると、SUCCESS チェックの結果を監視システムに送信します。 進行状況がない場合、またはエラーが発生した場合、監視システムには何も送信されません。

チェックには、この期間中に新しい進行状況を受け取ることが保証されるような関連性間隔が必要です。

監視システムは最後のスキャン結果の有効期間が終了するまで待機するため、問題の把握が遅れることに注意してください。 したがって、小切手の有効期間をあまり長くする必要はありません。

データベースの監視

ASMO システムのデータベースを制御するために、次のチェックを実行します。

1. バックアップ作成の確認
2. ディスクの空き容量を確認する

バックアップ作成の確認
ほとんどのアプリケーションでは、サーバーに障害が発生した場合にプログラムを新しいサーバーに展開できるように、最新のデータベースのバックアップを作成することが重要です。

ASMO は週に 9 回バックアップ コピーを作成し、ストレージに送信します。 この手順が正常に完了すると、成功チェックの結果が監視システムに送信されます。 検証結果の有効期間は XNUMX 日間です。 それらの。 バックアップの作成を制御するには、上で説明した「進行状況チェック」メカニズムが使用されます。

ディスクの空き容量を確認する
ディスク上に十分な空き領域がないと、データベースが適切に機能しなくなるため、空き領域の量を制御することが重要です。

数値パラメータを確認するにはメトリクスを使用すると便利です。

指標 は数値変数であり、その値は監視システムに送信されます。 監視システムはしきい値をチェックし、メトリクスのステータスを計算します。

以下は、監視システム内の「データベース」コンポーネントがどのように見えるかを示しています。

サーバー監視

サーバーを監視するには、次のチェックとメトリックを使用します。

1. ディスクの空き容量
ディスク容量が不足すると、アプリケーションは動作できなくなります。 2 つのしきい値を使用します。最初のレベルは警告、XNUMX 番目のレベルは警報です。

2. RAM の平均値 (XNUMX 時間あたりのパーセント)
時間平均を使用する理由は次のとおりです。 私たちは珍しい人種には興味がありません。

3. XNUMX 時間あたりの平均 CPU パーセンテージ
時間平均を使用する理由は次のとおりです。 私たちは珍しい人種には興味がありません。

4. Pingチェック
サーバーがオンラインであることを確認します。 監視システムはこのチェックを実行できるため、コードを記述する必要はありません。

以下は、監視システム内の「サーバー」コンポーネントがどのように見えるかを示しています。

設備監視

データの取得方法について説明します。 道路管理ポイント (MPC) ごとに、タスク プランナーにタスクがあります (たとえば、「Survey MPC M2 km 200」)。 タスクは、すべての MPC デバイスから 30 分ごとにデータを受信します。

通信チャネルの問題
ほとんどの機器は市外にあり、データ送信には GSM ネットワークが使用されますが、安定して動作しません (ネットワークがあるかないか)。

ネットワーク障害が多発したため、当初モニタリングでMPC調査を確認すると次のようになりました。

問題に関する誤った通知が多数あったため、これが有効なオプションではないことが明らかになりました。 次に、各デバイスに対して「進行状況チェック」を使用することが決定されました。 デバイスがエラーなしでポーリングされた場合、成功信号のみが監視システムに送信されます。 関連時間は 5 時間に設定されました。

モニタリングでは、デバイスが 5 時間以上ポーリングできない場合にのみ、問題に関する通知が送信されるようになりました。 高い確率で、これらは誤報ではなく、実際の問題です。

以下は、監視システム内の機器がどのように見えるかを示す図です。

重要！
GSM ネットワークが動作を停止すると、すべての MDC デバイスがポーリングされなくなります。 監視システムからの電子メールの数を減らすために、当社のエンジニアはコンポーネントの問題に関する通知を「デバイス」ではなく「MPC」タイプで購読しています。 これにより、デバイスごとに個別の通知を受信するのではなく、MPC ごとに XNUMX つの通知を受信できるようになります。

最終的な ASMO モニタリングスキーム

すべてをまとめて、どのような監視スキームがあるかを見てみましょう。

まとめ

要約しましょう。
ASMO のパフォーマンスを監視することで何が得られたのでしょうか?

1. 欠陥除去時間の短縮
以前にユーザーから不具合について報告を受けましたが、すべてのユーザーが不具合を報告するわけではありません。 たまたま、システムコンポーネントの不具合が発生してからXNUMX週間後にそのことを知りました。 現在、監視システムは問題が検出されるとすぐに問題を通知します。

2. システムの安定性が向上しました
欠陥が早期に排除され始めたため、システム全体がより安定して動作し始めました。

3. テクニカルサポートへの電話回数の削減
多くの問題は、ユーザーが気づく前に修正されるようになりました。 ユーザーはテクニカル サポートに連絡する頻度が減りました。 これらすべてが当社の評判に良い影響を与えます。

4. 顧客とユーザーのロイヤルティの向上
お客様は、システムの安定性に良い変化があることに気づきました。 ユーザーがシステムを使用する際に遭遇する問題が少なくなります。

5. テクニカルサポートコストの削減
手動チェックの実行を停止しました。 現在はすべてのチェックが自動化されています。 以前は、ユーザーから問題について学習していましたが、ユーザーがどのような問題について話しているのかを理解するのが難しいことがよくありました。 現在、ほとんどの問題は監視システムによって報告されており、通知には技術データが含まれているため、何がどこで問題になったかが常に明確になります。

重要！
アプリケーションが実行されているのと同じサーバーに監視システムをインストールすることはできません。 サーバーがダウンすると、アプリケーションは動作を停止し、それを通知する人がいなくなります。

監視システムは、別のデータセンターの別のサーバーで実行する必要があります。

新しいデータセンターで専用サーバーを使用したくない場合は、クラウド監視システムを使用できます。 当社では Zidium クラウド監視システムを使用していますが、他の監視システムを使用することもできます。 クラウド監視システムのコストは、新しいサーバーをレンタルするよりも低くなります。

推奨事項：

1. アプリケーションとシステムをコンポーネントのツリー形式でできるだけ詳細に分割すると、どこで何が壊れているのかを理解しやすくなり、制御がより完全になります。
2. コンポーネントの機能を確認するには、テストを使用します。 XNUMX つの複雑なチェックを行うよりも、単純なチェックを多数使用する方が良いでしょう。
3. メトリクスのしきい値は、コードで記述するのではなく、監視システム側で構成します。 これにより、アプリケーションを再コンパイル、再構成、または再起動する必要がなくなります。
4. カスタム チェックの場合、一部のチェックは完了までに通常よりも時間がかかるため、誤った通知を受信しないように、関連時間に余裕を持ってください。
5. 明らかに問題がある場合にのみ、監視システムのコンポーネントが赤になるようにしてください。 無駄に赤くなってしまうと、監視システムの通知に注意を払わなくなり、その意味が失われます。

まだ監視システムを使用していない場合は、始めてください。 思っているほど難しくありません。 自分で育てた緑の原料の木を見て興奮してください。

幸運。

出所： habr.com