LM稼働時間に関するアラート
最終更新日 - 15年2026月XNUMX日
LogicMonitorは、1つ以上の場所で指定された数のチェックが失敗した場合に、LM Uptimeリソースにアラートを発します。これらのアラート条件は、WebチェックまたはPingチェックの設定または管理時に、各ウェブサイトごとに個別に設定できます。アラートの発動方法は、チェックの種類と、外部チェックポイントから発生するか、内部LMコレクタから発生するかによって異なります。設定の詳細については、以下を参照してください。 LM Uptime を使用した Web チェックの概要 or LM Uptime を使用した Ping チェックの概要.
重要：
- 収集スケジュール
- アラートトリガー間隔
- アラートクリア間隔
- アラートのしきい値
以下のデータソースフィールドは変更しないでください。LM Uptimeは、Uptime DefaultsとLM Uptimeアラートチューニングロジックからこれらの値を自動的に取得します。手動で変更すると、アラートの動作が正しくなくなる可能性があります。
LM Uptime は、ポーリングベースのアラート遷移モデルを使用して、Web Check および Ping Check リソースのアラートがいつ発生し、いつ解除されるかを決定します。Uptime Defaults の Failed Check 値は、アラートが発生または解除されるまでに連続して何回のポーリング失敗が発生する必要があるかを決定します。
以下の式は、有効移行計算を表しています。
Effective Transition = Polling Interval × Failed Check
例えば、ポーリング間隔を5分、チェック失敗値を4とした場合、実質的な遷移値は20分となります。この例では、アラートは4回連続でポーリングが失敗した後にのみトリガーされます。アラートのクリア動作も、同じポーリングベースの遷移ロジックによって制御されます。
これらの計算の精度を維持するため、LM Uptimeデータソースは1分間隔の収集スケジュールを使用します。収集スケジュールを変更したり、アラートトリガー間隔、アラートクリア間隔、またはアラートしきい値を手動で上書きしたりすると、バックエンドのアラート計算が構成済みのUptimeデフォルト値と同期しなくなる可能性があります。
推奨事項： アップタイムデフォルト設定を使用しないチェックの場合、アラートのトリガーとクリア動作には、そのWebチェックまたはPingチェックのデバイス作成時に構成されたカスタムアラートチューニング値が使用されます。
これらの場合、LogicMonitorは同じポーリングベースの遷移計算を使用しますが、値はグローバルな稼働時間デフォルト値ではなく、カスタム構成から取得されます。
以下の式は、有効移行計算を表しています。
Effective Transition = Custom Polling Interval × Custom Failed Check
例えば、Webチェックで稼働時間デフォルト設定を使用せず、ポーリング間隔が3分、チェック失敗値が5に設定されている場合、有効な遷移値は15分となります。アラートは、そのチェックでポーリング間隔が5回連続して失敗した場合にのみトリガーされます。
Uptime Defaultsは、以下のLM Uptime DataSourceデータポイントのアラート設定を更新します。
Web_Check_Individual— ステータスと sslStatusWeb_Check_Overall—sslStatus、sslDaysUntilExpiration、およびoverallStatusPing_Check_Individual- 状態Ping_Check_Overall—全体的な状況
LM Uptimeリソースのアラートメッセージは、データソースアラートテンプレートを使用してグローバルにカスタマイズできます。これらのメッセージは、より効果的なアラートのために、動的で関連性の高い情報を含むトークンをサポートしています。詳細については、以下をご覧ください。 アラート メッセージ テンプレートの管理.
LM Uptimeのアラートは、LogicMonitor全体のアクティブなアラートを表示するメインのアラートページ、または特定のLM Uptimeリソースまたはグループのアラートタブで確認できます。アラートタブでは、選択したウェブサイトと機能に合わせてフィルタリングされたビューが表示されます。詳細については、以下をご覧ください。 [アラート]タブ (NAIST) と アラートページからのアラートの管理.
