最近、System Center Operations Managerのエージェントレス監視しているサーバー（今回は仮想マシンでしたが）を停止したところ、他サーバーの監視も含めて通知メールが一切飛ばないという事象に遭遇しました。
これは、マイクロソフトのプレミアサポートにご支援いただき無事解決したのですが、少し顛末をまとめておきます。
この判断ポイントは、イベントログ 10028の発生です。
手元の環境でもイベントログを検出できていたので、下記に貼っておきます。
※タイムスタンプはUTCです、念のため。
エージェントレス監視しているサーバーに対して、上記のイベントログが出ていると、SCOM自体の動作が不安定になっている可能性があります。その結果として、一切の通知メールが飛ばなくなることがあります。
本件に関しては、明示的にプロキシを構成しませんでした。ということはSCOMサーバーがプロキシになっていたわけです。
エージェントレス監視のベストプラクティスは、
エージェントレス監視のプロキシを構成する方法
にある通り、明示的にプロキシを構成することです。
が、前述の通り、プロキシとなっていたSCOMサーバーが不安定になっていました。
つまり、特定のエージェント監視しているサーバーをプロキシにしても、影響範囲が小さくなるだけということに。。。
このイベントログを発生させないこと、つまり不安定な状況を回避するには、エージェントレス監視のサーバーに対しメンテナンスモードを使います。
※障害が発生するとそうもいきませんけど。
なお、監視対象から削除してしまえば発生しませんが、通常はサービス停止にともなうサーバー撤去といったケースになってしまうでしょう。
ということで、できれはこの挙動が改善されることを願ってやみません。
これは、マイクロソフトのプレミアサポートにご支援いただき無事解決したのですが、少し顛末をまとめておきます。
この判断ポイントは、イベントログ 10028の発生です。
手元の環境でもイベントログを検出できていたので、下記に貼っておきます。
※タイムスタンプはUTCです、念のため。
エージェントレス監視しているサーバーに対して、上記のイベントログが出ていると、SCOM自体の動作が不安定になっている可能性があります。その結果として、一切の通知メールが飛ばなくなることがあります。
本件に関しては、明示的にプロキシを構成しませんでした。ということはSCOMサーバーがプロキシになっていたわけです。
エージェントレス監視のベストプラクティスは、
エージェントレス監視のプロキシを構成する方法
にある通り、明示的にプロキシを構成することです。
が、前述の通り、プロキシとなっていたSCOMサーバーが不安定になっていました。
つまり、特定のエージェント監視しているサーバーをプロキシにしても、影響範囲が小さくなるだけということに。。。
このイベントログを発生させないこと、つまり不安定な状況を回避するには、エージェントレス監視のサーバーに対しメンテナンスモードを使います。
※障害が発生するとそうもいきませんけど。
なお、監視対象から削除してしまえば発生しませんが、通常はサービス停止にともなうサーバー撤去といったケースになってしまうでしょう。
ということで、できれはこの挙動が改善されることを願ってやみません。
