運用の基本／画面とデバイス管理

デバイスヘルスステータスのカスタマイズ

NinjaOneのデバイス健全性判定を運用に合わせて調整する方法を説明します。27件の判定基準の管理画面、しきい値のカスタマイズ、判定対象からの除外、調整の進め方を解説します。

デバイスの健全性をどう判定するかを調整します。初期設定のままだと、自社の運用と合わない項目で警告が出続けることがあります。運用を1カ月ほど回した時点で見直してください。

ヘルスステータスの種類

デバイスの状態は、大きく次のように区分されます。

ダッシュボードやデバイス一覧では、この区分で色分けされます。

どの事象をどう扱うかは、AdministrationのDevicesにあるHealth Statusで管理されています。

初期状態で27件の判定基準が定義されています。それぞれにUnhealthyなどの状態が割り当てられており、Backup Failed、Failed Patches、Blocked Threatsといった事象が並びます。

各行の...からEditを選ぶと、その事象をどの状態として扱うかを変更できます。変更を元に戻したい場合はRestore defaultsで初期値に戻せます。

【運用のポイント】 27件を最初から全て調整する必要はありません。1カ月運用して、実態に合わない判定が出ている項目だけを変更してください。

デバイス詳細画面のHealth issuesには、検知されている問題が並びます。判定に使われるのは次のような要素です。

このうち再起動の保留は見落とされやすい項目です。パッチが適用済みに見えても、再起動していなければ有効になっていない場合があります。

【運用のポイント】 Uptimeが長いデバイスと再起動の保留を合わせて確認してください。数十日再起動されていないクライアント端末は、更新が反映されていない可能性が高くなります。

初期設定のしきい値が自社の運用に合わないことはよくあります。

典型的なのが次のケースです。

しきい値はPolicyの中で設定します。Device Roleごとに別のPolicyを当てることで、用途に応じた判定ができます。設計の考え方はPolicyとは：設計の考え方を参照してください。

一部の項目を判定に使わない設定もできます。

除外を検討するのは次のような場合です。

ただし除外は慎重に判断してください。除外した項目は、問題が起きても状態に反映されません。「対応できないから除外する」という判断は、問題を見えなくするだけです。

【注意】除外の設定は記録に残してください。何を、いつ、なぜ除外したかが分からなくなると、後任者が「なぜこの項目は監視されていないのか」を判断できません。

調整は次の順で進めると効率的です。

重要なのは2番目の分類です。警告が出続けている状態を放置すると、その警告全体が無視されるようになります。「ディスク容量の警告はいつも出ているから見なくていい」という状態になると、本当に逼迫したときにも気付けません。

調整の詳しい考え方はアラート設計のベストプラクティスで扱います。ヘルスステータスの調整とアラートの設計は同じ問題の裏表なので、あわせて読んでください。