広瀬です

監視対象サーバのロードアベレージが10ともなれば、監視方法によってはそのようなケースは発生しえると思われます。
以下の点を重点に見直ししてみては如何でしょうか。
念のため、弊社の監視対象サーバで10～20程度のロードアベレージを恒常的に引き起こすサーバありますが、以下の
設定の関係で、プロセスダウンと判断される事は今の所無く、極めて希です。

※お使いのＺａｂｂｉｘバージョンが判りませんので、お使いのバージョンによって状況が変わります。

１．～Ver1.8までの場合(Ver1.8.13以降のZabbixAgentでは、ServerActive値も変更が必要)

　①net.tcp.service[＊]アイテムキーは全てZabbixAgent管轄のアイテムでしたので、Passive方式ではなくActive方式に
　　 に切り替えて状態を見てみる。

　　 ⇒Passive方式では、ZabbixServer側から問い合わせた結果を待つ動きになるので、監視対象サーバが高負荷な場
　　　　合、結果を返答するのが遅くなり、タイムアウトしてNG判定されるケースが高まります

　②ZabbixAgentのTimeout値を見直しを行う(デフォルト3秒)のも一つの手段です。

　　 ⇒こちらも同様な事で、あまりにもタイムアウトが早い様では、高負荷サーバに対してはエラー応答を頻発する温床です

２．Ver2.0～以降の場合

　①Ver2.0以降では、net.tcp.service[＊]はシンプルチェック方式と、従来のZabbixAgent方式を両方とも使用が可能になった
　　 かと記憶していますが、前者のシンプルチェック方式では、Agentレスなので対高負荷サーバでは自然と負荷によるタイム
　　 アウトが原因で、NG判定に陥ると思われます。

　　 ⇒監視方式を変更する事が可能なら、こちらもシンプルチェック方式ではなく、Agent方式にし、且つActive方式にしておく
　　　　のが良いのではと思われます。

　　 ⇒Agent方式にした場合は、Timeoutの件はVer1.8と同じ事が言えます。
　　　　少々調べ切れていないので、確かな事は言えませんが、シンプルチェックの場合、ZabbixServer側のTimeoutが適用
　　　　されたはずですので、ZabbixServer側のTimeout値も検討対象の1つとお考えください。

３．ZabbixAgentの起動プロセス数を上げる

　①他の監視項目が多い場合などで、対象の監視項目を処理するのにZabbiAgentプロセスが足りない場合もありえます。
　　 デフォルトは3プロセスしか起動しなかったと思いますので、Agent起動プロセス数を増やすのも1つの手です。
　
　　 ⇒StartAgentsを増やす

などでしょうか。