7.3. モニタリング

1. ログ監視でsenju_syslogを監視した際の問題点

   問題

   UNIX/Linux版Senju DevOperation Conductorではログ監視において、senju_syslogに出力されるログの検知が遅延する場合があります。これは、syslogdが同一のログを複数連続して送信しようとした場合、最初の1つ目しか出力せず、以下の条件を満たすまで、出力を保留するためです。

   • syslogdが、ハングアップシグナル(SIGHUP)を受けた場合

   • 内容の異なるメッセージの出力要求が来た場合

   対策

   この事象はハングアップシグナル(SIGHUP)をsyslogdに定期的に送る処理を実施することで回避できます。

   OSがLinuxの場合で、cronコマンドを使用して上記動作を実現した場合のrootのcrontabファイルへの記述例を下記に示します。

   （crontabファイルへの記述例）

   0,10,20,30,40,50 * * * * kill -HUP `cat /var/run/syslogd.pid`
   

   尚、syslogdの動作はOSによって異なりますのでsyslogdの詳細については各OSベンダーへお問合せ下さい。

2. WindowsでIISをインストールした時の問題点

   問題

   WindowsにIISをインストールした直後にOSを再起動、もしくはシャットダウンすると、IIS監視においてFTP関係の監視タスクの値が取得できない場合があります。

   対策

   WindowsにIIS（FTP Service）をインストールした直後にOSを再起動、もしくはシャットダウンすると、FTP Service関連のWMIクラスが登録されない場合があり、本問題が起こる可能性があります。

   本問題に対しては、該当ノードのコマンドプロンプトからwmiadapコマンドを実行することで回避可能です。なお、コマンドの詳細についてはOSベンダーへお問合せ下さい。

   wmiadap /F

3. WindowsでSNMP監視を行った時の問題点

   問題

   Windowsで、”SNMP Service”サービスを利用したSNMP監視に失敗する場合があります。

   対策

   ”SNMP Service”サービスのセキュリティの設定により、値が取得できなくなっています。

   ”SNMP Service”サービスのプロパティにて、[セキュリティ]タブの設定を以下のように変更することでSNMP監視タスクの値が取得できるようになります。

   1. [セキュリティ]タブの設定にて [これらのホストからSNMPパケットを受け付ける]ボタンを選択して、[追加]ボタンをクリックし、千手エージェントまたはプローブノードのホスト名またはIPアドレスを登録します。

   2. [受け付けるコミュニティ名フィールドに、監視に使用するコミュニティ名（例：public）を入力します。

4. SQL Serverのメモリ消費について

   問題

   SQL Serverが多くの物理メモリを消費する。

   詳細

   SQL Serverはデフォルトでは使用可能なシステムリソースに基づいて、必要な物理メモリ使用量が動的に変更されるようになっているようです。

   対策

   使用するメモリの量は、SQL Server の環境設定オプション( max server memory )の設定により制限可能です。手順などにつきましては、Microsoft社のドキュメントに情報が掲載されていますのでこちらを参照願います。

   ［参考］Microsoft ドキュメント

   ［例：SQL Server 2019 の情報］

   サーバー メモリ オプション

   （https://docs.microsoft.com/ja-jp/sql/database-engine/configure-windows/server-memory-server-configuration-options?view=sql-server-ver15）

   なお、SQL Server ごとのURLなど詳細については、マイクロソフト社にお問い合わせいただけますようお願いいたします。

5. SQL Server 2005以降でフラグメンテーション監視を行った時の問題点

   問題

   SQL Server監視エクステンションでSQL Server上に作成されたユーザーテーブルの存在しないデータベースについて下記の監視を行った場合

   • 「SQL Server：データベース 物理スキャンフラグメンテーション率(%)」

   • 「SQL Server：データベース 論理スキャンフラグメンテーション率(%)」

   • 「SQL Server：データベース エクステントスキャンフラグメンテーション率(%)」

   付加文言が「値の計算に失敗しました」の障害メッセージが出て監視に失敗します。

   詳細

   Senju DevOperation Conductorでは、SQL Serverのフラグメンテーション監視結果を取得するために、"sysobjects"というシステムテーブルを参照し、監視対象データベース内に存在する全てのテーブル（システムテーブル、ユーザーテーブル）の情報を取得しています。

   SQL Serverでは、この"sysobjects"がシステムテーブルではなく「互換性ビュー」という形になり、ユーザーテーブルの情報だけが取得されるようになりました。

   この結果、SQL Serverでユーザーテーブルの存在しないデータベースのフラグメンテーション監視に失敗します。

   対策

   SQL Server上に作成したデータベースを監視する場合には、ユーザーテーブルを作成し、初期データを格納した後で監視の設定をして下さい。

6. SQL Serverの名前付きインスタンスの監視を行った時の問題点

   問題

   カスタム監視を使用して、SQL Serverの名前付きインスタンスを監視する際、以下メッセージが出て監視が強制停止される場合があります。

   !ISM130 検査間隔内に状況収集コマンドが終了しなかったため停止させました。(ノードID:wisdom,監視タスク名:(custom)SQL Server：データベースデータ領域 使用率(%),監視対象:,検査間隔:5)      発生条件

   SQL Server以下で、名前付きインスタンスの指定方法を間違った場合に、発生する事があります。インスタンスは サーバー名\インスタンス名 の様に指定しますが \ が余計に指定されている場合にこの問題が発生します。

   （例）

   \サーバー名\インスタンス名 （先頭に \ が指定されている）

   サーバー名\インスタンス名\ （末尾に \ が指定されている）

   詳細

   名前付きインスタンスの指定方法を間違うと、SQL Server監視に使用しているクライアントコマンド"osql.exe"がCPUを浪費して止まらなくなってしまい、その結果、【問題】にあるメッセージが出力されます。

   対策

   以下手順を行って下さい。

   1. !ISM130メッセージで表示された監視タスクを一時停止する

   2. タスクマネージャで、残っている"osql.exe"を停止する。

      このとき、他のSQL Server監視タスクが実行中でないことを確認して下さい。他の監視タスクで使用している"osql.exe"を停止すると監視に失敗します。

   3. 「1.」の監視タスクのパラメータを確認し、名前付きインスタンスの指定を正しく（ サーバー名\インスタンス名 ）する

   4. 「1.」で停止した監視タスクを再開する。

7. SQL Server監視でWindows認証接続ができない場合の設定

   問題

   SQL Server監視する際にWindows認証接続（信頼関係接続）を使用したいが、運用ポリシーの制限で千手センサー上にプローブノードの千手稼働アカウントと同一のアカウントを作成できない。

   詳細

   千手センサー上に作成するアカウントには次の条件がある。

   • アカウントのユーザー名／パスードは、プローブノードの千手稼働アカウントと同一。

   • アカウントにはSQL Serverへのアクセス権が必要。（例：ローカルのAdministratorsグループに所属している）

   対策

   プローブノードのOSがWindowsの場合、あらかじめ各センサーノードと接続ユーザを関連付けておくことで、プローブノードの千手稼働アカウント以外のアカウントを使用できます。

   ただし、SQL Serverへのアクセス権は必要です。

   1. プローブノードに、千手稼働アカウントでログインして下さい。

   2. 「ファイル名を指定して実行」を選択し、"Control keymgr.dll"と入力して実行して下さい。

   3. 表示された画面にて追加ボタンを押下し、各フィールドに以下を入力後、OKを押下。

      SQL Serverに接続するための“アカウント”と“パスワード”を以下例のように入力して下さい。

      （例）

      サーバー名 : sqldb
      ユーザー名 : sqldb\sqlwatch
      パスワード : （ユーザー名のパスワードを設定）
      ※ sqldbはセンサーのノードID
      ※ sqlwatchはセンサーにアクセスする際のアカウント
      

   4. プローブノードが監視しているセンサーの数だけ1.～3.の手順を繰り返して下さい。

   上記の設定は即座に反映されますので、プローブノードやセンサーノードの再起動は必要ありません。

8. カスタムカテゴリの監視タスクを「定義データの読み込み」で読み込んだ時の問題点

   問題

   「定義データの書き出し」を使用して書き出したカスタムカテゴリの監視タスクを、別のドメインで「定義データの読み込み」を使用して読み込んだ際、読み込んだ監視タスクが千手ブラウザに正しく表示されない場合があります。

   具体的には以下のような状態になります。

   • 千手ブラウザのモニタリング－カスタムカテゴリ－監視タスク以下の、書き出したのとは別のカテゴリの下に表示される

   • 千手ブラウザのモニタリング－カスタムカテゴリ－監視タスク以下の、どのカテゴリにも表示されない

   詳細

   「定義データの書き出し」を行った環境と「定義データの読み込み」を行った環境で、千手が内部で保持しているカスタムカテゴリのIDが異なっている為に正しく表示されません。

   対策

   対策については、Senjuカスタマサポートセンターまでお問い合わせ下さい。

9. 千手センサーのログ監視を行っている際に、端末にメッセージが送信された時の問題点

   問題

   千手センサーのログ監視における千手センサーのファイル状態変化を検査するタイミングと、千手センサーのログ監視用のアカウントに対してsyslogdからのメッセージが送信されるタイミングが重なった場合、千手センサーのログ監視の処理に失敗し以下障害メッセージが出る場合があります。

   !ANM287 監視対象ノードとの接続に失敗しました。

   詳細

   原因は、端末にメッセージが送信されると、千手センサーノードのファイル状態変化を検査する処理の結果に送信されたメッセージが混在し、期待した処理結果が得られず、処理が失敗したとみなされるためです。

   千手センサーのログ監視用のアカウントの端末に送信されるメッセージとは、具体的には以下のようなものです。

   • syslogd（または類似プロセス）の設定で、千手センサーのログ監視用のアカウントの端末に送信されるように指定されているメッセージ

   • 同報メッセージ(Broadcast Message)

   対策

   千手センサーのログ監視に使用しているアカウントの端末にメッセージが送信されないように、千手センサーの設定を変更して下さい。

10. ノードのプロパティでコンフィグレーション機能の使用を設定しても使用できない問題点

    問題

    ノードのプロパティでコンフィグレーションにチェック後、反映（監視属性）を行っても、構成情報取得デーモン（sjCCM_monitord）が起動しない。

    対策

    反映（監視属性）後に、構成情報取得デーモン（sjCCM_monitord）をノードモニタから起動して下さい。

11. 「データの書き出し」で出力したノード情報ファイルを Microsoft Excelで、編集後に「データの読み込み」を行うとイベントログの行でカラム数が多いエラーが発生する問題点

    問題

    「データの書き出し」で出力したノード情報のイベントログの行は、カラムが一つ少ないフォーマットになっています。
    そのため、Microsoft Excel で編集後、そのままテキストファイルに保存すると、イベントログ行の最終カラムにタブが増えるため、「データの読み込み」でエラーが発生します。

    対策

    Microsoft Excelで編集後した場合はノード情報を、 ユーザーズガイド「千手ブラウザ(共通編)」 の 「Microsoft Excel編集時の注意事項」 の 「データ保存時」 を参照し、イベントログの行の最終カラムのタブを削除して下さい。

12. バーチャルノードモニタでプローブノードに Windowsノードを指定した場合の問題点

    問題

    バーチャルノードモニタの情報取得で、プローブノードに Windowsノードを指定している場合、完全修飾ドメイン名の末尾が . (ピリオド)である仮想サーバーホストからの情報取得ができません。

    対策

    本事象は、以下のa)、b)いずれかの対処を行っていただくことで回避することが可能です。

    1. プローブノードの変更

       プローブノードに Windowsノードではなく、 Linuxノードを指定して下さい。

    2. 仮想サーバーホストの完全修飾ドメイン名の変更

       仮想サーバーホストの完全修飾ドメイン名の末尾が . (ピリオド)以外の名称となるよう、VMware ESXi / VMware vCenter Serverの設定を変更し、変更後の名称でノードを再登録して下さい。

13. イベントビューアにて「ログの消去」を行った時の問題点

    問題

    イベントビューアにて「ログの消去」を行う際に「保存と消去」を選択すると、その後に出力されたイベントログが検知されなくなります。

    対策

    以下手順にてイベントログ監視の定義を再登録して下さい。

    1. 消去したイベントログの監視定義を削除し、反映(監視属性)を実行

    2. 消去したイベントログの監視定義を追加し、反映(監視属性)を実行

14. Linuxの千手センサーのcshやsh、bashのアカウントへSSHによる接続を用いて、センサーのログ監視をした場合の問題点

    問題

    センサー側で監視対象ファイルに対して稼働しているtailコマンドが強制停止された場合に、プローブノード側に”<exiting>”という不要なプロセスが残る場合があります。

    対策

    不要なプロセスを削除するには、千手ブラウザのノードモニタより、プローブノードの“sjANM_rmtLogd”プロセスを再起動して下さい。

15. 千手マネージャと千手エージェントを共存させている環境にて、バーチャリゼーション情報転送プロセスが異常終了する問題

    問題

    千手マネージャがインストールされているノードに千手エージェントを共存させている環境にて、バーチャルノードモニタの情報取得を行っている場合、以下のメッセージがメッセージモニタに表示される事があります。

    !ANMH04 バーチャリゼーション情報取得でエラーが発生しました。(サーバー名:([仮想サーバーホスト名]) (バーチャリゼーション情報転送プロセス:異常終了[終了値:50]))

    対策

    千手マネージャと共存している千手エージェントを再起動して下さい。

16. ログ監視で空白を含むパス名を指定した場合の問題点

    問題

    千手システムは空白を含むパス名には対応していませんので、Windowsの環境において C:\Program Files のように空白を含むパス名やファイル名をログ監視で指定した場合、正常に動作しません。

    対策

    空白を含まない形式（短いファイル名の形式）でパス名を記述してください。

    （短いファイル名は、コマンドプロンプトにて dir /x コマンドを実行することで確認できます。）

    2015/11/18  19:30    <DIR>          PROGRA~1     Program Files
    2016/04/21  10:33    <DIR>          PROGRA~2     Program Files (x86)
    

    上記の例では、 Program Files の短いファイル名は PROGRA~1 。また、 Program Files (x86) の短いファイル名は PROGRA~2 になります。

17. Windows OSの千手センサーのログ監視での問題点

    問題

    千手センサーとプローブノードのOSがともにWindows Server 2008 R2以上で、SMB2.1以降のプロトコルが用いられている環境では、ログ監視において、監視中の監視対象ログファイルを外部プロセスから削除できなくなります。

    対策

    プローブノードに環境変数を設定することで、外部プロセスから監視対象ログファイルの削除が正常に行えるようになります。

    1. 以下のコマンドを実行し、環境変数 SjANM_ChkDelPending を設定します。

    > sj_source.exe -cSjANM_ChkDelPending=1
    

    2. 以下のコマンドを実行し、設定を確認します。

    > sj_getenv SjANM_ChkDelPending
    

    ※動作を元に戻す場合は以下のコマンドを実行し環境変数設定を削除します。

    > sj_source.exe -cSjANM_ChkDelPending=
    

    警告

    この環境変数を設定することにより、千手センサーのログ監視で監視対象ログの内容が削除されると以降のログ監視が正常に行えなくなります。

    正常に千手センサーのログ監視を行うためには、SMB2.1未満のプロトコルを使用するかセンサーノード側で Oplock Lease 機能を無効にする設定が必須です。 Oplock Lease 機能を無効にする場合は、以下のレジストリを変更し OS または Server Service を再起動してください。

    パス: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
    名前: DisableLeasing
    型　: DWORD
    値　: 1
    

18. .NET Framework監視を行った時の問題点

    問題

    以下の監視タスクの結果が異常になる原因として、取得対象のWMIクラス(Win32_PerfRawData_NETFramework_*)が存在しない場合があります。

    • APサーバー－.NET Framework：ガベージコレクション実行率(%)[WMI]

    • APサーバー－.NET Framework：ヒープ領域メモリ使用量(KB)[WMI]

    • APサーバー－.NET Framework：例外発生回数[WMI]

    • APサーバー－.NET Framework：JITコンパイル実行率(%)[WMI]

    対策

    再設定方法について、ベンダに案内された手順を以下に示します。コマンドの詳細についてはベンダにお問い合わせください。

    パフォーマンスカウンターを再登録することで、.NET Framework監視タスクの値が取得できるようになる場合があります。

    1. 「管理者として実行」を指定してコマンドプロンプトを起動します。

    2. 以下のコマンドを実行し、パフォーマンスカウンターに登録されている.NET Framework関連の設定を削除します。

       > unlodctr ".NET CLR Data"
       > unlodctr ".NET CLR Networking"
       > unlodctr ".NET Data Provider for Oracle"
       > unlodctr ".NET Data Provider for SqlServer"
       > unlodctr .NETFramework
       

    3. 以下のコマンドを実行し、パフォーマンスカウンターに.NET Framework関連の設定を再登録します。

       > lodctr "C:\Windows\INF\.NET CLR Data\_DataPerfCounters.ini"
       > lodctr "C:\Windows\INF\.NET CLR Networking\_Networkingperfcounters_v2.ini"
       > lodctr "C:\Windows\INF\.NET Data Provider for Oracle\_DataOracleClientPerfCounters_shared12_neutral.ini"
       > lodctr "C:\Windows\INF\.NET Data Provider for SqlServer\_dataperfcounters_shared12_neutral.ini"
       > lodctr "C:\Windows\INF\.NETFramework\corperfmonsymbols.ini"
       

    4. マシンの再起動をします。

19. OSがWindowsのプローブノードからSolaris 10 千手センサーへSSHによる接続を用いて、千手センサー監視した場合の問題点

    問題

    Solaris 10 千手センサーの千手センサー監視にて、WindowsプローブノードからSSHによる接続が失敗する。

    対策

    本事象は、以下のa)、b)いずれかの対処を行っていただくことで回避することが可能です。

    1. Solaris 10 千手センサーをSSHによる接続を用いて監視する場合、UNIXプローブを使用するようにして下さい。

    2. Solaris 10 千手センサーをWindowsプローブから監視する場合、TELNETによる接続を使用するようにして下さい。

20. ESXi 7.0以降をバーチャリゼーション監視する場合の問題

    問題

    vSphere SDK for Perl 7.0以降を用いてESXi7.0以降のサーバーに対して直接接続し、バーチャリゼーション監視を実行した場合、タスク情報を取得できない問題があります。

    対策

    vCenter経由で情報取得を行うように設定を変更してください。