관련링크

今月WhaTap Labsが準備したウェビナーは「SaaSモニタリングの巨匠である、WhaTapが教えるモニタリングの基礎」です。

1. モニタリングの定義

“to watch and check a situation carefully for a period of time in order to discover something about it”

モニタリングの事前定義は、特定のものを見つけるために状況を注意深く観察し確認する行為です。ITサービスを対象としたモニタリングとは、障害とエラーを検出するためにITサービス要素を監視および確認する行為を意味します。

2. なぜ私たちはモニタリングをしなければならないのですか？

モニタリングの目的は、障害やエラーを認識して予防することです。これだけで安定したサービスを提供できます。ここで言ってる障害とはどういう意味でしょう？ 安定したサービス、不安定なサービスはどのような基準で区切るべきでしょう？

3. 障害と安定性を管理したい場合は？

障害を管理したい場合は、障害と安定の基準を正しく定義する必要があります。安定性も同様です。安全でない状況の基準がなければ、これを管理できます。

障害を管理するために内部的に管理基準を立てておく場合があります。典型的には、CPU使用量やファイルシステム使用量などのリソース使用量を調べます。リソースをしきい値を超えて使用すると、障害状況が近接しているか安定していないと判断される可能性があります。このような場合は間違った障害基準と申し上げたいと思います。

正しい障害基準はどのように定義されるべきですか？ 平均応答時間が10秒を超えた場合、または要求に正常に応答が返されなかった場合を障害と判断できます。

つまり、障害の基準は、ユーザーがこのサービスを使用する過程で不快感を感じるかどうかです。正しい障害基準を設定した後は、安定性について定義する必要があります。どんなサービスも一年中1回のエラーなしに運用されるのは現実的に困難です。そのため、安定性を定義するときは、ユーザーの要求に数秒以内に正常に応答する割合が、特定の期間にわたって何パーセント以上必要であるかを目指します。障害と信頼性の正しい基準に基づいてサービス目標を設定し、モニタリングおよび管理します。

この過程で、必ず障害、障害現象、障害原因を明確に区分して認知する必要があります。

障害 vs. 障害現象対 vs. 障害の原因

• 障害：ユーザー要求にサービスが正常に応答しない現象
• 障害現象
  • CPU使用量の急増に伴う応答遅延
  • プロセスDownで無応答
• 障害の原因
  • CPU使用量の急増
    • 特定のアプリケーションロジックエラーによる過度のメモリ使用、メモリ不足による頻繁なGCの実行
  • プロセスDownによる無応答
    • アプリケーション Memory Access Violation でプロセスをDown
      • Fail-Overに3分所要

4. モニタリングしなければならないのは？

障害、障害現象、および障害の原因の3つすべてを監視する必要があります。

• 障害を認知できる指標 APDEX、TPS、平均応答時間
• 障害現象を示す指標 リソース使用量(CPU、メモリ、ネットワークリソースなど)、ポートオープン、プロセスダウンなど
• 障害原因分析に必要な情報 Log、詳細なリソース使用量情報、Stack情報

5. 誰がモニタリングしますか？

モニタリングは人ではなくツールでなければなりません。障害や安定性の阻害を引き起こす要因は多すぎます。これらの多くの指標は、人が休日なしで24時間見ることはできません。

モニタリングをツールに任せたら、誰が何をすべきですか？ 人はツールにモニタリングを任せる行為を進める。ツールを使用して異常が見つかった場合に通知を受け取ることができます。つまり、人は通知を管理し、根本原因を追跡して対処します。

6. モニタリングはどうすればよいですか？

モニタリングは大きく3段階で行われます。サービス目標レベルの定義、目標レベル達成妨害要素の把握、妨害要素の原因改善です。

第1段階 – 私のサービス目標レベルを定義します。

一般的なサービスであれば、ユーザーの要求に3秒以内に正常に応答する割合が月に99.5％以上でなければならないのが一般的な基準です。月に換算すると、この時間は3時間40分*程度になります。

高可用サービスの場合、目標基準は異なります。月に約20分程度のダウンタイムを消費できます。そのためには、サービスの多重化、Fail-overが充実していなければなりません。問題を認識したときにすぐに処理することができます。従業員は展開する必要があります。小規模、SMBで運営を担当される方には99.95%高可用を目指すことをお勧めしません。現実的に達成できない可能性が高い。99.5％程度の目標を定義することをお勧めします。

考慮事項として、まずシステム、人員限界に基づいて目標値を設定する必要があります。さらに、サービス目標を定義するときは、基準をできるだけ単純に定義する必要があります。この基準以外に別の基準を追加するのはサービスが成熟してからしても遅くはありません。

第2段階 – 目標レベルの達成を妨げる要因を特定します。

さまざまな妨害要因がある可能性があります。クエリが遅くなっている可能性があります。あるいは、ユーザーの流入自体が特定の時間帯だけを集めて応答時間が遅れる現象が発生することもあります。最も高い比重を占める妨害要素を探し、優先順位の高いものから一つずつ蹴る必要があります。モニタリングツールを使用している場合は、通知の発生履歴やトランザクション統計を活用できます。

第3段階 – 妨害要因の原因を改善します。

プログラムエラーを修正し、サーバーリソースを再配布し、認識された障害要因の原因を改善します。

この段階では、現象と原因を区別する必要があります。

例1）

• 現象：CPU使用量が高い
• 原因：どのようなプロセスですか？ アプリケーションソースはどこですか？

例2）

• 現象：プロセスがダウンしました
• 原因：ダウン前後の情報→情報による分析

7. 正しいモニタリングが必要な理由

障害の正確な原因を特定することは非常に重要です。そうしないと、担当者の立場で仕事は大変になり、費用は費用通り支出されることが多いです。たとえば、CPU使用率の高い障害が発生したとしましょう。正確な原因を特定するには、エラーロジックを分析または修正する必要があります。もしこのための人員が足りないとしたらどうしますか？ ほとんどの場合、リソースが不足しているため、サーバーが増設されます。リソースを増やすことですぐに問題を解決することはできますが、今後はいつでも同じ問題が再び発生する可能性があります。

8. WhaTapを使えば良い点

大きく3つを申し上げたいです。

簡単なインストール、効果的な通知ポリシー、正確な障害分析に助けを得られることです。

第一、適用自体が易しくて簡単です。

サインアップしてエージェントをインストールするだけです。命令語を数行だけ入力すればインストールできますので、気軽に適用できます。

オープンソースを検討することもできます。ただし、オープンソースを利用するために面倒な過程を経なければ効率が落ちることもあります。モニタリングはツールに任せ、節約した時間にはより重要なビジネスに集中してみたらいかがでしょうか。

第二、効率的に通知が設定できます。

どの条件で通知を設定する必要があるか試行錯誤を受ける必要はありません。適切に通知を設定しないと、通知を受けすぎて疲れたり、重大な障害を見逃したりする可能性があります。

WhaTabは通常、最も一般的な通知ポリシーをデフォルトとして提供します。通知の受信方法もさまざまです。連絡先を登録してアラームをオンにすると、SMS、E-mail、メッセンジャーなどで通知を受け取ることができます。

最後に、正確な障害分析に助けを得られます。

障害が発生したときに正確に分析することは本当に重要です。しかし、場合によっては分析に時間を費やすのは難しいかもしれません。

WhaTapでは分析のための情報を収集するため、ほとんどの問題はツールを使用して分析できます。ただし、データをどのように分析するかは、ユーザーの能力によって異なります。

サポートが必要な場合は、WhaTap Labsオンラインカスタマーサポートにお問い合わせください。経験豊富なWhaTap専門コンサルタントは、さまざまな視点で新しい視点を提示します。

入門者のためのすぐに活用するモニタリング、お役に立ってもらいましたか？

第2部 - モニタリング画面で注目すべき指標の紹介は [WhaTap Labsウェビナー]入門者のための直接活用するモニタリング をYouTubeで確認してみてください😉