Webサービスのパフォーマンスの監視。 パートI

開発プロセスが適切にセットアップされるほど、リリースでのパフォーマンスの問題は少なくなります。 一方、開発プロセス中にWebサービスの動作条件に関して「仮定」が行われ、人生は常に独自の調整を行うという単純な理由により、完全に回避することはできません。



多くは、そのような問題が発生する頻度とその修正の速さ-ユーザーのサービスに対する満足度、開発者の評判などに依存します。 パフォーマンスの問題にどのように対処できますか？



シナリオの1つは受動的反応です。 利用可能になったときに問題を解決します。 この場合、サポートサービスは、「クリティカルマス」が発生する前に苦情を蓄積し、開発者を引き付けます。 開発者は問題の検索と修正にしばらく時間を費やし、Webサービスは再びタスクの迅速な処理を開始します。



このオプションの主な欠点は、開発者が面倒を見る前に、ユーザーがWebサービスの応答性を完全に「楽しむ」時間があることです。 しかし、この後の問題はまだ見つかっていません。 別の欠点は、開発者が「昨日」の期限に取り組む必要があることです。これも印象的ではありません。



別のオプションは、 擬似アクティブ実装です。 すべてを監視するためにいくつかのユーティリティがインストールされており、タンバリンを持つ主なシャーマンは時々チャートを見て、問題の事実を特定しようとします。



シャーマンは退屈なグラフや数字を見ることにうんざりしているため、このオプションは最初のオプションと大差ありません。ほとんどの場合、同じ最初のオプションになります。 しかし、シャーマンが苦情の雪崩の前に問題を認識できたとしても、問題を見つけて修正するにはまだ時間がかかります。



別のシナリオが必要です。これにより、最小限のコストで「後れを取らない」ことができ、問題の原因を迅速に特定できます。

積極的な監視

プロアクティブな監視には次の2つの意味があります。

1. 電話、SMS、えら、icqまたは石鹸による問題の積極的な通知。
2. ローカライズとトラブルシューティングのための明確な行動計画。

既製の監視システムで通知を作成すると便利です。これには世界中に多くの監視システムがあります。 彼らは多くの愛好家なので、膝蓋骨は考慮しません。 しかし、専門家からは、 サボテン 、 ナギオス 、およびザビックスについて言及したいと思います。 しかし、ホットで相互に愛されているZabbixのみ（またはサボテンの何かを見逃しましたか？） は通知要件に適しており、 nagiosは問題の分析に非常に役立つ履歴データの保存にはあまり適していません。



アラートを使用すると、現地のシャーマンを真剣に解放します。1日数百のスケジュールをその場でじっと見つめる代わりに、携帯電話をポケットに入れて持ち運ぶだけで十分です。 唯一の質問は、何をどのように監視するかです。



パフォーマンスについて話し、他のトピックに触れない場合は、平均応答時間という1つのパラメーターのみを監視するだけで十分です。 Webサービスの要件で指定された値を超える場合、問題が発生しているため、さらに迅速に対処する必要があります。 これを行うには、ある時点で時間を費やし、問題を特定するための作業を計画する必要があります。



要求処理スキームを作成して、計画を開始する必要があります。 このようなスキームの例は次のとおりです。







この図には、オプションと必須の2つのタイプのコンポーネントがあります。 Webサーバーやハンドラーなどの必須は要求処理に常に存在し、それらへのアクセスは実線で示されます。 ただし、ファイルシステム、memkesh、muscleなどのコンポーネントはオプションであるため、破線で示されています。



このようなスキームを使用して、開発者が例外的なケースに関与できるように、各コンポーネントの考えられる問題のリストとそれらを解決するための方法論をペイントする必要があります。 このようなリストの例は次のとおりです。

＃	症状	理由	反応
1。	無料ハンドラーの平均アイドル時間が許容値を超えました。	ユーザーの流入	水平スケーリング
2。	平均読み取り/送信要求時間が適切な値を超えました	ネットワークリソースを超えました。	料金プランの変更
3。	平均リクエスト処理時間が許容値を超えました	コード\ base \などの問題	開発者を引き付ける時です

実際、3番目の段落は多くのサブパラグラフで構成されていますが、その一部は管理上解決されており、まれに開発者が関与する必要があります。



そのような計画を立てることの利点は明らかです。ほとんどの問題は、瞬時ではなくとも特定の時間に解決されます。 ただし、計画の立案とシステムの最終決定の両方に一生懸命取り組む必要がありますが、それについては後で詳しく説明します。



継続するには...