Tivoli Log File Agentください。Log File Agent 固有のソフトウェア製品互換性レポートを実行する方法については、8 ページの『Log File Agent 用のソフトウェア製品互換性レポートの生成』を参照してください。v

Tivoli Log File Agentバージョン 6.3

ユーザーズ・ガイド

SA88-4868-01(英文原典：SC14-7484-04)

��

Tivoli Log File Agentバージョン 6.3

ユーザーズ・ガイド

SA88-4868-01(英文原典：SC14-7484-04)

��

お願い本書および本書で紹介する製品をご使用になる前に、 163ページの『特記事項』に記載されている情報をお読みください。

本書は、Tivoli Log File Agent のバージョン 6.3 (製品番号 5724-C04) および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　

原典： SC14-7484-04

Tivoli Log File Agent

Version 6.3

User's Guide

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

第1刷 2013.4

© Copyright IBM Corporation 2010, 2013.

目次図 . . . . . . . . . . . . . . . . . v

表 . . . . . . . . . . . . . . . . . vii

第 1 章エージェントの概要 . . . . . . 1IBM Tivoli Monitoring . . . . . . . . . . . 1このリリースの新機能 . . . . . . . . . . . 1IBM Tivoli Monitoring 環境のコンポーネント . . . 2エージェント管理サービス . . . . . . . . . . 3ユーザー・インターフェースのオプション . . . . 3データ・ソース . . . . . . . . . . . . . 5

第 2 章エージェントをインストールおよび構成するための要件 . . . . . . . . . 7モニター・エージェントの要件 . . . . . . . . 7

Log File Agent 用のソフトウェア製品互換性レポートの生成 . . . . . . . . . . . . . . 8

エージェント固有のインストールおよび構成 . . . . 9構成パネルからの構成 . . . . . . . . . . 9コマンド行からの構成 . . . . . . . . . . 11構成ファイル . . . . . . . . . . . . . 12エージェントの構成ファイルとフォーマット・ファイルの変更 . . . . . . . . . . . . . 13一元化された構成 . . . . . . . . . . . 14CPU スロットル . . . . . . . . . . . . 14リモート・ログ・ファイル・モニター . . . . 15リモート・インストールおよび構成 . . . . . 18エージェントの開始 . . . . . . . . . . 19Tivoli Netcool OMNIbus ObjectServer へのイベントの転送 . . . . . . . . . . . . . . 19サブノード . . . . . . . . . . . . . 23

第 3 章構成ファイル . . . . . . . . 27

第 4 章フォーマット・ファイル . . . . 39フォーマット・ファイル仕様 . . . . . . . . 39継承 . . . . . . . . . . . . . . . . . 43複数行 . . . . . . . . . . . . . . . . 44マッピング . . . . . . . . . . . . . . 45値指定子 . . . . . . . . . . . . . . 46キーワード . . . . . . . . . . . . . 47最大メッセージ長 . . . . . . . . . . . 49

第 5 章イベント・フィルタリングおよび要約 . . . . . . . . . . . . . . . . 51重複イベントの検出およびフィルタリング . . . . 51要約間隔 . . . . . . . . . . . . . . . 52イベントのフィルタリング . . . . . . . . . 52要約属性 . . . . . . . . . . . . . . . 53

Tivoli Enterprise Portal でのイベント・フィルタリングおよび要約の表示 . . . . . . . . . . . 53

第 6 章ワークスペースの参照 . . . . . 59事前定義ワークスペース . . . . . . . . . . 60ワークスペースの説明 . . . . . . . . . . . 60ログ・ファイル・ナビゲーター項目 . . . . . 61LFA プロファイル・ナビゲーター項目 . . . . 64LogFile イベント・ナビゲーター項目 . . . . . 64Tivoli Log File Profile サブノード . . . . . . 65

第 7 章属性リファレンス . . . . . . . 67モニター・エージェントの属性グループ . . . . . 67各属性グループの属性 . . . . . . . . . . . 68

LFA プロファイル属性グループ . . . . . . 68ログ・ファイル正規表現統計属性グループ . . . 70ログ・ファイル状況属性グループ . . . . . . 74LogFile イベント属性グループ . . . . . . . 77LogfileProfile イベント属性グループ . . . . . 82パフォーマンス・オブジェクト状況属性グループ 86pro パフォーマンス・オブジェクト状況属性グループ . . . . . . . . . . . . . . . . 91スレッド・プールの状況属性グループ . . . . 96

ヒストリカル・データのディスク・キャパシティー・プランニング . . . . . . . . . . . . 100

第 8 章シチュエーション・リファレンス . . . . . . . . . . . . . . . . 103事前定義シチュエーション . . . . . . . . . 104シチュエーションの説明 . . . . . . . . . . 104

KLO_Log_Agent_Config_Error シチュエーション 104KLO_PRO_Log_Agent_Config_Error シチュエーション . . . . . . . . . . . . . . . 105

第 9 章アクション実行コマンド参照 107事前定義されているアクション実行コマンド . . . 107

第 10 章ポリシーの解説. . . . . . . 109事前定義ポリシー . . . . . . . . . . . . 109

第 11 章トラブルシューティング . . . 111トレース・ロギング . . . . . . . . . . . 112ログ・ファイル管理の概要 . . . . . . . . 113主要トレース・ログ・ファイル . . . . . . 113例: トレース・ログの使用 . . . . . . . . 118RAS トレース・パラメーター . . . . . . . 119トレース設定の動的な変更 . . . . . . . . 121Tivoli Enterprise Console サーバーのトレース・パラメーターの設定 . . . . . . . . . . 124

問題および解決方法 . . . . . . . . . . . 125

© Copyright IBM Corp. 2010, 2013 iii

インストールおよび構成のトラブルシューティング . . . . . . . . . . . . . . . . 125リモート・デプロイメントのトラブルシューティング . . . . . . . . . . . . . . . 131エージェントのトラブルシューティング . . . 132CPU スロットルのトラブルシューティング . . 140リモート・ログ・ファイル・モニターのトラブルシューティング . . . . . . . . . . . . 141ワークスペースのトラブルシューティング . . . 142シチュエーションのトラブルシューティング . . 145アクション実行コマンドのトラブルシューティング . . . . . . . . . . . . . . . . 149

サポート情報 . . . . . . . . . . . . . 150

付録 A. イベント・マッピング . . . . 151

付録 B. Windows 2008 イベント・ログ . . . . . . . . . . . . . . . . 157

付録 C. 文書ライブラリー . . . . . . 159前提資料 . . . . . . . . . . . . . . . 159関連資料 . . . . . . . . . . . . . . . 160その他の文書の入手先 . . . . . . . . . . 160

特記事項. . . . . . . . . . . . . . 163商標 . . . . . . . . . . . . . . . . 165

索引 . . . . . . . . . . . . . . . 167

iv Tivoli Log File Agent ユーザーズ・ガイド

図1. send_all が選択された場合のヒストリカル・ビ

ューおよびキャッシュ・ビュー . . . . . . 552. send_none が選択された場合のヒストリカル・

ビューおよびキャッシュ・ビュー . . . . . 56

3. send_first が選択された場合のヒストリカル・ビューおよびキャッシュ・ビュー . . . . . 57

4. nInteger が選択された場合のヒストリカル・ビューおよびキャッシュ・ビュー . . . . . . 58

© Copyright IBM Corp. 2010, 2013 v

vi Tivoli Log File Agent ユーザーズ・ガイド

表1. サーバーへの構成ファイルの割り振り . . . . 252. スロットおよび DEFAULT 値 . . . . . . 473. EventFloodThreshold 値 . . . . . . . . . 524. Log File Agent によってログに記録されるヒストリカル・データのキャパシティー・プランニング . . . . . . . . . . . . . 101

5. IBM ソフトウェア・サポートへの問い合わせ前に収集する情報 . . . . . . . . . . 111

6. トラブルシューティング・エージェントのトレース・ログ・ファイル . . . . . . . . 114

7. インストールおよび構成の問題と解決方法 1268. アンインストールの一般的な問題および解決方法 . . . . . . . . . . . . . . 129

9. リモート・デプロイメントの問題および解決方法 . . . . . . . . . . . . . . 131

10. エージェントの問題および解決方法 . . . . 13211. CPU スロットルの問題および解決方法 14012. リモート・ログ・ファイル・モニターの問題

とその解決方法 . . . . . . . . . . . 14113. ワークスペースの問題および解決方法 14314. シチュエーションの問題および解決方法 14515. アクション実行コマンドの問題および解決方

法 . . . . . . . . . . . . . . . 149

© Copyright IBM Corp. 2010, 2013 vii

viii Tivoli Log File Agent ユーザーズ・ガイド

第 1 章エージェントの概要

Tivoli Log File Agent (製品コード: LO) には、アプリケーション・ログ・ファイルをモニターする機能が用意されています。

IBM® Tivoli® Monitoring は、Log File Agentのベースとなるソフトウェアです。

Tivoli Log File Agent は、正規表現を使用する構成可能なログ・ファイル・モニター能力を備えたエージェントです。互換性を維持するために、このエージェントは、以前 Tivoli Event Console ログ・ファイル・アダプターによって使用されていた構成情報および書式制御ストリングを使用できるようになっています。これらのストリングを使用することにより、エージェントはフォーマット・ファイル内のパターンに従ってログ・データをフィルターに掛け、関係のあるデータのみをイベント・コンシューマーに送信できます。エージェントはデータを、Tivoli Enterprise Monitoring Server にも、Event Integration Facility (EIF) を介して OMNIbus EIF プローブなどの任意の EIF 受信側にも、両方に送信できます。

IBM Tivoli MonitoringIBM Tivoli Monitoring により、指定された 1 台または複数のワークステーションからエンタープライズ内のすべてのシステムのアベイラビリティーおよびパフォーマンスをモニターできます。また、トレンドを追跡したり、システムの問題のトラブルシューティングを行ったりするのに役立つヒストリカル・データが提供されます。

IBM Tivoli Monitoring を使用して、以下のタスクを実行できます。

v 定義済みのシチュエーションまたはカスタム・シチュエーションを使用して管理対象システムのアラートをモニターする。

v 独自のパフォーマンスしきい値を設定する。

v アラートに至った原因をトレースする。

v システム条件に関する広範囲のデータを収集する。

v ポリシーを使用してアクションの実行、作業のスケジュール、および手動タスクの自動化を行う。

Tivoli Enterprise Portal は、IBM Tivoli Monitoring 製品のインターフェースです。Tivoli Enterprise Portal

に表示されたご使用の環境の統合ビューを使用して、エンタープライズ全体のパフォーマンスの問題をモニターし、解決することができます。

IBM Tivoli Monitoring および Tivoli Enterprise Portal について詳しくは、 159ページの『前提資料』に記載されている IBM Tivoli Monitoring の資料を参照してください。

このリリースの新機能バージョン 6.3 の Log File Agentでは、バージョン 6.2.3.2 以降に、以下の機能拡張が行われています。

v リモート・ログ・ファイル・モニター。Log File Agent では、セキュア・シェル (SSH) ファイル転送プロトコルを使用して、リモート・システムでテキスト・ログをモニターすることができます。詳しくは、 15ページの『リモート・ログ・ファイル・モニター』を参照してください。

v システム要件に関する変更。システム要件に関する情報については、Software product compatibility

reports (http://publib.boulder.ibm.com/infocenter/prodguid/v1r0/clarity/index.html) を参照して

© Copyright IBM Corp. 2010, 2013 1

http://publib.boulder.ibm.com/infocenter/prodguid/v1r0/clarity/index.html


ください。Log File Agent 固有のソフトウェア製品互換性レポートを実行する方法については、 8ページの『Log File Agent 用のソフトウェア製品互換性レポートの生成』を参照してください。

v IBM Tivoli Enterprise Console® イベント・マッピングの変更をサポートするように klo.barocファイルが更新されました。

v IBM 前提条件スキャナーのサポートが追加されました。前提条件スキャナーは、Tivoli 製品または IBM

ソリューションのインストールまたはアップグレードの前にシステム環境を分析する、スタンドアロンの前提条件チェック・ツールです。

IBM Tivoli Monitoring 環境のコンポーネントLog File Agent をインストールしてセットアップすると、Tivoli Monitoring 用にクライアント、サーバー、およびモニター・エージェントが実装された環境になります。

この Tivoli Monitoring 環境には、以下のコンポーネントが含まれます。

Tivoli Enterprise Portal クライアントこのポータルには、エンタープライズの表示およびモニターを行うための Java™ ベースのユーザー・インターフェースが用意されています。

Tivoli Enterprise Portal Serverポータル・サーバーは、クライアントと Tivoli Enterprise Monitoring Server の間に置かれ、モニター・エージェントからのデータを取得、操作、および分析できるようにします。 Tivoli Enterprise

Portal Server は、すべてのユーザー・データの中央リポジトリーです。

Tivoli Enterprise Monitoring Serverモニター・サーバーは、モニター・エージェントから受け取ったアラートの収集および制御を行うポイントとして機能し、パフォーマンスおよび可用性のデータを収集します。Tivoli Enterprise

Monitoring Server は、ヒストリカル・データのリポジトリーでもあります。

Tivoli Enterprise Monitoring Agent、Log File Agentこのモニター・エージェントは、データを収集して、収集したデータを Tivoli Enterprise

Monitoring Server、Tivoli Enterprise Portal Server、Tivoli Enterprise Portal、Tivoli Data

Warehouse、および IBM Dashboard Application Services Hub に配布します。

このエージェントの複数のコピーを同一のシステム上で実行できます。

IBM Tivoli Netcool/OMNIbusTivoli Netcool/OMNIbus はオプションのコンポーネントであり、推奨されるイベント管理コンポーネントです。Netcool/OMNIbus ソフトウェアは、複雑なネットワークと IT ドメイン・イベントをリアルタイムに集中モニターするサービス・レベル管理 (SLM) システムです。イベント情報は高性能なメモリー内データベースで追跡され、個別に構成可能なフィルターおよびビューを通して特定のユーザーに表示されます。このソフトウェアには、管理対象イベントでインテリジェント処理を実行するために使用できる自動化機能が含まれています。このソフトウェアを使用すると、Tivoli Monitoring シチュエーションのイベントを Tivoli Netcool/OMNIbus に転送できます。

IBM Tivoli Enterprise ConsoleTivoli Enterprise Console はオプションのコンポーネントであり、他の Tivoli ソフトウェア・アプリケーション、Tivoli パートナー・アプリケーション、カスタム・アプリケーション、ネットワーク管理プラットフォーム、およびリレーショナル・データベース・システムなどといった、さまざまなソースからのイベントを一元的に収集します。これらのイベントは、Tivoli Enterprise Portal

を介して (イベント・ビューアーを使用して) 表示できます。また、Tivoli Monitoring のシチュエーションから Tivoli Enterprise Console コンポーネントにイベントを転送することも可能です。ま

2 Tivoli Log File Agent ユーザーズ・ガイド

だ Tivoli Enterprise Console を使用しておらず、イベント管理コンポーネントが必要な場合は、IBM Tivoli Netcool/OMNIbus を使用することを選択できます。

IBM Tivoli Common ReportingTivoli Common Reporting は、Tivoli ソフトウェアのユーザーが利用できる、単独でインストール可能な機能で、レポートを生成してカスタマイズするための一貫した方法を提供します。一部の個別製品には、Tivoli Common Reporting での使用を想定して設計されたレポートが用意されており、一貫性のあるルック・アンド・フィールを備えています。

IBM Tivoli Application Dependency Discovery Manager (TADDM)TADDM は、アプリケーションの複雑さをリアルタイムで把握できるアプリケーション・マップを作成するための自動化ディスカバリーおよび構成トラッキングの機能を提供します。

IBM Tivoli Business Service ManagerTivoli Business Service Manager コンポーネントは、ビジネス要件に基づいて効果的にアラートに応答するのに役立つリアルタイム情報を提供します。必要に応じて、このコンポーネントを使用して、サービス・レベルの合意 (SLA) を満たすことができます。 Tivoli Business Service Manager

ツールを使用すると、Tivoli Netcool/OMNIbus アラートと統合したり、オプションで SQL データ・ソースのデータと統合したりできるサービス・モデルを構築するのに役立ちます。オプションのコンポーネントでは、他の IBM Tivoli アプリケーション (Tivoli Monitoring や TADDM など)

のデータにアクセスできます。

IBM Dashboard Application Services HubDashboard Application Services Hub には、ネットワーク・セキュリティーやデータベース管理などの重要な管理機能を提供する、核となるコンポーネントのセットが組み込まれています。バージョン 2.2 より新しいリリースでは、このコンポーネントによって Tivoli Integrated Portal コンポーネントが置き換えられます。

エージェント管理サービスIBM Tivoli Monitoring エージェント管理サービスを使用して、Log File Agent を管理できます。

エージェント管理サービスは、Windows、Linux、および UNIX の各 IBM Tivoli Monitoring OS エージェントで使用可能です。これらのサービスは、Log File Agent を使用できる状態を保持し、製品の状況に関する情報を Tivoli Enterprise Portal に提供するように設計されています。IBM Tivoli Monitoring V6.2.2 フィックスパック 2 以降では、エージェント管理サービスがサポートされています。エージェント管理サービスについて詳しくは、「IBM Tivoli Monitoring 管理者ガイド」の『エージェント管理サービス』を参照してください。

ユーザー・インターフェースのオプション基本 IBM Tivoli Monitoring ソフトウェアおよびその他の統合アプリケーションをインストールすると、さまざまなインターフェースが提供され、リソースおよびデータの処理に使用できるようになります。

使用可能なインターフェースは次のとおりです。

Tivoli Enterprise Portal ユーザー・インターフェースTivoli Enterprise Portal をデスクトップ・アプリケーションとして実行することも、ブラウザー・アプリケーションとして実行することも可能です。クライアント・インターフェースは、Windows

または Linux ワークステーション上の Java ベースのグラフィカル・ユーザー・インターフェース(GUI) です。ブラウザー・アプリケーションは Tivoli Enterprise Portal Server とともに自動的にインストールされます。デスクトップ・アプリケーションは、Tivoli Monitoring インストール・メデ

第 1 章エージェントの概要 3

ィアまたは Java Web Start アプリケーションを使用してインストールされます。インターネット・ブラウザーで Tivoli Enterprise Portal ブラウザー・クライアントを開始するには、Web サーバーにインストールした特定の Tivoli Enterprise Portal ブラウザー・クライアントの URL を入力します。

コマンド行インターフェースTivoli Monitoring コマンドを使用して、Tivoli Monitoring コンポーネントおよびその構成を管理することができます。Tivoli Enterprise Console イベント・サーバーまたは Tivoli Netcool/OMNIbus

ObjectServer のコマンドを実行して、エンタープライズ・シチュエーションに関するイベント同期を構成することもできます。

Tivoli Enterprise Monitoring Services の管理ウィンドウTivoli Enterprise Monitoring Services の管理ユーティリティーのウィンドウを使用して、エージェントを構成し、自動開始が指定されていない Tivoli サービスを開始できます。

IBM Tivoli Netcool/OMNIbus イベント・リストNetcool/OMNIbus イベント・リストを使用して、イベントをモニターおよび管理することができます。Netcool/OMNIbus ObjectServer がイベント、アラート、メッセージ、またはデータ項目を受け取ると、イベントが作成されます。各イベントは、ObjectServer の alerts.status 表の行に表示される情報の列 (またはフィールド) で構成されています。また、Tivoli Netcool/OMNIbus Web GUI

は、1 つ以上のデータ・ソースからのネットワーク・イベントを処理して、イベント・データをさまざまなグラフィカル形式で表示する Web ベースのアプリケーションです。

IBM Tivoli Enterprise ConsoleTivoli Enterprise Console を使用して、組織の IT サービスの可用性を最適化することができます。Tivoli Enterprise Console は、システム、ネットワーク、データベース、およびアプリケーションの管理を統合するイベント管理アプリケーションです。まだ Tivoli Enterprise Console を使用しておらず、イベント管理コンポーネントが必要な場合は、Tivoli Netcool/OMNIbus を使用することを選択できます。

IBM Tivoli Common ReportingTivoli Common Reporting Web ユーザー・インターフェースを使用して、レポート・パラメーターおよびその他のレポート・プロパティーの指定、フォーマット済みレポートの生成、レポート生成のスケジュール設定、およびレポートの表示を行うことができます。このユーザー・インターフェースは、Dashboard Application Services Hub に基づくインターフェースです。

IBM Tivoli Application Dependency Discovery Managerディスカバリー管理コンソールは、ディスカバリーを管理するための TADDM クライアント・ユーザー・インターフェースです。

IBM Tivoli Business Service ManagerTivoli Business Service Manager コンソールでは、サービス・モデル内のサービスおよびビジネス要件を論理的にリンクするために使用できるグラフィカル・ユーザー・インターフェースが提供されます。サービス・モデルは、特定の時点における企業のパフォーマンス、または特定の期間にわたる企業のパフォーマンスに関する秒単位のビューをオペレーターに提供します。

IBM Dashboard Application Services HubDashboard Application Services Hub には、このフレームワークを使用するアプリケーション用の管理コンソールが用意されています。これは Web ベースのコンソールで、製品用の共通タスクをナビゲーションする機能、複数の製品のデータを 1 つのビューに集約する機能、さまざまな製品のビューの間でメッセージを受け渡す機能を提供します。バージョン 2.2 より新しいリリースでは、このインターフェースによって Tivoli Integrated Portal コンポーネントが置き換えられます。


データ・ソースモニター・エージェントは、特定のデータ・ソースからデータを収集します。

Log File Agent は、以下のソースからデータを収集します。

ログ・ファイルこのエージェントは、ファイル・システムを使用してアプリケーションのログ・ファイルをモニターし、他のデータ・ファイルを使用してメトリックを収集します。

第 1 章エージェントの概要 5


第 2 章エージェントをインストールおよび構成するための要件

エージェントをインストールおよび構成するためには、「IBM Tivoli Monitoring インストールおよび設定ガイド」と、エージェント固有のインストールおよび構成情報を参照する必要があります。

Tivoli Log File Agent のインストールおよび構成を行うには、「IBM Tivoli Monitoring インストールおよび設定ガイド」に記載されたモニター・エージェントのインストールに関する手順とともに、エージェント固有のインストールおよび構成情報を参照してください。

応答ファイルを使用してサイレント・インストールを行う場合は、「IBM Tivoli Monitoring インストールおよび設定ガイド」の『IBM Tivoli Monitoring のサイレント・インストールの実行』を参照してください。

自己記述型エージェント機能を使用すると、IBM Tivoli Monitoring V6.2.3 以降を使用する、新規または更新された IBM Tivoli Monitoring エージェントは、追加の製品サポート・インストール手順を実行しなくても、インストール後に作動可能になります。この機能を利用するには、「IBM Tivoli Monitoring インストールおよび設定ガイド」の『ハブ・モニター・サーバーでの自己記述型エージェント機能の使用可能化』を参照してください。また、「IBM Tivoli Monitoring 管理者ガイド」の『自己記述型モニター・エージェント』も参照してください。

モニター・エージェントの要件Log File Agent には、オペレーティング・システム、リソース、およびソフトウェアに関する特定の要件があります。

Tivoli Log File Agent には、「IBM Tivoli Monitoring インストールおよび設定ガイド」に記載された要件のほかに、以下の要件があります。

v システム要件に関する最新情報については、Software product compatibility reports (http://

publib.boulder.ibm.com/infocenter/prodguid/v1r0/clarity/index.html) を参照してください。Log File Agent 固有のソフトウェア製品互換性レポートを実行する方法については、 8ページの『Log File Agent 用のソフトウェア製品互換性レポートの生成』を参照してください。

v ハブ・モニター・サーバー、ポータル・サーバー、およびモニター・エージェントをホストする単一コンピューターには、約 300 MB のスペースが必要です。モニター・エージェントのみをホストするコンピューターには、約 30 MB のスペースが必要です。これには、モニター・エージェントのための特定の有効化コードのスペースが含まれます。モニター・コンピューターにデプロイする追加のモニター・エージェントごとに、さらにスペースが必要になります。 30 MB という数値は概算であり、オペレーティング・システムによって異なります。

v Linux バージョンでは、エージェントを正常に機能させるためにいくつかの互換性ライブラリーをインストールする必要があります。エージェントを正常に機能させるためには、最新バージョンのlibstdc++、libgcc、および compat-libstdc++ が必要です。 Linux RedHat 4、5 および 6、およびSuSE 9 および 10 では C++ Runtime 6.0、libstdc++.so.6 も必要です。

v モニター・エージェントを、次のいずれか (または両方) のソフトウェア製品に接続する必要があります。

– IBM Tivoli Monitoring V6.2.2.2 以降

– Tivoli Netcool/OMNIbus



前提ソフトウェアをインストールした後、Tivoli Log File Agent が作動するのに必要な以下のソフトウェアをインストールします。

– Tivoli Log File Agent

イベントを IBM Tivoli Monitoring に送信するには、以下のソフトウェアをインストールします。

– Tivoli Log File Agent (Tivoli Enterprise Monitoring Server のサポートに必要)

– Tivoli Log File Agent (Tivoli Enterprise Portal Server のサポートに必要)

– Tivoli Log File Agent (Tivoli Enterprise Portal デスクトップ・クライアントのサポートに必要)

– Tivoli Log File Agent (Tivoli Enterprise Portal ブラウザー・クライアントのサポートに必要)

イベントを Tivoli Netcool/OMNIbus に送信するには、以下のソフトウェアをインストールします。

– Probe for Tivoli EIF

詳しくは、「IBM Tivoli Netcool/OMNIbus Probe for Tivoli EIF リファレンス・ガイド」を参照してください。

このモニター・エージェントは、以下のデータ・ソースからデータを収集します。

ログ・ファイルエージェントは、ファイル・システムを使用して以下のログ・ファイル・タイプをモニターします。

v アプリケーション・ログ・ファイル

v Windows イベント・ログ

v UNIX システム・ログ

v AIX® エラー・レポート・コマンド・ログ

Log File Agent 用のソフトウェア製品互換性レポートの生成Log File Agent 用のソフトウェア製品互換性レポートを生成するには、以下の手順を実行します。

このタスクについて

IBM サポート・ポータルで、Software Product Compatibility Reports を使用することができます。Software

Product Compatibility Reports は、互換性のある IBM ソフトウェアの組み合わせに関するカスタム・レポートを簡単に生成することができるツールです。

手順1. Software Product Compatibility Reports のサイト (Software Product Compatibility Reports) に移動します。

2. 「In-depth reports」セクションで「Create a report」を選択します。

3. 「Full or partial product name:」フィールドに「Tivoli Monitoring」と入力します。

4. 検索アイコンをクリックします。

5. 「Search results:」領域で「Tivoli Monitoring」を選択します。

6. 「Version」リストで、いずれかのバージョンを選択します。

7. 「Scope of report」セクションで「Product component」を選択します。

8. 「Select component」セクションで「Log File Agent」を選択します。

9. 「Submit」をクリックします。新しいブラウザー・ウィンドウでレポートが表示されます。


http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcool_OMNIbus.doc/probes/tivoli_eif_v11/tivoli_eif_v11/wip/reference/tveifv11_intro.html


エージェント固有のインストールおよび構成Tivoli Log File Agentのインストールおよび構成を行うには、「 IBM Tivoli Monitoring インストールおよび設定ガイド」のインストールと構成の情報に加え、このセクションの情報を参照してください。

エージェントを構成するには、構成パネルまたはコマンド行を使用して、構成ファイルを作成します。構成ファイルは、エージェントに対して、モニター対象のログ・ファイル、それらのファイルの位置、および使用するフォーマットを指示します。

構成パネルからの構成構成パネルを使用すると、Tivoli Enterprise Portal Server グラフィカル・ユーザー・インターフェースからエージェントを構成することができます。

手順Tivoli Enterprise Monitoring Server を使用する場合

v 「Tivoli Enterprise Monitoring Services の管理」グラフィカル・インターフェースからエージェントを構成するには、リストからそのエージェントを選択し、右クリックして、UNIX/Linux の場合は「構成」を、Windows の場合は「デフォルトを使用して構成します」を選択します。構成パネルが開きます。構成パネルには、「ログ・ファイル・アダプターの構成」と「ログ・ファイル・アダプターのグローバル設定」の 2 つのタブがあります。

v 「ログ・ファイル・アダプターの構成」タブで、以下の構成アイテムを指定する必要があります。

– インスタンス名

エージェントのこのインスタンスを一意的に識別するために、分かりやすい ID ストリングを入力してください。特定の 1 つのシステムでエージェントの複数のインスタンスを、それぞれ別個の構成で実行することが可能です。例えば、1 つのシステムにある 2 つの異なるアプリケーションのログをモニターしたい場合があります。各アプリケーションではログのフォーマットが異なるため、それぞれのアプリケーション用に別個のフォーマット・ファイルを用意する必要があります。エージェントのこのインスタンスが 2 つのアプリケーションのうちのどちらをモニターするのかを識別するための名前を、ここで指定してください。

– 構成ファイル

詳細な構成オプションを含む .conf ファイルへの絶対パス名。例えば、以前に UNIX システムでTivoli Enterprise Console ログ・ファイル・アダプターを使用していた場合、構成ファイルは/etc/Tivoli/tecad/etc/tecad_logfile.conf などのようになります。その値をここで指定してください。.conf ファイルについて詳しくは、 27ページの『第 3 章構成ファイル』を参照してください。

注: モニター・プロファイルを作成するためにサブノード機能を使用する場合、複数の構成ファイルを用意することができます。複数の構成ファイルがある場合、ここにはパス名を入力しないでください。詳しくは、 23ページの『サブノード』を参照してください。

– フォーマット・ファイル

モニター対象ログで突き合わせるフォーマット・ストリング・パターンを含む .fmt ファイルへの絶対パス名。例えば、以前に UNIX システムで Tivoli Enterprise Console ログ・ファイル・アダプターを使用していた場合、フォーマット・ファイルは /etc/Tivoli/tecad/etc/C/tecad_logfile.fmt などのようになります。その値をここで指定してください。.fmt ファイルについて詳しくは、 39ページの『第 4 章フォーマット・ファイル』を参照してください。

第 2 章エージェントをインストールおよび構成するための要件 9

注: モニター・プロファイルを作成するためにサブノード機能を使用する場合、複数のフォーマット・ファイルを用意することができます。複数のフォーマット・ファイルがある場合、ここにはパス名を入力しないでください。詳しくは、 23ページの『サブノード』を参照してください。

– ITM イベントの送信

このオプションが Yes に設定されている場合、エージェントはイベント・データを Tivoli Enterprise

Monitoring Server に送信し、このオプションが No に設定されている場合、エージェントはイベント・データを送信しません。このオプションの設定はグローバルであり、すべてのモニタリング・プロファイルに適用されます。

– EIF イベントを送信

このオプションが Yes に設定されている場合、エージェントは EIF を介して受信側に直接イベント・データを送信し、このオプションが No に設定されている場合、エージェントはイベント・データを送信しません。このオプションの設定はグローバルであり、すべてのモニタリング・プロファイルに適用されます。

注: イベントは、EIF 受信側で使用する必要があります。そうしないと、エージェント・キャッシュがいっぱいになった場合に問題が発生する可能性があります。エージェント・キャッシュ内の EIF イベントのバッファリングについては、 35ページの『以下のオプションは、イベントが EIF に転送される場合にのみ適用されます。』を参照してください。

– UNIX syslog の自動的初期化

UNIX および Linux システムでこのオプションを Yes に設定すると、エージェントが自動的にsyslog 機能を構成し、イベントの標準的なセットを、エージェントがモニターするパイプに書き込むようになります。この設定を有効にすると、ログ・ファイルの保守およびロールオーバーを行わずにsyslog イベントをモニターすることができます。 USE_CONF_FILE_VALUE に設定すると、エージェントは、構成ファイル (.conf) で (AutoInitSyslog) の設定を検査します。構成ファイルでこの設定を行わない場合、No に設定した場合と同じになります。

この設定は、Microsoft Windows では無視されます。デフォルト値は USE_CONF_FILE_VALUE です。

v 「ログ・ファイル・アダプターのグローバル設定」タブで、以下のオプションの構成アイテムを指定することができます。

– プロセスの優先順位クラス

この設定は、プロセスに対するオペレーティング・システムのスケジューラー優先順位です。A が最低の優先順位で、C がオペレーティング・システムのデフォルト、F が最高の優先順位です。設定値は、A、B、C、D、E、F、「USE_CONF_FILE_VALUE」のいずれかです。デフォルト設定はUSE_CONF_FILE_VALUE です。この設定は、CPU スロットル機能と関連付けられています。

– プロセスの最大 CPU 率

この設定値は、1 分の間隔内でエージェントが使用できる、すべてのシステム CPU の最大許容率を表します。有効な値は 5 から 100 です。デフォルト値は 100 です。この設定は、CPU スロットル機能と関連付けられています。5 より小さい値を指定すると、最小値である 5 が使用されます。

– 構成ファイル自動検出ディレクトリー

この設定は、構成ファイル (.conf) を自動検出するためにスキャンするファイル・システム・ディレクトリー・ツリーのポイントを設定するストリング値です。同じロケーションに、同じベース名のフォーマット・ファイル (.fmt) が存在する必要があります。このようなファイルのペアが検出されるたびに、モニタリング・プロファイルが作成されます。デフォルト設定は ${CANDLE_HOME}/config/lo


です。この設定は、サブノード (モニタリング・プロファイル) 機能と関連付けられています。ディレクトリー・パスを 1 つだけ指定できます。コンマで区切るなどして複数のディレクトリー・パスを入力することはできません。

注: システム・リソースに影響するのを避けるため、このパスをディレクトリー・ツリー内のあまり高いレベルに設定しないでください。エージェントは、指定されたポイントから再帰的に検索します。例えば、パスを / に設定すると、エージェントは 1 分ごとにファイル・システム全体を検索しようとします。

Tivoli Enterprise Monitoring Server を使用しない場合

v 前に説明した「構成」パネルで、「ITM イベントの送信」オプションを「No」に設定します。

注: Windows 以外のシステムでは、「Tivoli Enterprise Monitoring Services の管理」インターフェースにより、Tivoli Enterprise Monitoring Server への接続を構成するためのパネルも提供されます。このパネルには、「TEMS なし」というチェック・ボックスがあります。このオプションを選択すると、「TEMSホスト名」フィールドが使用不可になります。

関連概念:

14ページの『CPU スロットル』CPU スロットルを使用して、エージェントのプロセッサー使用量を管理します。

23ページの『サブノード』サブノードを使用して、単一のエージェント・インスタンスから複数のアプリケーションをモニターするモニター・プロファイルを実装します。

関連タスク:

19ページの『Tivoli Netcool OMNIbus ObjectServer へのイベントの転送』イベントを 1 つ以上の Tivoli Netcool/OMNIbus ObjectServer に転送するように Tivoli Log File Agent を構成できます。

『コマンド行からの構成』UNIX システムでは、コマンド行から Tivoli Log File Agent を構成することができます。

関連資料:

12ページの『構成ファイル』構成ファイル (.conf および .fmt) は、エージェントに対して、モニター対象のログ・ファイル、それらのファイルの位置、およびそれらのファイルを読み取るためのフォーマットを指示します。

コマンド行からの構成UNIX システムでは、コマンド行から Tivoli Log File Agent を構成することができます。

手順

UNIX システムのコマンド行から Tivoli Log File Agent を構成するには、次のコマンドを入力して、表示されるプロンプトに従います。itmcmd config -A lo

注: 構成オプションは、構成パネルから構成する場合に説明されているオプションと同じです。


関連タスク:

9ページの『構成パネルからの構成』構成パネルを使用すると、Tivoli Enterprise Portal Server グラフィカル・ユーザー・インターフェースからエージェントを構成することができます。

構成ファイル構成ファイル (.conf および .fmt) は、エージェントに対して、モニター対象のログ・ファイル、それらのファイルの位置、およびそれらのファイルを読み取るためのフォーマットを指示します。

構成ファイルについて

エージェント構成は、命名、エージェント操作のモード、および構成ファイル (.conf) とフォーマット・ファイル (.fmt) の位置を示します。2 つの構成ファイルは、ファイル・モニタリングを制御します。構成ファイルの位置は IBM Tivoli Monitoring の構成プロセス中に指定する必要があります。後続の構成は、これらのファイルに基づいて行われます。

注: モニター・プロファイルを作成するためにサブノード機能を使用する場合、構成ファイル (.conf) とフォーマット・ファイル (.fmt) のペアを複数用意することができます。詳しくは、 23ページの『サブノード』を参照してください。

構成ファイルとフォーマット・ファイルの例がエージェントで提供されます。例えば、regex1.conf およびregex1.fmt は正規表現で使用される構成ファイルとフォーマット・ファイルです。これらのサンプル・ファイルは、エージェント・メディア・イメージの examples ディレクトリーにあります。

(.conf) ファイルと (.fmt) ファイルのパスおよびファイル名は ASCII のみにする必要があります。構成ファイルとフォーマット・ファイルの名前を、モニター対象のアプリケーション・ファイルまたはログ・ファイルと一致させると便利です。

注: 構成ファイルの Filter ステートメントは EIF にのみ適用されます。.conf ファイルで使用できるFilter ステートメントは、EIF 受信側に送信される任意の EIF イベントに適用されますが、Tivoli

Enterprise Monitoring Server に送信されるイベントには適用されません。したがって、Tivoli Enterprise

Monitoring Server に送信されるイベントをフィルターに掛ける必要がある場合には、フォーマット・ファイルを使用してください。例えば、フォーマット・ファイル内のイベントを特殊な「*DISCARD*」クラスに割り当てると、それらのイベントは無視されます。この仕組みは、いずれかのイベント・チャネルを介して実現されます。


関連概念:

39ページの『第 4 章フォーマット・ファイル』Tivoli Log File Agent は、システム・ログ・メッセージから情報を抽出し、さまざまなログ・メッセージをイベント・クラスと突き合わせます。フォーマット・ファイルは、ログ・メッセージをイベント・クラスと突き合わせるためのルックアップ・ファイルとして機能します。これにより、読み取る内容、突き合わせる内容、およびデータをフォーマット設定する方法をイベント・クラスに指示します。

39ページの『フォーマット・ファイル仕様』フォーマット・ファイルは、モニター対象ログ内のイベントを突き合わせるためにエージェントが検索するパターンを記述します。フォーマット・ファイルは、1 つ以上のフォーマット仕様から成り立っています。

関連タスク:


関連資料:

27ページの『第 3 章構成ファイル』Tivoli Log File Agent は、構成オプションとフィルターを含む構成ファイルを使用します。この構成ファイルを作成して、それを使用するためのエージェント・インスタンスを構成してください。

エージェントの構成ファイルとフォーマット・ファイルの変更Tivoli Log File Agent は、開始時にその構成ファイル (.conf) とフォーマット・ファイル (.fmt) を読み取り、その後 60 秒ごとにタイム・スタンプをモニターします。

構成ファイルまたはフォーマット・ファイルのタイム・スタンプが変更された場合、エージェントは、再始動することなくその構成を動的に再初期化します。再初期化中に、モニタリングが一時的に中断します。モニタリングの再開時に、エージェントは、モニター・ログ内の再開位置を決定する必要があります。この場合、エージェントは完全な停止後の再始動の場合と同様に動作します。

注: 構成ファイルまたはフォーマット・ファイルが変更された後のエージェント再初期化によって、ログ・ファイル正規表現統計、ログ・ファイル状況、およびログ・ファイル・イベントの各属性グループ内の情報がリセットされます。これらの属性グループについて詳しくは、 67ページの『第 7 章属性リファレンス』を参照してください。

デフォルトでは、再初期化が完了すると、エージェントはファイルの末尾からモニタリングを開始します。この開始位置によって、モニタリングの中断中に発生したイベントが欠落する可能性があります。モニタリングの再開時にこのようなイベントを確実に収集するには、NumEventsToCatchUp=-1 設定を使用してください。

NumEventsToCatchUp=-1 を設定すると、位置ファイルが維持されます。位置ファイルは、エージェントがログ・ファイルを読み取るたびに更新されます。更新では、エージェントの再始動に備えてログ・ファイル内にエージェントの位置が保存されます。位置ファイルの維持はパフォーマンスに若干の影響を与えますので、このファイルは必要な場合にのみ維持してください。 NumEventsToCatchUp について詳しくは、 27ページの『第 3 章構成ファイル』を参照してください。

注: 一部の構成値は構成ファイル内に存在しないため、初期構成時に設定されません。これらの値を変更した場合には、エージェントを再始動する必要があります。


エージェント構成の動的な再初期化を実行すると、構成ファイルとフォーマット・ファイルの管理のためにIBM Tivoli Monitoring の一元化された構成を使用できるようになります。詳しくは、『一元化された構成』を参照してください。

関連概念:


関連資料:


一元化された構成多くのモニター・エージェントでローカル構成ファイルを更新するには、一元化された構成を使用してください。

一元化された構成を使用して、中央の HTTP サーバーで Log File Agent の構成ファイルおよびフォーマット・ファイルをホストすることができます。Tivoli Log File Agent とともにインストールされたユーザー提供の XML ファイルには、HTTP サーバーの場所、ファイルへのパス、および認証情報 (存在する場合) が記述されます。エージェントは、サーバーを定期的にポーリングし、変更が行われた場合にはファイルをダウンロードします。エージェントは、ファイルのローカル・コピーが変更されたことを自動的に認識し、それらのローカル・コピーを使用できるようにエージェント自体を再初期化します。

セットアップの詳細については、「IBM Tivoli Monitoring 管理者ガイド」の『一元化された構成』を参照してください。

CPU スロットルCPU スロットルを使用して、エージェントのプロセッサー使用量を管理します。

エージェントをインストールするときには、オプションの「プロセスの優先順位クラス」および「プロセスの最大 CPU 率」設定を指定できます。これらのオプションの設定を使用して、エージェントによるプロセッサー時間の使用を制限できます。これらの設定を使用して、Log File Agent プロセスの優先順位を設定するか、プロセッサー使用量を制限することができます。通常は、どちらか一方を設定します。

「プロセスの優先順位クラス」設定を使用して、Log File Agent プロセスのオペレーティング・システム優先順位を設定します。この値を正しく設定すると、Log File Agent は、システム上の他のプロセスがプロセッサーを必要としない場合にのみ実行されます。また、この値が正しく設定されると、Log File Agent

は、実行中の他のアプリケーションを妨害しない場合にのみログを処理します。「プロセスの優先順位クラス」値を使用するのは、Log File Agent が使用するプロセッサー時間を特定の割合に明示的に制限しない場合です。例えば、システムがアイドルである場合に使用します。

「プロセスの最大 CPU 率」設定を使用して、1 分間隔での Log File Agent プロセスの最大プロセッサー使用量を管理します。100 より小さい「プロセスの最大 CPU 率」値が指定された場合、スロットルが有効になります。「プロセスの最大 CPU 率」値は、1 分の時間間隔内でのエージェントによるプロセッサーの使用の最大制限を設定します。

「プロセスの最大 CPU 率」値を設定するときには、以下の点に注意する必要があります。


http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.3fp1/adminuse/centralconfig_intro.htm

v 「プロセスの最大 CPU 率」値は、1 分の測定間隔内での目標です。1 分より小さい間隔については、エージェントがプロセッサー時間の 100% を使用しても、1 分の測定間隔の目標を達成することは可能です。比較の手段として、Linux インストール済み環境では、top コマンドを使用して、プロセスのプロセッサー使用量を表示し、毎秒変化する値を表示することができます。しかし、1 分間隔でのプロセスのプロセッサー使用量を評価する方法としては、間隔の値 60 を指定した top コマンド (top -d 60) のほうが適切です。

v 「プロセスの最大 CPU 率」値は、1 分の測定間隔内での目標です。実際の使用量はこの値より小さい場合があります。例えば、1 分間隔の後半に多くのイベントが到着した場合、エージェントは、間隔の前半の使用量が少なかったことを考慮しないため、間隔の後半で最大制限を超えることはありません。

v CPU スロットルは、エージェントが仮想マシン (VM) 内で実行されている場合には、予期されたとおりに動作しないことがあります。VM のクロックは正確ですが、VM に割り振られる実際のプロセッサー時間は、VM の内部から判別できません。したがって、特定の実時間の中で使用可能な実際のプロセッサー時間を確定できない可能性があります。時間を確定できないために、エージェントがそのプロセッサー使用量を不正確に認識し、その目標を達成できないことがあります。

v CPU スロットルを使用すると、大量のデータを処理するために必要な経過時間が引き延ばされます。イベントを処理するには、所定のプロセッサー時間が必要です。制限の設定が低すぎる場合、エージェントは、高いイベント率に対応できないことがあります。

関連タスク:


リモート・ログ・ファイル・モニターリモート・ログ・ファイル・モニターを使用して、リモート・システムでログ・ファイルをモニターすることができます。

Log File Agent では、セキュア・シェル (SSH) ファイル転送プロトコルを使用して、リモート・システムでテキスト・ログ・ファイルをモニターすることできます。SSH ファイル転送プロトコルはセキュア FTP

(SFTP) とも呼ばれます。リモート・ログ・ファイル・モニターでは、リモート・システムで SFTP プロトコルをサポートする SSH デーモンが機能している必要があります。Log File Agent モニター・プロファイルごとに、モニター対象のリモート・ホストのリストを指定することができます。リモート・ホスト・リストの指定は、モニター・プロファイルの構成ファイルの構成 (.conf) ファイル設定 SshHostList を使用して行います。モニター・プロファイルについて詳しくは、 23ページの『サブノード』を参照してください。モニター対象のログ・ファイルは、通常、非リモート・ファイルで使用されるため、LogSources またはRegexLogSources 構成設定を使用して構成されます。SshHostList 設定を使用してリモート・ホスト・リストを指定した場合、リストされたリモート・ホストごとに構成されたすべてのログ・ファイルがモニターされます。

リモート・ホストの認証情報を提供する必要もあります。この情報は、すべてのリモート・システムで有効なユーザー名と、証明書ベースの認証用のパスワードまたは秘密鍵と公開鍵のペアで構成されます。単一の構成内のすべてのリモート・システムで同じ認証データを使用する必要があります。

正規表現処理ではプロセッサーに負荷がかかる場合があることに注意してください。複数のリモート・システムでログ・ファイルをモニターするために単一のエージェントが使用されている場合、そのエージェントはすべての正規表現処理を実行します。この処理は、すべてのリモート・ホストから到着したデータに対して実行されます。このプロセスではワークロードが分散されず集中します。この集中とは、モニター対象のリモート・システムの数の増加に伴い、エージェントが実行されるシステムのワークロードが相当量になる


可能性があることを意味します。多くの場合、サーバーをモニター・エージェントの実行タスク専用にするのが賢明です。このアーキテクチャーには、モニター対象のシステムに正規表現処理のプロセッサー負荷がかからないという利点もあります。この場合、正規表現処理によって、それらのシステムの業務目的が妨げられることはありません。

イベントが生成され、Tivoli Monitoring に送信されると、そのイベントにはイベント発生元のシステムのID である RemoteHost 属性が含まれます。イベントがローカル・システムで発生した場合、この属性は空になります。イベントがリモート・システムで発生した場合、この属性には user@host:port という形式のストリングが設定されます。このストリングは、イベントが発生したリモート・ホストの名前と、そのホスト上で接続に使用されるユーザー名とポートを示しています。

イベントが生成され、Event Integration Facility (EIF) を使用して Tivoli Netcool/OMNIbus に送信された場合は、リモート・ホストに関する情報を伝達する際に RemoteHost という名前のスロットが使用されます。イベントを Tivoli Netcool/OMNIbus に送信する前に、このスロットをフォーマット・ファイル (.fmt) に定義する必要があります。このスロットには RemoteHost という名前を付け、DEFAULT という値を指定します。Log File Agent は、イベントのリモート発信元に関する情報を使用して値を入力します。イベントがローカル・システムで発生した場合、この属性は空になります。イベントがリモート・システムで発生した場合、この属性には user@host:port という形式のストリングが設定されます。このストリングは、イベントが発生したリモート・ホストの名前と、そのホスト上で接続に使用されるユーザー名とポートを示しています。DEFAULT キーワードについて詳しくは、 47ページの『キーワード』を参照してください。

現在、Tivoli 自己モニターの「モニター対象ファイルの状況」属性グループには類似属性が含まれています。この属性を使用すると、モニター対象ファイルごとに、ファイルがモニターされるリモート・システムが表示されます。リモート・ファイルの場合、この属性グループ内の他の情報に影響はありません。リモート・ログ・ファイル・モニターの構成設定について詳しくは、 32ページの『SSH を使用するリモート・ログ・ファイル・モニターのオプション』を参照してください。

例

host1、host2、および host3 という 3 つのリモート・ホストをモニターし、Event Integration Facility (EIF)

を使用してイベントを送信します。これには、イベント内のイベントのリモート発信元も含まれます。loguser というユーザーとして、そのユーザーのパスワードを使用してリモート・ホストで認証を行います。

構成 (.conf) ファイルに (通常の他のオプションに加えて) 以下を追加します。

SshHostList=host1,host2,host3SshUserid=loguserSshAuthType=PASSWORDSshPassword=password

フォーマット・ファイルで、次のように、必要なリモート・スロットをベース・イベントに追加して、他のイベントが継承できるようにします。

REGEX BaseRemoteEvent^(.*)$RemoteHost DEFAULTmsg $1END

REGEX ErrorRemoteEvent FOLLOWS BaseRemoteEvent^ERROR:(.*)$END


サポートされている SSH 機能およびフィーチャー

Log File Agent でサポートされている SSH 機能とフィーチャーを以下に示します。ローカル・システムとリモート・システムの通信用に、鍵交換方式、ホスト・キー・タイプ、暗号、圧縮、MAC ハッシュのいずれかを、リモート・システムでサポートする必要があります。例えば、リモート・システムの SSH デーモンで、いずれかの鍵交換方式がサポートされていない場合、「ログ・ファイルの状況」オブジェクトにはNO SUPPORTED DESC という状況が表示されます。:

鍵交換方式diffie-hellman-group1-sha1、diffie-hellman-group14-sha1、diffie-hellman-group-exchange-sha1

ホスト・キー・タイプssh-rsa、ssh-dss

暗号 aes256-cbc ([email protected])、aes192-cbc、aes128-cbc、arcfour、3des-cbc

圧縮なし

MAC ハッシュhmac-sha1、hmac-sha1-96、hmac-md5、hmac-md5-96

注: Windows では、ネイティブの SSH はサポートされていないため、Windows システムをリモート・サーバーとして使用する場合は、Windows システムに SSH ソフトウェアをインストールして構成する必要があります。

パスワードまたはパスフレーズの暗号化セキュリティーを高めるために、リモート・ログ・ファイル・モニターの使用時に、リモート・システムに送信されるパスワードとパスフレーズを暗号化することができます。


暗号化されたパスワードとパスフレーズは、構成ファイル (.conf) に保管されます。構成ファイルの詳細については、 27ページの『第 3 章構成ファイル』を参照してください。

手順

以下のように、itmpwdsnmp コマンドを実行し、暗号化するパスワードまたはパスフレーズを指定します。

v UNIX および Linux システムの場合、コマンドは IBM Tivoli Monitoring インストール・ディレクトリーから実行されます。

制約事項: CANDLEHOME 環境変数をインストール・ディレクトリー・パスに設定する必要があります。

v Windows の場合、コマンドは TMAITM6 ディレクトリー (デフォルトでは C:¥IBM¥ITM¥TMAITM6) から実行されます。

Linux システムで実行されるコマンドの例を以下に示します。

$ export CANDLEHOME=/opt/IBM/ITM$ /opt/IBM/ITM/bin/itmpwdsnmp

Enter string to be encrypted:mypassword

Confirm string:mypassword

{AES256:keyfile:a}Z7BS23aupYqwlXb1Gh+weg==$


この例のコマンド {AES256:keyfile:a}Z7BS23aupYqwlXb1Gh+weg== からの出力全体が、エージェント構成ファイルに SshPassword を設定する際に使用されます。接頭部 {AES256:keyfile:a} は、エージェントに対して、パスワードが暗号化されていることを示します。秘密鍵ファイルのパスフレーズを暗号化する場合も同じ手順に従ってください。

リモート・インストールおよび構成モニター・エージェントをリモート側でインストールするには、Tivoli Enterprise Portal またはコマンド行を使用します。

エージェントをリモート側にインストールする場合は、エージェントを作動させるための構成値を指定する必要があります。 9ページの『構成パネルからの構成』を参照してください。

configureSystem コマンドまたは addSystem コマンドで使用可能な構成オプションについて詳しくは、「IBM Tivoli Monitoring コマンド・リファレンス」の『tacmd describeSystemType』セクションを参照してください。

addsystem コマンドを実行する前に、tacmd addBundles コマンドを使用してエージェントをリモート・デプロイ・デポに追加する必要があります。以下に例を示します。

tacmd addbundles -i <path to bundles> -t lo -f

リモート側で Tivoli Enterprise Portal またはコマンド行インターフェースからエージェントを構成し、エージェント・インスタンスをリモート側で開始および停止するためには、tacmd addBundles コマンドも実行する必要があります。

Tivoli Enterprise Portal からエージェントをインストールする場合は、「IBM Tivoli Monitoring インストールおよび設定ガイド」を参照してください。

コマンド行インターフェースを使用する場合のリモート・インストールおよび構成コマンドの例を以下に示します。

単一構成の例

構成を 1 つだけ持つ Windows オペレーティング・システムの例です。この例は、Probe for Tivoli EIF 経由でイベントを Tivoli Netcool/OMNIbus サーバーに送信する構成を示します。

tacmd addSystem -t LO -n Primary:sample.node.name:NT-p LOG_FILE_ADAPTER_CONFIGURATION.KLO_AUTO_INIT_SYSLOG=NoLOG_FILE_ADAPTER_CONFIGURATION.KLO_CONF_FILE=valueLOG_FILE_ADAPTER_CONFIGURATION.KLO_FORMAT_FILE=valueLOG_FILE_ADAPTER_CONFIGURATION.KLO_SEND_EIF_EVENTS=YesLOG_FILE_ADAPTER_CONFIGURATION.KLO_SEND_ITM_EVENTS=No

INSTANCE="inst1”

複数構成の例

ディレクトリー /opt/IBM/ITM/config/lo にある複数の構成ファイルの自動検出を使用してサブノードを作成する UNIX オペレーティング・システムの例です。この例は、イベントを Tivoli Monitoring に送信し、プロセッサー使用率を 25% に制限する構成を示します。

tacmd addSystem -t LO -n sample.node.name:KUX-p LOG_FILE_ADAPTER_CONFIGURATION.KLO_AUTO_INIT_SYSLOG=USE_CONF_FILE_VALUELOG_FILE_ADAPTER_CONFIGURATION.KLO_SEND_EIF_EVENTS=NoLOG_FILE_ADAPTER_CONFIGURATION.KLO_SEND_ITM_EVENTS=YesLOG_FILE_ADAPTER_GLOBAL_SETTINGS.KLO_FILE_DISCOVERY_DIR=/opt/IBM/ITM/config/loLOG_FILE_ADAPTER_GLOBAL_SETTINGS.KLO_PROCESS_MAX_CPU_PCT=25INSTANCE="inst2”


エージェントの開始この手順を使用して、Tivoli Log File Agent を UNIX 上のコマンド行から開始します。

Log File Agent を UNIX 上のコマンド行から開始するには、以下のコマンドを入力します。

itmcmd agent -o instance start lo

ここで、instance は、構成中に指定したラベルを示します。

Log File Agent のインスタンスを UNIX 上の GUI から開始するには、以下のステップを実行します。

1. bin/CandleManage コマンドを IBM Tivoli Monitoring インストール・ディレクトリーから入力して、GUI を開始します。

2. インスタンスを右クリックします。

3. 「start」を選択します。1 つ以上のインスタンスを構成した場合、GUI には、インスタンスのリストを示すパネルが表示されます。プロンプトが出されたら、開始するインスタンスを選択します。

Windows 上で Log File Agent のインスタンスを開始するには、以下のステップを実行します。

1. 「スタート」メニューから、「スタート」->「IBM Tivoli Monitoring」->「Tivoli Monitoring

Services の管理」を指定します。

2. インスタンスを右クリックします。

3. 「start」を選択します。1 つ以上のインスタンスを構成した場合、GUI には、インスタンスのリストを示すパネルが表示されます。プロンプトが出されたら、開始するインスタンスを選択します。

Tivoli Netcool OMNIbus ObjectServer へのイベントの転送イベントを 1 つ以上の Tivoli Netcool/OMNIbus ObjectServer に転送するように Tivoli Log File Agent を構成できます。

手順1. Tivoli Enterprise Console イベントを受信するように、IBM Tivoli Netcool/OMNIbus ObjectServer を構成します。

2. 「IBM Tivoli Netcool/OMNIbus Probe for Tivoli EIF リファレンス・ガイド」の説明に従って Probe for

Tivoli EIF をインストールします。

3. Probe for Tivoli EIF を実行します。

4. 「EIF イベントを OMNIbus に送信」値を Yes に設定して、イベントを Probe for Tivoli EIF リスナー・ポートに転送するように、Tivoli Log File Agent を構成します。

5. オプション: イベントを複数の Netcool® OMNIbus ObjectServer に転送するには、サーバー数を指定するエントリー NumAdditionalServers=n を構成ファイルに追加します。ここで、n は、8 以下の正整数です。

6. .conf ファイル内で ServerLocation および ServerPort 変数を設定して、プライマリー EIF プローブのロケーションを構成します。 ServerLocation には、ホスト名または IP アドレスを指定できます。ServerPort は、EIF プローブが listen しているネットワーク・ポート番号です。例えば、ServerLocation=probehost.mycompany.com および ServerPort=5529 です。

イベントを複数のサーバーに転送するための上記のステップをオプションとして実行した場合は、同じ構成名を使用し、1 で開始されるインデックス番号を後に付加して、追加サーバーを指定できます。以下に例を示します。



BufEvtPath=/tmp/main.cacheServerLocation=1.2.3.4ServerPort=1000NumAdditionalServers=2BufEvtPath1=/tmp/alt1.cacheServerLocation1=2.3.4.5ServerPort1=1000BufEvtPath2=/tmp/alt2.cacheServerLocation2=3.4.5.6ServerPort2=3000

この例の構成では、エージェントは EIF イベントを 3 つの受信側 (デフォルト受信側および 2 つの代替受信側) に同時に送信します。必須のデフォルト受信側が構成されている場合にのみ、代替受信側を使用できます。代替受信側はオプションです。必要な場合には、サーバー・ロケーションのフェイルオーバー値 (ServerLocation1=2.3.4.5,2.3.4.6 など) を指定できます。BufEvtPath、ServerLocation、およびServerPort 変数に限り、代替構成において異なる値を指定できます。その他のすべての値は直接コピーされ、すべての受信側で同じになります。

7. Tivoli Log File Agent を始動します。詳しくは、 19ページの『エージェントの開始』を参照してください。

関連タスク:


ObjectServer の構成Log File Agent のカスタム・フィールドを Tivoli Netcool/OMNIbus ObjectServer のフィールドにマップするように、Tivoli Netcool/OMNIbus ObjectServer を構成します。

始める前に

ObjectServer を開始します。例:

$OMNIHOME/bin/nco_objserv -name NCOMS


このセクションでは、Log File Agent のカスタム・フィールドを Tivoli Netcool/OMNIbus ObjectServer のフィールドにマップするように ObjectServer を構成する方法について説明します。

Log File Agent のカスタム・フィールドを IBM Tivoli Tivoli Netcool/OMNIbus ObjectServer のフィールドにマップするには、いくつかのカスタム・フィールドを ObjectServer にさらに追加する必要があります。

手順v UNIX オペレーティング・システムでは、以下のコマンドを実行します。

$OMNIHOME/bin/nco_sql -user username -password password-server server_name < path_to_file/tec_db_update.sql

例:

$NCHOME/omnibus/bin/nco_sql -user root -password "" -server NCOMS< $NCHOME/omnibus/probes/linux2x86/tec_db_update.sql

v Windows では、以下のコマンドを実行します。

"%OMNIHOME%"¥bin¥redist¥isql.exe -S server_name -U username -P password< "%OMNIHOME%"¥probes¥win32¥tec_db_update.sql


例:

"%OMNIHOME%"¥bin¥redist¥isql.exe -S NCOMS -U root -P ""< "%OMNIHOME%"¥probes¥win32¥tec_db_update.sql

注: 例を読みやすくするため、単一のコマンドを複数の行で示しています。

Tivoli Netcool OMNIbus ObjectServer にカスタム変数を含むイベントを転送する送信されるイベントに含まれるカスタム変数を Tivoli Netcool/OMNIbus ObjectServer に転送するようにTivoli Log File Agent を構成できます。

始める前に

Tivoli Netcool OMNIbus ObjectServer へのイベント転送について詳しくは、 19ページの『Tivoli Netcool

OMNIbus ObjectServer へのイベントの転送』を参照してください。


転送されるイベントに含まれるカスタム値を認識し、Tivoli Netcool OMNIbus ObjectServer に転送するように Log File Agent を構成することができます。これらのカスタム属性を認識するように Tivoli

Netcool/OMNIbus ObjectServer を構成する必要もあります。

手順1. フォーマット・ファイル (.fmt) にカスタム変数を定義します。例えば、以下のフォーマット・ファイル・エントリーの場合、TheFirst および TheSecond はユーザーによって追加されたカスタム変数です。

FORMAT Whitespace_Base%s %sTheFirst $1TheSecond $2END

2. Probe for Tivoli EIF tivoli_eif_tec.rule ファイルを更新します。このファイルは、ディレクトリー・パス $OMNIHOME/probes/arch の配下に格納されています。更新例を以下に示します。

@TECTheFirst = $TheFirst@TECTheSecond = $TheSecond

3. Probe for Tivoli EIF tec_db_update.sql ファイルを更新します。このファイルは、ディレクトリー・パス $OMNIHOME/probes/arch の配下に格納されています。更新例を以下に示します。

alter table alerts.status add column TECTheFirst varchar(64);goalter table alerts.status add column TECTheSecond varchar(64);go

4. Tivoli Netcool/OMNIbus ObjectServer で以下のコマンドを実行します。

v Windows の場合:

"%NCHOME%"¥bin¥redist¥isql.exe -S server_name -U username -P password< "%OMNIHOME%"¥probes¥win32¥tec_db_update.sql

v UNIX オペレーティング・システムの場合:

$OMNIHOME/bin/nco_sql -user username -password password -server server_name< $OMNIHOME/probes/arch/tec_db_update.sql

次のタスク

OMNIbus イベント・リストで、カスタム変数をリストおよび表示するビューを編集します。前述のステップの例の場合、OMNIbus イベント・リストに追加する TheFirst およびTheSecond という 2 つのフィールドがあります。


あるいは、カスタム変数を割り当てるために OMNIbus の「要約」フィールドを更新することもできます。前述のステップの例の場合、最初のカスタム変数を「要約」フィールドに割り当てることができます。これを行うには、プローブ・ルール・ファイル内のデフォルトの「要約」フィールド割り当てを @Summary

= $msg から @Summary = $TheFirst に変更します。

Probe for Tivoli EIFProbe for Tivoli EIF を使用して、イベントを外部イベント・ソースから Tivoli Netcool/OMNIbus

ObjectServer に転送できます。

詳しくは、「Netcool/OMNIbus Probe for Tivoli EIF リファレンス・ガイド」を参照してください。

共通プロパティーおよびルール・フォーマットについては、「IBM Tivoli Netcool/OMNIbus プローブとゲートウェイ・ガイド」を参照してください。

Probe for Tivoli EIF プロパティープロパティーを使用して、Probe for Tivoli EIF が Monitoring Agent for Log Files と対話する方法を指定します。

注: Monitoring Agent for Log Files によって生成される予期されるイベント・アクティビティーと整合性を持つように、Probe for Tivoli EIF を構成します。

これらおよびその他のプロパティーについて詳しくは、以下の場所にある「Netcool/OMNIbus Probe for

Tivoli EIF リファレンス・ガイド」を参照してください。

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcool_OMNIbus.doc/probes/

tivoli_eif_v11/tivoli_eif_v11/wip/reference/tveifv11_intro.html

UNIX 上での Probe for Tivoli EIF の実行この手順を使用して、UNIX システム上で Probe for Tivoli EIF を開始および停止します。

手順1. プローブを開始するには、以下のコマンドを入力します。$OMNIHOME/probes/nco_p_tivoli_eif

2. プローブを停止するには、以下のステップを実行します。

a. バックグラウンド・プロセスとして開始した場合は、プロセスの位置を指定し、kill コマンドを使用してプロセスを停止します。

b. プローブをコンソール・ウィンドウまたは端末ウィンドウで開始した場合は、コンソール・ウィンドウまたは端末ウィンドウで Ctrl+C を押します。

Windows 上での Probe for Tivoli EIF の実行この手順を使用して、Windows システム上で Probe for Tivoli EIF を開始および停止します。

手順

次のいずれかの方法で、プローブを開始および停止できます。

v Windows コマンド・プロンプトを使用する

1. プローブを開始するには、Windows のコマンド・プロンプトを開き、ディレクトリー・パス"%OMNIHOME%"¥probes¥win32 で以下のコマンドを入力します。

nco_p_tivoli_eif.bat



http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcool_OMNIbus.doc_7.3.1/omn_pdf_prgw_master.pdf

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcool_OMNIbus.doc_7.3.1/omn_pdf_prgw_master.pdf



2. プローブを停止するには、プローブを開始した Windows コマンド・プロンプト内で Ctrl-C またはCtrl-Break を押します。

v プローブをインストールし、Windows サービスとして開始する

1. コマンド "%OMNIHOME%"¥probes¥nco_p_tivoli_eif /INSTALL を入力してサービスをインストールします。

2. Windows メニュー・オプションの「管理ツール」 > 「サービス」に進み、eif プロセスを開始または停止します。

サブノードサブノードを使用して、単一のエージェント・インスタンスから複数のアプリケーションをモニターするモニター・プロファイルを実装します。

サブノードを使用して、単一のエージェント・インスタンスから以下のタスクを実行できます。

v システム上で実行されているアプリケーションの各インスタンスをモニターします。

v さまざまなパターンをさまざまなログに適用して、単一のエージェント・インスタンスから複数の異なるアプリケーションをモニターします。このタイプのモニターの場合、1 つのアプリケーションのログでは、別のアプリケーションからのパターンは検索されません。このタイプのモニターにより、効率が向上します。

v 単一のエージェント・インスタンスから、さまざまな重複検出設定 (Tivoli Monitoring のみ) を必要とするログをモニターします。

v 複数のエージェント・インスタンスを作成することなく、論理的に分離されたパターン・グループを編成します。パターンは、さまざまな管理者によって、さまざまな書き込み権限が設定された複数のファイル内で保守されます。

サブノードおよびモニター・プロファイルの作成

モニターしているシステム上で、複数のアプリケーションをモニターすることがあります。単一のエージェント・インスタンスからこれらのアプリケーションをすべてモニターするには、各アプリケーションにプロファイルを関連付けます。プロファイルは、構成とフォーマット・ファイルの単一のペアを表し、サブノードを使用して実装されます。このようなプロファイルの分離により、1 つのアプリケーションのログでは、別のアプリケーションからのパターンは検索されないため、効率が向上します。

サブノードを作成するには、各アプリケーションの構成 (.conf ファイル) とフォーマット (.fmt ファイル) のペアを作成し、それらを特定のディレクトリー・ロケーション内に格納します。エージェントに対してディレクトリー・ロケーションを指定するには、構成パネル内で「構成ファイル自動検出ディレクトリー」値を使用します。構成パネル値の設定について詳しくは、 9ページの『構成パネルからの構成』を参照してください。

プロファイルを編成するために、構成とフォーマット・ファイルのペアを、ディレクトリー・ツリー構造内の「構成ファイル自動検出ディレクトリー」の下に保管できます。個々のペアの構成とフォーマット・ファイルは、同じディレクトリー内に保管する必要があります。構成とフォーマット・ファイルの各ペアは、ペア単位で異なるディレクトリー内に保管できます。Log File Agent は、「構成ファイル自動検出ディレクトリー」のロケーションを定期的に検査し、ディレクトリー構造内で新規構成ファイルの再帰的検索を実行します。エージェントは、同じディレクトリー内で構成ファイルと同じベース名を持つフォーマット・ファイルが見つかることを前提としています。エージェントは、構成とフォーマット・ファイルのペアを検出するたびに、構成ファイルのベース名をプロファイル (サブノード) 名として使用して、サブノードを作成します。サブノードの数は、構成とフォーマット・ファイルのペアの数によって決定されます。サブノードが作成されると、Log File Agent は各構成のモニターを開始します。以降の介入は不要です。


エージェントをインストールするときにすべてのサブノードにグローバルに適用される構成設定を設定します。これらのグローバル構成設定を設定するには、構成パネルまたはコマンド行を使用します。これらのインストール時グローバル構成設定のうちの 2 つについては、構成ファイル設定を使用するようにオーバーライドすることができます。構成ファイル設定によってオーバーライドできるグローバル設定は、以下のとおりです。

v UNIX syslog の自動的初期化: 個々のサブノードに対して適用される構成ファイル値 AutoInitSyslog を使用するように、この値をインストール時に設定できます。この構成ファイル値を使用するには、「UNIX

syslog の自動的初期化」を USE_CONF_FILE_VALUE に設定します。この値はデフォルトです。

v プロセスの優先順位クラス: 構成ファイル設定 ProcessPriorityClass を使用するように、この値をインストール時に設定できます。この構成ファイル値を使用するには、「プロセスの優先順位クラス」をUSE_CONF_FILE_VALUE に設定します。この構成ファイル値は、構成ファイルごとに異なる値を持つことができないため、個々のサブノードに対しては適用されません。異なる値を持つことができないという制限は、既存の構成ファイルを使用する旧バージョンとの互換性をサポートするために存在します。このように制限する理由は、サブノードを使用したモニター・プロファイルが導入される前は、この値が構成ファイル内に設定されていたためです。

エージェント・インスタンスの代わりにサブノードを使用して多数のアプリケーション・インスタンスのモニターを定義すると、Tivoli Monitoring 環境のスケールとパフォーマンスを大幅に拡張できます。

構成とフォーマット・ファイルは、セントラル・ロケーション内でホストできます。詳しくは、 14ページの『一元化された構成』を参照してください。

例

WebSphere® サーバーのグループについて、同じまたは似たようなタイプのログ・ファイルをモニターするとします。いくつかのサーバーは Linux オペレーティング・システムを実行し、その他のサーバーは AIX

オペレーティング・システムを実行します。各サーバーには、DB2® または Oracle データベースがあります。各オペレーティング・システムおよびデータベースには、モニターされるログ・ファイルと、これらのログ・ファイル内で検索されるパターンから成るセットがあります。

この例の目的は、以下のログ・ファイルを使用する 3 つの WebSphere サーバーをモニターすることです。

WS_server_1:AIX_logfileDB2_logfile

WS_server_2:Linux_logfileOracle_logfile

WS_server_3:Linux_logfileDB2_logfile

1 つのエージェント・インスタンスがすべてのログ・ファイルをモニターするために必要なサブノードを作成するには、構成とフォーマット・ファイルのペアを 4 つ作成します。

translog_aix.conftranslog_aix.fmt

translog_db2.conftranslog_db2.fmt

translog_linux.conf


translog_linux.fmt

translog_oracle.conftranslog_oracle.fmt

ファイルのペアが完成したら、それらを「構成ファイル自動検出ディレクトリー」で設定されたディレクトリー内に格納します。Log File Agent は、次にディレクトリーを検査するときに、ファイルの各ペアに対してサブノードを作成し、各構成のモニターを開始します。

この例における構成ファイルは、表 1 に示すサーバーにデプロイされます。

表 1. サーバーへの構成ファイルの割り振り

サーバー構成ファイル

WS_server_1 translog_aix.conf

translog_aix.fmt

translog_db2.conf

translog_db2.fmt

WS_server_2translog_linux.conf

translog_linux.fmt

translog_oracle.conf

translog_oracle.fmt

WS_server_3translog_linux.conf

translog_linux.fmt

translog_db2.conf

translog_db2.fmt

この構成にすると、例えば WS_server_1 は、このサーバーで決して発生しない Linux または Oracle メッセージを検索してリソースを浪費することはありません。

関連タスク:


関連資料:




第 3 章構成ファイル

Tivoli Log File Agent は、構成オプションとフィルターを含む構成ファイルを使用します。この構成ファイルを作成して、それを使用するためのエージェント・インスタンスを構成してください。

構成ファイルは、エージェントの開始時にエージェントによって読み取られ、その後 60 秒ごとに、そのタイム・スタンプの変更がモニターされます。ファイルのタイム・スタンプが変更された場合、エージェントは、その構成を動的に再初期化します。エージェントの再始動は不要です。詳しくは、 13ページの『エージェントの構成ファイルとフォーマット・ファイルの変更』を参照してください。

Log File Agent の .conf ファイルは、以下のオプションを受け入れます。

DupDetectionKeyAttributesIBM Tivoli Monitoring 属性のコンマ区切りリスト。これらの属性は、どのイベントが重複イベントで、どのイベントが重複イベントではないかを判別するために使用されます。LogFile イベント属性について詳しくは、 77ページの『LogFile イベント属性グループ』を参照してください。指定されたすべての属性が 2 つのイベントで同じである場合、それらの 2 つのイベントは重複イベントであると見なされます。このオプションは IBM Tivoli Monitoring イベントのみに適用されます。詳しくは、 51ページの『第 5 章イベント・フィルタリングおよび要約』を参照してください。

注:

1. 属性名は大/小文字が区別されるため、示すとおりの名前を入力する必要があります。

2. 属性のリストを指定しなかった場合、値はデフォルトで Class および Logname になります。

ENFORCE_STRICT_TEC_COMPATIBILITYこのパラメーターを Y に設定すると、Log File Agent は空白文字を Tivoli Enterprise Console ログ・ファイル・アダプターと同じ方法で処理します。つまり、ログ・データ内のすべての空白文字は、空白として扱われます。たとえば、ログ・メッセージから情報を抽出するために "%s %s" などのフォーマットを使用すると、Log File Agent は、リテラル・スペースだけでなく、それ以外のタブや復帰として存在している空白文字も突き合わせます。

このパラメーターを設定しない場合、Tivoli Enterprise Console が Log File Agent スタイル書式制御ストリングを突き合わせるときのデフォルト動作では、フォーマットを左から右に処理しながら、できるだけ多くの入力テキストを突き合わせます。

例えば、書式制御ストリングが %s:%s で、入力ストリングが one:two:three であるとします。Log File Agent はデフォルトでは、one.two を最初のパラメーター (最初の %s に対応する) に割り当て、three を 2 番目のパラメーターに割り当てます。Tivoli Enterprise Console ログ・ファイル・アダプターの動作はその逆です。ENFORCE_STRICT_TEC_COMPATIBILITY パラメーターを Y に設定すると、Log File Agent は、書式の突き合わせにおいて Tivoli Enterprise Console ログ・ファイル・アダプターと同じように動作します。

注:

1. このパラメーターは、Tivoli Enterprise Console のログ・ファイル・アダプター構文を使用するフォーマット指定ステートメントにのみ適用されます。正規表現構文を使用するフォーマット指定ステートメントには適用されません。


2. このパラメーターを設定すると、パフォーマンスに影響を与えます。マッチングの動作およびパフォーマンスをより効果的に制御するためには、このパラメーターの設定を回避し、代わりに正規表現を使用してください。

EventSummaryIntervalエージェントが抑止対象の重複イベントを検索する秒数を指定します。正の整数に設定してください。このオプションは IBM Tivoli Monitoring イベントのみに適用されます。詳しくは、 51ページの『第 5 章イベント・フィルタリングおよび要約』を参照してください。

EventFloodThreshold重複イベントが検出されたときに送信するイベントを指定します。 send_none、send_all、send_first、または正の整数に設定してください。このオプションは IBM Tivoli Monitoring イベントのみに適用されます。詳しくは、 51ページの『第 5 章イベント・フィルタリングおよび要約』を参照してください。

EventMaxSize生成されるイベントの最大サイズをバイト単位で指定します。このパラメーターを指定した場合、パラメーターは 2 カ所で使用されます。

1. このパラメーターは、イベントの処理に使用されるバッファーのサイズを設定するために、エージェントが使用することができます。このパラメーターを指定しない場合、デフォルトのバッファー・サイズとして 16384 バイトが使用されます。バッファーの設定値が小さすぎる場合、イベントは切り捨てられ、場合によっては廃棄されます。

2. このパラメーターは、イベントを OMNIbus EIF プローブなどの EIF 受信側に送信する目的で使用されるバッファーのサイズを設定するために、EIF 送信側が使用することができます。このパラメーターを指定しない場合、デフォルトのバッファー・サイズとして 4096 バイトが使用されます。バッファーの設定値が小さすぎる場合、イベントは廃棄されます。

FileComparisonMode複数のログ・ファイルがワイルドカード・パターンに一致した場合にモニターするログ・ファイルを指定します。使用可能な値は以下のとおりです。

CompareByAllMatchesこの値はデフォルトの動作です。LogSources で指定されたワイルドカード・パターンに一致するすべてのファイルがモニターされます。

CompareByLastUpdateLogSources で指定されたワイルドカード・パターンに一致するファイルのうち、最終更新のタイム・スタンプが最も新しいファイルがモニターされます。

CompareBySizeファイル名パターン基準に一致する 2 つ以上のファイルのうち、より大きなファイルがモニター対象として選択されます。同時に更新されてファイル・サイズが増大する一致ファイルが複数ある場合には、CompareBySize を使用しないでください。最大のファイルが頻繁に変更される場合、モニタリングは常に、新規に選択されたファイルの先頭から再開される可能性があります。複数の一致ファイルがあり、そのうち 1 つのみがアクティブであり特定の時点に更新される場合には、代わりに CompareBySize を使用してください。

CompareByCreationTimeLogSources で指定されたワイルドカード・パターンに一致するファイルのうち、作成のタイム・スタンプが最も新しいファイルがモニターされます。


ヒント: CompareByLastUpdate、CompareBySize、および CompareByCreationTime の各値は、ローリング・ログ・ファイルに使用できます。CompareByLastUpdate は通常、これらのファイルに使用されます。

制約事項: CompareByCreationTime 値については以下のとおりです。

v UNIX および Linux オペレーティング・システムではファイルの実際の作成時刻は保管されないため、Windows オペレーティング・システムにのみ適用されます。

v セキュア・シェル (SSH) ファイル転送プロトコルを使用してモニターするリモート・ファイルではサポートされません。

FQDomainエージェントがドメイン名を設定するかどうか、およびその設定方法を指定します。

v yes に設定すると、エージェントがシステム・ドメイン名を決定します。

v no に設定すると、エージェントはドメイン名を設定しません。 fqhostname 属性には空白ストリングが割り当てられます。

v yes 値も no 値も含まれないように設定すると、ドメイン名が値として受け入れられ、ホスト名の後に追加されます。

詳しくは、 39ページの『第 4 章フォーマット・ファイル』を参照してください。

IncludeEIFEventAttrこのエージェントには、EIFEvent という大きな属性が含まれています。この属性は、Event

Integration Facility 機能が使用可能になっている場合に、この機能によって送信されるイベントを表しています。 EIFEvent 属性に含まれている情報は、他の属性にも含まれていることがあります。サイズの大きさが原因で問題が発生することがあるため、この属性はバージョン 6.2.3 では使用不可になり、Tivoli Enterprise Portal で表示しても値は示されません。この値を y に設定すると、Tivoli Monitoring で EIFEvent 属性が再び使用可能になります。

注: この属性を使用すると、大きなイベントがある場合にシチュエーションが失敗することがあります。このコンテキストにおける大きなイベントとは、すべての属性およびその名前の値をすべて含めるために必要なバイト数を合計した結果、3600 バイトを超えるストリングになるイベントです。

LognameIsBasenamey に設定すると、IBM Tivoli Monitoring の Logname 属性の値が、イベント検出時のログ・ファイルのベース名になります。このオプションは IBM Tivoli Monitoring イベントのみに適用されます。パスは削除されます。たとえば、/data/logs/mylog.log は mylog.log になります。この値をn に設定すると、絶対パスが得られます。ただし、属性の長さは 64 文字までに制限されているため、n に設定すると、それより長い名前の部分は切り捨てられます。したがって、デフォルト値はy になっています。長い属性で絶対パス名を表示するには、.fmt ファイル内のフォーマットのマッピング・セクションで、例えば filename FILENAME CustomSlot1 のように指定することができます。このマッピングにより、filename という名前のスロットに、イベントが検出されたファイルの絶対パスが入り、そのスロットが 256 文字の長さの CustomSlot1 にマップされます。

LogSourcesメッセージをポーリングするテキスト・ログ・ファイルを指定します。各ファイルへの完全パスを指定する必要があり、ファイル名をコンマで区切る必要があります。それぞれのファイル名内では、アスタリスク (*) を使用して任意の一連の文字を表したり、疑問符 (?) を使用して任意の 1

文字を表したりすることもできます。例えば、mylog* と指定すると、mylog で始まる名前を持つすべてのログ・ファイルがポーリングされ、mylog??? と指定すると、mylog とその後に続く厳密

第 3 章構成ファイル 29

に 3 文字で構成される名前を持つすべてのログ・ファイルがポーリングされます。これらのワイルドカード文字は、ファイル名の中でのみサポートされます。パスは明示的に指定する必要があります。

パスで正規表現またはパターン・マッチングを使用する場合は、RegexLogSources の説明を参照してください。

ログ・ファイル・ソースは、エージェントの開始時点で存在している必要はありません。ログ・ファイルは作成されたときにポーリングされます。

NewFilePollIntervalエージェントがモニター対象の新規ファイルを検査する頻度を秒単位で指定します。例えば、LogSources または RegexLogSources 構成ファイルの設定で指定された名前のファイルがまだ存在していない場合、エージェントは開始時に、この時間間隔が経過した後でそのファイルの存在の有無を再検査します。

NumEventsToCatchUpログ内の、エージェントの開始点になるイベントを指定します。このオプションを使用すると、モニター対象のソースが新規である場合またはエージェントが長時間停止していた場合の柔軟性がある程度高くなります。有効な値は以下のとおりです。

注: テキスト・ファイルの場合、値 0 および -1 が適用されます。Windows イベント・ログの場合、値 0、-1、および n が適用されます。

0 ログ内の次のイベントから開始します。この値はデフォルトです。

-1 -1 に設定すると、エージェントはモニター対象のファイルにおけるエージェントの位置を保存します。位置が保存されるため、エージェントが停止して後で再開したときに、停止中にログに書き込まれたイベントを処理することができます。それ以外の場合、エージェントは停止中に到着したイベントを無視し、ファイルの末尾から再開します。この設定は、パイプ、または UNIX および Linux での syslog モニタリングには適用されません。

n 正の整数に設定してください。ログ内の最新イベントから n 番目のイベントから開始します。つまり、ログ内の最新イベントより前の n 件のイベントが開始されます。 n が選択可能なイベントの数より大きい場合、選択可能なすべてのイベントが処理されます。

注: 値 n は、Windows イベント・ログの場合にのみ使用することができます。値 n は、UseNewEventLogAPI が y に設定されている場合には無視されます。

PollIntervalLogSources オプションでリストされた各ログ・ファイルをポーリングして新規メッセージの有無を調べる頻度を、秒単位で指定します。デフォルト値は 5 秒です。

前のリリースから Windows イベント・ログ・アダプターをアップグレードして、Windows レジストリーで PollingInterval の値を設定している場合、Windows レジストリーで使用した値と同じ値をエージェント構成ファイルの PollInterval オプションに指定する必要があります。このルールは、レジストリーに値が保管されている Tivoli Enterprise Console Log File Agent を置き換える場合にのみ適用されます。

ProcessPriorityClassエージェントの処理優先順位を指定します。エージェントが大ボリュームのイベントを処理していて、使用するプロセッサー・リソースが多すぎる場合、この値を調整してシステム・パフォーマンスを向上させることができます。指定できる値は以下のとおりです。

v A - 非常に低い優先順位

v B - 低い優先順位


v C - 標準的な優先順位

v D - 標準より高い優先順位

v E - 高い優先順位

v F - 非常に高い優先順位

v USE_CONF_FILE_VALUE - 構成ファイルに指定された値を使用します (この値がデフォルトです)

注: この設定の値はグローバルです。サブノードを使用してモニタリング・プロファイルを実装している場合、この値はすべてのモニタリング・プロファイルに適用されます。その値は、同じエージェント用の異なる構成ファイルで異なっていてはなりません。

RegexLogSourcesメッセージをポーリングするテキスト・ログ・ファイルを指定します。このオプションは、ファイル名のベース名部分およびファイル名の少なくとも 1 つのサブディレクトリーで正規表現のメタ文字が使用できる点で、LogSources オプションとは異なっています。この違いにより、複数のディレクトリーにあるモニター対象の複数ファイルを、LogSources オプションよりはるかに柔軟に記述することができます。

例えば、LogSources ステートメントで /var/log/mylog* を指定することは、RegexLogSources ステートメントで、ドット (.) メタ文字を使用し、その後にアスタリスク (*) メタ文字を使用して、/var/log/mylog.* にするのと同じ意味を持ちます。このタイプの修飾子を使用すると、/var/log ディレクトリー内の、ベース名が mylog で始まってその後にゼロ個以上の文字が続く、すべてのログ・ファイルがポーリングされます。 /var/log/mylog.+ という修飾子を使用すると、/var/log ディレクトリー内の、名前が mylog で始まってその後に 1 つ以上の文字が続く、すべてのログ・ファイルがポーリングされます。

LogSources と同様に、各ファイルへの完全パスを指定する必要があり、ファイル名をコンマで区切る必要があります。ただし、コンマも正規表現内の有効な文字です。正規表現の一部として使用されるコンマと、ファイル名を区切るのに使用されるコンマを区別するため、正規表現の一部として使用されるコンマは、円記号 (¥) 文字を付けてエスケープする必要があります。

例えば、正規表現 /logs/.*¥.log および /other/logs/[a-z]{0,3}¥.log のいずれかに一致するログを検索する場合は、2 番目の正規表現の {0,3} 節のコンマを以下のようにエスケープして、エージェントがこのコンマを新しい正規表現の始まりと間違えることがないようにします。RegexLogSources=/logs/.*¥.log,/other/logs/[a-z]{0¥,3}¥.log

パス名でメタ文字を使用した場合、そのメタ文字はパスの 1 つのサブディレクトリーでのみ使用できます。例えば、/var/log/[0-9¥.]*/mylog.* と指定すると、1 つのサブディレクトリーでメタ文字を使用できます。[0-9¥.]* を指定すると、/var/log 内の、番号とドット (.) のみで構成されるサブディレクトリーが突き合わされます。 mylog.* を指定すると、これらの /var/log サブディレクトリー内の、mylog で始まり、ゼロ個以上の文字が続くファイル名が突き合わされます。

一部のオペレーティング・システムでは円記号 (¥) がディレクトリー分離文字として使用されるため、正規表現のエスケープ・メタ文字と混同される可能性があります。この混同を避けるため、ディレクトリーを表すには常にスラッシュを使用する必要があります。例えば、Windows ファイルを C:¥temp¥mylog.* と指定した場合、¥t がタブ文字の短縮表記と解釈される可能性があります。したがって、すべてのオペレーティング・システムで常に、ディレクトリー分離文字としてスラッシュ (/) を使用してください。 C:/temp/mylog.* という例は、C:/temp ディレクトリー内の、mylog で始まるすべてのファイルを表します。

複数のサブディレクトリーにメタ文字が含まれている場合、トレース・メッセージの発行も行われます。例えば、c:/[0-9¥.]*/temp.files/mylog.* には、メタ文字が使用された 2 つのサブディレクトリーがあります。[0-9¥.]* はメタ文字を使用した最初のサブディレクトリーであり、


temp.files はドット (.)・メタ文字を使用した 2 番目のサブディレクトリーです。この場合エージェントは、メタ文字を含む最初のサブディレクトリーを使用し、メタ文字を含む後続のディレクトリーは無視するものと見なします。正規表現の問題のトラブルシューティングについて詳しくは、 132ページの『エージェントのトラブルシューティング』を参照してください。

SubnodeNameモニタリング・プロファイル・サブノードに割り当てられたデフォルト名をオーバーライドするために使用できるストリング値。デフォルトでは、モニタリング・プロファイルに割り当てられたサブノード名は、そのプロファイルに使用される構成ファイルのベース名に対応します。この設定を使用することにより、別のサブノード名を割り当てることができます。

SubnodeDescriptionLFAProfiles ワークスペースの Subnode Description 属性に値を割り当てるために使用できるストリング値。

UnmatchLogエージェントによってイベント・クラスに解析できない廃棄済みイベントを記録するファイルを指定します。その後、廃棄済みイベントを分析して、エージェントのフォーマット・ファイルを修正する必要があるかどうかを判別できます。 *DISCARD* を使用したパターンに一致するイベントは、パターンに一致したため、不一致ログには表示されません。

このオプションは一般に、フォーマット・ファイル内のフィルターを検証するために、テスト環境で使用されます。このオプションを長時間にわたってオンのままにすると、ファイル・システムがいっぱいになってしまいます。

SSH を使用するリモート・ログ・ファイル・モニターのオプション

リストである SshHostList を除く、すべてのオプションで指定できる値はそれぞれ 1 つのみです。この値は SshHostList に指定されるすべてのリモート・ホストに適用されます。

サポートされるのはテキスト・ログ・ファイルのみです。AIX エラー・レポート、syslog、およびWindows イベント・ログはサポートされません。

ヒント: syslog を設定して、syslog の出力をテキストのログ・ファイルに書き込み、Log File Agent を使用して、そのテキスト・ファイルをリモートでモニターすることができます。

SshAuthTypePASSWORD または PUBLICKEY のいずれかに設定する必要があります。PASSWORD に設定した場合、SshPassword の値は、すべてのリモート・システムでの SSH 認証で使用されるパスワードとして処理されます。 PUBLICKEY に設定した場合、SshPassword の値は、秘密鍵ファイルへのアクセスを制御するパスフレーズとして処理されます。PUBLICKEY に設定する場合は、SshPrivKeyfile と SshPubKeyfile も指定する必要があります。

SshHostListモニター対象のリモート・ホストのコンマ区切りリスト。LogSources または RegexLogSources ステートメントに指定されているすべてのログ・ファイルは、ここにリストされる各ホストでモニターされます。指定されているホスト名のいずれかが localhost である場合、エージェントはローカル・システム上の同じファイル・セットを直接モニターします。localhost を指定すると、ローカル・システム上のファイルにアクセスする際に SSH は使用されず、ログ・ファイルが直接読み取られます。

SshPasswordSshAuthType の値が PASSWORD である場合、この値は、SshUserid に指定されているユーザーのアカウント・パスワードになります。アカウント・パスワードは平文で指定することができます。


あるいは、IBM Tivoli Monitoring itmpwdsnmp コマンドで暗号化されたパスワードを指定することもできます。itmpwdsnmp コマンドによるパスワードの暗号化方法について詳しくは、 17ページの『パスワードまたはパスフレーズの暗号化』を参照してください。

SshAuthType の値が PUBLICKEY である場合、この値は、SshPrivKeyfile パラメーターで指定されている秘密鍵の暗号化を解除するパスフレーズとなります。パスフレーズは平文で指定することができます。あるいは、IBM Tivoli Monitoring itmpwdsnmp コマンドで暗号化されたパスフレーズを指定することもできます。itmpwdsnmp コマンドによるパスワードの暗号化方法について詳しくは、 17ページの『パスワードまたはパスフレーズの暗号化』を参照してください。

注: SshAuthType の値が PUBLICKEY であり、パスフレーズを必要としないように SSH を構成した場合は、SshPassword を NULL に設定する必要があります。 SshPassword を NULL に設定する場合、構成ファイル内の項目は以下のようになります。

SshPassword=

SshPortSSH 用の接続先 TCP ポート。これを設定しない場合、デフォルトの 22 に設定されます。

SshPrivKeyfileSshAuthType が PUBLICKEY に設定されている場合、この値は、SshUserid に指定されているユーザーの秘密鍵を含むファイルへの絶対パスでなければなりません。また、SshPubKeyfile も設定する必要があります。SshAuthType が PUBLICKEY に設定されていない場合、この値は必要ないため、無視されます。

SshPubKeyfileSshAuthType が PUBLICKEY に設定されている場合、この値は、SshUserid に指定されているユーザーの公開鍵を含むファイルへの絶対パスでなければなりません。また、SshPrivKeyfile も設定する必要があります。SshAuthType が PUBLICKEY に設定されていない場合、この値は必要ないため、無視されます。

SshUseridエージェントが SSH 認証で使用するリモート・システムでのユーザー名。

以下のオプションは UNIX および Linux でのみサポートされます。AutoInitSyslog

このオプションを Yes に設定すると、エージェントは、イベントの標準的なセットをエージェントのモニター対象のパイプに書き込むように、syslog 機能を自動的に構成します。この設定を有効にすると、ログ・ファイルの保守およびロールオーバーを行わずに syslog イベントをモニターすることができます。構成ファイルでこの設定を行わない場合、No に設定した場合と同じになります。

制約事項: このオプションは、リモート・ログ・ファイル・モニターではサポートされていません。

以下のオプションは Windows でのみサポートされます。NTEventLogMaxReadBytes

Windows システムでイベント・ログ・データを読み取るために古い NT イベント・ログ・インターフェースを使用している場合 (UseNewEventLogAPI が y に設定されていない場合)、エージェントは、イベント・ログで新規データの有無を検査するたびにこのバイト数まで読み取ります。この値を 0 に設定すると、エージェントは、前のリリースの場合と同様にすべての新規データを読み取ろうとします。このアクティビティーによって、多くのイベントが発生するシステムではエージ


ェントがかなりの時間占有されることがあります。デフォルト値は 655360 です。この値を設定した場合、エージェントは、指定どおりの正確な値で停止するのではなく、この値に最も近い、内部バッファー・サイズの倍数で停止します。

PreFilterエージェントで処理を行う前に Windows イベント・ログ内のイベントをフィルタリングする方法を指定します。PreFilter ステートメントは、イベント・ログからエージェントに送信するイベントを決定するときに PreFilterMode によって使用されます。 PreFilter ステートメント内のそれぞれの attribute=value 指定がイベント・ログ内のイベントと一致したときに、イベントはPreFilter ステートメントと一致したと見なされます。 PreFilter ステートメントには少なくともログ指定が含まれている必要があり、オプションで 3 つまでの追加指定 (イベント ID、イベント・タイプ、およびイベント・ソース) を含めることができます。ステートメント内での属性の順序は任意です。

PreFilter ステートメントの基本フォーマットは次のとおりです。

PreFilter:Log=log_name;EventId=value; EventType=value;Source=value;

属性ごとに、コンマで区切って複数の値を指定することができます。

各 PreFilter ステートメントは 1 行で指定する必要があります。

PreFilter は必須ではありません。 PreFilter が指定されていなくて、 PreFilterMode=OUT になっている場合、すべての Windows ログ・イベントがエージェントに送信されます。

PreFilterModeこのオプションは Windows イベント・ログにのみ適用されます。PreFilter ステートメントに一致するWindows ログ・イベントが送信されるのか (PreFilterMode=IN) または無視されるのか(PreFilterMode=OUT) を指定します。有効な値は IN、in、OUT、または out です。デフォルト値はOUT です。

PreFilterMode はオプションです。PreFilterMode が指定されていない場合、どの PreFilter ステートメントにも一致しないイベントのみがエージェントに送信されます。

注: PreFilterMode=IN を設定した場合、PreFilter ステートメントも定義する必要があります。

SpaceReplacementWindows イベント・ログ (Windows Server 2008 のみ) ではデフォルトで TRUE に設定します。ただし、前のバージョンのイベント・ログではそのように設定しないでください。SpaceReplacement

が TRUE になっている場合、イベント・ログ・メッセージのセキュリティー ID、サブソース、レベル、およびキーワード・フィールドに含まれるスペースは、下線 (_) で置き換えられます。SpaceReplacement が FALSE になっている場合、イベント・ログ・メッセージのセキュリティーID、サブソース、レベル、およびキーワード・フィールド内のスペースは変わりません。このオプションについて詳しくは、 157ページの『付録 B. Windows 2008 イベント・ログ』を参照してください。

UseNewEventLogAPIWindows システムで y に設定すると、イベント・ログに新規の Windows イベント・ログ・インターフェースが使用されます。このオプションは Windows 2008 以降でのみサポートされます。Windows 2008 およびそこで実行されるアプリケーションで初めて使用されるようになった新規イベント・ログの多くにアクセスするには、このオプションが必要です。このオプションは、前のバージョンの Windows、および UNIX と Linux では無視されます。このオプションについて詳しくは、 157ページの『付録 B. Windows 2008 イベント・ログ』を参照してください。

WINEVENTLOGSどの Windows イベント・ログをモニターするのかを制御します。


WINEVENTLOGS ステートメントは、スペースを含まないコンマ区切りリストです。詳しくは、157ページの『付録 B. Windows 2008 イベント・ログ』を参照してください。

注: Windows イベント内の復帰、タブ、または改行は、スペースで置き換えられます。

以下のオプションは AIX でのみサポートされます。AIXErrptCmd

エージェントが実行する errpt (エラー・レポート) コマンド・ストリングをここに指定することができます。コマンド出力は、モニター対象のログ・データのストリームにフィードされます。

例えば、次のコマンドを使用すると、エージェントは始動時に mmddhhmmyy ストリングを検索し、このストリングを実際の日時に置き換えます。ストリングの 1 番目のオカレンスのみが置換されます。

AIXErrptCmd=errpt -c -smmddhhmmyy

独自の errpt コマンドを指定できますが、Log File Agent は Monitoring Agent for UNIX Logs の場合と同じ制約をこのコマンドに適用します。特に、コマンドを連続的に実行するために -c (並行モード) オプションを使用する必要があります。-t オプション、または詳細出力を生成する-a、-A、または -g オプションを使用することはできません。データ・ストリームは errpt コマンドからの標準出力であるため、突き合わせるためには .fmt ファイル内で正規表現を作成する必要があります。例えば、データ出力は以下のようになることがあります。

IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTIONF7FA22C9 0723182911 I O SYSJ2 UNABLE TO ALLOCATE SPACE IN FILE SYSTEM2B4F5CAB 1006152710 U U ffdc UNDETERMINED ERROR2B4F5CAB 1006152610 U U ffdc UNDETERMINED ERROR

ヘッダー以外のデータ行を選出するサンプル・フォーマットを以下に示します。

REGEX GenericErrpt^([A-F0-9]{8}) +([0-9]{10}) ([A-Z]) ([A-Z]) (¥S+) +(.*)$Identifier $1 CustomSlot1Timestamp $2 CustomSlot2T $3 CustomSlot3C $4 CustomSlot4Resource $5 CustomSlot5msg $6END

「Agent Builder ユーザーズ・ガイド」の『AIX バイナリー・ログのモニター』を参照してください。

以下のオプションは、イベントが EIF に転送される場合にのみ適用されます。BufferEvents

イベント・バッファリングを使用可能にする方法を指定します。指定できる値は以下のとおりです。

v YES - BufEvtPath オプションで指定されたファイルにイベントを保管します (この値がデフォルトです)。

v MEMORY_ONLY - イベントをメモリー内のバッファーに入れます。

v NO - イベントを保管したりまたはバッファーに入れたりしません。

BufEvtPathエージェント・キャッシュ・ファイルの絶対パス名を指定します。このパスを指定しなかった場合、以下のパスがデフォルトとして使用されます。

v UNIX システム: /etc/Tivoli/tec/cache


http://pic.dhe.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.3fp1/agentbuilder6231_user.htm

v Windows システム: ¥etc¥Tivoli¥tec¥cache

注: イベントが複数のサーバーに転送される場合、転送チャネルごとに BufEvtPath 値を指定する必要があります。追加項目ごとに索引番号が BufEvtPath 名に付加されます。例えば、最初の追加サーバーに転送するエージェント・キャッシュ・ファイルのパス名を指定するには、BufEvtPath1

を使用します。それぞれの BufEvtPath で設定する値は固有でなければなりません。

BufEvtMaxSizeエージェント・キャッシュ・ファイルの最大サイズを KB 単位で指定します。デフォルト値は 64

です。BufferEvents オプションが Yes に設定されている場合、キャッシュ・ファイルはイベントをディスクに保管します。このファイルの最小サイズは 8 KB です。このレベルより低く指定されたファイル・サイズは無視され、8 KB が使用されます。ファイルの最大サイズに対する上限値はありません。

注: キャッシュ・ファイルが存在する場合、オプション変更を有効にするには、そのファイルを削除する必要があります。

NO_UTF8_CONVERSIONTivoli Event Integration Facility がイベント・データを UTF-8 でエンコードするかどうかを指定します。このオプションが YES に設定されている場合、Tivoli Event Integration Facility はイベント・データを UTF-8 でエンコードしません。このデータは Tivoli Event Integration Facility に渡されたときに、既に UTF-8 でエンコードされていると想定されます。ただし、データが UTF-8

でエンコードされていることを示すためのフラグに接頭部が追加されます (このフラグがイベント・データの先頭に存在しない場合)。デフォルト値は NO です。

MaxEventQueueDepthこの値は、転送のためのキューに入れることができるイベントの最大数を示します。この限界に達すると、キューに入れられた各新規イベントは最も古いイベントをキューから除去します。指定しない場合、デフォルト値は 1000 です。この設定は、NumAdditionalServers が使用されている場合にはすべての転送チャネルに適用されます。

NumAdditionalServers複数の Netcool OMNIbus ObjectServer にイベントを転送する場合、この項目は必須です。この値は、イベントの転送先サーバーの数を示すために使用されます。有効な値は 1 から 8 です。

ServerLocationイベント・サーバーのインストール先ホストの名前を指定します。 host_name または IP_address

を指定します。IP_address にはドット・フォーマットを使用してください。必要に応じて、サーバー・ロケーションのフェイルオーバー値 (例えば、ServerLocation1=2.3.4.5,2.3.4.6.) を指定することができます。ServerLocation のフェイルオーバー値を指定する場合は、ServerLocation ごとに追加のServerPort 値も指定する必要があります。

注: イベントが複数のサーバーに転送される場合、サーバーごとに ServerLocation 値を指定する必要があります。追加項目ごとに索引番号が ServerLocation 名に付加されます。例えば、最初の追加サーバーのインストール先ホストの名前を指定するには、ServerLocation1 を使用します。

ServerPortEIF 受信側がイベントを listen するポート番号を指定します。 ServerPort オプションには、コンマで区切られた 8 つまでの値を含めることができます。ServerLocation のフェイルオーバー値が指定されている場合、それに相当する ServerPort 値を設定する必要があります。ServerPort は、TransportList オプションが指定されている場合には使用されません。


注: イベントが複数のサーバーに転送される場合、サーバーごとに ServerPort 値を指定する必要があります。追加項目ごとに索引番号が ServerPort 名に付加されます。例えば、EIF 受信側が最初の追加サーバーに関するイベントを listen するポート番号を指定するには、ServerPort1 を使用します。

TransportListコンマで区切られた、トランスポート・メカニズムのユーザー定義名を指定します。あるトランスポート・メカニズムが送信側アプリケーションで失敗した場合、API は、リストで指定された順に以下のトランスポート・メカニズムを使用します。受信アプリケーションの場合、API がすべてのトランスポート・メカニズムを作成して使用します。各 type_name のトランスポート・タイプとチャネルは、Type キーワードと Channels キーワードを使用して指定する必要があります。

type_nameType

TransportList オプションで指定されたトランスポート・メカニズムのトランスポート・タイプを指定します。サポートされるトランスポート・タイプは SOCKET のみです。

各 channel_name のサーバーとポートは、ServerLocation オプションと ServerPort オプションで指定する必要があります。

type_nameChannels

channel_namePortトランスポート・メカニズム・サーバーが (Channel オプションで設定された) 指定のチャネルを listen するポート番号を指定します。このキーワードをゼロに設定した場合、ポートマッパーが使用されます。このキーワードは必須です。

channel_namePortMapper指定されたチャネルについてポートマッパーを使用可能にします。

channel_namePortMapperNameポートマッパーが使用可能になっている場合、そのポートマッパーの名前を指定します。

channel_namePortMapperNumberリモート・プロシージャー・コールによって登録された ID を指定します。

channel_namePortMapperVersionポートマッパーが使用可能になっている場合、そのポートマッパーのバージョンを指定します。

channel_nameServerLocation指定されたチャネルに関するトランスポート・メカニズム用のサーバーが置かれているイベント・サーバーおよび領域の名前を指定します。このチャネルは Channel

オプションで設定する必要があります。このキーワードは必須です。

サポートされない構成ファイル・オプション:

Tivoli Enterprise Console ログ・ファイル・アダプターによってサポートされる以下の .conf ファイル・オプションは、Log File Agent によって無視されます。

v BufferMaxSize

v HostnameIsAdapterHost

v LanguageID

v ProcessDisablePriorityBoost

v NewLogBasedOn


v PingTimeout

v NumberOfPingCalls

注: 上記の構成ファイル・オプション以外には、Log File Agent は、「IBM Tivoli Enterprise Console アダプター・ガイド」に記載されたその他のすべての構成ファイル・オプションをサポートします。

構成ファイルは、OMNIbus で直接使用される一般 EIF オプションを受け入れます。これらのオプションは、OMNIbus への EIF 接続を介してのみ作動します。 IBM Tivoli Monitoring に送信されるイベントには影響を与えません。これらの EIF オプションについて詳しくは、EIF キーワードを参照してください。

関連概念:

51ページの『第 5 章イベント・フィルタリングおよび要約』構成 (.conf) ファイル内に設定するイベント・フィルタリングおよび要約オプションを使用して、Tivoli

Log File Agent が重複イベントを処理する方法を制御します。

関連資料:

77ページの『LogFile イベント属性グループ』モニター対象ログ・ファイル内の、構成済みフォーマットと一致するイベント。

13ページの『エージェントの構成ファイルとフォーマット・ファイルの変更』Tivoli Log File Agent は、開始時にその構成ファイル (.conf) とフォーマット・ファイル (.fmt) を読み取り、その後 60 秒ごとにタイム・スタンプをモニターします。



http://publib.boulder.ibm.com/tividd/td/tec/GC32-0691-01/en_US/HTML/eifmst106.htm#HDREIFAP041003253

第 4 章フォーマット・ファイル

Tivoli Log File Agent は、システム・ログ・メッセージから情報を抽出し、さまざまなログ・メッセージをイベント・クラスと突き合わせます。フォーマット・ファイルは、ログ・メッセージをイベント・クラスと突き合わせるためのルックアップ・ファイルとして機能します。これにより、読み取る内容、突き合わせる内容、およびデータをフォーマット設定する方法をイベント・クラスに指示します。

フォーマット・ファイルがルックアップ・ファイルとして使用されると、ファイル内のすべてのフォーマット仕様は、ファイルの先頭から末尾への順序で比較されます。1 つのメッセージに対して 2 つのクラスが一致する場合または複数の一致クラスがある場合は、末尾から開始して最初に一致する式が使用されます。一致が見つからない場合、イベントは廃棄されます。不一致ログが .conf ファイル内で定義されている場合、廃棄されたイベントは不一致ログに書き込まれます。

この章では、ログ・メッセージとイベントを突き合わせるパターンを作成するために使用する正規表現構文について説明します。検査対象の属性値が指定のパターンに一致するかどうかを調べるために、International Components for Unicode (ICU) ライブラリーを使用した正規表現フィルタリングのサポートが提供されます。

正規表現の使用について詳しくは、http://userguide.icu-project.org/strings/regexp を参照してください。

注: 互換性を維持する目的で、Tivoli Enterprise Console ログ・ファイル・アダプターで使用される構文は、現在でもサポートされています。既存のファイルへの新規フォーマットの追加もサポートされています。しかし、新規フォーマット・ファイルを作成するときには、ここで説明する構文を使用してください。Tivoli Enterprise Console ログ・ファイル・アダプターで使用される構文について詳しい情報が必要な場合は、『フォーマット・ファイルについての参照』を参照してください。

関連資料:


フォーマット・ファイル仕様フォーマット・ファイルは、モニター対象ログ内のイベントを突き合わせるためにエージェントが検索するパターンを記述します。フォーマット・ファイルは、1 つ以上のフォーマット仕様から成り立っています。

エージェント・インスタンスの実行中にフォーマット・ファイルを変更できます。エージェントは、開始時にこのファイルを読み取り、それ以降は 60 秒ごとにタイム・スタンプが変更されたかどうかをモニターします。ファイルのタイム・スタンプが変更された場合、エージェントは、その構成を動的に再初期化します。エージェントの再始動は不要です。詳しくは、 13ページの『エージェントの構成ファイルとフォーマット・ファイルの変更』を参照してください。

イベントを突き合わせる新規パターンを作成するには、以下の部分から成り立っている新規の正規表現構文を使用します。

v フォーマット・ヘッダー

v 正規表現

v スロット・マッピング


http://userguide.icu-project.org/strings/regexp

http://publib.boulder.ibm.com/tividd/td/tec/SC32-1242-00/en_US/HTML/ecoamst281.htm

v 終了ステートメント

フォーマット・ヘッダーには、キーワード REGEX が含まれます。これは、エージェントに対して、モニター対象ログ内のパターンを突き合わせるために正規表現を使用していることを通知します。

以下の例に示すように、この正規表現をイベント・クラスに割り当てます。

REGEX REExample

特別な事前定義イベント・クラス *DISCARD* をイベント・クラスとして使用する場合、関連付けられたパターンと一致するログ・レコードはすべて廃棄され、それらに対するイベントは生成されません。以下に例を示します。

REGEX *DISCARD*

1 つのパターンと一致したため、不一致ログには何も書き込まれません。これらの廃棄されたイベントは、一致するログ・ファイル状況レコードに含まれます。

注: 複数のイベント定義を同じイベント・クラスまたは複数の異なるイベント・クラスに割り当てることができます。クラス名は任意であり、これを使用して、イベントのタイプを示したり、さまざまな方法でイベントをグループ化したりできます。

フォーマット・ヘッダーの後のフォーマット・コンテンツは、最初の行の正規表現と、それに続くマッピングから成り立っています。各マッピングはそれぞれ別個の行に表示されます。これらのマッピングについては、以下の例で説明します。

正規表現と一致するすべての行が選択され、モニター・サーバーにイベントとして送信されます。正規表現には副次式が含まれます。副次式を使用すると、一致するこれらの行の特定の部分を、Event Integration

Facility 内の「スロット」と呼ばれる変数と突き合わせることができます。オプションとして、これらのスロットを、IBM Tivoli Monitoring 内の特定の属性にマップできます。

ここに示すモニター・ログには、モニター対象にできる 3 つの行が含まれます。

Error: disk failureError: out of memoryWARNING: incorrect login

例えば、Error: で開始される行などの特定のエラーに対してイベントを生成し、Warning: で開始される行を無視します。正規表現は、Error: で開始される行と一致し、副次式を含む必要があります。副次式は括弧で示され、msg スロットに割り当てる入力テキストのみと一致する必要があります。以下のフォーマット定義は、1 つの例を示しています。

REGEX REExampleError: (.*)msg $1END

注: この例は、1 つの副次式のみを含む単純な正規表現を示しています。

このフォーマット仕様およびログ・データの以前のセットに基づいて、エージェントは 2 つのイベントを生成します。どちらのイベントにも REEXample イベント・クラスが割り当てられます。最初のイベントでは、disk failure の値が msg スロットに割り当てられます。また、2 番目のイベントでは、out of

memory の値が msg スロットに割り当てられます。Warning 行は正規表現と一致しなかったため、この行は無視され、イベントは生成されません。

$1 の値を msg スロットに割り当てると、最初の副次式の値が割り当てられます。


例えば、以下のエラーを含むログ・テキストがあるとします。

Error: disk failure on device /dev/sd0: bad sectorError: disk failure on device /dev/sd1: temperature out of range

ディスク障害が発生した場合に即時に通知を受け取れるように、これらのエラー・メッセージを専用のイベント・クラスに割り当てることができます。エラーが発生したディスクの説明およびディスク・エラーのより具体的な説明をイベント内に組み込むことができます。

以下の正規表現には、この情報を識別する 2 つの副次式が含まれます。

REGEX DiskFailureError: disk failure on device (/dev/sd[0-9]):(.*)device $1 CustomSlot1msg $2END

これらの 2 つの副次式をイベント・スロットに割り当てます。生成される 2 つのイベントには、以下の値が含まれます。

"device=/dev/sd0" and "msg=bad sector""device=/dev/sd1" and "msg=temperature out of range"

EIF を使用して最初のイベントを生成する場合は、以下の例に示すように表示されます。

DiskError;device=’/dev/sd0’;msg=’bad sector’;END

イベントが IBM Tivoli Monitoring に送信される場合は、msg という名前のスロットが、同じ名前の IBM

Tivoli Monitoring 属性に割り当てられます。しかし、device という名前のスロットに対応する事前定義IBM Tivoli Monitoring 属性はありません。

device に割り当てられた値を、Tivoli Enterprise Portal 上で直接確認するか、この値に対するシチュエーションを記述する必要がある場合は、このスロットを IBM Tivoli Monitoring 属性に割り当てる必要があります。

Tivoli Log File Agent には、以下の 13 個の事前定義属性が含まれます。

v 以下の範囲の 10 個のストリング・タイプ属性

CustomSlot1 から CustomSlot10 まで

v 以下の範囲の 3 つの整数タイプ属性

CustomInteger1 から CustomInteger3 まで

フォーマット・ファイル内でこれらの属性名を使用して、同じ名前の IBM Tivoli Monitoring 属性にデータを取り込みます。これらの属性を使用しても、OMNIbus に直接送信される EIF イベントのコンテンツには影響しません。

注: CustomSlot および CustomInteger 属性名では大/小文字が区別されるため、示された名前を正確に入力する必要があります。

フォーマット・ファイル内でスロットをイベント定義からこれらのカスタム IBM Tivoli Monitoring 属性の1 つに割り当てます。

以下の例に示すように、device スロットを、CustomSlot1 という名前の IBM Tivoli Monitoring ストリング・タイプ属性に割り当てます。

第 4 章フォーマット・ファイル 41

REGEX DiskFailureError: disk failure on device (/dev/sd[0-9]):(.*)device $1 CustomSlot1msg $2END

イベントが IBM Tivoli Monitoring に表示されると、device スロットに割り当てられた値が、CustomSlot1

という名前の IBM Tivoli Monitoring 属性に割り当てられます。この値を Tivoli Enterprise Portal 上で確認するか、この値を使用してシチュエーションを定義します。イベント定義内の任意のスロットを、10 個のカスタム IBM Tivoli Monitoring 属性のいずれかに同じ方法で割り当てることができます。割り当てるには、「CustomSlot<n>」を指定します。ここで、<n> は、スロット定義に続く 1 から 10 までの番号です。

この例では、最初の副次式は (/dev/sd[0-9]) として具体的に定義されますが、2 番目の副次式は (.*) として一般的に定義されます。正規表現をできるだけ具体的に定義しておくと、パフォーマンスが向上します。したがって、ここで定義された特定のエラー・メッセージと一致しないデバイス上のエラーに対する検索が入力された場合、検索手順は、エラーが見つからないと即時に停止します。一致を検索するために時間を浪費することはありません。

END キーワードは、フォーマット仕様を完了します。以下の例に示すように、フォーマット・ヘッダー、正規表現、および END キーワードは、それぞれ改行後に開始される必要があります。

REGEX REExampleError:msg $1END <EOL><EOF>

注: ファイル内の最後のフォーマットでは、例に示すように、END キーワードの後に改行を挿入する必要があります。これに違反すると、構文解析エラーが発生します。

カスタム整数属性 CustomInteger1 から CustomInteger3 までは、64 ビット整数属性です。これらは、ストリング・タイプ CustomSlot 属性と同じ方法で使用できます。これらの属性を使用して、個別のスロットまたは副次式を、ログ・ファイルから個別の IBM Tivoli Monitoring 属性にマップできます。これらの属性は数値であるため、属性に対して < および > などの算術比較を使用できます。ストリング属性に対してはこのような比較を使用できません。

注: これらの値は、IBM Tivoli Monitoring インフラストラクチャーによって整数として評価されますが、EIF の用途およびフォーマット・ファイル内ではストリングとして扱われます。したがって、例えば、整数スロットを PRINTF ステートメント内で使用するには、「%d」ではなく「%s」を使用してスロットを識別します。

以下の例は、カスタム整数属性の使用を示しています。定期的な UNIX syslog メッセージを受信し、以下の架空のログ・レコードのように、ファイル・システムの空きスペースの割合が報告されるとします。

Oct 24 11:05:10 jimmy fschecker[2165]: Filesystem /usr is 97% full.

フォーマット・ファイル内で以下のステートメントを使用して、ファイル・システムの空きスペースの割合を検査できます。

REGEX FileSystemUsage^([A-Z][a-z]{2}) ([ 0-9][0-9]) ([0-9]{2}:[0-9]{2}:[0-9]{2}) (.*?) (.*?):Filesystem (.*?) is ([0-9]+)% full¥.$Month $1 CustomSlot1Date $2 CustomSlot2Time $3 CustomSlot3Host $4 CustomSlot4


Service $5 CustomSlot5Filesystem $6 CustomSlot6PctFull $7 CustomInteger1msg PRINTF("%s: %s% full", Filesystem, PctFull)END

注: 上記のステートメントでは、2 行目の ^ シンボルと 3 行目の $ シンボルの間のストリング全体を単一行で指定する必要があります。

他のイベントが CustomInteger1 内に値を挿入する可能性があるため、異なるイベント・タイプの混同を避けるために、Class 属性の値を使用して、影響の範囲を適切なイベント・タイプのみに制限できます。例えば、以下のシチュエーション式を使用すると、FileSystemUsage イベント・クラスのイベントの値がCustomInteger1 内で 95 以上である場合にのみ、シチュエーションが起動されます。

( Class == ’FileSystemUsage’ AND CustomInteger1 >= 95)

それ以外のイベントが CustomInteger1 を別の目的で使用しても、このシチュエーションを誤ってトリガーすることはありません。

これで、IBM Tivoli Monitoring 内で CustomInteger 属性に対して算術演算子を使用するシチュエーションを記述できます。CustomSlots 属性に対してはこのような演算子を使用できません。

注: 非整数データを CustomInteger 属性にマップした場合、結果の値は、ゼロまたは何らかの予期しない値になることがあります。

関連資料:

74ページの『ログ・ファイル状況属性グループ』「ログ・ファイル状況」属性グループには、このエージェントがモニターしているログ・ファイルの状況を反映する情報が含まれています。

13ページの『エージェントの構成ファイルとフォーマット・ファイルの変更』Tivoli Log File Agent は、開始時にその構成ファイル (.conf) とフォーマット・ファイル (.fmt) を読み取り、その後 60 秒ごとにタイム・スタンプをモニターします。


継承フォーマット・ファイルは、継承を使用して、以前に定義されたフォーマット仕様からスロット定義を派生させます。

FOLLOWS 関係を指定すると、継承を使用して、汎用フォーマット仕様から特定のフォーマット仕様を作成できます。

最初に、以下の例に示すように、基本クラスを定義し、それに DiskFailure という名前を付けます。

REGEX DiskFailureDisk Failure on device (.*)device $1 CustomSlot1END

この正規表現はモニター・ログ内の Disk Failure on device/dev/sd0 エラーと一致するため、/dev/sd0

値が device スロットに割り当てられます。


ただし、モニター・ログ内で報告されたこのエラー・メッセージの拡張バージョンを表示することもできます。

例えば、Disk Failure on device /dev/sd0, error code: 13 エラー・メッセージがあるとします。

このエラー・メッセージは、以下の例に示すように、スロットと突き合わされます。

REGEX DiskFailureError FOLLOWS DiskFailureDisk Failure on device (.*), error code: ([0-9]*)errcode $2 CustomSlot2END

この場合、イベントには、device スロットおよび errcode スロットが含まれます。DiskFailure イベント・クラスではデバイス名のスロットが既に定義されているため、サブクラスにそのスロットを継承させると、この継承により 2 回目の宣言を省略できます。スロットは $1 として定義されるため、正規表現内の最初の副次式がそのスロットに割り当てられます。

しかし、DiskFailureError クラスでは、2 番目の副次式も定義されます。この副次式を errcode という名前の新規スロットに割り当て、それを $2 として定義して、正規表現内の 2 番目の副次式を参照することができます。このタイプの割り当ては、ログ・テキストを表示する上記の例に示されています。

このイベントでは、device スロットに /dev/sd0 の値が割り当てられ、errcode スロットに 13 の値が割り当てられます。CustomSlot1 にデバイスが割り当てられ、CustomSlot2 にエラー・コードが割り当てられます。

IBM Tivoli Monitoring カスタム属性マッピングも継承されます。IBM Tivoli Monitoring カスタム属性マッピングについて詳しくは、 39ページの『フォーマット・ファイル仕様』を参照してください。

複数行複数行構文を使用して、複数の行にまたがるレコードを、モニターしているログ内のパターンと突き合わせます。

正規表現の一部として ¥n 改行文字を指定して、モニター・ログ内で改行が発生する位置を示します。以下の例にあるこのタイプの構文を参照してください。

REGEX REMultiLineLine1:(.*)¥nLine2(.*)msg $1second_msg $2END

注: Windows では、復帰と改行の組み合わせ (¥r¥n) を指定します。

以下のエラー・メッセージがログ・テキスト内で報告されている場合は、REMultiLine イベントが作成されます。

Line1: An error occurredLine2: The error was "disk error"

msg スロットには An error occurred の値が割り当てられ、second_msg スロットには The error was

"disk error" の値が割り当てられます。


マッピングTivoli Log File Agent は、マッピングを使用して、システム・ログ・メッセージのイベント・クラスを判別します。エージェントは、メッセージをフォーマット・ファイル内のパターンと突き合わせて、イベント・クラスを判別します。

エージェントは、ログ・メッセージを、属性 name=value ペアを含むイベント・クラス・インスタンスに変換します。その後、イベントはイベント・サーバーに送信されます。

エージェントは、ソースでのシステム・ログ・メッセージのイベント・クラスを判別します。エージェントは、システム・ログ・メッセージをフォーマット・ファイル内のパターンと突き合わせて、イベント・クラスを判別します。この突き合わせ手順を使用してクラスを判別した後で、値を属性に割り当てる必要があります。

属性値は、以下のようなさまざまなソースから取得されます。

v エージェントによって提供されるデフォルト値

v 正規表現内の特定の副次式と一致するログ・テキスト

フォーマット・ファイル内に含まれているマップ・ステートメントの構文は以下のとおりです。

name value CustomSlotn

ここでは、任意の ID を指定して、スロット (変数、属性、または値 ID とも呼ばれます) の name を定義します。次に、 46ページの『値指定子』で説明されている任意の値を適用して、このスロットに割り当てる値を指定します。

カスタム・スロットを使用して、データを Tivoli Enterprise Portal 内に表示し、シチュエーションを定義します。シチュエーションを作成する場合、すべてのカスタム・スロット値はストリングです。重複検出を実行するときにも、重複を判別するには、使用されるスロットを識別する必要があるため、カスタム・スロットが必要です。イベントのフィルタリングについて詳しくは、 51ページの『第 5 章イベント・フィルタリングおよび要約』を参照してください。msg は、イベント・テーブル内で専用の属性を持つ特別なスロット名です。msg では、カスタム・スロットを使用する必要はありません。

スロットがフォーマット定義内にのみ存在するように、スロットの有効範囲を制限できます。スロットを定義するときに、スロット名の前にダッシュを付けます。以下に例を示します。

-name value

この方法で定義したスロットは、最終イベント内に含まれません。しかし、フォーマット定義内の他の場所ではこのスロットを参照できます。具体的には、PRINTF ステートメント内で参照します。以下のREGenericSyslog の例では、service スロットは、生成されるイベントに含まれません。しかし、このスロットは、PRINTF ステートメント内で参照できます。元のスロットがダッシュなしで定義された場合にスロットに適用されたのと同じ値が保持されます。この手順を使用して、最終イベント内に含まれない一時変数をフォーマット定義内で使用できます。例えば、以下の方法でイベント・クラス REGenericSyslog を定義して、汎用 UNIX syslog イベントを突き合わせることができます。

REGEX REGenericSyslog^([A-Z][a-z]{2}) ([ 0-9][0-9]) ([0-9]{2}:[0-9]{2}:[0-9]{2}) (.*?) (.*?): (.*)$month $1date $2time $3host $4


-service $5msg $6syslog_msg PRINTF("service %s reports %s", service, msg)END

値指定子このセクションでは、フォーマット仕様内のマッピングによって値を属性に割り当てる方法について説明します。

フォーマット仕様のマッピング部分は、以下のタイプの値指定子から成り立っています。

v $i

v ストリング定数

v PRINTF ステートメント

$i

i は、書式制御ストリング内の副次式の位置を示します。各副次式には、1 から書式制御ストリング内の副次式の最大数までの番号が付きます。

$i 値指定子 (変数、スロット、または属性とも呼ばれます) の値は、システム・ログ・メッセージにおいて、対応する副次式と一致する部分を示します。

以下の例では、ログ・エージェントは、UNIX syslog 機能からのすべてのログ・メッセージを、割り当てられた値を持つ syslog イベントに変換します。

REGEX REGenericSyslog^([A-Z][a-z]{2}) ([ 0-9][0-9]) ([0-9]{2}:[0-9]{2}:[0-9]{2})(.*?) (.*?): (.*)$month $1date $2time $3host $4service $5msg $6END

$1 から $6 までの番号が付いた各副次式は、正規表現内の括弧で囲まれた 1 つの項目と一致します。

したがって、例えば、以下の syslog イベントがあるとします。

Apr 6 10:03:20 jimmy syslogd 1.4.1: restart.

このイベントには、以下の値が割り当てられます。

month=Aprdate=6time=10:03:20host=jimmyservice=syslogd 1.4.1msg=restart.

例えば、syslog イベント内で、10:03:20 値は、正規表現内の括弧で囲まれた 3 番目の項目と一致します。したがって、値は、$3 の時刻値に割り当てられます。同様に、jimmy 値は、正規表現内の括弧で囲まれた 4 番目の項目と一致します。したがって、値は、$4 のホスト値に割り当てられます。

ストリング定数


ストリング定数は、指定されたストリングが属性の値であることを宣言します。属性値がスペースを含まない単一の定数である場合は、以下の例に示すように、二重引用符 (" ") で囲まないで指定します。

severity WARNING

反対に、属性値がスペースを含む場合は、以下の例に示すように、二重引用符を使用する必要があります。

component "Web Server"

PRINTF ステートメント

PRINTF ステートメントは、他の属性値を組み合わせた複合属性値を作成します。PRINTF ステートメントは、キーワード PRINTF およびそれに続く printf() C スタイル書式制御ストリングと 1

つ以上の属性名から成り立っています。

書式制御ストリングは、%s コンポーネント指定子のみをサポートします。PRINTF ステートメント内で使用される属性の値は、$i 値指定または定数ストリング値指定から派生させる必要があります (別の PRINTF ステートメントから派生させることはできません)。

引数属性の値を使用して、書式制御ストリングに従って新規定数ストリングを作成します。この新規定数ストリングが属性の値になります。

PRINTF キーワードを使用すると、REGenericSyslog 基本クラスおよび service と msg のスロットを定義した上記の例に基づいて、syslog_msg という名前の属性を定義できます。

syslog_msg PRINTF("service %s reports %s", service, msg)

例えば、以下のログ・メッセージが報告されたとします。

Apr 6 10:03:20 jimmy syslogd 1.4.1: restart.

以下に示すように、書式制御ストリングからの属性値を含む新規定数ストリングが作成されます。

syslog_msg="service syslogd 1.4.1 reports restart."

キーワードキーワードを使用して、実行時に拡張される値をフォーマット・ファイル内で割り当てます。

以下のキーワードは、実行時に拡張されます。

v DEFAULT

v FILENAME

v LABEL

v REGEX

DEFAULT

DEFAULT キーワードを使用して、DEFAULT 値を特定のスロットまたは属性に割り当てます。Tivoli Log File Agent は、内部デフォルト値を、以下の表で説明するスロットに割り当てます。

表 2. スロットおよび DEFAULT 値

スロット説明

hostname hostname は、エージェントが実行されているシステムの短いホスト名です。システムのドメイン名は含まれません。


表 2. スロットおよび DEFAULT 値 (続き)

スロット説明

origin origin は、エージェントが実行されているシステムの IP

アドレスです。

fqhostname fqhostname は、エージェントが実行されているシステムの完全修飾ホスト名です。システムのドメイン名が含まれます。

RemoteHost イベントがローカル・システムで発生した場合、この属性は空になります。イベントがリモート・システムで発生した場合、RemoteHost には user@host:port という形式のストリングが設定されます。このストリングは、イベントが発生したリモート・ホストの名前と、そのホスト上で接続に使用されるユーザー名とポートを示しています。

fqhostname に割り当てられる値は、.conf ファイル内の以下の FQDomain (オプション) 設定によって影響されます。

v FQDomain を「yes」値に設定した場合、エージェントはシステム・ドメイン名自体を決定します。

v FQDomain の値を設定しなかった場合、または「no」値を設定した場合、エージェントはドメイン名を設定しません。fqhostname 属性には、空白のストリングが割り当てられます。

v 最後に、FQDomain を「yes」または「no」以外の値に設定した場合、ドメイン名は値として受け入れられ、ホスト名の後に付加されます。

以下の例では、フォーマット定義には 3 つの属性またはスロットが含まれます。

v hostname DEFAULT

v origin DEFAULT

v fqhostname DEFAULT

例えば、.conf ファイル内で FQDomain を「yes」に設定し、以下のプロパティーを持つコンピューター上で実行するとします。

v hostname: myhost

v IP address: 192.168.1.100

v domainname: mycompany.com

イベントが作成され、3 つのスロットに以下の値が割り当てられます。

"hostname=myhost", "origin=192.168.1.100", "fqhostname=myhost.mycompany.com"

FILENAME

FILENAME キーワードは、メッセージを格納するログ・ファイルの完全修飾ファイル名 (パスを含む) を示します。単一のエージェントを使用して複数のログ・ファイルをモニターし、イベントのソースを識別する必要がある場合は、このキーワードを使用して、イベント属性にファイル名を取り込みます。メッセージがシステム・ログから取得される場合、マッピングは、EventLog

(Windows エージェントの場合) および SysLogD (UNIX ログ・ファイル・エージェントの場合) に設定されます。

注: IBM Tivoli Monitoring パスには、このキーワードの属性が含まれます。

LABELLABEL キーワードは、エージェントが現在実行されているシステムのホスト名を示します。


REGEXREGEX キーワードは、メッセージと一致し、イベントの原因となった正規表現に拡張されます。

最大メッセージ長この値は、Log File Agent がメッセージを切り捨てないで受信できる最大メッセージ長です。

最大メッセージ長は、Tivoli Monitoring の場合と Tivoli Netcool/OMNIbus の場合で異なります。

Tivoli MonitoringIBM Tivoli Monitoring に送信されるイベントの場合、msg 属性は 2048 バイトに制限されます。これより長いメッセージは切り捨てられます。

Tivoli Netcool/OMNIbusProbe for Tivoli EIF を通じて Netcool/OMNIbus に送信されるイベントの場合、クラス名およびすべてのスロットとその値を含むイベントの合計サイズは、4096 バイトを超えることはできません(これは、エージェントのバージョン 6.2.2.3 時点での拡張された制限です)。例えば、以下のサンプル EIF イベントでは、;END は、4096 バイト制限の一部としてカウントされません。しかし、セミコロン、引用符、等号などの構文要素を含むその他のすべてのバイトは、制限の一部としてカウントされます。

Class;attr1=value1;attr2=value2;msg=’Hello, world’;END



第 5 章イベント・フィルタリングおよび要約

構成 (.conf) ファイル内に設定するイベント・フィルタリングおよび要約オプションを使用して、Tivoli

Log File Agent が重複イベントを処理する方法を制御します。

ログがモニターされるときに、1 つのイベントが短期間で複数回表示されることがあります。例えば、この繰り返しロギングは、ログを生成するアプリケーションがエラーを検出し、その状況が解決されるまでこのエラーを継続的にログに記録した場合に発生することがあります。このようなロギングが発生すると、非常に多くのイベントがモニター・インフラストラクチャーに送信されます。大量のイベントはパフォーマンスに悪影響を及ぼします。

注: イベント検出および要約手順は、IBM Tivoli Monitoring に送信されるイベントでのみサポートされます。EIF によって OMNIbus に送信されるイベントでこれらの手順を実行することはできません。

関連資料:


重複イベントの検出およびフィルタリング重複イベントを処理するように、Tivoli Log File Agent を構成できます。

複数の重複イベントの問題を軽減するために、.conf ファイル内で DupDetectionKeyAttributes タグを使用して、重複イベントの構成要件を定義します。コンマ区切りリストに、あるイベントが重複しているかどうかを判別するために使用する 1 つ以上の定義済み IBM Tivoli Monitoring 属性を組み込みます。以下の例では、同じメッセージおよび同じ CustomSlot1 を持つイベントは、重複していると見なされます。

DupDetectionKeyAttributes=msg,CustomSlot1

重複イベントは、IBM Tivoli Monitoring 属性から検出されます。したがって、定義した特定のスロットに基づいて重複を検出する場合は、以下のステップを実行します。

1. スロット値を IBM Tivoli Monitoring 属性にマップします。

2. IBM Tivoli Monitoring 属性を .conf ファイル内の DupDetectionKeyAttributes タグにマップします。

以下の例では、重要なスロット eventclass および eventid が CustomSlot1 および CustomSlot2 にマップされます。

REGEX BaseAuditEvent^([A-Z][a-z]{2} [0-9]{1,2} [0-9]{1,2}:[0-9]{2}:[0-9]{2}[0-9] {4}) [0-9] (¥S+) (¥S+) ¥Microsoft-Windows-Security-Auditing (¥S+) ([0-9]+) (.*)timestamp $1severity $2eventclass $3 CustomSlot1eventkeywords $4eventid $5 CustomSlot2msg $6END

.conf ファイル内で特定のイベントを重複イベントとして指定する場合は、以下に示すように、IBM Tivoli

Monitoring 属性を DupDetectionKeyAttributes タグにマップします。


DupDetectionKeyAttributes=CustomSlot1,CustomSlot2

注:

1. CustomSlot 属性名では大/小文字が区別されるため、上記の例に示された名前を正確に入力する必要があります。

2. 属性のリストを指定しなかった場合、値はデフォルトで Class および Logname になります。

これらの属性が一致するイベントは、エージェントによって重複イベントであると見なされます。

重複検出はグローバルであるため、キーとして使用するカスタム・スロットのセットを選択し、それらのスロットをすべてのフォーマット指定ステートメント内でキーとして使用する手法をお勧めします。例えば、キーとしてスロット 1 から 3 を使用します。あるフォーマットでキーを 1 つのみ指定し、さらに追加のスロットを指定する必要がある場合は、名前値を格納するためにスロット 1 を使用し、その他のデータを格納するためにスロット 4 から n を使用します。

要約間隔重複検出手順は、要約間隔と呼ばれる 1 つの期間の中で実行されます。

重複イベントは、この間隔内でカウントされ、間隔が終了するとリセットされます。カウンターは、新規の要約間隔が開始されるたびに、カウントを 0 から再び開始します。

エージェントは、間隔内でモニターした各イベント・セットの要約イベントを送信します。要約イベントには、一致した最初のイベントの属性値が含まれます。要約イベントには、要約間隔内で発生したそのイベントの重複回数を示す数も含まれます。

要約間隔は、構成 (.conf) ファイル内で、以下の例に示すように設定されます。

EventSummaryInterval=300

要約間隔に割り当てられる値は秒単位であるため、この例の要約間隔は 5 分です。

イベントのフィルタリングイベントのフィルタリングが実行されている場合、構成 (.conf) ファイル内の EventFloodThreshold 設定は、エージェントに対して、イベントをいつ送信するかを通知します。

以下の表は、EventFloodThreshold 値を示しています。

表 3. EventFloodThreshold 値

EventFloodThreshold 値説明

send_all send_all 値はデフォルト値です。イベントが重複イベントである場合でも、すべてのイベントが送信されます。

send_none send_none 値は、個々のイベントが送信されないことを意味します。要約イベントのみが送信されます。

send_first send_first 値を使用すると、最初のイベントが検出されたら直ちに送信されます。指定された時間内にその最初のイベントと重複するイベントが検出された場合、この最初のイベントの後続の重複イベントは送信されません。詳しくは、『要約間隔』を参照してください。


表 3. EventFloodThreshold 値 (続き)

EventFloodThreshold 値説明

n integer n integer 値を使用すると、特定の時間内に検出された n

番目ごとの重複イベント (例えば、5 番目ごとの重複イベント) のみが送信されます。詳しくは、 52ページの『要約間隔』を参照してください。

要約属性イベント・タイプ属性と発生回数属性は、イベントの要約を支援するために使用されます。

イベント要約が使用可能である場合、イベント・タイプ属性と発生回数属性は意味を持ちます。イベント・タイプ属性は、イベントのタイプを示し、Event または Summary Event のいずれかです。ログ内にあるレコードと 1 対 1 で対応する一般的なイベントには、Event タグが付けられます。要約間隔の最後に送信される要約イベントには、Summary Event タグが付けられます。

発生回数属性は、ログ内にあるイベントの重複レコードの合計数を示します。この属性は、直前の要約間隔内で受信されたイベントのうち、要約イベントと一致したイベントの数を表示します。したがって、要約イベントにはこの合計数が含まれます。

シチュエーションと要約イベント

52ページの『イベントのフィルタリング』で説明したフィルター値に関係なく、各要約間隔の最後には必ず、その間隔中に少なくとも 1 回発生したあらゆるイベントについての要約イベントが得られます。要約イベントを想定していないと、シチュエーションが誤ってトリガーされることがあります。このようにシチュエーションが誤ってトリガーされることを避けるには、シチュエーションに Event Type== Event またはEvent Type!= Summary Event の節を組み込みます。

Tivoli Enterprise Portal でのイベント・フィルタリングおよび要約の表示イベント・フィルタリングおよび要約のオプション選択により、データの処理方法がどのようになるかの例を示します。

エージェントは、最近受信されたイベントのキャッシュを保守します。デフォルトでは、このキャッシュのサイズは 100 です。エージェントのイベント・フィルタリングおよび要約を使用可能にした場合は、キャッシュ内のイベントの数と IBM Tivoli Monitoring に送信されるイベントの数の間に差異が発生することがあります。キャッシュに追加されたイベントが、指定された送信しきい値に到達しない可能性があります。あるいは、send_all オプションを選択した場合、キャッシュ内のイベントのほうが少ない可能性があります。send_all オプションが設定されている場合、イベントは、重複が発生するたびに送信されます。しかし、キャッシュ内に保持されるイベントのコピーは 1 つのみであり、発生回数はイベントが発生するたびに増加します。IBM Tivoli Monitoring に送信されるイベントを表示するには、ヒストリカル・ビューを作成します。ヒストリカル・ビューの作成については、「Tivoli Enterprise Portal User's Guide」の『Historical Reporting』を参照してください。このビューを Tivoli Enterprise Portal 内のリアルタイム・キャッシュ・ビューと比較できます。シチュエーションを使用して同じ比較を実行することもできます。

以下の例は、同じデータが、イベント・フィルタリングおよび要約のオプション選択によって (選択した場合は) 異なる処理が行われる様子を示します。EventFloodThreshold 設定で使用可能な 4 つの値にそれぞれ対応する 4 つのエージェント・インスタンスが作成されます。インスタンスは、インスタンスが .conf フ

第 5 章イベント・フィルタリングおよび要約 53

http://pic.dhe.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.3fp1/adminuse/history_intro_tep.htm

ァイル内で使用する EventFloodThreshold の値と同じ名前を持ちます。4 つのインスタンスはいずれも、以下の .conf ファイル設定によって制御される CustomSlot1 を重複検出キーとして使用します。

DupDetectionKeyAttributes=CustomSlot1

各インスタンスは、以下のような同じフォーマット定義を使用します。

REGEX DupExampleexample: (.*)example $1 CustomSlot1msg PRINTF("The example is %s", example)END

4 つのインスタンスはいずれも、同じテキスト・ログをモニターします。同じテキスト行がモニター対象ログに 10 回追加されました。

example: This is an error

それぞれの例で、ヒストリカル・ビューとリアルタイム (キャッシュ)・ビューが表示されます。デフォルトでは、ヒストリカル・ビューには最新のイベントが最後の行に表示され、キャッシュのデフォルト・リアルタイム・ビューには最新のイベントが最初の行に表示されます。これらの例では、ヒストリカル・ビューは、直近の 1 時間を示しています。CustomSlot2-10 は、これらの例では非表示になっています。

新規イベントが到着すると、それらがキャッシュ・ビュー内に表示されます。重複イベントが到着すると、既存の行のデータが更新されます。要約間隔が経過すると、既存のイベントが要約イベントに変換され、送信されます。その後、次の要約間隔のために新規行が追加されます。

55ページの図 1 は、.conf ファイル内で send_all オプションを選択した場合のヒストリカル・ビューおよびキャッシュ・ビューを示しています。send_all オプションはデフォルト・オプションです。10 個のイベントおよび 1 個の要約イベントがヒストリカル・ビュー内に表示されます。


56ページの図 2 は、.conf ファイル内で send_none オプションを選択した場合のヒストリカル・ビューおよびキャッシュ・ビューを示しています。要約イベントのみが両方のビュー内に表示されます。

図 1. send_all が選択された場合のヒストリカル・ビューおよびキャッシュ・ビュー


57ページの図 3 は、.conf ファイル内で send_first オプションを選択した場合のヒストリカル・ビューおよびキャッシュ・ビューを示しています。要約間隔内で最初に受信されたイベントおよび間隔の要約イベントがヒストリカル・ビュー内に表示されます。

図 2. send_none が選択された場合のヒストリカル・ビューおよびキャッシュ・ビュー


58ページの図 4 は、.conf ファイル内で nInteger オプションを選択し、値 5 を入力した場合のヒストリカル・ビューおよびキャッシュ・ビューを示しています。5 つの重複イベント (最初のイベントを含む)

が間隔内で受信された場合にのみ、1 つのイベントが表示されます。受信された重複が 5 つより少ない場合、イベントは表示されません。間隔内で受信された重複が 6 つ、7 つ、8 つ、または 9 つである場合は、1 つのイベントが表示されます。10 個の重複が受信されたため、2 つのイベントおよび 1 つの要約イベントが表示されます。

図 3. send_first が選択された場合のヒストリカル・ビューおよびキャッシュ・ビュー


図 4. nInteger が選択された場合のヒストリカル・ビューおよびキャッシュ・ビュー


第 6 章ワークスペースの参照

ワークスペースとは、Tivoli Enterprise Portal アプリケーション・ウィンドウの作業域です。ナビゲーター・ツリーには、エージェントによって提供されるワークスペースのリストが含まれています。

ワークスペースについて

ナビゲーター・ツリーを使用して、表示したいワークスペースを選択します。アプリケーション・ウィンドウ内のステータス・バーには、表示されている情報に該当する Tivoli Enterprise Portal Server の名前とポート番号、および現行ユーザーの ID が表示されます。

ナビゲーター・ツリーの項目を選択すると、デフォルト・ワークスペースが表示されます。ナビゲーター項目を右クリックすると、ワークスペース項目を含むメニューが表示されます。ワークスペース項目には、そのナビゲーター項目のワークスペースのリストがあります。各ワークスペースには、少なくとも 1 つのビューがあります。ビューの中には他のワークスペースへのリンクを含むものもあります。「Tivoli

Enterprise Portal ユーザーズ・ガイド」で説明されているワークスペース・ギャラリー・ツールを使用して、ワークスペースを開くこともできます。

ナビゲーター内のワークスペースは、エンタープライズを物理マッピングとして示す「物理」ビュー、または動的にデータが取り込まれるエージェント固有の論理ビューで表示されます。「論理」ビューを作成することもできます。デフォルトのビューは物理ビューです。

このモニター・エージェントには、事前定義ワークスペースがあります。事前定義ワークスペースを変更または削除することはできませんが、事前定義ワークスペースを編集して別の名前で変更を保管することで、新規ワークスペースを作成できます。

Tivoli Log File Agent には、さまざまなデフォルトのワークスペースがあります。こうしたワークスペースは、ナビゲーター・ツリーで、このモニター・エージェントの次のようなノードやサブノードの下に表示されます。

ログ・ファイルログ・ファイル・インスタンスに相当し、エージェント・インスタンス・レベルのワークスペースも含みます。

Tivoli Log File ProfileTivoli Log File Profile

モニター・エージェントの複数インスタンスがシステムで定義されているとき、最上位ノードはログ・ファイルになります。ログ・ファイル・ワークスペースは、このノードで定義されません。各インスタンスのノードは Instance:Hostname:LO として作成されます。Instance:Hostname:LO というワークスペースが、インスタンス・ノードと関連づけられます。このワークスペースはログ・ファイル・ワークスペースに相当します。

ワークスペース・ビューは、照会ベース・ビュー、イベント・ビュー、および特別な目的のビューを任意に組み合わせて生成することができます。


ワークスペースに関する追加情報

ワークスペースの作成、カスタマイズ、および操作について詳しくは、「Tivoli Enterprise Portal ユーザーズ・ガイド」の『ワークスペースの使用』を参照してください。

このモニター・エージェントの事前定義ワークスペースのリストと各ワークスペースの説明については、事前定義ワークスペースおよびそれぞれの個別ワークスペースの情報を参照してください。

このモニター・エージェントの属性グループには、このエージェント用の事前定義ワークスペースまたはビューで表示されないものもあります。属性グループの全リストについては、 67ページの『モニター・エージェントの属性グループ』を参照してください。

事前定義ワークスペースLog File Agent には、ナビゲーター項目別に編成された、以下の事前定義ワークスペースが用意されています。

エージェント・レベル・ナビゲーター項目

v ログ・ファイル・ナビゲーター項目

– ログ・ファイル・ワークスペース

– すべての正規表現の統計ワークスペース

– データ収集状況ワークスペース

– データ収集状況 (リモート) ワークスペース

– 平均 CPU の高い正規表現ワークスペース

– 合計 CPU の高い正規表現ワークスペース

– Logfile イベント (リモート) ワークスペース

– Logfile イベント (v6) ワークスペース

– Tivoli Log File Profile (リモート) ワークスペース

– 一致しなかった正規表現ワークスペース

v LFA プロファイル・ナビゲーター項目

– LFA プロファイル・ワークスペース

v LogFile イベント・ナビゲーター項目

– Logfile イベント (v6) ワークスペース

– LogFile イベント・ワークスペース

Tivoli Log File Profile (pro) サブノード

v Tivoli Log File Profile ナビゲーター項目

– Tivoli Log File Profile ワークスペース

v LogfileProfile イベント・ナビゲーター項目

– LogfileProfile イベント・ワークスペース

ワークスペースの説明それぞれのワークスペースの説明では、ワークスペースに関する情報 (目的や、そのワークスペースに表示されるビューのリストなど) が表示されます。


ワークスペースは、ナビゲーター項目の下にリストされます。エージェントのサブノードがある場合、ナビゲーター項目はサブノードの下にリストされます。

ログ・ファイル・ナビゲーター項目ワークスペースの説明は、関連するナビゲーター項目ごとに編成されています。ログ・ファイル・ワークスペース

このワークスペースは、モニター対象ログで検出されたイベントのエージェントのキャッシュのビューを表示します。すべてのログからのイベントが同じワークスペースにまとめて表示されます。イベント・フィルタリングおよび要約を使用している場合は、このワークスペースに行が表示されても、必ずしもイベントが送信されたことを示しているわけではありません。レコードは、他のレコードと比較して送信時期を決定するために、内部で保存する必要があります。保存されているレコードは、イベントがまったく送信されない場合にもここで見ることができます。要約間隔が終了して要約イベントが送信されると、このワークスペースの対応する行が「イベント」から「要約イベント」に変わります (行が追加されるわけではありません)。しかし、実際のイベントは別途送信されています。イベント・フィルタリングおよび要約を使用していない場合、このワークスペースには、送信されたイベントのみが表示されます。

このワークスペースには次のビューがあります。LogFile イベント

モニター対象ログで検出されたレコードの表を表示します。すべての正規表現の統計ワークスペース

このワークスペースは、フォーマット・ファイルで構成されているすべての正規表現に関する情報を提供します。

このワークスペースには次のビューがあります。すべての正規表現の統計

このビューは、フォーマット・ファイルで構成されているすべての正規表現に関する情報を提供します。

データ収集状況ワークスペースこのワークスペースには、ターゲット・システムのデータ収集の概要が表示されます。

このワークスペースには次のビューがあります。データの収集状況

このビューには、このアプリケーションを構成するすべての属性グループのデータ収集の状況を一括して反映した情報が含まれています。各属性グループは、この表の行によって表されています。属性グループの状況には、その属性グループ・データの最新の収集試行結果が反映されます。状況情報の確認時に、エージェントが正常に動作しているかどうかを確認することができます。

スレッド・プールの状況このビューには、内部でデータ収集を初期化するために使用される内部スレッド・プールの状況を反映した情報が含まれています。

モニター対象ファイルの状況このビューには、ログ・エージェントによってモニターされている各種のファイルおよび他のデータ・ソースの状況を反映した情報が含まれています。

データ収集状況 (リモート) ワークスペースこのワークスペースは、モニター対象ログで検出されたイベントのエージェントのキャッシュのビューを表示します。すべてのログからのイベントが同じワークスペースにまとめて表示されます。イベント・フィルタリングおよび要約を使用している場合は、このワークスペースに行が表示されても、必ずしもイベントが送信されたことを示しているわけではありません。レコードは、他のレコードと比較して送信時期を決定するために、内部で保存する必要があります。保存されているレ

第 6 章ワークスペースの参照 61

コードは、イベントがまったく送信されない場合にもここで見ることができます。要約間隔が終了して要約イベントが送信されると、このワークスペースの対応する行が「イベント」から「要約イベント」に変わります (行が追加されるわけではありません)。しかし、実際のイベントは別途送信されています。イベント・フィルタリングおよび要約を使用していない場合、このワークスペースには、送信されたイベントのみが表示されます。このワークスペースの (リモート) バージョンでは、イベントの発生元のホストを示す RemoteHost 属性も使用することができます。



平均 CPU の高い正規表現ワークスペースこのワークスペースは、フォーマット・ファイル内の正規表現のうち、エージェントでのプロセッサー使用率が最も高い正規表現に関する情報を提供します。

このワークスペースには次のビューがあります。平均 CPU 時間消費が上位 10 件以内の正規表現

このビューは、フォーマット・ファイル内の正規表現のうち、エージェントでのプロセッサー使用率の上位 10 件を占める正規表現のグラフを表示します。X 軸には、正規表現を示すインデックス番号のラベルが付けられます。この番号をフィルター番号と対応させると、それぞれのインデックスで表される実際の正規表現が分かります。

平均 CPU 時間消費が上位 10 件以内の正規表現このビューは、フォーマット・ファイル内の正規表現のうち、エージェントでのプロセッサー使用率の上位 10 件を占める正規表現の表を表示します。

合計 CPU の高い正規表現ワークスペースこのワークスペースは、フォーマット・ファイル内の正規表現のうち、エージェントでのプロセッサー使用率が最も高い正規表現に関する情報を提供します。

このワークスペースには次のビューがあります。合計 CPU 時間消費が上位 10 件以内の正規表現

このビューは、フォーマット・ファイル内の正規表現のうち、エージェントでのプロセッサー使用率の上位 10 件を占める正規表現のグラフを表示します。X 軸には、正規表現を示すインデックス番号のラベルが付けられます。この番号をフィルター番号と対応させると、それぞれのインデックスで表される実際の正規表現が分かります。

合計 CPU 時間消費が上位 10 件以内の正規表現このビューは、フォーマット・ファイル内の正規表現のうち、エージェントでのプロセッサー使用率の上位 10 件を占める正規表現の表を表示します。

Logfile イベント (リモート) ワークスペースこのワークスペースは、モニター対象ログで検出されたイベントのエージェントのキャッシュのビューを表示します。すべてのログからのイベントが同じワークスペースにまとめて表示されます。イベント・フィルタリングおよび要約を使用している場合は、このワークスペースに行が表示されても、必ずしもイベントが送信されたことを示しているわけではありません。レコードは、他のレコードと比較して送信時期を決定するために、内部で保存する必要があります。保存されているレコードは、イベントがまったく送信されない場合にもここで見ることができます。要約間隔が終了して要約イベントが送信されると、このワークスペースの対応する行が「イベント」から「要約イベント」に変わります (行が追加されるわけではありません)。しかし、実際のイベントは別途送信されています。イベント・フィルタリングおよび要約を使用していない場合、このワークスペースには、送信されたイベントのみが表示されます。このワークスペースの (リモート) バージョンでは、イベントの発生元のホストを示す RemoteHost 属性も使用することができます。

このワークスペースには次のビューがあります。


すべての正規表現の統計このビューは、フォーマット・ファイルで構成されているすべての正規表現に関する情報を提供します。

Logfile イベント (v6) ワークスペースこのワークスペースは、モニター対象ログで検出されたイベントのエージェントのキャッシュのビューを表示します。すべてのログからのイベントが同じワークスペースにまとめて表示されます。イベント・フィルタリングおよび要約を使用している場合は、このワークスペースに行が表示されても、必ずしもイベントが送信されたことを示しているわけではありません。レコードは、他のレコードと比較して送信時期を決定するために、内部で保存する必要があります。保存されているレコードは、イベントがまったく送信されない場合にもここで見ることができます。要約間隔が終了して要約イベントが送信されると、このワークスペースの対応する行が「イベント」から「要約イベント」に変わります (行が追加されるわけではありません)。しかし、実際のイベントは別途送信されています。イベント・フィルタリングおよび要約を使用していない場合、このワークスペースには、送信されたイベントのみが表示されます。このワークスペースの (v6) バージョンでは、CustomInteger スロットも使用可能です。



Tivoli Log File Profile (リモート) ワークスペースこのワークスペースは、モニター対象ログで検出されたイベントのエージェントのキャッシュのビューを表示します。すべてのログからのイベントが同じワークスペースにまとめて表示されます。イベント・フィルタリングおよび要約を使用している場合は、このワークスペースに行が表示されても、必ずしもイベントが送信されたことを示しているわけではありません。レコードは、他のレコードと比較して送信時期を決定するために、内部で保存する必要があります。保存されているレコードは、イベントがまったく送信されない場合にもここで見ることができます。要約間隔が終了して要約イベントが送信されると、このワークスペースの対応する行が「イベント」から「要約イベント」に変わります (行が追加されるわけではありません)。しかし、実際のイベントは別途送信されています。イベント・フィルタリングおよび要約を使用していない場合、このワークスペースには、送信されたイベントのみが表示されます。このワークスペースの (リモート) バージョンでは、イベントの発生元のホストを示す RemoteHost 属性も使用することができます。



一致しなかった正規表現ワークスペースこのワークスペースは、フォーマット・ファイル内の正規表現のうち、ログ内のどのパターンにも一致しなかった正規表現に関する情報を提供します。これらの一致しなかった正規表現は、不要であれば、削除します。あるいは、これらの一致しなかった正規表現が最後に検査されるようにフォーマット・ファイルの順序を最適化します (フォーマットはフォーマット・ファイルの末尾から先頭の順に検索されます)。

このワークスペースには次のビューがあります。一致しなかった正規表現

このビューは、フォーマット・ファイル内の正規表現のうち、ログ内のどのパターンにも一致しなかった正規表現の表を表示します。これらの一致しなかった正規表現は、不要で


あれば、削除します。あるいは、これらの一致しなかった正規表現が最後に検査されるようにフォーマット・ファイルの順序を最適化します (フォーマットはフォーマット・ファイルの末尾から先頭の順に検索されます)。

LFA プロファイル・ナビゲーター項目ワークスペースの説明は、関連するナビゲーター項目ごとに編成されています。LFA プロファイル・ワークスペース

このワークスペースは、エージェントによってディスカバーされた個々のモニター・プロファイルのビューを表示します。FILE_DISCOVERY_DIR 構成ディレクトリー内でディスカバーされた構成/

フォーマット・ファイルの各ペアに対して、サブノードが作成されます。

このワークスペースには次のビューがあります。Log File Agent プロファイル

このワークスペースは、エージェントによってディスカバーされた個々のモニター・プロファイルのビューを表示します。FILE_DISCOVERY_DIR 構成ディレクトリー内でディスカバーされた構成/フォーマット・ファイルの各ペアに対して、サブノードが作成されます。

LogFile イベント・ナビゲーター項目ワークスペースの説明は、関連するナビゲーター項目ごとに編成されています。Logfile イベント (v6) ワークスペース

このワークスペースは、モニター対象ログで検出されたイベントのエージェントのキャッシュのビューを表示します。すべてのログからのイベントが同じワークスペースにまとめて表示されます。イベント・フィルタリングおよび要約を使用している場合は、このワークスペースに行が表示されても、必ずしもイベントが送信されたことを示しているわけではありません。レコードは、他のレコードと比較して送信時期を決定するために、内部で保存する必要があります。保存されているレコードは、イベントがまったく送信されない場合にもここで見ることができます。要約間隔が終了して要約イベントが送信されると、このワークスペースの対応する行が「イベント」から「要約イベント」に変わります (行が追加されるわけではありません)。しかし、実際のイベントは別途送信されています。イベント・フィルタリングおよび要約を使用していない場合、このワークスペースには、送信されたイベントのみが表示されます。このワークスペースの (v6) バージョンでは、CustomInteger スロットも使用可能です。



LogFile イベント・ワークスペースこのワークスペースは、モニター対象ログで検出されたイベントのエージェントのキャッシュのビューを表示します。すべてのログからのイベントが同じワークスペースにまとめて表示されます。イベント・フィルタリングおよび要約を使用している場合は、このワークスペースに行が表示されても、必ずしもイベントが送信されたことを示しているわけではありません。レコードは、他のレコードと比較して送信時期を決定するために、内部で保存する必要があります。保存されているレコードは、イベントがまったく送信されない場合にもここで見ることができます。要約間隔が終了して要約イベントが送信されると、このワークスペースの対応する行が「イベント」から「要約イベント」に変わります (行が追加されるわけではありません)。しかし、実際のイベントは別途送信されています。イベント・フィルタリングおよび要約を使用していない場合、このワークスペースには、送信されたイベントのみが表示されます。


このワークスペースには次のビューがあります。LogFile イベント

モニター対象ログで検出されたレコードの表を表示します。

Tivoli Log File Profile サブノードサブノード用の事前定義ワークスペースの説明は、そのワークスペースが関連するナビゲーター項目別に編成されています。

Tivoli Log File Profile ナビゲーター項目Tivoli Log File Profile ワークスペース


このワークスペースには次のビューがあります。Tivoli Log File Profile


LogfileProfile イベント・ナビゲーター項目LogfileProfile イベント・ワークスペース


このワークスペースには次のビューがあります。Tivoli Log File Profile




第 7 章属性リファレンス

属性とは、Tivoli Log File Agent によって測定と報告が行われるアプリケーション・プロパティーです。

属性について

属性は、属性グループに編成されています。属性グループ内の属性は、アプリケーションなどの単一オブジェクト、または状況情報などの単一の種類のデータに関連しています。

グループ内の属性は、照会、照会ベース・ビュー、シチュエーション、ポリシー・ワークフロー、アクション実行定義、およびアプリケーション起動定義で使用することができます。図表ビューまたはテーブル・ビューとシチュエーションは、グループ内の属性の使用方法を示す 2 つの例です。

v 図表ビューまたはテーブル・ビュー

属性は、図表ビューとテーブル・ビューに表示されます。図表ビューとテーブル・ビューでは、モニター・エージェントから要求する属性値を指定するための照会を使用します。既存の照会に基づいてビューの内容や外観を定義するためにフィルターを適用したりスタイルを設定したりするには、プロパティー・エディターを使用します。

v シチュエーション

属性を使用して、オペレーティング・システム、データベース、アプリケーションの状態をモニターするためのシチュエーションを作成できます。シチュエーションでは、テストする条件を記述します。シチュエーションを開始すると、シチュエーション属性に割り当てた値と Log File Agent が収集した値が比較され、条件に合致する場合はイベントが登録されます。イベントに対するアラートは、ナビゲーターに表示されるインディケーター・アイコンによって示されます。

属性に関する追加情報

属性と属性グループの使用方法について詳しくは、「Tivoli Enterprise Portal ユーザーズ・ガイド」を参照してください。

属性グループのリスト、各属性グループ内の属性のリスト、およびこのモニター・エージェントの属性の説明については、『モニター・エージェントの属性グループ』および 68ページの『各属性グループの属性』を参照してください。

モニター・エージェントの属性グループLog File Agent には、以下の属性グループが含まれています。表名は、Tivoli Data Warehouse に使用されているターゲット・データベースの表名の最大長制限に依存します。名前の最大長が 30 文字の場合、30

文字を超えるウェアハウス表名は 30 文字に縮められます。

v 属性グループ名: LFA プロファイル

– 表名: KLOLFAPFLS

– ウェアハウスの表名: KLO_LFAPROFILES または KLOLFAPFLS

v 属性グループ名: ログ・ファイル正規表現統計

– 表名: KLOLOGFRX

– ウェアハウスの表名: KLO_LOG_FILE_REGEX_STATISTICS または KLOLOGFRX


v 属性グループ名: ログ・ファイル状況

– 表名: KLOLOGFST

– ウェアハウスの表名: KLO_LOG_FILE_STATUS または KLOLOGFST

v 属性グループ名: LogFile イベント

– 表名: KLOLOGEVTS

– ウェアハウスの表名: KLO_LOGFILEEVENTS または KLOLOGEVTS

v 属性グループ名: LogfileProfile イベント

– 表名: KLOLOGPEVT

– ウェアハウスの表名: KLO_LOGFILEPROFILEEVENTS または KLOLOGPEVT

v 属性グループ名: パフォーマンス・オブジェクト状況

– 表名: KLOPOBJST

– ウェアハウスの表名: KLO_PERFORMANCE_OBJECT_STATUS または KLOPOBJST

v 属性グループ名: pro パフォーマンス・オブジェクト状況

– 表名: KLOPROPOS

– ウェアハウスの表名: KLO_PRO_PERFORMANCE_OBJECT_STATUS または KLOPROPOS

v 属性グループ名: スレッド・プール状況

– 表名: KLOTHPLST

– ウェアハウスの表名: KLO_THREAD_POOL_STATUS または KLOTHPLST

各属性グループの属性各 Log File Agent 属性グループ内の属性は、エージェントがモニタリングに使用するデータを収集します。

属性グループの説明には以下の情報が含まれます。

ヒストリカル・グループ属性グループが、データウェアハウスにロールオフできるヒストリカル・タイプであるかどうか。

属性の説明説明、タイプ、ソース、ウェアハウス名など、属性グループ内の各属性の情報です (該当する場合)。

一部の属性は、キー属性として指定されます。キー属性とは、ウェアハウス集約で同じオブジェクトを表すデータ行を識別するために使用される属性です。

ソースの情報では、属性の派生方法を記述するために、if-then-else 節の C プログラム・コード構文が使用されることがあります。以下に例を示します。

(CPU_Pct < 0 ) || (Memory_Pct < 0 )? 0 : 1

この例の場合、CPU_Pct 属性または Memory_Pct 属性が 0 より小さい場合、その属性は 0 に設定され、それ以外の場合は 1 に設定されます。

LFA プロファイル属性グループLog File Agent プロファイルヒストリカル・グループ

この属性グループは、Tivoli Data Warehouse で使用するのに適格です。


属性の説明次のリストには、LFA プロファイル属性グループの各属性に関する情報を示します。ノード属性: この属性はキー属性です。

説明エージェントの管理対象システム名。タイプ

ストリングソースこの属性のソースは、エージェントです。ウェアハウス名

NODE

タイム・スタンプ属性説明データ収集時のエージェントでの現地時間。タイプ


TIMESTAMP

サブノード MSN 属性: この属性はキー属性です。説明サブノード・エージェントの管理対象システム名。タイプ

ストリングウェアハウス名

SUBNODE_MSN または SN_MSN

サブノード・アフィニティー属性説明サブノード・エージェントのアフィニティー。タイプ


SUBNODE_AFFINITY または SN_AFFIN

サブノード・タイプ属性: この属性はキー属性です。説明このサブノードのノード・タイプ。タイプ


SUBNODE_TYPE または SN_TYPE

サブノード・リソース名属性説明サブノード・エージェントのリソース名。タイプ


SUBNODE_RESOURCE_NAME または SN_RES

サブノードのバージョン属性説明サブノード・エージェントのバージョン。タイプ


SUBNODE_VERSION または SN_VER

サブノードの構成ファイル属性

第 7 章属性リファレンス 69

説明このサブノードが作成される原因となった、ディスカバーされた構成ファイルへのパス。

タイプストリング

ウェアハウス名SUBNODE_CONFIG_FILE または SN_FILE

サブノードの説明属性説明ユーザーが指定する、このサブノードの説明。構成ファイルの SubnodeDescription

キーで指定されます。タイプ

列挙値のストリング。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v 構成ファイルの SubnodeDescription キーワードを設定して、このフィールドにデータを取り込みます (none)

これ以外の値の場合は、Tivoli Enterprise Portal ではエージェントから戻された値です。

ウェアハウス名SUBNODE_DESCRIPTION または SN_DESC

ログ・ファイル正規表現統計属性グループ「ログ・ファイル正規表現統計」属性グループには、ログ・ファイルの正規表現検索式の統計を示す情報が含まれます。正規表現を使用することで、レコードのフィルタリングやレコードの定義を行うことができます。この属性グループは、両方のタイプに関する情報を示します。「結果タイプ」属性値が INCLUDE または EXCLUDE の場合、フィルターはレコードをフィルタリングするために使用されます。値が BEGIN

または END の場合、フィルターはレコードを定義するために使用されます。CPU 測定値は、オペレーティング・システムによって公開されるデータの細分度に基づく近似値です。正規表現の評価にほとんど時間がかからない場合、これは 0.00 になることがあります。CPU 時間は、正規表現の相対コストを判別し、特定の正規表現の動作を最適化するために使用する必要があります。ヒストリカル・グループ

この属性グループは、Tivoli Data Warehouse で使用するのに適格です。属性の説明

ログ・ファイル正規表現統計属性グループの各属性についての情報を、以下のリストに示します。ノード属性: この属性はキー属性です。



NODE



TIMESTAMP


表の名前属性: この属性はキー属性です。説明ログ・ファイル属性グループの名前。タイプ


TABLE_NAME または TBLNAME

属性名属性: この属性はキー属性です。説明このフィルターが適用される属性の名前。タイプ


ATTRIB_NAME または ATRNAME

フィルター番号属性説明属性に使用されているフィルターのシーケンス番号 (ゼロから開始)。タイプ

整数 (32 ビット数値プロパティー)

ウェアハウス名FILTER_NUMBER または FLTRNUM

平均プロセッサー時間属性説明この属性のフィルター処理のために使用されたプロセッサー秒数の平均。平均プロ

セッサー時間は、プロセッサー秒数の合計をフィルター回数で除算したものです。タイプ

列挙型の値を持つ小数点以下 2 桁の精度の実数 (32 ビット・ゲージ)。Tivoli

Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v N/A (-1)

v N/A (-100)


ウェアハウス名AVERAGE_PROCESSOR_TIME または CPUTAVG

合計プロセッサー時間属性説明この属性のフィルター処理のために使用されたプロセッサー秒数の合計。プロセッ

サー時間は累積的であり、切り捨てられます。丸め処理は行われません。これは、Linux の /proc/123/task/12/stat と同様です (ここで、123 はプロセスの PID であり、12 はスレッド ID です)。

タイプ列挙値の実数 (64 ビット・カウンター)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v N/A (-1)

v N/A (-100)


ウェアハウス名TOTAL_PROCESSOR_TIME または CPUTIME

最大プロセッサー時間属性


説明単一のフィルター処理のために使用された最大プロセッサー秒数。フィルターが一度も使用されなかった場合、または各フィルター処理の所要時間が 100 分の 1 秒未満であった場合、最大値がゼロになることがあります。

タイプ列挙型の値を持つ小数点以下 2 桁の精度の実数 (32 ビット・ゲージ)。Tivoli


v N/A (-100)


ウェアハウス名MAX_PROCESSOR_TIME または CPUTMAX

最小プロセッサー時間属性説明単一のフィルター処理のために使用された最小プロセッサー秒数。いずれかのフィ

ルター処理の所要時間が 100 分の 1 未満であった場合、最小値がゼロになることがあります。

タイプ列挙型の値を持つ小数点以下 2 桁の精度の実数 (32 ビット・ゲージ)。Tivoli


v N/A (-100)


ウェアハウス名MIN_PROCESSOR_TIME または CPUTMIN

フィルター回数属性説明フィルターが呼び出された回数。合計プロセッサー時間とともに使用されて、平均

プロセッサー時間が計算されます。タイプ

整数 (64 ビット・カウンター)

ウェアハウス名FILTER_COUNT または COUNT

フィルター一致回数属性説明フィルターが呼び出され、属性が一致した回数。タイプ


ウェアハウス名FILTER_COUNT_MATCHED または COUNTMA

フィルター不一致回数属性説明フィルターが呼び出され、属性が一致しなかった回数。タイプ


ウェアハウス名FILTER_COUNT_UNMATCHED または COUNTUN

正規表現パターン属性: この属性はキー属性です。


説明突き合わせに使用した正規表現。タイプ


REGEX_PATTERN または REGXPAT

最終一致時刻属性説明フィルターが使用されて結果が一致した最後の時刻。タイプ

列挙値のタイム・スタンプ。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v N/A (0000000000000001)


ウェアハウス名LAST_MATCHED_TIME または LASTMAT

最終不一致時刻属性説明フィルターが使用されて結果が一致しなかった最後の時刻。タイプ

列挙値のタイム・スタンプ。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v N/A (0000000000000001)


ウェアハウス名LAST_UNMATCHED_TIME または LASTUMA

結果タイプ属性説明フィルターが一致した場合に属性を受け入れる場合はフィルター・タイプ

INCLUDE を、属性を拒否する場合はフィルター・タイプ EXCLUDE をそれぞれ指定します。複数行レコードのレコードの先頭または末尾を指定するには、フィルター・タイプ BEGIN または END を指定します。

タイプ列挙値の整数 (32 ビット数値プロパティー)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v 不明 (0)

v INCLUDE (1)

v EXCLUDE (2)

v BEGIN (3)

v END (4)


ウェアハウス名RESULT_TYPE または RSTTYPE


ログ・ファイル状況属性グループ「ログ・ファイル状況」属性グループには、このエージェントがモニターしているログ・ファイルの状況を反映する情報が含まれています。ヒストリカル・グループ


ログ・ファイル状況属性グループの各属性についての情報を、以下のリストに示します。ノード属性: この属性はキー属性です。



NODE



TIMESTAMP

表の名前属性: この属性はキー属性です。説明このログがモニターされている表の名前。タイプ


TABLE_NAME または TBLNAME

ファイル名属性: この属性はキー属性です。説明モニター対象ファイルの名前。行が、次回のスキャンで突き合わせるファイル・パ

ターンを表す場合、ファイル名は NULL になります。タイプ


FILE_NAME または FILNAME

正規表現パターン属性: この属性はキー属性です。説明このファイルをモニター対象として選択した正規表現パターン (存在する場合)。正

規表現にメタ文字が含まれていない場合、または、ドット・メタ文字が実際にドットに一致する場合は、正規表現は「ファイル名」属性と同じであることがあります。正規表現が、NULL 以外の「ファイル名」属性と異なる場合は、ファイル名の突き合わせに正規表現パターンが使用されました。


ウェアハウス名REGEX_PATTERN または REPATRN

ファイル・タイプ属性説明このファイルのタイプ (標準ファイルまたはパイプ)。


タイプ列挙値の整数 (32 ビット数値プロパティー)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v 不明 (0)

v REGULAR FILE (1)

v PIPE (2)


ウェアハウス名FILE_TYPE または FILTYPE

ファイル状況属性説明このファイルの現在の状況。タイプ

列挙値の整数 (32 ビット数値プロパティー)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v N/A (-1)

v OK (0)

v PERMISSION DENIED (1)

v FILE DOES NOT EXIST (2)

v PATH DOES NOT EXIST (3)

v INTERRUPTED SYSTEM CALL (4)

v I/O ERROR (5)

v NO SUCH DEVICE (6)

v BAD FILE NUMBER (9)

v OUT OF MEMORY (12)

v ACCESS DENIED (13)

v RESOURCE BUSY (16)

v NOT A DIRECTORY (20)

v IS A DIRECTORY (21)

v INVALID ARGUMENT (22)

v FILE TABLE OVERFLOW (23)

v TOO MANY OPEN FILES (24)

v TEXT FILE BUSY (26)

v FILE TOO LARGE (27)

v NO SPACE LEFT ON DEVICE (28)

v ILLEGAL SEEK ON PIPE (29)

v READ-ONLY FILE SYSTEM (30)

v TOO MANY LINKS (31)

v BROKEN PIPE (32)

v PASSWORD EXPIRED (50)

v PUBLIC KEY UNVERIFIED (51)

v PUBLIC KEY UNRECOGNIZED (52)

v NO SUPPORTED DESCR (53)

v KEY FILE ACCESS ERROR (126)



ウェアハウス名FILE_STATUS または FILSTAT

一致レコード数属性説明指定されたパターンのいずれかと一致した、このログで処理されたレコードの数。タイプ


ウェアハウス名NUM_RECORDS_MATCHED または RECMTCH

不一致レコード数属性説明指定されたどのパターンとも一致しなかった、このログで処理されたレコードの

数。タイプ

列挙値の整数 (32 ビット・カウンター)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v UNMATCH LOG NOT ENABLED (-1)


ウェアハウス名NUM_RECORDS_NOT_MATCHED または RECUNMT

処理レコード数属性説明エージェントの開始以降にこのログで処理されたレコードの数 (一致/イベントでな

いレコードを含む)。タイプ


ウェアハウス名NUM_RECORDS_PROCESSED または RECPROC

現行ファイル位置属性説明モニター対象ファイルの現行位置 (バイト)。この位置までのデータは処理されまし

たが、それ以降はまだ処理されていません。パイプには適用されません。タイプ

列挙値の整数 (64 ビット数値プロパティー)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v N/A (-1)


ウェアハウス名CURRENT_FILE_POSITION または OFFSET

現行ファイル・サイズ属性説明モニター対象ファイルの現行サイズ。パイプには適用されません。タイプ

列挙値の整数 (64 ビット・カウンター)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。


v N/A (-1)


ウェアハウス名CURRENT_FILE_SIZE または FILSIZE

最終変更時刻属性説明モニター対象ファイルの最終書き込み時刻。パイプには適用されません。タイプ

列挙値のタイム・スタンプ。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v NOT INITIALIZED (0)


ウェアハウス名LAST_MODIFICATION_TIME または LASTMOD

コード・ページ属性説明モニター対象ファイルの言語コード・ページ。タイプ


CODEPAGE または CODEPG

リモート・ホスト属性: この属性はキー属性です。説明モニター対象ファイルが存在するリモート・ホストの名前。行がローカル・ファイ

ルを表している場合、このホスト名は「N/A」になります。タイプ


REMOTE_HOST または REMHOST

関連概念:

140ページの『CPU スロットルのトラブルシューティング』モニター・エージェントの CPU スロットルで問題が発生する場合があります。


関連タスク:

119ページの『GUI を使用した RAS トレース・パラメーターの設定』Windows システムでは、グラフィカル・ユーザー・インターフェースを使用してトレース・オプションを設定できます。

LogFile イベント属性グループモニター対象ログ・ファイル内の、構成済みフォーマットと一致するイベント。ヒストリカル・グループ


次のリストには、LogFile イベント属性グループの各属性に関する情報を示します。


ノード属性: この属性はキー属性です。説明エージェントの管理対象システム名。タイプ


NODE



TIMESTAMP

クラス属性: この属性はキー属性です。説明構成済みフォーマット・ファイル (.fmt) に定義されている、ログ・ファイル・イ

ベントのクラス名。タイプ

ストリングソースこの属性のソースは、ログ・ファイル・データです。ウェアハウス名

CLASS または TECCLASS

ログ名属性: この属性はキー属性です。説明一致するレコードが検出されたログの名前。タイプ


LOGNAME

EIF イベント属性説明 EIF フォーマットでのログ・ファイル・イベントの内容。タイプ


EIFEVENT

メッセージ属性説明 EIF イベントのメッセージ・スロットの内容。タイプ


MSG

カスタム・スロット 1 属性説明 EIF イベントのユーザー定義スロット。タイプ

ストリングソースこの属性のソースは、ログ・ファイル・データです。


ウェアハウス名CUSTOMSLOT1 または CUSLOT1



CUSTOMSLOT2 または CUSLOT2

















ストリング


ソースこの属性のソースは、ログ・ファイル・データです。ウェアハウス名








発生回数属性説明このイベントが現在のフラッディング制御要約間隔で発生した回数。タイプ

列挙値の整数 (32 ビット・ゲージ)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v 値が最大値を超過 (2147483647)

v 値が最小値を超過 (-2147483648)


ソースこの属性のソースは次のように導き出されます: occurrenceCount()

ウェアハウス名OCCURRENCE_COUNT または OCOUNT

イベント・タイプ属性説明現在のイベントがフラッディング制御要約イベントであるかどうかを示すフラグ。タイプ

列挙値の整数 (32 ビット数値プロパティー)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v イベント (0)

v 要約イベント (1)


ソースこの属性のソースは次のように導き出されます: isSummaryEvent()

ウェアハウス名EVENT_TYPE または EVTYPE

カスタム整数型 1 属性説明 EIF イベントの整数型のユーザー定義スロット。


タイプ列挙値の整数 (64 ビット・ゲージ)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v 値が最大値を超過 (9223372036854775807)

v 値が最小値を超過 (-9223372036854775808)



CUSTOMINTEGER1 または CUINT1

カスタム整数型 2 属性説明 EIF イベントの整数型のユーザー定義スロット。タイプ


v 値が最小値を超過 (-9223372036854775808)






v 値が最小値を超過 (-9223372036854775808)




リモート・ホスト属性説明 ssh またはリモートを使用している場合の、イベントの発生元のリモート・ホスト

(ローカル・システムの場合はブランク)。タイプ


REMOTEHOST または REMHOST


関連資料:


LogfileProfile イベント属性グループモニター対象ログ・ファイル内の、構成済みフォーマットと一致するイベント。ヒストリカル・グループ


次のリストには、LogfileProfile イベント属性グループの各属性に関する情報を示します。ノード属性: この属性はキー属性です。



NODE



TIMESTAMP

クラス属性: この属性はキー属性です。説明構成済みフォーマット・ファイル (.fmt) に定義されている、ログ・ファイル・イ

ベントのクラス名。タイプ


CLASS または TECCLASS

ログ名属性: この属性はキー属性です。説明一致するレコードが検出されたログの名前。タイプ


LOGNAME

EIF イベント属性説明 EIF フォーマットでのログ・ファイル・イベントの内容。タイプ


EIFEVENT


メッセージ属性説明 EIF イベントのメッセージ・スロットの内容。タイプ


MSG

















ストリングソースこの属性のソースは、ログ・ファイル・データです。


ウェアハウス名CUSTOMSLOT6 または CUSLOT6













発生回数属性説明このイベントが現在のフラッディング制御要約間隔で発生した回数。タイプ


v 値が最小値を超過 (-2147483648)


ソースこの属性のソースは次のように導き出されます: occurrenceCount()

ウェアハウス名OCCURRENCE_COUNT または OCOUNT

イベント・タイプ属性説明現在のイベントがフラッディング制御要約イベントであるかどうかを示すフラグ。


タイプ列挙値の整数 (32 ビット数値プロパティー)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v イベント (0)

v 要約イベント (1)


ソースこの属性のソースは次のように導き出されます: isSummaryEvent()

ウェアハウス名EVENT_TYPE または EVTYPE



v 値が最小値を超過 (-9223372036854775808)






v 値が最小値を超過 (-9223372036854775808)






v 値が最小値を超過 (-9223372036854775808)





リモート・ホスト属性説明 ssh またはリモートを使用している場合の、イベントの発生元のリモート・ホスト

(ローカル・システムの場合はブランク)。タイプ


REMOTEHOST または REMHOST

パフォーマンス・オブジェクト状況属性グループパフォーマンス・オブジェクト状況属性グループには、他の属性グループの状況を反映する情報が含まれているため、このグループでは、このアプリケーションを構成する全パフォーマンス・オブジェクトの状況を一度に確認できます。他のパフォーマンス属性グループはそれぞれ、この表 (または他のタイプのビュー)

内の各行で表されます。属性グループの状況には、その属性グループについてデータを収集した最新の試行結果が反映されているため、エージェントが正常に動作しているかどうかを確認できます。その他の属性グループとは異なり、「パフォーマンス・オブジェクトの状況」属性グループはモニター対象アプリケーションの状態を反映していません。この属性グループは、通常、パフォーマンス属性グループのいずれかでデータを利用できない場合にその理由を判別するために使用します。ヒストリカル・グループ


パフォーマンス・オブジェクト状況属性グループの各属性についての情報を、以下のリストに示します。ノード属性: この属性はキー属性です。



NODE



TIMESTAMP

照会名属性: この属性はキー属性です。説明属性グループの名前。タイプ


QUERY_NAME または ATTRGRP

オブジェクト名属性説明パフォーマンス・オブジェクトの名前。



ウェアハウス名OBJECT_NAME または OBJNAME

オブジェクト・タイプ属性説明パフォーマンス・オブジェクトのタイプ。タイプ

列挙値の整数。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v WMI (0)

v パフォーマンス・モニター (1)

v WMI 関連グループ (2)

v JMX (3)

v SNMP (4)

v シェル・コマンド (5)

v 結合されたグループ (6)

v CIMOM (7)

v カスタム (8)

v ロールアップ・データ (9)

v WMI リモート・データ (10)

v ログ・ファイル (11)

v JDBC (12)

v 構成ディスカバリー (13)

v NT イベント・ログ (14)

v フィルター (15)

v SNMP イベント (16)

v PING (17)

v ディレクター・データ (18)

v ディレクター・イベント (19)

v SSH リモート・シェル・コマンド (20)


ウェアハウス名OBJECT_TYPE または OBJTYPE

オブジェクト状況属性説明パフォーマンス・オブジェクトの状況。タイプ

列挙値の整数。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v アクティブ (0)

v 非アクティブ (1)


ウェアハウス名OBJECT_STATUS または OBJSTTS

エラー・コード属性説明照会に関連付けられているエラー・コード。


タイプ列挙値の整数。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v エラーなし (0)

v 一般エラー (1)

v オブジェクトが見つかりません (2)

v カウンターが見つかりません (3)

v 名前空間エラー (4)

v オブジェクトは現在使用不可です (5)

v COM ライブラリー初期化障害 (6)

v セキュリティー初期化障害 (7)

v プロキシー・セキュリティー障害 (9)

v 返されるインスタンスはありません (10)

v アソシエーター照会は失敗しました (11)

v 参照照会は失敗しました (12)

v 応答が受け取られていません (13)

v 結合照会が見つかりません (14)

v 照会 1 の結果に結合属性が見つかりません (15)


v 照会 1 は Singleton ではありません (17)


v 照会 1 で返されるインスタンスはありません (19)


v ロールアップ照会が見つかりません (21)

v ロールアップ属性が見つかりません (22)

v ファイルがオフラインです (23)

v ホスト名がありません (24)

v ライブラリーが欠落しています (25)

v 属性カウントが不一致です (26)

v 属性名が不一致です (27)

v 共通データ・プロバイダーが開始していません (28)

v コールバック登録エラー (29)

v MDL ロード・エラー (30)

v 認証が失敗しました (31)

v ホスト名を解決できません (32)

v サブノードが使用不可です (33)

v サブノードが構成内に見つかりません (34)

v 属性エラー (35)

v CLASSPATH エラー (36)

v 接続障害 (37)

v フィルター構文エラー (38)

v ファイル名欠落 (39)

v SQL 照会エラー (40)

v SQL フィルター照会エラー (41)

v SQL データベース照会エラー (42)

v SQL データベース・フィルター照会エラー (43)

v ポートのオープンに失敗しました (44)

v アクセスが拒否されました (45)


v タイムアウト (46)

v インプリメントされていません (47)

v 誤った値を要求しました (48)

v 応答が大きすぎます (49)

v 一般的な応答エラー (50)

v スクリプトはゼロ以外を返しました (51)

v スクリプトが見つかりません (52)

v スクリプトの起動エラー (53)

v 構成ファイルが存在しません (54)

v 構成ファイルへのアクセスが拒否されました (55)

v 無効な構成ファイル (56)

v EIF の初期化に失敗しました (57)

v フォーマット・ファイルを開けません (58)

v フォーマット・ファイル構文エラー (59)

v リモート・ホスト利用不可 (60)

v イベント・ログが存在しません (61)

v ping ファイルが存在しません (62)

v ping デバイス・ファイルがありません (63)

v ping デバイス・リスト・ファイルがありません (64)

v SNMP のパスワードが欠落しています (65)

v 使用不可 (66)

v URL ファイルが見つかりません (67)

v XML 構文解析エラー (68)

v 初期化されていません (69)

v ICMP ソケット障害 (70)

v 重複した構成ファイル (71)


ウェアハウス名ERROR_CODE または ERRCODE

最終収集開始属性説明このグループの最後のデータ収集が開始された時刻。タイプ

列挙値のタイム・スタンプ。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v 収集なし (0691231190000000)

v 収集なし (0000000000000001)


ウェアハウス名LAST_COLLECTION_START または COLSTRT

最終収集完了属性説明このグループの最後のデータ収集が終了した時刻。


タイプ列挙値のタイム・スタンプ。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v 収集なし (0691231190000000)

v 収集なし (0000000000000001)


ウェアハウス名LAST_COLLECTION_FINISHED または COLFINI

最終収集期間属性説明このグループのデータ収集が完了した最新の期間 (秒)。タイプ

小数点以下 2 桁の実数 (32 ビット・カウンター)

ウェアハウス名LAST_COLLECTION_DURATION または COLDURA

平均収集期間属性説明このグループのすべてのデータ収集の平均期間 (秒)。タイプ

列挙型の値を持つ、小数点以下 2 桁の精度の実数 (32 ビット・カウンター)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-100)


ウェアハウス名AVERAGE_COLLECTION_DURATION または COLAVGD

最新表示間隔属性説明このグループが最新表示される間隔 (秒)。タイプ


ウェアハウス名REFRESH_INTERVAL または REFRINT

収集の数属性説明エージェントの開始以降にこのグループが収集された回数。タイプ


ウェアハウス名NUMBER_OF_COLLECTIONS または NUMCOLL

キャッシュ・ヒット属性説明このグループの外部データ要求がキャッシュから満たされた回数。タイプ


ウェアハウス名CACHE_HITS または CACHEHT

キャッシュで未検出属性説明このグループの外部データ要求がキャッシュで使用できなかった回数。


タイプ整数 (32 ビット・カウンター)

ウェアハウス名CACHE_MISSES または CACHEMS

キャッシュ・ヒット率属性説明このグループの外部データ要求がキャッシュから満たされた比率。タイプ


ウェアハウス名CACHE_HIT_PERCENT または CACHPCT

スキップされた間隔属性説明次の収集の開始予定時刻に前の収集がまだ実行中だったため、このグループのバッ

クグラウンド・データ収集がスキップされた回数。タイプ


ウェアハウス名INTERVALS_SKIPPED または INTSKIP

pro パフォーマンス・オブジェクト状況属性グループパフォーマンス・オブジェクト状況属性グループには、他の属性グループの状況を反映する情報が含まれているため、このグループでは、このアプリケーションを構成する全パフォーマンス・オブジェクトの状況を一度に確認できます。他のパフォーマンス属性グループはそれぞれ、この表 (または他のタイプのビュー)

内の各行で表されます。属性グループの状況には、その属性グループについてデータを収集した最新の試行結果が反映されているため、エージェントが正常に動作しているかどうかを確認できます。その他の属性グループとは異なり、「パフォーマンス・オブジェクトの状況」属性グループはモニター対象アプリケーションの状態を反映していません。この属性グループは、通常、パフォーマンス属性グループのいずれかでデータを利用できない場合にその理由を判別するために使用します。ヒストリカル・グループ


pro パフォーマンス・オブジェクト状況属性グループの各属性についての情報を、以下のリストに示します。ノード属性: この属性はキー属性です。



NODE



TIMESTAMP

照会名属性: この属性はキー属性です。説明属性グループの名前。



ウェアハウス名QUERY_NAME または ATTRGRP

オブジェクト名属性説明パフォーマンス・オブジェクトの名前。タイプ


OBJECT_NAME または OBJNAME

オブジェクト・タイプ属性説明パフォーマンス・オブジェクトのタイプ。タイプ

列挙値の整数。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v WMI (0)

v パフォーマンス・モニター (1)

v WMI 関連グループ (2)

v JMX (3)

v SNMP (4)

v シェル・コマンド (5)

v 結合されたグループ (6)

v CIMOM (7)

v カスタム (8)

v ロールアップ・データ (9)

v WMI リモート・データ (10)

v ログ・ファイル (11)

v JDBC (12)

v 構成ディスカバリー (13)

v NT イベント・ログ (14)

v フィルター (15)

v SNMP イベント (16)

v PING (17)

v ディレクター・データ (18)

v ディレクター・イベント (19)

v SSH リモート・シェル・コマンド (20)


ウェアハウス名OBJECT_TYPE または OBJTYPE

オブジェクト状況属性説明パフォーマンス・オブジェクトの状況。タイプ

列挙値の整数。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v アクティブ (0)

v 非アクティブ (1)



ウェアハウス名OBJECT_STATUS または OBJSTTS

エラー・コード属性説明照会に関連付けられているエラー・コード。タイプ

列挙値の整数。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v エラーなし (0)

v 一般エラー (1)

v オブジェクトが見つかりません (2)

v カウンターが見つかりません (3)

v 名前空間エラー (4)

v オブジェクトは現在使用不可です (5)

v COM ライブラリー初期化障害 (6)

v セキュリティー初期化障害 (7)

v プロキシー・セキュリティー障害 (9)

v 返されるインスタンスはありません (10)

v アソシエーター照会は失敗しました (11)

v 参照照会は失敗しました (12)

v 応答が受け取られていません (13)

v 結合照会が見つかりません (14)







v ロールアップ照会が見つかりません (21)

v ロールアップ属性が見つかりません (22)

v ファイルがオフラインです (23)

v ホスト名がありません (24)

v ライブラリーが欠落しています (25)

v 属性カウントが不一致です (26)

v 属性名が不一致です (27)

v 共通データ・プロバイダーが開始していません (28)

v コールバック登録エラー (29)

v MDL ロード・エラー (30)

v 認証が失敗しました (31)

v ホスト名を解決できません (32)

v サブノードが使用不可です (33)

v サブノードが構成内に見つかりません (34)

v 属性エラー (35)

v CLASSPATH エラー (36)

v 接続障害 (37)

v フィルター構文エラー (38)

v ファイル名欠落 (39)


v SQL 照会エラー (40)

v SQL フィルター照会エラー (41)

v SQL データベース照会エラー (42)

v SQL データベース・フィルター照会エラー (43)

v ポートのオープンに失敗しました (44)

v アクセスが拒否されました (45)

v タイムアウト (46)

v インプリメントされていません (47)

v 誤った値を要求しました (48)

v 応答が大きすぎます (49)

v 一般的な応答エラー (50)

v スクリプトはゼロ以外を返しました (51)

v スクリプトが見つかりません (52)

v スクリプトの起動エラー (53)

v 構成ファイルが存在しません (54)

v 構成ファイルへのアクセスが拒否されました (55)

v 無効な構成ファイル (56)

v EIF の初期化に失敗しました (57)

v フォーマット・ファイルを開けません (58)

v フォーマット・ファイル構文エラー (59)

v リモート・ホスト利用不可 (60)

v イベント・ログが存在しません (61)

v ping ファイルが存在しません (62)

v ping デバイス・ファイルがありません (63)

v ping デバイス・リスト・ファイルがありません (64)

v SNMP のパスワードが欠落しています (65)

v 使用不可 (66)

v URL ファイルが見つかりません (67)

v XML 構文解析エラー (68)

v 初期化されていません (69)

v ICMP ソケット障害 (70)

v 重複した構成ファイル (71)


ウェアハウス名ERROR_CODE または ERRCODE

最終収集開始属性説明このグループの最後のデータ収集が開始された時刻。タイプ


v 収集なし (0000000000000001)



ウェアハウス名LAST_COLLECTION_START または COLSTRT

最終収集完了属性説明このグループの最後のデータ収集が終了した時刻。タイプ


v 収集なし (0000000000000001)


ウェアハウス名LAST_COLLECTION_FINISHED または COLFINI

最終収集期間属性説明このグループのデータ収集が完了した最新の期間 (秒)。タイプ


ウェアハウス名LAST_COLLECTION_DURATION または COLDURA

平均収集期間属性説明このグループのすべてのデータ収集の平均期間 (秒)。タイプ

列挙型の値を持つ、小数点以下 2 桁の精度の実数 (32 ビット・カウンター)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-100)


ウェアハウス名AVERAGE_COLLECTION_DURATION または COLAVGD

最新表示間隔属性説明このグループが最新表示される間隔 (秒)。タイプ


ウェアハウス名REFRESH_INTERVAL または REFRINT

収集の数属性説明エージェントの開始以降にこのグループが収集された回数。タイプ


ウェアハウス名NUMBER_OF_COLLECTIONS または NUMCOLL

キャッシュ・ヒット属性説明このグループの外部データ要求がキャッシュから満たされた回数。タイプ



ウェアハウス名CACHE_HITS または CACHEHT

キャッシュで未検出属性説明このグループの外部データ要求がキャッシュで使用できなかった回数。タイプ


ウェアハウス名CACHE_MISSES または CACHEMS

キャッシュ・ヒット率属性説明このグループの外部データ要求がキャッシュから満たされた比率。タイプ


ウェアハウス名CACHE_HIT_PERCENT または CACHPCT

スキップされた間隔属性説明次の収集の開始予定時刻に前の収集がまだ実行中だったため、このグループのバッ

クグラウンド・データ収集がスキップされた回数。タイプ


ウェアハウス名INTERVALS_SKIPPED または INTSKIP

スレッド・プールの状況属性グループスレッド・プールの状況属性グループには、データを非同期に収集するために使用する内部スレッド・プールの状況を反映した情報が含まれています。ヒストリカル・グループ


スレッド・プールの状況属性グループの各属性についての情報を、以下のリストに示します。ノード属性: この属性はキー属性です。



NODE



TIMESTAMP

スレッド・プール・サイズ属性説明現在スレッド・プール内に存在するスレッドの数。


タイプ列挙値の整数 (32 ビット・ゲージ)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-1)

v データなし (-100)


ウェアハウス名THREAD_POOL_SIZE または THPSIZE

スレッド・プール最大サイズ属性説明スレッド・プール内に存在することが許可されているスレッドの最大数。タイプ

列挙値の整数 (32 ビット数値プロパティー)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-1)



ウェアハウス名THREAD_POOL_MAX_SIZE または TPMAXSZ

スレッド・プールのアクティブ・スレッド属性説明現在作業を実行しているアクティブなスレッド・プール内のスレッドの数。タイプ

列挙値の整数 (32 ビット・ゲージ)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-1)



ウェアハウス名THREAD_POOL_ACTIVE_THREADS または TPACTTH

スレッド・プールの平均アクティブ・スレッド属性説明同時に作業を実行しているアクティブなスレッド・プール内のスレッドの平均数。タイプ


Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-1)



ウェアハウス名THREAD_POOL_AVG_ACTIVE_THREADS または TPAVGAT

スレッド・プールの最小アクティブ・スレッド属性


説明スレッド・プール内で同時に作業を実行していたアクティブなスレッドの最小数。タイプ

列挙値の整数 (32 ビット・カウンター)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-1)



ウェアハウス名THREAD_POOL_MIN_ACTIVE_THREADS または TPMINAT

スレッド・プールの最大アクティブ・スレッド属性説明スレッド・プール内で同時に作業を実行していたアクティブなスレッドのピーク

数。タイプ




ウェアハウス名THREAD_POOL_MAX_ACTIVE_THREADS または TPMAXAT

スレッド・プール・キューの長さ属性説明現在スレッド・プール・キューで待機しているジョブの数。タイプ

列挙値の整数 (32 ビット・ゲージ)。Tivoli Enterprise Portal ではストリングが表示されます。ウェアハウスおよび照会は、括弧内に示された値を戻します。次の値が定義されています。v データなし (-1)



ウェアハウス名THREAD_POOL_QUEUE_LENGTH または TPQLGTH

スレッド・プール・キューの平均の長さ属性説明この実行中のスレッド・プール・キューの平均の長さ。タイプ






ウェアハウス名THREAD_POOL_AVG_QUEUE_LENGTH または TPAVGQL

スレッド・プール・キューの最小の長さ属性説明スレッド・プール・キューが到達した最小の長さ。タイプ




ウェアハウス名THREAD_POOL_MIN_QUEUE_LENGTH または TPMINQL

スレッド・プール・キューの最大の長さ属性説明スレッド・プール・キューが到達したピークの長さ。タイプ




ウェアハウス名THREAD_POOL_MAX_QUEUE_LENGTH または TPMAXQL

スレッド・プールの平均ジョブ待機属性説明ジョブがスレッド・プール・キューで待機するのに費やす平均時間 (秒)。タイプ





ウェアハウス名THREAD_POOL_AVG_JOB_WAIT または TPAVJBW

スレッド・プール合計ジョブ属性説明エージェントの開始以降、プール内のすべてのスレッドが実行したジョブの数。タイプ





ウェアハウス名THREAD_POOL_TOTAL_JOBS または TPTJOBS

ヒストリカル・データのディスク・キャパシティー・プランニングモニター・エージェントのディスク・キャパシティー・プランニングとは、ヒストリカル・データを収集する属性グループごとにヒストリカル・データで使用されるディスク・スペースの量を予測することです。必要なディスク・ストレージは、ヒストリカル・データ収集のデータ収集ルールおよび方針を規定する際の重要な要因です。

「ヒストリカル・データのキャパシティー・プランニング」表は、このモニター・エージェントのディスク・スペースを計算するのに必要な、以下の情報を提供します。

表表は、ウェアハウスに書き込まれるように属性グループが構成されている場合の、ウェアハウス・データベース内で表示される名前です。ここに示される表名は、 67ページの『モニター・エージェントの属性グループ』の表名に対応しています。

属性グループウェアハウス・データベース内に表を作成するときに使用された属性グループの名前 (ただし、この名前が、ウェアハウスに使用されているデータベースの表名の制限文字数に収まる場合)。ここにリストされる属性グループ名は、 67ページの『モニター・エージェントの属性グループ』のウェアハウスの表名に対応します。

行当たりのバイト数 (エージェント)ヒストリカル・データ収集用にエージェント・ディスクに書き込まれる各行または各インスタンスのレコード長の見積もり。この見積もりは、エージェント・ディスク・スペースを計画する目的で使用できます。

データベースの行当たりのバイト数 (ウェアハウス)ウェアハウスに書き込まれるように属性グループが構成されている場合に、ウェアハウス・データベースに書き込まれる詳細レコードのレコード長の見積もり。詳細レコードとは、長期ヒストリカル・データ収集のためにエージェントからアップロードされたレコードです。この見積もりは、ウェアハウス・ディスク・スペースを計画する目的で使用できます。

集約の行当たりのバイト数 (ウェアハウス)ウェアハウスに書き込まれるように属性グループが構成されている場合に、ウェアハウス・データベースに書き込まれる集約レコードのレコード長の見積もり。集約レコードは、要約用に構成された属性グループの要約エージェントによって作成されます。この見積もりは、ウェアハウス・ディスク・スペースを計画する目的で使用できます。

テーブルの情報に加え、収集しようとしているデータの行数もわかっていることが必要です。1 つの属性グループには、モニター対象のアプリケーション環境に応じて単一または複数のデータ行を含めることができます。例えば、デュアル・プロセッサー・コンピューターを使用していて、属性グループがコンピューター内の各プロセッサーをモニターする場合、行数は 2 になります。


表 4. Log File Agent によってログに記録されるヒストリカル・データのキャパシティー・プランニング

表属性グループ

行当たりのバイト数 (エージェント)

データベースの行当たりのバイト数 (ウェアハウス)

集約の行当たりのバイト数 (ウェアハウス)

KLOLFAPFLS KLO LFA プロファイル 2245 2256 2293

KLOLOGEVTS KLO ログ・ファイル・イベント 6892 6955 7160

KLOLOGPEVT KLO LogfileProfile イベント 6892 6955 7160

KLOLOGFRX KLO ログ・ファイル正規表現統計 798 856 1178

KLOLOGFST KLO ログ・ファイル状況 688 704 813

KLOPOBJST KLO パフォーマンス・オブジェクト状況 352 399 664

KLOPROPOS KLO PRO パフォーマンス・オブジェクト状況 352 399 664

KLOTHPLST KLO スレッド・プールの状況 124 168 550

ヒストリカル・データ収集の詳細については、「IBM Tivoli Monitoring 管理者ガイド」の『ヒストリカル・データの管理』を参照してください。



第 8 章シチュエーション・リファレンス

シチュエーションとは、1 つ以上のシステム状態に関する論理式です。ネットワーク内のシステムの状態をモニターするときにシチュエーションを使用します。シチュエーションの管理は、Tivoli Enterprise Portal

からシチュエーション・エディターを使用して行うことも、コマンド行インターフェースからシチュエーションに関する tacmd コマンドを使用して行うこともできます。プライベート構成 XML ファイルを使用して、プライベート・シチュエーションを管理することができます。

シチュエーションについて

システム環境をモニターするために使用するモニター・エージェントには、現状のまま使用できる一連の事前定義シチュエーションが付属しています。各自の要件に合わせて新規シチュエーションを作成することもできます。

事前定義されたシチュエーションには、多くのエンタープライズに共通するシステム条件を確認する属性が含まれています。事前定義シチュエーションを使用すると、Tivoli Log File Agent の使用を開始するまでの期間が短くなります。事前定義シチュエーションがモニターしている条件または値を、エンタープライズに最適な条件または値に変更できます。

シチュエーション・エディターでは、事前定義シチュエーションを表示し、各自のシチュエーションを作成できます。シチュエーション・エディターには、選択したナビゲーター項目に関連するシチュエーションが最初にリストされます。シチュエーション名をクリックするかシチュエーションを作成すると、次のタブを持つパネルが開きます。

式テストされる条件を記述した式。

配布シチュエーションを配布できる管理対象システム (オペレーティング・システム、サブシステム、またはアプリケーション) のリスト。すべての Log File Agent の管理対象システムがデフォルトで割り当てられています。

エキスパート・アドバイスイベント・ワークスペースに表示されるコメントと指示。

アクションシステムに送信されるコマンド。

EIF Event Integration Facility 受信側へのイベントの転送をカスタマイズします。(Tivoli Enterprise

Monitoring Server がイベントを転送するように構成されている場合に使用可能。)

期限一定期間の経過後、または別のシチュエーションが true になった場合にイベントを閉じるオプション

シチュエーションに関する追加情報

事前定義シチュエーションとカスタム・シチュエーションについて、およびそれらのシチュエーションを使用してアラートに対応する方法について詳しくは、「Tivoli Enterprise Portal ユーザーズ・ガイド」を参照してください。

このモニター・エージェント用の事前定義シチュエーションのリストおよび個別の各シチュエーションに関する情報については、 104ページの『事前定義シチュエーション』を参照してください。


事前定義シチュエーションモニター・エージェントには、事前定義シチュエーションが含まれています。

v パフォーマンス・オブジェクトの状況

– - KLO_Log_Agent_Config_Error

v pro パフォーマンス・オブジェクト状況

– - KLO_Log_Agent_Config_Error

シチュエーションの説明各シチュエーションの説明では、ネットワーク内のシステムの状態をモニターするために使用できる、シチュエーションに関する情報が提供されます。

シチュエーションの説明では以下の情報が提供されます。

説明シチュエーションがテストする条件に関する情報。

式シチュエーションがモニターする条件を記述した、1 つ以上の論理式を含む構文

配布シチュエーションがエージェントのインスタンスへ自動的に配布されるか、または手動配布できるかのいずれか。

開始時に実行エージェントが開始したときにシチュエーションがモニタリングを開始するかどうか。

サンプリング間隔モニター・エージェントがサーバーのデータのサンプルを 1 回収集してから、次のサンプルを収集するまでの間に経過する秒数。

シチュエーションの永続性シチュエーションが発生する前に、シチュエーションに指定された条件が、ここで定義される出現回数にわたって連続して「true」と評価されるまで待つかどうか。デフォルトの 1 は、永続性の検査が実施されないことを意味します。

重大度定義済みイベントの重大度 (警告、通知、またはクリティカル)。

消去条件true シチュエーションがクローズされる条件を制御します。条件は、一定時間の経過後、または別のシチュエーションが true になった場合で、両方が選択されると、先にどちらか一方が発生した場合になります。

KLO_Log_Agent_Config_Error シチュエーションこのシチュエーションは、パフォーマンス・オブジェクト状況属性グループからのデータを使用します。

KLO_Log_Agent_Config_Error シチュエーション

説明エージェントは正しく構成されておらず、何もモニターしていません。

シチュエーションは、ATTRGRP 属性のそれぞれ異なる値について評価されます。

式 *IF *VALUE KLO_PERFORMANCE_OBJECT_STATUS.Object_Status *EQ INACTIVE

この式の属性の説明については、 68ページの『各属性グループの属性』を参照してください。

配布このシチュエーションは、このエージェントのインスタンスに自動的に配布されます。


開始時に実行はい

サンプリング間隔1 分

シチュエーションの永続性シチュエーションが true となるために必要なシチュエーションの条件の発生回数は 2 です。

エラー条件警告

消去条件条件が false になると、シチュエーションは消去されます。

KLO_PRO_Log_Agent_Config_Error シチュエーションこのシチュエーションは、pro パフォーマンス・オブジェクト状況属性グループからのデータを使用します。

KLO_PRO_Log_Agent_Config_Error シチュエーション

説明エージェントは正しく構成されておらず、何もモニターしていません。

シチュエーションは、ATTRGRP 属性のそれぞれ異なる値について評価されます。

式 *IF *VALUE KLO_PRO_PERFORMANCE_OBJECT_STATUS.Object_Status *EQ INACTIVE

この式の属性の説明については、 68ページの『各属性グループの属性』を参照してください。

配布このシチュエーションは、このエージェントのインスタンスに自動的に配布されます。

開始時に実行はい

サンプリング間隔1 分 40 秒

シチュエーションの永続性シチュエーションが true となるために必要なシチュエーションの条件の発生回数は 2 です。

エラー条件警告

消去条件条件が false になると、シチュエーションは消去されます。

第 8 章シチュエーション・リファレンス 105


第 9 章アクション実行コマンド参照

アクション実行コマンドは、ポータル・クライアントから実行するか、またはシチュエーションやポリシーに組み込むことができます。

アクション実行コマンドについて

シチュエーションに組み込むと、シチュエーションが True になったときにコマンドが実行されます。シチュエーションのアクション実行コマンドは、リフレックス・オートメーションとも呼ばれます。シチュエーションでアクション実行コマンドを使用可能にすると、システム状態に対する応答が自動化されます。例えば、管理対象システムでプロセスを再始動するコマンドを送信したり、テキスト・メッセージを携帯電話に送信したりする場合に、アクション実行コマンドを使用できます。

拡張オートメーションでは、ポリシーを使用して、アクションの実行、作業のスケジュール、および手動タスクの自動化が行われます。ポリシーは、アクティビティーと呼ばれる一連の自動化ステップで構成されており、これらの各アクティビティーが相互に結びついてワークフローを形成しています。アクティビティーが完了すると、Tivoli Enterprise Portal は戻りコード・フィードバックを受信します。これに対応して、拡張オートメーション・ロジックがこのフィードバックに記述されている後続アクティビティーを実行します。

基本的なアクション実行コマンドでは、アクションが完了した後で表示されるメッセージ・ボックス内またはログ・ファイルに操作の戻りコードが示されます。このウィンドウを閉じると、このアクションの追加情報は入手できなくなります。

アクション実行コマンドに関する追加情報

アクション実行コマンドの操作について詳しくは、「Tivoli Enterprise Portal ユーザーズ・ガイド」の『アクション実行コマンド』を参照してください。

事前定義されているアクション実行コマンド必ずしもすべてのエージェントが事前定義されているアクション実行コマンドを備えているわけではありません。しかし、任意のエージェント用にアクション実行コマンドを作成することができます。

Tivoli Log File Agent には、事前定義のアクション実行コマンドはありません。



第 10 章ポリシーの解説

ポリシーは、単純な自動化機能で作成できるワークフロー・ストラテジーよりも複雑なワークフロー・ストラテジーを実現する、高度な自動化手法として使用されます。必ずしもすべてのエージェントが事前定義ポリシーを備えているわけではありませんが、任意のエージェント用にポリシーを作成することができます。

ポリシーは、アクションの実行、ユーザー作業のスケジュール、または手動タスクの自動化を実行できる、自動化されたシステム・プロセスの集合です。ポリシーを設計するには、ワークフロー・エディターを使用します。アクティビティーとも呼ばれる、一連の自動化されたステップをポリシーが実行する順序を制御します。複数のポリシーを接続することで、ワークフローが作成されます。アクティビティーが完了すると、Tivoli Enterprise Portal は戻りコード・フィードバックを受信します。これに対応して、拡張オートメーション・ロジックがこのフィードバックに記述されている後続アクティビティーを実行します。

ポリシーの操作について詳しくは、「Tivoli Enterprise Portal ユーザーズ・ガイド」の『ポリシーの自動化』を参照してください。

ワークフロー・エディターの使用方法については、「IBM Tivoli Monitoring 管理者ガイド」または Tivoli

Enterprise Portal オンライン・ヘルプを参照してください。

事前定義ポリシー必ずしもすべてのエージェントが事前定義ポリシーを備えているわけではありません。しかし、任意のエージェント用にポリシーを作成することができます。

Tivoli Log File Agentは、事前定義ポリシーを備えていません。



第 11 章トラブルシューティング

問題は、IBM Tivoli Monitoring、または使用している特定のエージェントに関連しています。

一般的なトラブルシューティング情報については、「IBM Tivoli Monitoring トラブルシューティング・ガイド」を参照してください。その他の問題解決オプションについては、 150ページの『サポート情報』を参照してください。

インフォメーション・センター内のエージェントの『前提条件』トピック、またはエージェントのユーザーズ・ガイドの『要件』トピックにリストされているシステム要件に、ご使用のシステムを一致させることによって、問題を解決できる場合もあります。

以下のアクティビティーを実行することにより、発生している問題の解決方法が見つかりやすくなる可能性があります。

v 『IBM ソフトウェア・サポートに提供する製品情報の収集』

v 112ページの『ロギングの使用』

v 112ページの『識別済みの問題および回避策のリストの確認』

IBM ソフトウェア・サポートに提供する製品情報の収集

この製品に関して発生している問題について IBM ソフトウェア・サポートに連絡する前に、表 5に示された情報を収集してください。

表 5. IBM ソフトウェア・サポートへの問い合わせ前に収集する情報

情報のタイプ説明

ログ・ファイル障害が起こったシステムからトレース・ログ・ファイルを収集します。ログの多くは、ホスト・コンピューターのlogs サブディレクトリー内に格納されます。すべてのトレース・ログ・ファイルとそのロケーションのリストについては、 113ページの『主要トレース・ログ・ファイル』を参照してください。

IBM Tivoli Monitoring 環境に関する一般情報については、「Tivoli Enterprise Portal ユーザーズ・ガイド」を参照してください。

アプリケーション・ログ・ファイル情報バージョン番号とパッチ・レベル

オペレーティング・システムオペレーティング・システムのバージョン番号およびパッチ・レベル

メッセージ画面に表示されるメッセージなどの情報

IBM Tivoli Monitoring のバージョン番号モニター環境の以下のメンバーのバージョン番号

v IBM Tivoli Monitoring. (該当する場合はパッチ・レベルも提供してください)。

v Tivoli Log File Agent

画面取り誤った出力の画面取り (ある場合)


表 5. IBM ソフトウェア・サポートへの問い合わせ前に収集する情報 (続き)

情報のタイプ説明

(UNIX システムのみ) コア・ダンプ・ファイル UNIX システム上でシステムが停止した場合は、install_dir/bin ディレクトリーからコア・ダンプ・ファイルを収集してください。ここで、install_dir はモニター・エージェントをインストールしたディレクトリーです。

pdcollect ツールを使用して、最も頻繁に使用される情報をシステムから収集できます。このツールは、ログ・ファイル、構成情報、バージョン情報などのデータを収集します。このツールの使用に関する詳細については、「IBM Tivoli Monitoring トラブルシューティング・ガイド」の『pdcollect ツール』を参照してください。

IBM ソフトウェア・サポートの利用方法については、IBM サポート・ポータルのサービス・リクエスト(SR) & PMR (http://www.ibm.com/support/entry/portal/Open_service_request/Software/Software_support_

(general))を参照してください。

ロギングの使用

ロギングは、Log File Agent の基本的なトラブルシューティング機能です。ロギングとは、Log File

Agent によって生成されたテキスト・メッセージおよびトレース・データを指します。メッセージおよびトレース・データはファイルに送信されます。

トレース・データは、コンポーネントまたはアプリケーションが設計どおりの動作に失敗したときに、現在の稼働環境に関する経過情報を収集します。IBM ソフトウェア・サポート担当員は、収集されたトレース情報を使用してエラーの原因や予期しない条件を判別します。詳しくは、『トレース・ロギング』を参照してください。

識別済みの問題および回避策のリストの確認

既知の問題は、見付けやすいように、次のリストに示すようにタイプ別に編成されています。

v インストールおよび構成

v 一般の使用および操作

v モニター・データの表示

v アクション実行コマンド

これらのタイプの問題の症状に関する情報および詳しい回避策は、 125ページの『問題および解決方法』に記載されています。

一般的なトラブルシューティング情報については、「IBM Tivoli Monitoring トラブルシューティング・ガイド」を参照してください。

トレース・ロギングトレース・ログは、コンポーネント・ソフトウェアが設計どおりに動作しなかった場合に、稼働環境についての情報を収集するために使用します。

最も主要なログ・タイプは、RAS (信頼性、アベイラビリティー、および保守性) トレース・ログです。これらのログは、英語のみで提供されます。RAS トレース・ログ・メカニズムは、IBM Tivoli Monitoring の


http://www.ibm.com/support/entry/portal/Open_service_request/Software/Software_support_(general)

http://www.ibm.com/support/entry/portal/Open_service_request/Software/Software_support_(general)

すべてのコンポーネントで使用可能です。ログの多くは、ホスト・コンピューターの logs サブディレクトリー内に格納されます。トレース・ロギングの構成方法および使用方法を確認するには、以下の情報を参照してください。

v 『主要トレース・ログ・ファイル』

v 118ページの『例: トレース・ログの使用』

v 119ページの『GUI を使用した RAS トレース・パラメーターの設定』

注: 本書では、IBM Tivoli Monitoring の RAS 機能を「RAS1」と呼びます。

IBM ソフトウェア・サポート担当員は、トレース・ロギングで収集された情報を使用して、問題の原因のトレースや、エラーが発生した原因の判別を行います。IBM Tivoli Monitoring 環境にあるすべてのコンポーネントには、デフォルトのトレース・レベルがあります。コンポーネントごとのレベルでトレース・レベルを変更することにより、収集するトレース情報のタイプ、トレース詳細の程度、保持するトレース・ログ数、およびトレースに使用するディスク・スペース量を調整できます。

ログ・ファイル管理の概要ログ・ファイルの命名規則を知っておくと、ファイルを見つけやすくなります。

エージェントのログ・ファイルの命名規則

114ページの表 6 は、IBM Tivoli Monitoring の一般的な RAS1 ログ・ファイルの名前、場所、および説明をまとめたものです。Log File Agentのログ・ファイル名は、以下の命名規則に従っています。

Windows システムhostname_productcode_instance-name_program_HEXtimestamp-nn.log

Linux および UNIX システムhostname_productcode_instance-name_program_HEXtimestamp-nn.log

各部分の意味は、次のとおりです。

hostname

モニター・コンポーネントが実行されているコンピューターのホスト名。

productcode

2 文字の製品コード。Tivoli Log File Agent の場合、製品コードは lo です。

instance-name

エージェントのインスタンス名。

program

実行中のプログラムの名前。

HEXtimestamp

プログラムの開始時刻を示す 16 進数タイム・スタンプ。

nn ロールするログのサフィックス。

主要トレース・ログ・ファイルトレース・ログ・ファイルは、さまざまなシステムに格納されます。

114ページの表 6 に、エージェントに関する問題のソースを判別するのに役立つトレース・ログの格納場所、ファイル名、および説明を示します。

第 11 章トラブルシューティング 113

表 6. トラブルシューティング・エージェントのトレース・ログ・ファイル

ログが置かれているシステムファイル名およびパス説明

Tivoli Enterprise Monitoring Server 上 v Windows の場合:

install_dir¥InstallITM パスのIBM Tivoli Monitoring

timestamp.log ファイル

v UNIX の場合: install_dir/logs

パスにあるcandle_installation.log ファイル

v Linux の場合: install_dir/logs

パスにあるcandle_installation.log ファイル

インストールされた製品についての詳細を提供します。注: トレース・ロギングはデフォルトで使用可能です。このトレースを使用可能にするのに構成ステップは必要ありません。

Tivoli Enterprise Monitoring Server 上 Warehouse_Configuration.log ファイルは、Windows システム上のinstall_dir¥InstallITM にあります。

ヒストリカル・レポート用データウェアハウジングの構成についての詳細を示します。

Tivoli Enterprise Monitoring Server 上 RAS ログ・ファイルの名前を以下に示します。


install_dir¥logs

¥hostname_ms_timestamp-nn.log

v UNIX の場合:

install_dir/logs/

hostname_ms_timestamp-nn.log

v Linux の場合:

install_dir/logs/

hostname_ms_timestamp-nn.log

注: RAS1 ログのファイル名には、16

進数のタイム・スタンプが含まれます。

また、UNIX システムの場合は、10

進数のタイム・スタンプが記載されたログも提供されます。ファイル名は、hostname_productcode_timestamp.log

および hostname_productcode_

timestamp.pidnnnnn で、パスはinstall_dir/logs です。nnnnn はプロセス ID 番号です。

モニター・サーバーでのアクティビティーをトレースします。


表 6. トラブルシューティング・エージェントのトレース・ログ・ファイル (続き)


Tivoli Enterprise Portal Server 上 RAS ログ・ファイルの名前を以下に示します。


install_dir¥logs¥hostname

_cq_HEXtimestamp-nn.log

v UNIX の場合: install_dir

/logs/hostname_cq_HEXtimestamp-

nn.log

v Linux の場合: install_dir

/logs/hostname_cq_HEXtimestamp-

nn.log

注: RAS1 ログのファイル名には、16

進数のタイム・スタンプが含まれます。

また、UNIX システムの場合は、10

進数のタイム・スタンプが記載されたログも提供されます。ファイル名は、hostname_productcode_timestamp.log

および hostname_productcode_

timestamp.pidnnnnn で、パスはinstall_dir/logs です。nnnnn はプロセス ID 番号です。

ポータル・サーバーでのアクティビティーをトレースします。

Tivoli Enterprise Portal Server 上 teps_odbc.log ファイルは、以下のパスにあります。


install_dir¥InstallITM



ヒストリカル・レポートを使用可能にした場合、このログ・ファイルはウェアハウス・プロキシー・エージェントの状況をトレースします。




モニター・エージェントをホストするコンピューター上

RAS1 ログ・ファイルは以下のとおりです。

v Windows の場合: hostname

_lo_instance_name_kloagent_

HEXtimestamp-nn.log

(install_dir¥tmaitm6¥logs ディレクトリー内)

v UNIX の場合:

hostname_lo_instance_name_

kloagent_

HEXtimestamp-nn.log

(install_dir/logs ディレクトリー内)

v Linux の場合:

hostname_lo_instance_name_

kloagent_

HEXtimestamp-nn.log

(install_dir/logs ディレクトリー内)

これらのログは、以下のディレクトリーにあります。


install_dir¥tmaitm6¥logs



Linux システムでは、以下のログも追加で生成されます。

– hostname_lo_timestamp.log

– install_dir/logs パスのhostname

_lo_timestamp.pidnnnnn。ここで nnnnn はプロセス ID 番号です。

モニター・エージェントのアクティビティーをトレースします。





エージェントのオペレーション・ログ・ファイルは以下のとおりです。

instance_hostnameLO.LG0 は、エージェントの始動時に作成される現行ログです。

instance_hostname_LO.LG1 は、以前のログのバックアップです。

これらのログは、使用しているオペレーティング・システムに応じて、以下のディレクトリーに保管されます。





エージェントがモニター・サーバーに接続できたかどうかを示します。エージェントの稼働中に開始/停止したシチュエーションと、その他のイベントを示します。エージェントが再始動するたびに、このファイルは新しいバージョンが生成されます。

IBM Tivoli Monitoring では、*.LG0

ファイルにタグ .LG1 が付いたバックアップ・コピーが 1 つ生成されます。直前のモニター・セッションに関する以下の詳細を確認するには、.LG1 タグを表示します。

v モニター・サーバーとの接続の状況

v 実行していたシチュエーション

v アクション実行コマンドの成功または失敗状況


アクション実行コマンドのログ・ファイルは以下のとおりです。

v host_lo_instance_

takeactioncommand.log

このログは、以下のディレクトリーにあります。





アクション実行コマンドが実行されるたびにアクティビティーをトレースします。例えば、start_command というアクション実行コマンドが実行されると、 IBM Tivoli Monitoring はstart_command.log ファイルを生成します。

変数の定義:

v timestamp は、yyyymmdd hhmm 形式のタイム・スタンプです (年 (y)、月 (m)、日 (d)、時 (h)、分 (m))。

v HEXtimestamp は、プロセスが始動した時刻を 16 進数で表したものです。

v install_dir は、IBM Tivoli Monitoring コンポーネントのインストール先のディレクトリー・パスを表します。install_dir は、モニター・システム、モニター・エージェント、またはポータルをホストするコンピューターのパスを表します。

v instance は、モニターするデータベース・インスタンスの名前を指します。

v instance_name は、エージェント・インスタンスの名前を指します。

v hostname は、IBM Tivoli Monitoring コンポーネントが実行されるコンピューターの名前を指します。

v nn は、ログが循環する循環番号を表します。この値は、デフォルトでは 1 から 5 の範囲を取ります。ただし、先頭のログには構成パラメーターが定義されているため、このログは常に保存された状態になります。

v productcode は製品コードを示します。例えば、Universal Agent は um、Windows システムは nt です。

モニター・サーバー上で保守されるトレース・ログの完全セットの詳細については、「IBM Tivoli

Monitoring インストールおよび設定ガイド」を参照してください。


例: トレース・ログの使用トレース・ログをテキスト・エディターで開くと、IBM Tivoli Monitoring 環境についてのいくつかの基本的な事実を確認できます。

IBM ソフトウェア・サポートが専門的な知識を応用してトレース・ログを分析して問題の原因を判別します。以下に、Tivoli Enterprise Monitoring Server ログの例を示します。

例 1 この抜粋は、モニター・エージェントと server1a というホスト名のモニター・サーバーとの間の接続が失敗した場合の典型的なログを示します。

(Thursday, August 11, 2005, 08:21:30-{94C}kdcl0cl.c,105,"KDCL0_ClientLookup") status=1c020006,"location server unavailable", ncs/KDC1_STC_SERVER_UNAVAILABLE(Thursday, August 11, 2005, 08:21:35-{94C}kraarreg.cpp,1157,"LookupProxy") Unable to connect tobroker at ip.pipe:: status=0, "success", ncs/KDC1_STC_OK(Thursday, August 11, 2005, 08:21:35-{94C}kraarreg.cpp,1402,"FindProxyUsingLocalLookup") Unableto find running CMS on CT_CMSLIST <IP.PIPE:#server1a>

例 2 モニター・サーバーに関するトレース・ログからの以下の抜粋は、ここで「Remote node」として識別されているエージェントの状況を示します。エージェントが実行中であるコンピューターの名前は SERVER5B です。

(42C039F9.0000-6A4:kpxreqhb.cpp,649,"HeartbeatInserter") Remote node SERVER5B:LO is ON-LINE.. . .(42C3079B.0000-6A4:kpxreqhb.cpp,644,"HeartbeatInserter") Remote node SERVER5B:LO is OFF-LINE.

上記の抜粋で、以下のキー・ポイントを確認します。

v モニター・サーバーは、サーバー名の後ろに LO 製品コードを付加して、この Tivoli Log File

Agent のインスタンスに固有の名前 (SERVER5B:LO) を作成します。この固有名を使用すると、SERVER5B 上で稼働している複数のモニター製品を区別できます。

v ログは、環境内でエージェントが開始された時点 (ON-LINE) とその後で停止された時点(OFF-LINE) を示します。

v 簡潔にするため、エージェントの実行中に生成された一連のトレース・ログ・エントリーを省略符号 (...) で表します。

v ON-LINE ログ・エントリーと OFF-LINE ログ・エントリーの間には、エージェントとモニター・サーバーの通信が確立されていました。

v ON-LINE ログ・エントリーと OFF-LINE ログ・エントリーは、トレース・ログで常時使用可能です。 119ページの『GUI を使用した RAS トレース・パラメーターの設定』で説明するすべてのトレース・レベルで、これらのエントリーが提供されます。

Windows システムでは、以下の代替方法を使用してトレース・ログを表示できます。

1. Windows の「スタート」メニューで「プログラムファイル」 > 「IBM Tivoli Monitoring」 >

「Tivoli Enterprise Monitoring Services の管理」をクリックします。「Tivoli Enterprise Monitoring

Services の管理」ウィンドウが表示されます。

2. コンポーネントを右クリックし、メニューの「拡張」 > 「トレース・ログの表示」をクリックします。例えば、Tivoli Log File Agent のトレース・ログを表示する場合は、ウィンドウ内でそのエージェントの名前を右クリックします。ビューアーを使用してリモート・ログにアクセスすることもできます。

注: ビューアーは、ログのタイム・スタンプを読みやすい形式に変換します。


RAS トレース・パラメーターモニター対象エージェントおよびモジュールの個別コンポーネントの詳細なトレースを設定することで、問題を正確に記述します。

ログのローリングについて理解し、ログ・ファイルの生成を管理するときに正しいログ・ファイルを参照できるようにするには、 113ページの『ログ・ファイル管理の概要』を参照してください。

GUI を使用した RAS トレース・パラメーターの設定Windows システムでは、グラフィカル・ユーザー・インターフェースを使用してトレース・オプションを設定できます。


Tivoli Log File Agentは RAS1 トレースを使用して、 114ページの表 6 で説明したログを生成します。デフォルトの RAS1 トレース・レベルは ERROR です。

手順1. 「Tivoli Enterprise Monitoring Services の管理」ウィンドウを開きます。

2. 「拡張」 > 「トレース・パラメーターの編集」を選択します。「Tivoli Enterprise Monitoring Server トレース・パラメーター」ウィンドウが表示されます。

3. 「RAS1 フィルターの入力 (Enter RAS1 Filters)」フィールドのプルダウン・メニューで新規のトレース設定を選択するか、または有効なストリングを入力します。

v 一般的なエラー・トレース。KBB_RAS1=ERROR

v 強力なエラー・トレース。KBB_RAS1=ERROR (UNIT:logmonitor ALL) (UNIT:kum ALL)

注: この例が示すように、単一のステートメントで複数の RAS トレース・オプションを設定できます。

4. ログ・ファイルのサイズを変更するには、ファイルあたりの最大ログ・サイズの値を変更します(LIMIT 値が変更されます)。

5. プログラムの 1 回の始動で使用するログ・ファイルの数を変更するには、セッションあたりのログ・ファイルの最大数の値を変更します (COUNT 値が変更されます)。

6. プログラムのすべての始動で使用するログ・ファイルの数を変更するには、ログ・ファイルの合計最大数の値を変更します (MAXFILES 値が変更されます)。

7. オプション: 「KDC_DEBUG 設定」メニューで「Y (はい)」をクリックすると、モニター・エージェントとモニター・サーバーの間の通信および接続の問題を診断するときに役立つ情報がログに記録されます。KDC_DEBUG 設定および最大エラー・トレース設定を行うと、大量のトレース・ロギングが生成される可能性があります。問題をトラブルシューティングしている間だけ一時的にこれらの設定を使用してください。そうしないと、ハード・ディスク・スペースをログが過剰に占有する可能性があります。

8. 「OK」をクリックします。モニター・エージェントを再始動して変更内容を有効にするように通知するメッセージが表示されます。

次のタスク

logs ディレクトリーのサイズをモニターしてください。デフォルトの動作では、コンピューターで実行されている各エージェントにつき、合計で 45 MB から 60 MB のログ・データが生成されます。例えば、モニター対象のデータベース・インスタンスごとに 45 MB から 60 MB のログ・データが生成されま


す。『手順』セクションを参照して、ログ・ファイルのファイル・サイズと数を調整する方法を確認し、ロギング・アクティビティーがディスク・スペースを過度に占有することのないようにしてください。

定期的に logs ディレクトリーから RAS1 ログ・ファイル以外のログ・ファイルを除去します。自動的に除去される RAS1 ログ・ファイルと異なり、他のログ・タイプは無限に増加します (例えば、プロセス ID

番号 (PID) を含む、 114ページの表 6 のログ)。

トラブルシューティングのための追加情報ソースとして、コレクター・トレース・ログを使用します。

注: KDC_DEBUG 設定および最大エラー・トレース設定を行うと、大量のトレース・ロギングが生成される可能性があります。問題をトラブルシューティングしている間だけ一時的にこれらの設定を使用してください。そうしないと、ハード・ディスク・スペースをログが過剰に占有する可能性があります。

関連概念:

140ページの『CPU スロットルのトラブルシューティング』モニター・エージェントの CPU スロットルで問題が発生する場合があります。

関連資料:


手動による RAS トレース・パラメーターの設定RAS1 トレース・ロギング・パラメーターは手動で編集できます。


Log File Agentは RAS1 トレースを使用して、 114ページの表 6 で説明したログを生成します。デフォルトの RAS1 トレース・レベルは ERROR です。

手順1. トレース・オプション・ファイルを開きます。

v Windows システム:

install_dir¥tmaitm6¥KLOENV_instance name

v UNIX システム:

install_dir /config/lo_instance name.config

2. KBB_RAS1= で始まる行を編集して、トレース・ロギング・プリファレンスを設定します。例えば、詳細なトレース・ロギングが必要な場合は、最大トレース・オプションを KBB_RAS1=ERROR (UNIT:klo

ALL) (UNIT:kra ALL) に設定します。

3. KBB_RAS1_LOG= で始まる行を編集して、ログ・ファイルの生成を管理します。

v MAXFILES: 特定のプログラムのすべての始動で保持するファイルの総数。この値を超えると、最も古いログ・ファイルが廃棄されます。デフォルト値は 9 です。

v LIMIT: メガバイト (MB) 単位で示した RAS1 ログ・ファイルの最大サイズ。デフォルト値は 5 です。

v IBM ソフトウェア・サポートから、以下のパラメーターを変更するよう指示がある場合があります。

– COUNT: 1 つのプログラムの始動におけるローリング・サイクルで保持するログ・ファイルの数。デフォルトは、3 です。


– PRESERVE: 1 つのプログラムの始動におけるローリング・サイクルで再使用しないファイルの数。デフォルト値は 1 です。

注: また、KBB_RAS1_LOG パラメーターでは、ログ・ファイルのディレクトリー、ログ・ファイル名、およびインベントリー制御ファイルのディレクトリーと名前を指定します。これらの値を変更しないでください。変更すると、ログ情報が失われることがあります。

4. モニター・エージェントを再始動し、変更を有効にします。

次のタスク

logs ディレクトリーのサイズをモニターしてください。デフォルトの動作では、コンピューターで実行されている各エージェントにつき、合計で 45 MB から 60 MB のログ・データが生成されます。例えば、モニター対象のデータベース・インスタンスごとに 45 MB から 60 MB のログ・データが生成されます。『手順』セクションを参照して、ログ・ファイルのファイル・サイズと数を調整する方法を確認し、ロギング・アクティビティーがディスク・スペースを過度に占有することのないようにしてください。

通常は、logs ディレクトリー内の RAS1 ログ・ファイル以外のログ・ファイルを除去します。自動的に除去される RAS1 ログ・ファイルと異なり、他のログ・タイプは無限に増加します (例えば、プロセス ID

番号 (PID) を含む、 114ページの表 6 のログ)。

トラブルシューティングのための追加情報ソースとして、コレクター・トレース・ログを使用します。

注: KDC_DEBUG 設定および最大エラー・トレース設定を行うと、大量のトレース・ロギングが生成される可能性があります。問題をトラブルシューティングしている間だけ一時的にこれらの設定を使用してください。そうしないと、ハード・ディスク・スペースをログが過剰に占有する可能性があります。

トレース設定の動的な変更Tivoli Enterprise Monitoring Server、Tivoli Enterprise Portal Server、大部分のモニター・エージェントなどの IBM Tivoli Monitoring コンポーネントのトレース設定を動的に変更することができます。それらのコンポーネントには、一部のモニター・エージェントを除き、トレース・ユーティリティーからアクセスできます。

トレース設定の動的な変更は、コンポーネントを再始動する必要がないため、最も効率的です。設定内容は即座に有効になります。この方法による変更の内容は、永続的ではありません。

注: コンポーネントが再始動されると、トレース設定が .env ファイルから再度読み取られます。これらの設定を動的に変更しても、.env ファイルの設定は変更されません。これらのトレース設定を永続的に変更するには、.env ファイル内の設定を変更します。

ras1

Tivoli Monitoring コンポーネントのトレース設定を変更するには、このコマンドを使用します。

構文は以下のとおりです。

ras1 set|list (UNIT|COMP: class_name ANY|ALL|Detail|ERROR|Flow|INPUT|Metrics|OUTPUT|STATE){(UNIT|COMP: class_name ANY|ALL|Detail|ERROR|Flow|INPUT|Metrics|OUTPUT|STATE)}

トレース設定の適用先コンポーネント・クラスは複数指定することができます。


コマンド・オプションset

パラメーターの値に応じてトレースをオンまたはオフにします。パラメーターが ANY の場合はオフにします。それ以外のパラメーターの場合は、指定されたタイプまたはレベルに基づいてトレースをオンにします。

list

デフォルトで設定されるトレースのレベルおよびタイプを表示します。

パラメーター

トレース設定の適用先コンポーネント・クラスを決定するパラメーターは以下のとおりです。

COMP: class_name

class_name によって指定されたコンポーネント・クラスの名前 (COMP:KDH など) に対するトレース設定を変更します。出力には、指定されたクラスのトレースが含められます。

UNIT: class_name

指定された class_name 値で始まる装置 (UNIT: kra など) のトレース設定を変更します。出力には、指定されたフィルター・パターンで始まる装置のトレースが含められます。

トレースのレベルおよびタイプを決定するパラメーターは以下のとおりです。

ALLコンポーネントに対して定義されたすべてのトレース・ポイントを含め、すべてのトレース・レベルを表示します。この設定では、トレースが膨大な量になる場合があるため、不要なトレースを除外するには他のパラメーターを指定してください。問題を切り分けるには ALL パラメーターを指定する必要がある場合があります。このパラメーターは、「Error Detail Flow State Input Output Metrics」を設定するのと同じことです。

ANYトレースをオフにします。

Detail各関数についての詳細情報を表示します。

list オプションと共に入力した場合、トレースには Det のタグが付きます。

ERROR内部エラー状態をログに記録します。

list オプションと共に入力した場合、トレースには ER のタグが付きます。出力にもEVERYE+EVERYU+ER のタグが付きます。

Flow各関数の入口と出口の制御フロー・データを表示します。

list オプションと共に入力した場合、トレースには Fl のタグが付きます。

INPUT各関数の入力データを表示します。

list オプションと共に入力した場合、トレースには IN のタグが付きます。

Metrics各関数についてのメトリックを表示します。

list オプションと共に入力した場合、トレースには ME のタグが付きます。


OUTPUT各関数の出力データを表示します。

list オプションと共に入力した場合、トレースには OUT のタグが付きます。

State各関数の状況を表示します。

list オプションと共に入力した場合、トレースには St のタグが付きます。

例

ras1 set (COMP:KDH ALL) (COMP:ACF1 ALL) (COMP:KDE ALL) と入力すると、トレース・ユーティリティーは、KDH、ACF1、および KDE がクラスであるすべてのファイルおよび関数のすべてのレベルのトレースをオンにします。

kbbcre1.c, 400, May 29 2007, 12:54:43, 1.1, *kbbcrn1.c, 400, May 29 2007, 12:54:42, 1.1, *kdhb1de.c, 400, May 29 2007, 12:59:34, 1.1, KDHkdh0med.c, 400, May 29 2007, 12:59:24, 1.1, KDHkdhsrej.c, 400, May 29 2007, 13:00:06, 1.5, KDHkdhb1fh.c, 400, May 29 2007, 12:59:33, 1.1, KDHkdhb1oe.c, 400, May 29 2007, 12:59:38, 1.2, KDHkdhs1ns.c, 400, May 29 2007, 13:00:08, 1.3, KDHkbbacdl.c, 400, May 29 2007, 12:54:27, 1.2, ACF1kbbaclc.c, 400, May 29 2007, 12:54:27, 1.4, ACF1kbbac1i.c, 400, May 29 2007, 12:54:28, 1.11, ACF1vkdhsfcn.c, 400, May 29 2007, 13:00:11, 1.1, KDHkdhserq.c, 400, May 29 2007, 12:59:53, 1.1, KDHkdhb1pr.c, 400, May 29 2007, 12:59:39, 1.1, KDHkdhsgnh.c, 400, May 29 2007, 12:59:49, 1.1, KDHkdh0uts.c, 400, May 29 2007, 12:59:23, 1.1, KDHkdhsrsp.c, 400, May 29 2007, 13:00:13, 1.2, KDHkdhs1rp.c, 400, May 29 2007, 13:00:12, 1.1, KDHkdhscsv.c, 400, May 29 2007, 12:59:58, 1.9, KDHkdebbac.c, 400, May 29 2007, 12:56:50, 1.10, KDE...

トレースのオンへの切り替えトレース・ユーティリティーを使用するには、コンピューターのローカル・ログオン資格情報を使用する必要があります。このトレース方式は、IBM Tivoli Monitoring サービス・コンソールを使用します。このサービス・コンソールには、Web ブラウザーを使用してアクセスします。


サービス・コンソールを開始すると、現在そのコンピューターで実行されているコンポーネントについての情報が表示されます。例えば、当該コンポーネントが以下のようにリストされます。

v Tivoli Enterprise Portal Server: cnp

v Monitoring Agent for Windows OS: nt

v Tivoli Enterprise Monitoring Server: ms

ログオンした後は、疑問符 (?) を入力すると、サポートされるコマンドのリストが表示されます。トレース設定を変更するには、ras1 コマンドを使用します。サービス・コンソール・ウィンドウに表示されるフィールドにこのコマンドを入力して、「実行 (Submit)」をクリックすると、このコマンドのヘルプが表示されます。


手順1. Web ブラウザーを開いて URL を入力し、サービス・コンソールにアクセスします。

http://hostname:1920

ここで hostname は、IBM Tivoli Monitoring コンポーネントが実行されているコンピューターの IP アドレスまたはホスト名です。

2. トレース設定を変更するコンポーネントに関連したハイパーリンクをクリックします。

注: 前のビューで Tivoli Enterprise Monitoring Server のトレースを変更する場合は、「サービス・ポイント: system.your host name_ms」の下にある「IBM Tivoli Monitoring Service Console」を選択します。

3. ユーザー ID およびパスワードを入力してシステムにアクセスします。この ID は、システムへのアクセス権を持つ有効なユーザーであれば、どのユーザーでもかまいません。

4. 指定されたコンポーネント・クラスまたは装置について目的のトレース・レベルをオンにするコマンドを入力します。

ras1 set (UNIT|COMP: class_name ALL|Flow|ERROR|Detail|INPUT|Metrics|OUTPUT|STATE){(UNIT|COMP: class_name ALL|Flow|ERROR|Detail|INPUT|Metrics|OUTPUT|STATE)}

例えば、KDE の制御フロー・トレースをオンにするコマンドは以下のとおりです。

ras1 (COMP:KDE Flow)

トレースのオフへの切り替えIBM Tivoli Monitoring サービス・コンソールを使用して ras1 コマンドを実行したり動的にトレースをオフにしたりすることができます。

手順1. Web ブラウザーを開いて URL を入力し、サービス・コンソールにアクセスします。

http://hostname:1920

ここで hostname は、IBM Tivoli Monitoring コンポーネントが実行されているコンピューターの IP アドレスまたはホスト名です。

2. トレース設定を変更するコンポーネントに関連したハイパーリンクをクリックします。

3. ユーザー ID およびパスワードを入力してシステムにアクセスします。この ID は、システムへのアクセス権を持つ有効なユーザーであれば、どのユーザーでもかまいません。

4. 指定されたコンポーネント・クラスまたは装置について目的のトレース・レベルをオフにするコマンドを入力します。

ras1 set (UNIT|COMP: class_name ANY){(UNIT|COMP: class_name ANY)}

例えば、Windows OS エージェントの kbbcrcd クラスのトレースをオフにするには、以下のコマンドを使用します。

ras1 set (UNIT:kbbcrcd ANY)

Tivoli Enterprise Console サーバーのトレース・パラメーターの設定IBM Tivoli Monitoring によって取り込まれたトレース情報のほかに、イベント・サーバー・メトリックを収集する Tivoli Enterprise Console コンポーネントのトレース情報を追加収集することもできます。



この情報を収集するには、Tivoli Enterprise Console イベント・サーバーの .tec_diag_config ファイルを変更します。イベント・サーバー・トレース・パラメーターを変更するには、以下の手順を実行します。

手順1. ASCII エディターで $BINDIR/TME/TEC/.tec_diag_config ファイルを開きます。

2. イベント・サーバー上のエージェント・コンポーネントのトレース・ロギングを構成するエントリーを見つけます。tec_reception のエントリーと tec_rule のエントリーの 2 つがあります。

# to debug Agent Utilstec_reception Agent_Utils error /tmp/tec_receptionSP# to debug Agent Utilstec_rule Agent_Utils error /tmp/tec_rule

3. 追加のトレース情報を収集するには、これらのエントリーを変更して、trace2 のトレース・レベルを指定します。

# to debug Agent Utilstec_reception Agent_Utils trace2 /tmp/tec_receptionSP# to debug Agent Utilstec_rule Agent_Utils trace2 /tmp/tec_rule

4. さらに、tec_rule と tec_reception の Highest_level エントリーを以下のように変更します。

tec_reception Highest_level trace2SPtec_rule Highest_level trace2

問題および解決方法既知の問題および解決方法は、Log File Agent で発生する可能性がある問題の種類 (インストールと構成の問題、ワークスペースの問題など) に応じて分類されています。

注: 7ページの『第 2 章エージェントをインストールおよび構成するための要件』にリストされているシステム要件と、ご使用のシステムが一致するようにすることで、問題が解決することもあります。

一般的なトラブルシューティング情報については、「IBM Tivoli Monitoring トラブルシューティング・ガイド」を参照してください。

インストールおよび構成のトラブルシューティングエージェントのインストール、構成、およびアンインストール中に問題が発生する場合があります。

126ページの表 7 に、エージェントのインストール、構成、およびアンインストール中に発生する可能性がある問題と、その解決方法を示します。


表 7. インストールおよび構成の問題と解決方法

問題解決方法

(UNIX のみ ) コマンド行インストール中に、現在インストールされているコンポーネントをインストールすることを選択すると、「警告 - 同じバージョンの"component_name" をインストールしようとしています」という警告が表示される (component_name は、インストールしようとしているコンポーネントの名前)。注: この問題は、UNIX でのコマンド行インストールに影響します。 Windows 環境のみをモニターしている場合、製品コンポーネント (例えばモニター・サーバー) をUNIX システムにインストールするよう選択すると、この問題が発生します。

インストール・プロセスを終了して再始動する必要があります。インストールするコンポーネントを選択したリストに戻ることはできません。インストーラーを再実行するときには、インストール済みのコンポーネントはインストールしないでください。

製品のブラウズ設定に関する問題の診断 (Windows システムのみ)。

ブラウズ設定に問題がある場合、次のステップを実行してください。

1. 「スタート」 > 「プログラム」 > 「IBM Tivoli

Monitoring」 > 「Tivoli Enterprise Monitoring

Services の管理」をクリックします。「Tivoli

Enterprise Monitoring Services の管理」ウィンドウが表示されます。

2. Windows エージェントを右クリックして、「設定のブラウズ (Browse Settings)」を選択します。テキスト・ウィンドウが表示されます。

3. 「別名保存」をクリックして、テキスト・ファイルに情報を保存します。

要求があった場合に、分析用にこのファイルを IBM ソフトウェア・サポートに転送します。

ログ・ファイルに「CT_CMSLIST に実行中の CMS が見つかりません」のようなメッセージが表示される。

ログ・ファイルに「CT_CMSLIST で実行中の CMS を検出できません」のようなメッセージが表示されている場合、エージェントはモニター・サーバーに接続できていません。次の点を確認してください。

v 複数のネットワーク・インターフェース・カード (NIC)

がシステム上に存在していますか。

v システムに複数の NIC が搭載されている場合は、モニター・サーバー用に構成されている NIC を特定します。IBM Tivoli Monitoring 環境で通信するための正しいホスト名およびポート設定が指定されていることを確認します。


表 7. インストールおよび構成の問題と解決方法 (続き)

問題解決方法

システムでの CPU 使用率が高い。

エージェント使用中の CPU 使用率が高い場合、以下の 1

つ以上の問題が発生している可能性があります。

v モニター対象のログ・ファイルに書き込まれるデータの量が多いため、多くの処理が必要であり、イベントが集中的に発生する可能性があります。

v フォーマット・ファイルの正規表現の順序が不適切です。フォーマット・ファイルは、最初から最後の順に処理されます。一致するものを検索するためにレコードをほとんどすべての正規表現と比較する必要がある場合、CPU 使用率が影響を受けます。

v 計算に長い時間がかかる正規表現を使用しています。

エージェントの使用中に CPU 使用率が高くなる問題を軽減するには、以下のようにします。

v 効率的な正規表現を作成するためのベスト・プラクティスに従ってください

v ほとんどのレコードに一致する可能性がある正規表現は、できるだけフォーマット・ファイルの末尾から遠い位置に記述してください。

v フォーマット・ファイルの末尾に *DISCARD* ステートメントを記述して、不要なレコードを破棄してください。

v EIF イベントを送信する場合は、集中的に発生したイベントを格納できるだけの十分な EIF キャッシュを確保してください。

v 複数行レコードの使用を最小限に抑えてください。

エージェント・プロセス: KLOCMA プロセスのメモリー使用量を表示します。CPU 使用率が過大である可能性がある場合は、モニター・エージェントを再始動してください。

ネットワーク・カード: ネットワーク・カードの構成により、システムのパフォーマンスが低下することがあります。パケットの各ストリームがブロードキャストであったり、その宛先が低パフォーマンスのシステムであると想定すると、ネットワーク・カードが受信するパケットの各ストリームにより、CPU の割り込みが発生し、データがI/O バスを介して転送されている可能性が高くなります。当該のネットワーク・カードがバス・マスター・カードである場合、作業の負荷を軽減したり、CPU の処理能力を使用せずにメモリーとネットワーク・カード間のデータ転送を続行することができます。バス・マスター・カードは32 ビットで、PCI または EISA バス・アーキテクチャーをベースにしています。


表 7. インストールおよび構成の問題と解決方法 (続き)

問題解決方法

64 ビット版 Windows システムで Tivoli Log File Agent

のインストールが失敗する。注:

この問題は、以下のものが存在するシステムに Tivoli Log

File Agent をインストールしようとするユーザーにのみ該当します。

v 64 ビット版 Windows オペレーティング・システム

v 旧バージョンの IBM Tivoli Monitoring 32 ビット/64

ビット Compatibility Package

v インストール済みの IBM Tivoli Monitoring エージェント (Tivoli Log File Agent 以外)

IBM Tivoli Monitoring インストーラーでは、旧バージョンの IBM Tivoli Monitoring 32 ビット/64 ビットCompatibility Package が存在する 64 ビット版 Windows

システムには、Tivoli Log File Agent をインストールできません。IBM Tivoli Monitoring インストーラーは、IBM

Tivoli Monitoring 32 ビット/64 ビット Compatibility

Package をアップグレードできません。

以下のいずれかの方法で、ベースの IBM Tivoli

Monitoring 6.2.2.2 の DVD から、IBM Tivoli Monitoring

32 ビット/64 ビット Compatibility Package (コンポーネント AC) をインストールします。

v setup.exe を実行してプロンプトに応答する。

または

v IBM Tivoli Monitoring リモート・デプロイメント機能を使用する。

IBM Tivoli Monitoring リモート・デプロイメント機能を使用する場合は、以下の操作を行います。

v IBM Tivoli Monitoring 6.2.2.2 バージョンの AC コンポーネントを、Tivoli Enterprise Monitoring Server のデプロイメント・デポに追加します。

v Tivoli Enterprise Monitoring Server のデプロイメント・デポから、Tivoli Monitoring 32 ビット/64 ビットCompatibility Package (コンポーネント AC) をデプロイします。

setup.exe および IBM Tivoli Monitoring リモート・デプロイメント機能を使用したインストールの実行について詳しくは、「IBM Tivoli Monitoring インストールおよび設定ガイド」を参照してください。

Tivoli Enterprise Monitoring Agent Framework (コンポーネント GL) のバージョンが 06.23.00.00 または 06.23.01.00

である 64 ビット Windows システムで構成パネルがブランクである。

Windows コマンド行から kincinfo -t GL を実行して、GL

コンポーネントのバージョンを確認します。例:

%CANDLE_HOME%¥InstallITM¥kincinfo -t GL

GL コンポーネントのバージョンが 06.23.00.00 または06.23.01.00 の場合は、以下のいずれかのアクションを実行します。

v 優先アクション: Windows OS Agent をバージョン6.2.3 フィックスパック 2 にアップグレードします。

v 代替アクション: IBM Tivoli Monitoring V6.2.3 フィックスパック 1 メディアから Agent Compatibility (AC)

コンポーネントをインストールします。『Agent

Compatibility (AC) コンポーネントのインストール(Installing the Agent Compatibility (AC) component)』(http://pic.dhe.ibm.com/infocenter/tivihelp/v15r1/topic/

com.ibm.itm.doc_6.2.3fp1/

itm623FP1_install199.htm#acpinstall) を参照してください。


http://pic.dhe.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.3fp1/itm623FP1_install199.htm#acpinstall



表 8. アンインストールの一般的な問題および解決方法

問題解決方法

Windows システムでの IBM Tivoli Monitoring のアンインストールで、環境全体のアンインストールに失敗する。

「IBM Tivoli Monitoring インストールおよび設定ガイド」で説明されている、以下の一般的なアンインストール・プロセスを正しく実行しているかどうかを確認します。

1. 以下のステップを実行して、Tivoli Enterprise

Monitoring Server Application サポートを除去します。

a. 「Tivoli Enterprise Monitoring Services の管理」を使用します。

b. 「Tivoli Enterprise Monitoring Server」を選択します。

c. 右クリックして「拡張 (Advanced)」を選択します。

d. 「TEMS アプリケーション・サポートの除去(Remove TEMS application support)」を選択します。

e. アプリケーション・サポートを除去するエージェントを選択します。

2. 以下の例のように、最初にモニター・エージェントをアンインストールします。

v 特定データベース用の単一モニター・エージェントをアンインストールします。

-または-

v IBM Tivoli Monitoring for Databases など、モニター製品のすべてのインスタンスをアンインストールします。

3. IBM Tivoli Monitoring をアンインストールします。

非アクティブの管理対象システム (システム状況はOFFLINE) をポータルのナビゲーター・ツリーから除去する方法が不明である。

以下のステップを使用して、オフラインの管理対象システムをナビゲーター・ツリーから除去します (アンインストールではありません)。

1. ナビゲーター・ツリーの「エンタープライズ」アイコンをクリックします。

2. 右クリックしてから、「ワークスペース」 > 「管理対象システムの状況」をクリックします。

3. オフラインの管理対象システムを右クリックし、「オフライン・エントリーの消去 (Clear offline entry)」を選択します。

モニター・エージェントをアンインストールするには、「IBM Tivoli Monitoring インストールおよび設定ガイド」で説明している手順を実行します。


表 8. アンインストールの一般的な問題および解決方法 (続き)

問題解決方法

IBM Tivoli Monitoring は、モニター・コンポーネントの名前を自動生成するときに名前を切り捨てるので、モニター・コンポーネントに固有の名前を生成できない場合がある。

エージェントが複数インスタンスをサポートしている場合、IBM Tivoli Monitoring は各モニター・コンポーネントについて、サブシステム名、ホスト名、および製品コードをコロンで区切って連結 (subsystem_name:hostname:KLO

のように) することで、コンポーネント名を自動的に作成します。注: データベースなどのマルチノード・システムをモニターする場合、IBM Tivoli Monitoring は、連結した名前にサブシステム名を追加します (一般的にはデータベース・インスタンス名)。

IBM Tivoli Monitoring が生成する名前の長さは 32 文字までに制限されます。名前を切り捨てると、複数のコンポーネントが同じ 32 文字の名前になってしまう場合があります。この問題が発生した場合は、名前の hostname 部分を以下のように短縮します。

1. モニター・エージェントの構成ファイルを開きます。このファイルは、以下のパスにあります。


install_dir¥tmaitm6¥Kproduct_codeCMA.INI。例えば、Windows OS 用 Monitoring Agent の製品コードは NT です。ファイル名は、KNTCMA.INI です。

v UNIX および Linux の場合: itm_home/config/

product_code.ini および product_code.config。例えば、UNIX OS 用 Monitoring Agent のファイル名は ux.ini および ux.config です。

2. CTIRA_HOSTNAME= で始まる行を見つけます。

3. ホスト名の新しい名前を入力します。名前は、ホスト・コンピューターに固有で、現在よりも短い名前にしてください。サブシステム名、新規ホスト名、および KLO を含む最終的に連結された名前は、32 文字を超えることはできません。注: 結果として生成される名前は、以前に Tivoli

Enterprise Monitoring Server に登録された既存モニター・コンポーネントすべてから見て、固有であることを確認してください。

4. ファイルを保存します。

5. エージェントを再始動します。

UNIX および Linux システム上のエージェントのソフトウェア・インベントリー・タグがエージェントのアンインストール中に削除されない。

エージェントをアンインストールした後で、エージェントの絶対パス名.cmptag という名前のファイルを$CANDLEHOME/properties/version/ ディレクトリーから手動で削除します。


表 8. アンインストールの一般的な問題および解決方法 (続き)

問題解決方法

グループ・デプロイメントを使用してエージェントをインストールした際、deploygroup が複数回実行された。グループ・デプロイメントは正常に開始して完了するが、Tivoli Enterprise Portal のデプロイ状況要約ワークスペースには複数のエントリーが存在した。このコマンドが複数回インストールを試行したときに、追加のインストールもキューに入れられ、それらが失敗状態になるが、エージェントは正常にデプロイされた。注:

v バンドル・グループに単一のバンドルが含まれており、デプロイメント・グループに複数のメンバー (AIX

または Linux と同じタイプの管理対象システム) が含まれている場合は、両方のシステムで正常にデプロイされる。

v バンドル・グループに複数のバンドルが含まれており、デプロイメント・グループに 1 つ以上のメンバーが含まれている場合は、バンドル・グループおよびデプロイメント・グループに存在するメンバーに応じて、各グループ・メンバー (管理対象システム) についてデプロイが実行される。

v 各ターゲット・システムの XX バンドルごとに、コマンドによってトランザクションが作成される。デプロイメント・メンバーのオペレーティング・システムに一致するバンドルは正常に処理される。それ以外のトランザクションはキューに入っているか失敗した状態になった。

現時点での解決方法はありません。

リモート・デプロイメントのトラブルシューティングリモート・デプロイメントと、Agent Remote Deploy プロセスを使用したエージェント・ソフトウェアの除去に関する問題が発生する場合があります。

リモート・デプロイメントに関連した問題および解決方法を表 9 に示します。

表 9. リモート・デプロイメントの問題および解決方法

問題解決方法

リモート・デプロイメント機能を使用して Tivoli Log

File Agentをインストールする場合、空のコマンド・ウィンドウがターゲット・コンピューターに表示される。この問題は、リモート・デプロイメントのターゲットがWindows コンピューターであるときに発生します。 (リモート・デプロイメント機能について詳しくは、「IBM

Tivoli Monitoring インストールおよび設定ガイド」を参照してください。)

このウィンドウを閉じたり、または変更したりしないでください。これはインストール・プロセスの一部分であり、自動的に終了します。


表 9. リモート・デプロイメントの問題および解決方法 (続き)

問題解決方法

Tivoli Enterprise Portal デスクトップまたはブラウザーでリモート除去プロセスを使用した場合、モニター・エージェントの除去が失敗する。

この問題は、Tivoli Enterprise Monitoring Server を再始動した直後にリモート除去プロセスを試行すると発生する可能性があります。リモート除去プロセスを開始する前に、モニター・エージェントが Tivoli Enterprise Monitoring

Server との接続をリフレッシュするための時間をとるようにしてください。

エージェントのトラブルシューティングエージェントのインストール後に、エージェントに関する問題が発生する場合があります。

エージェントのインストール後にエージェントに関して発生する可能性がある問題および解決方法を、表10 に示します。

表 10. エージェントの問題および解決方法

問題解決方法

ログ・データの累積が早すぎる。 RAS トレース・オプション設定を確認します (詳しくは、 119ページの『GUI を使用した RAS トレース・パラメーターの設定』を参照してください)。KBB_RAS1= と KDC_DEBUG= の行で設定できるトレース・オプション設定により、大量のデータが生成される可能性があります。

itmcmd agent コマンドを使用してこのモニター・エージェントを開始または停止するときに、以下のエラー・メッセージが表示される。

MKCIIN0201E 指定された製品が構成されていません。

開始または停止するインスタンスを指定するコマンド・オプション -o を含めてください。インスタンス名は、エージェントを構成するために使用した名前と一致させる必要があります。以下に例を示します。

./itmcmd agent -o Test1 start lo

itmcmd コマンドの使用法について詳しくは、「IBM Tivoli Monitoring コマンド・リファレンス」を参照してください。


表 10. エージェントの問題および解決方法 (続き)

問題解決方法

モニター・エージェントの構成済みで実行中のインスタンスが Tivoli

Enterprise Portal に表示されず、同じシステム上のモニター・エージェントの他のインスタンスがポータルに表示される。

IBM Tivoli Monitoring 製品は、リモート・プロシージャー・コール (RPC)

を使用して製品の動作を定義および制御します。RPC は、クライアント・プロセスが、ネットワーク内のどこかにあるサーバー・プロセスに対してサブルーチン呼び出し (GetTimeOfDay または ShutdownServer など) を行うために使用するメカニズムです。必要に応じて、RPC 用のプロトコル (または送達機構) として TCP/UDP、TCP/IP、SNA、および SSL を使用するように、Tivoli プロセスを構成できます。

IP.PIPE は、RPC 用の Tivoli TCP/IP プロトコルに付けられた名前です。RPC は、TCP/IP ポートを使用してソケット・アドレスを形成するソケット・ベースの操作です。IP.PIPE は、仮想ソケットを実装し、単一の物理TCP/IP ポートを通過するすべての仮想ソケット・トラフィックを多重化します (netstat コマンドを使用して表示できます)。

Tivoli プロセスは、ハブ Tivoli Enterprise Monitoring Server の構成済みのウェルノウン・ポートに基づいて、IP.PIPE 通信用の物理ポートを特定します。(このウェルノウン・ポートまたは BASE_PORT は、KDC_FAMILIES /

KDE_TRANSPORT 環境変数に「PORT:」キーワードを使用することによって構成され、デフォルトでは「1918」になります。)

物理ポート割り振り方式は、(BASE_PORT + 4096*N) と定義されています。Tivoli Enterprise Monitoring Server プロセスの場合は N=0、別のタイプのモニター・サーバー・プロセスの場合は N={1, 2, ..., 15} です。物理ポート割り振り方式の結果として、以下の 2 つのアーキテクチャー上の制限が存在します。

v 特定の Tivoli Enterprise Monitoring Server ハブに報告を行う Tivoli

Enterprise Monitoring Server をシステム・イメージ上で複数アクティブにできない。

v 15 個以内の IP.PIPE プロセスを単一システム・イメージ上でアクティブにすることができます。

単一システム・イメージでは、そのイメージ上の各 Tivoli Enterprise

Monitoring Server がそれぞれ異なるハブに対して報告を行っている場合、任意の数の Tivoli Enterprise Monitoring Server プロセス (アドレス・スペース)

をサポートできます。定義上、モニター Enterprise ごとに 1 つの Tivoli

Enterprise Monitoring Server ハブが使用可能であるため、このアーキテクチャー制限は緩和されて、システム・イメージごとに 1 つの Tivoli Enterprise

Monitoring Server になりました。

15 個以内の IP.PIPE プロセスまたはアドレス・スペースを単一システム・イメージ上でアクティブにすることができます。上記の最初の制限があるため、この 2 番目の制限は、具体的には Tivoli Enterprise Monitoring Agent プロセスを意味しています。つまり、システム・イメージごとのエージェント数が 15 個を超えてはなりません。

次の行へ続く。



問題解決方法

前の行から続く Tivoli Enterprise Monitoring Agent プロセスが EPHEMERAL IP.PIPE プロセスを使用するように構成されている場合、この制限は (最新の保守レベルである IBM Tivoli Monitoring V6.1、Fix Pack 4 以降で) 回避することができます。(このプロセスは、KDC_FAMILIES / KDE_TRANSPORT 環境変数で「EPHEMERAL:Y」キーワードを使用して構成した IP.PIPE です)。システム・イメージごとの一時 IP.PIPE 接続の数に制限はありません。一時エンドポイントが使用される場合、ウェアハウス・プロキシー・エージェントには、一時接続を使用するエージェントに関連付けられている Tivoli Enterprise

Monitoring Server から、同じコンピューター上でウェアハウス・プロキシー・エージェントを実行するかまたはファイアウォール・ゲートウェイ機能を使用することでアクセスできます。(ファイアウォール・ゲートウェイ機能は、ウェアハウス・プロキシー・エージェントが同じコンピューター上に共存できない場合に、ウェアハウス・プロキシー・エージェント接続を Tivoli

Enterprise Monitoring Server コンピューターからウェアハウス・プロキシー・エージェント・コンピューターに中継します。)

照会が見つからない。サブノードが含まれているエージェントでは、属性グループのロケーションを表す照会エディター・リストのエレメント内にそれぞれの照会が表示されます。照会は、ほとんどの場合、エージェントの名前ではなくサブノードの名前の下にあります。



問題解決方法

エージェントが開始されているにもかかわらず、Tivoli Enterprise Portal にイベントが表示されない。

この問題は、以下のいずれかの問題が原因で発生する可能性があります。

v エージェントが、IBM Tivoli Monitoring にイベントを送信するように構成されていない。

「ITM イベントの送信」構成値がコマンドで「yes」に設定されているか、GUI でチェック・マークが付いていることを確認します。

v 構成ファイルが見つからない。パフォーマンス・オブジェクト状況属性グループが「構成ファイルが存在しません」と報告する。

構成ファイルの構成設定の値が正しいことを確認します。これは構成ファイルの完全修飾パスでなければならず、このファイルを読み取るための十分なアクセス権をエージェントに付与しておく必要があります。

v フォーマット・ファイルが見つからない。パフォーマンス・オブジェクト状況属性グループが「フォーマット・ファイルを開けません」と報告する。

フォーマット・ファイルの構成設定の値が正しいことを確認します。これはフォーマット・ファイルの完全修飾パスでなければならず、このファイルを読み取るための十分なアクセス権をエージェントに付与しておく必要があります。

v フォーマット・ファイルで構文解析エラーが発生する。パフォーマンス・オブジェクト状況属性グループが「フォーマット・ファイルの構文エラー」を報告する。エージェントのエラー・ログに、構文解析エラーが発生したフォーマット・ファイルの行が示される。

フォーマット・ファイルの構文エラーを修正します。

v フォーマット・ファイルのいずれのパターンも、ログ・ソースから読み取られたレコードに一致しない。

不一致ファイルを使用するようにエージェント・インスタンスを構成し、不一致ログの内容を調べます。正規表現テスト・ツールを使用すると、不一致ログに書き込まれたレコードに一致する正規表現を作成するのに便利です。フォーマット・ファイルを更新します。



問題解決方法

Tivoli Log File Agent インスタンスに対して、KLO_Log_Agent_Config_Error

シチュエーションが true になる。

以下のいずれかの問題が発生する場合は、KLO_Log_Agent_Config_Error シチュエーションが true になっています。

v エージェントが、IBM Tivoli Monitoring にイベントを送信するように構成されていない。

「ITM イベントの送信」構成値がコマンドで「yes」に設定されているか、GUI でチェック・マークが付いていることを確認します。

v 構成ファイルが見つからない。パフォーマンス・オブジェクト状況属性グループが「構成ファイルが存在しません」と報告する。

構成ファイルの構成設定の値が正しいことを確認します。これは構成ファイルの完全修飾パスでなければならず、このファイルを読み取るための十分なアクセス権をエージェントに付与しておく必要があります。

v フォーマット・ファイルが見つからない。パフォーマンス・オブジェクト状況属性グループが「フォーマット・ファイルを開けません」と報告する。

フォーマット・ファイルの構成設定の値が正しいことを確認します。これはフォーマット・ファイルの完全修飾パスでなければならず、このファイルを読み取るための十分なアクセス権をエージェントに付与しておく必要があります。

v フォーマット・ファイルで構文解析エラーが発生する。パフォーマンス・オブジェクト状況属性グループが「フォーマット・ファイルの構文エラー」を報告する。エージェントのエラー・ログに、構文解析エラーが発生したフォーマット・ファイルの行が示される。

フォーマット・ファイルの構文エラーを修正します。

v フォーマット・ファイルのいずれのパターンも、ログ・ソースから読み取られたレコードに一致しない。

不一致ファイルを使用するようにエージェント・インスタンスを構成し、不一致ログの内容を調べます。正規表現テスト・ツールを使用すると、不一致ログに書き込まれたレコードに一致する正規表現を作成するのに便利です。フォーマット・ファイルを更新します。



問題解決方法

最初は一部のイベントが Tivoli

Enterprise Portal に表示されるが、ログ・ソースにフォーマット・ファイルの正規表現に一致するレコードが含まれているにもかかわらず、新しいイベントが生成されない。

EIF イベントを送信するようにエージェントが構成されているが、イベントを受信するための EIF 受信側が構成されていないか実行中でない場合(OMNIbus プローブなど)、エージェントの EIF 受信ログがいっぱいになり、イベントを処理できなくなります。

EIF イベントが送信されないようにする場合は、以下のステップを実行します。

1. エージェントを停止します。

2. エージェントを再構成して、「EIF イベントを OMNIbus に送信」の構成値を「いいえ」に設定します。

3. エージェントを始動します。

EIF イベントを送信させる場合は、以下のステップを実行します。

1. EIF 受信側が実行されていることを確認します。

2. エージェントの構成ファイルの EIF 設定を確認します。

3. 送信されるイベントが多すぎる場合は、EIF イベント・キャッシュのサイズが、イベントの集中発生に対応できる程度に十分に大きくない可能性があります。エージェントの構成ファイルで BufEvtMaxSize 構成の値を増加させます。

一部の HP-UX オペレーティング・システムで syslogd が名前付きパイプをサポートしていない。

「UNIX syslog の自動的初期化」構成オプションは syslogd を使用します。一部の HP-UX オペレーティング・システムは名前付きパイプをサポートしていないため、それらの HP-UX オペレーティング・システムでは「UNIX

syslog の自動的初期化」機能が動作しません。

回避策はありません。

EIF イベントを送信するように構成されたエージェントは、多数のイベントが生成されたときにイベントの処理を停止するため、ハングしたように見えます。

EIF イベント・キャッシュに、イベントの集中発生に対応できる程度の十分な大きさがない可能性があります。エージェントの構成ファイルでBufEvtMaxSize 構成の値を増加させます。

ログ・レコードが所定の正規表現に一致しない。生成されたイベントに、あるべきイベント・クラスまたはイベント属性がない。

正規表現は、フォーマット・ファイルの最後から最初の順に処理されます。レコードに一致した最初の正規表現が、使用される正規表現になります。汎用の正規表現はファイルの最初に記述し、固有の正規表現は最後に記述してください。

LogSources または RegexLogSources

の使用中にファイルがモニターされていない。

KBB_RAS1=ERROR (UNIT:kumpdcm STATE) を設定すると、ファイルがLogSources パターンおよび FileComparisonMethod と照合されるたびにトレース項目が作成されます。出力例を以下に示します。Directory /logs/data/

File notsmoke.log did not match pattern smoke.*¥.log File

<smoke03.log> skipped, not more recently updated than previous file

<smoke01.log>



問題解決方法

RegexLogSources を使用するとき、複数のサブディレクトリーにメタ文字が存在する場合に、使用される正規表現およびファイル名を知りたい。

「ログ・ファイル状況」属性グループには、モニター対象の各ログ・ファイルに関する情報が表示されます。モニターしているファイルごとに、ファイルの選択に使用された正規表現パターンが示されます。RegexLogSources でのログ・ファイル・パターンの指定が誤っていた場合は、「ログ・ファイル状況」属性グループに示される正規表現パターンが、構成 (.conf) ファイルで指定された正規表現パターンと異なるため、警告のトレース項目が書き込まれます。

Windows システムにおいて、.conf ファイルの LogSources ステートメントおよび RegexLogSources ステートメントでルート・ディレクトリーのファイルをドライブ名無しで指定すると、モニター対象ファイルが検出されない。以下に例を示します。

LogSources=¥temp*

RegexLogSources=/.*/reg4ex/.*.log

LogSources ステートメントおよび RegexLogSources ステートメントにファイル・パスのドライブ名を入れてください。例えば、 LogSources=C:¥temp* および RegexLogSources=C:/.*/reg4ex/.*.log とします。LogSources またはRegexLogSources のルート・ディレクトリーのドライブ名を指定しない場合は、システムが別のデフォルト・ドライブ名を持つように構成されていても、エージェントはドライブ名を C: と見なします。

Log File Agent の構成ファイルで EIF

構成が接続指向 (ConnectionMode=co

またはConnectionMode=connection_oriented)

に設定されていて、エージェントの開始時に EIF 受信側がダウンしている場合、リモート受信側が約 2 分間応答しない。その間、エージェントはログをモニターしていない。プロファイル/サブノードが使用中であり、各.conf ファイルが同じように構成されている場合、これらの遅延は逐次的に発生する。

この問題を回避するには、エージェントの開始時に必ず EIF 受信側が稼働しているようにするか、あるいは、イベント配信用の connection_less オプションを使用します。

HP/UX 11.11 において、一部のシステムはデフォルトでプロセス当たり 65

スレッドしか許可されない。Log File

Agent は、モニターしているファイルごとに 1 スレッドを使用するだけでなく、他にも、バックグラウンドのハウスキーピング・タスクを実行する多数のスレッドを使用する。サブノードを使用している場合や、多数のファイルをモニターしている場合は、このオペレーティング・システムによる制限を超える可能性があり、超えたときは、一部のファイルのモニターに失敗する。

この問題を回避するには、HP/UX の「sam」ツールを使用して、カーネル・パラメーター max_thread_proc がより大きな値になるように構成します。推奨値は「500」です。この値にすると、大規模構成でも十分なスレッド数になります。



問題解決方法

指定された一部のログ・ファイルがモニターされない。

「ログ・ファイル状況」属性グループを確認してください。このグループには、モニター対象の各ログ・ファイルに関する情報が表示されます。具体的には以下のとおりです。

v ファイルがモニター対象のログ・ファイルのいずれかであることを確認します。モニター対象である場合は、「ファイル状況」属性が「OK (0)」であることを確認します。「OK」の場合は、ログ・ファイル・エージェントが既にファイル全体を読み取った可能性があるため、「現行ファイル位置」が「現行ファイル・サイズ」よりも小さいことを確認してください。

v モニター対象のファイルのいずれかについて、「正規表現パターン」属性が、欠落ファイルを表す、構成 (.conf) ファイルに指定されているファイルと一致することを確認します。

すべてのログ・ファイルが「ログ・ファイル状況」属性グループにない場合は、トレース・ログ・ファイルでシステム・リソースの制限を確認してください。例えば、モニター対象の各ログ・ファイルが別個のスレッドであり、UNIX システムの ulimit -u (最大ユーザー・プロセス数) が小さすぎる場合があります。

v **** ファイル address file name のファイル・サーバー・プロセスの開始に失敗しました (File server process startup failed for file

address file name)

v **** ファイル file name のマルチスレッド・ファイル・サーバー・プロセスの開始に失敗しました (MultiThreaded File server process startup

failed for file file name)

v **** file name のファイル・サーバー・プロセスの開始に失敗しました(File server process startup failed for file name)

一部のバージョンの Firefox ブラウザーでヘルプ・ファイルを表示すると、チェコ語のサポートで問題が発生することがある。

バージョン 18 以降の Firefox ブラウザーを使用してください。


CPU スロットルのトラブルシューティングモニター・エージェントの CPU スロットルで問題が発生する場合があります。

表 11. CPU スロットルの問題および解決方法

問題解決方法

CPU スロットルの使用中、ログ・ファイルのレビューには、モニター・エージェントの CPU 使用量制限によってイベントが制限されているかどうかは示されません。

v 「ログ・ファイル状況」属性グループには、モニター対象の各ログ・ファイルに関する情報が表示されます。特に、モニター対象の各ファイルに関する現行ファイル位置と現行ファイル・サイズの差は、ログ・ファイル・モニターがこれから処理する必要のあるデータの量を示しています。この未処理データの量は、Log

File Agent の遅延の程度を示しています。

v KBB_RAS1=ERROR (UNIT:kumpcpu STATE) を設定すると、スレッドの速度が目立って低下するたびにトレース項目が作成されます。トレース項目には、プロセスが使用された秒数、経過時間、および使用率が示されます。ミリ秒単位の待ち時間は、CPU スロットルの目標を達成するために必要とされたミリ秒単位の遅延時間です。ホット・スレッドの数は、現在 CPU 集中の作業を行っているアクティブ・スレッドの数です。

出力例: Spent 0.589910000 sec processor,

5.890441194 sec elapsed, 5.0073%; Waiting 8

millisec; 1 hot threads; From

(kumpiafi.c,1161"KUMP_ConstructAttrFilterInfo")

CPU スロットルの使用中には、そのエージェントの CPU

使用量を調べることはできません。KBB_RAS1=ERROR (UNIT:kumpcpu METRICS STATE) を設定すると、各プロセスのプロセッサー使用率を示すトレース項目が毎分作成されます。すべてのプラットフォームは、プロセスのプロセッサー使用率を判別することができます。例えば、Windows タスクマネージャまたは Linux top コマンドを使用して、プロセス情報を判別することができます。

出力例: Process processor utilization 3.6311% (8.71

/ 120.00); Process interval utilization 3.6311%

(8.71 / 120.00); 2 cores

CPU スロットルの使用中には、そのエージェントの CPU

使用量制限を超えているかどうかを調べることはできません。

ある間隔について CPU スロットルの最大値を超えると、エラー・トレースが実行されます。プロセッサー使用率が目標の 10% 以内である場合、それは通知トレース・メッセージであると考えられます。プロセッサー使用率が目標を 10% 超えている場合、それはエラー・トレース・メッセージであると考えられます。

出力例: Informational: Interval processor

utilization 11.1372% (26.72 / 120.00) exceeds

processor utilization goal 10 with 2 cores


関連タスク:

119ページの『GUI を使用した RAS トレース・パラメーターの設定』Windows システムでは、グラフィカル・ユーザー・インターフェースを使用してトレース・オプションを設定できます。

関連資料:


リモート・ログ・ファイル・モニターのトラブルシューティングリモート・ログ・ファイル・モニターにおいて、リモート・システムに対するエージェント通信で問題が発生する場合があります。

表 12. リモート・ログ・ファイル・モニターの問題とその解決方法

問題解決方法

リモート・ログ・ファイルから、イベントやデータが読み取られない。

「ログ・ファイル状況」を確認してください。この状況に「OK」が表示されていれば、ファイルはモニターされています。

「ログ・ファイル状況」に「OK」というファイル状況が表示されていない。

リモート・ファイルに関連する以下のファイル状況を確認してください。

PASSWORD EXPIRED

パスワードが期限切れになっています。

PUBLIC KEY UNRECOGNIZED

証明書を読み取ることができません (パスフレーズまたはファイルが正しくない)。

PUBLIC KEY UNVERIFIED

証明書を検証できません。

NO SUPPORTED DESCR

17ページの『サポートされている SSH 機能およびフィーチャー』に記載されているいずれの認証方式も、リモート・システムでサポートされていません。

SOCKET_TIMEOUT

通信がタイムアウトになりました。通信の切断またはファイアウォールにより、タイムアウトが発生した可能性があります。

KEY FILE ACCESS ERROR

ローカル・システムで、公開鍵ファイルまたは秘密鍵ファイルが見つかりません。

HOSTNAME UNRESOLVED

ドメイン・ネーム・サーバー (DNS) でリモート・ホスト名を解決することができません。

FAMILY UNSUPPORTED

DNS から返されたホスト名の IP アドレスが、サポートされている IP ファミリーではありません (IPv4 対 IPv6)。


表 12. リモート・ログ・ファイル・モニターの問題とその解決方法 (続き)

問題解決方法

「ログ・ファイルの状況」に、ファイルの状況に関する上記の 2 つのトラブルシューティング項目の値のいずれも表示されていない。

Log File Aagent が稼働しているシステムで、リモート・パラメーター(userid、password、certification、filename) が指定された SSH、SFTP、または SCP を使用して、ファイルの読み取りができるかどうかを確認してください。

上記のいずれのトラブルシューティング項目を試してみても、問題を解決できない。

トレース ERROR (UNIT:KUMPLIBSSH STATE) を有効にしてください。この設定により、Log File Agent とリモート・システム間のすべての libssh2 通信がトレースされます。トレース・ログで、API に対するゼロ以外の戻りコードを探してください。トレース・ログの詳細については、 112ページの『トレース・ロギング』を参照してください。

ワークスペースのトラブルシューティング一般のワークスペースおよびエージェント固有のワークスペースに関する問題が発生する場合があります。

ワークスペースに関連した問題および解決方法を 143ページの表 13 に示します。


表 13. ワークスペースの問題および解決方法

問題解決方法

プロセス・アプリケーション・コンポーネントは使用可能だが、アベイラビリティー状況はPROCESS_DATA_NOT_ AVAILABLE を示している。

この問題は、PerfProc パフォーマンス・オブジェクトが使用不可であるために発生します。この状態にある場合、IBM Tivoli Monitoring はこのプロセスのパフォーマンス・データを収集できません。この問題が存在することを確認し、それを解決するには、以下のステップを実行します。

1. Windows の「スタート」メニューから、「ファイル名を指定して実行」をクリックします。

2. 「ファイル名を指定して実行」ウィンドウの「開く(Open)」フィールドに perfmon.exe と入力します。「パフォーマンス」ウィンドウが表示されます。

3. ツールバーの正符号 (+) をクリックします。「カウンタの追加」ウィンドウが表示されます。

4. 「パフォーマンスオブジェクト」メニューで「Process」を探します。

5. 次のいずれかのアクションを実行します。

v メニューに「Process」が表示される場合、PerfProc

パフォーマンス・オブジェクトは使用可能であり、この問題は別の原因によるものです。場合によっては、IBM ソフトウェア・サポートに連絡する必要があります。

v メニューに「Process」が表示されない場合は、Microsoft.com Operations の Web サイトにあるMicrosoft のユーティリティーを使用して、PerfProc

パフォーマンス・オブジェクトを有効にします。

「カウンタの追加」ウィンドウの「パフォーマンスオブジェクト」メニューに「Process」パフォーマンス・オブジェクトが表示されるようになり、IBM

Tivoli Monitoring は可用性データを検出することができます。

6. モニター・エージェントを再始動します。

属性の名前が棒グラフまたはグラフ・ビューに表示されない。

属性を含む図表またはグラフのビューのサイズを小さくすると、切り捨てられた名前ではなく空白のスペースが表示されます。属性の名前を表示するには、属性名のすべての文字を表示するのに十分なスペースが確保されるまで、図表ビューを拡張します。

各ビューの末尾に、ヒストリカル・ワークスペースのエラー KFWITM220E「実行中に要求が失敗しました」が表示される。

ビューにデータを提供するすべてのグループが構成されていることを確認します。ヒストリカル構成ビューで、ビューにデータを提供するすべてのグループのデータ収集が開始していることを確認してください。


http://blogs.technet.com/b/mscom/archive/2008/12/18/the-mystery-of-the-missing-process-performance-counter-in-perfmon.aspx

表 13. ワークスペースの問題および解決方法 (続き)

問題解決方法

ヒストリカル・データの収集を開始したが、データを表示できない。

ヒストリカル・データ収集には以下の管理オプションを使用します。

v 基本的なヒストリカル・データ収集では、Warehouse

にロー・データが取り込まれます。このタイプのデータ収集はデフォルトでオフになっています。データ収集間隔の設定方法など、この機能の管理について詳しくは、「IBM Tivoli Monitoring 管理者ガイド」の『ヒストリカル・データの管理』を参照してください。データ収集をより頻繁な間隔に設定すると、データがアップロードされるたびに生じるシステムの負荷が削減されます。

v 要約およびプルーニング・エージェントを使用して、特定の量およびタイプのヒストリカル・データを収集します。要約およびプルーニング・モニター・エージェントがデータ収集を開始するまでヒストリカル・データは表示されません。デフォルトでは、このエージェントは毎日午前 2 時に収集を開始します。その時点で、ワークスペース・ビュー内のデータが表示されるようになります。収集のデフォルト設定を変更する方法について詳しくは、「IBM Tivoli Monitoring 管理者ガイド」の『ヒストリカル・データの管理』を参照してください。

Tivoli Enterprise Portal の照会に誤りがあるため、ヒストリカル・データ収集が使用できない。

Sort By、Group By、および First/Last の列関数は、ヒストリカル・データ収集の機能とは互換性がありません。これらの拡張機能を使用すると、ヒストリカル・データ収集に対して照会を選択できなくなります。

データ収集が開始されていても、図または表の照会に列関数または拡張照会オプション (Sort By、Group

By、First/Last) が含まれていると、タイム・スパン機能は使用できません。

ヒストリカル・データ収集をサポートするには、照会でSort By、Group By、または First/Last 関数を使用しないでください。

ヒストリカル・データ収集機能について詳しくは、「IBM

Tivoli Monitoring 管理者ガイド」の『ヒストリカル・データの管理』または Tivoli Enterprise Portal のオンライン・ヘルプを参照してください。

シチュエーションに長いプロセス名を使用すると、プロセス名が切り捨てられる。

ポータルの表示において可用性の表内のシチュエーションのプロセス名またはサービス名が切り捨てられるという現象は、予期される動作です。名前の最大長は 100 バイトです。

定期的 (非ヒストリカル) モニター・データの表示に失敗する。

データの収集に使用する照会の形式を確認します。例えば、無効な SQL ステートメントがないか探します。


表 13. ワークスペースの問題および解決方法 (続き)

問題解決方法

ナビゲーター項目およびワークスペース・タイトルが、正しい名前 (ディスクなど) ではなく Kxx:KXX0000 などの内部名でラベル付けされている。ここで、XX および xx

は、2 文字のエージェント・コードを表す。

アプリケーション・サポートがモニター・サーバー、ポータル・サーバー、およびポータル・クライアントに追加されていることを確認します。

アプリケーション・サポートのインストールについて詳しくは、「IBM Tivoli Monitoring インストールおよび設定ガイド」の『アプリケーション・サポートのインストールおよび使用可能化』を参照してください。

シチュエーションのトラブルシューティングシチュエーションおよびシチュエーション構成に関する問題が発生する場合があります。

シチュエーションの問題および解決方法を表 14 に示します。

表 14. シチュエーションの問題および解決方法

問題解決方法

アクティビティーのモニターで必要とされるディスク・スペースが多すぎる。

119ページの『GUI を使用した RAS トレース・パラメーターの設定』で説明されている RAS トレース・ロギング設定を確認してください。例えば、ロギング・オプション ALL を適用すると、トレース・ログは急速に大きくなります。

アクティビティーのモニターで必要とされるシステム・リソースが多すぎる。

100ページの『ヒストリカル・データのディスク・キャパシティー・プランニング』では、特定の属性グループのパフォーマンスへの影響について説明されています。可能な場合、たくさんのシステム・リソースが必要な属性グループの使用は控えてください。

数値演算子を使用する計算式が誤っている。例えば、モニター対象が Linux システムである場合、空きメモリーが合計メモリーの 10% を下回っているかを計算する計算式LT #’Linux_VM_Stats.Total_Memory’ / 10 が機能しない。

シチュエーションの述部は論理演算子のみをサポートするため、この公式は誤っています。計算式に数値演算子を使用することはできません。注: シチュエーション・エディターは、数値演算子の代替手段を提供します。例では、% Memory Free 属性を選択すると、数値演算子は必要なくなります。

ナビゲーション・ツリーにシチュエーションが表示されるときのシチュエーションの外観を変更したい。

1. ナビゲーション・ツリー内の項目を右クリックします。

2. メニューの「シチュエーション」をクリックします。「シチュエーション・エディター」ウィンドウが表示されます。

3. 変更するシチュエーションを選択します。

4. 「状態」メニューを使用して、シチュエーションのトリガー時の状況および外観を設定します。注: 「状態」設定は、Tivoli Enterprise Console の重大度の設定とは関係ありません。


表 14. シチュエーションの問題および解決方法 (続き)

問題解決方法

シチュエーションがイベント・ログ属性グループでトリガーされると、イベント ID 項目がイベント・ログ・ワークスペースに存在する限り、そのシチュエーションがシチュエーション・イベント・コンソール内に残る。このイベント ID 項目を Tivoli Enterprise Portal の「イベント・ログ」ワークスペースから削除すると、このイベントの原因となった実際の問題が解決されていない場合でも、シチュエーションもクリアされる。また、このイベント ID 項目は Windows のイベント・ビューアーにも表示される。

NT イベント・ログ・グループのイベントのキャッシュでタイムアウトが発生します。以下の変数およびタイムアウト値をエージェントの KpcENV ファイル (pc は 2 文字の製品コード) に追加して、要件に合うようにイベント・ログ収集のキャッシュ時間を増加させます。CDP_NT_EVENT_LOG_CACHE_TIMEOUT=3600

この変数は、NT イベント・ログからのイベントを保持する期間を決定します。

イベントがイベント・コンシューマーによって受信されない。または受信されたが切り捨てられる。

エージェント構成ファイルの EventMaxSize 属性を調整します。

CustomInteger 属性の値が、予期しない値になっている。 CustomInteger 属性にマップされている値が整数であることを確認してください。例えば、以下の値をCustomInteger 属性にマップすると、予期しない結果になります。

v ストリング "twenty" を CustomInteger 属性にマップすると、0 の値になります

v 浮動小数点数 "1.9" を CustomInteger 属性にマップすると、1 の値になります

v ストリング "2 thousand" を CustomInteger 属性にマップすると、2 の値になります

「MISSING」演算子を使用するシチュエーションがリモートのエージェントレス・モニター・サブノードに配布された場合、そのシチュエーションが true になったときに、Tivoli Enterprise Portal にもシチュエーション・イベント・コンソールにもそのことが示されない。

現在、MISSING 述部はサブノード上でサポートされません。MISSING 述部が使用されているシチュエーションがサブノードに配布された場合、エージェントは、どのサブノードまたはノードでイベントが発生しているのかを判別できません。IRA は、イベントの起点ノードとしてシステム名を挿入し、復帰します。イベントが Tivoli

Enterprise Portal Server に到達したとき、発生元ノードは、当該シチュエーションが関連付けられているサブノードのシステム名と一致しないため、そのイベントは破棄されます。

シチュエーションのエキスパート・アドバイスに外部Web サイト (例えば、Microsoft TechNet Web サイト) へのハイパーリンクが含まれている場合、ハイパーリンクをクリックすると、その Web サイトは外部ウィンドウで開く。しかし、その外部ウィンドウは応答を停止する。

外部ウィンドウは、「プレビュー」ウィンドウと「シチュエーション・エディター」ウィンドウが閉じられた後に応答します。

Tivoli Enterprise Portal で、特定のエージェントのシチュエーションが表示されない。

シチュエーション・エディターを開きます。「すべての管理対象サーバー (All managed servers)」ビューにアクセスします。シチュエーションが表示されない場合は、エージェントに対してモニター・サーバーがシードされていることを確認してください。エージェントに対してモニター・サーバーがシードされていない場合は、「IBM Tivoli

Monitoring インストールおよび設定ガイド」の説明に従ってモニター・サーバーをシードします。



問題解決方法

モニター間隔が長すぎる。変更するシチュエーションの「シチュエーション・エディター」ビューにアクセスします。「式」タブの「サンプリング間隔」領域を確認します。必要に応じて時間間隔を調整します。

始動時にシチュエーションが活動化されなかった。次のようにシチュエーションを手動で再生します。

1. シチュエーションを右クリックして、「シチュエーションの停止」を選択します。

2. シチュエーションを右クリックし、「シチュエーションの開始」を選択します。

注: 特定のシチュエーションの「シチュエーション・エディター」ビューの「開始時に実行」チェック・ボックスを選択すると、この問題を永続的に回避することができます。

シチュエーションが表示されない。「アクション」タブをクリックし、シチュエーションに自動修正アクションがあるかどうかを確認します。このアクションは直接発生することも、ポリシー経由で発生することもあります。シチュエーションの解決が急速で、グラフィカル・ユーザー・インターフェースにイベントや更新情報が表示されないこともあります。

述部が正しく指定されているにも関わらず、警告イベントが発生しなかった。

ログ、レポート、およびワークスペースを確認してください。

シチュエーションが予期しない管理対象オブジェクト上で起動される。

シチュエーションが正しい管理対象システムに配布され、そこで開始されたことを確認してください。

シチュエーションが管理対象システムに配布されていない。

「配布」タブをクリックし、シチュエーションの配布設定を確認してください。



問題解決方法

シチュエーションが起動されていない。この問題は、シチュエーションを定義する公式の述部に誤りがある場合に発生することがあります。例えば、管理対象オブジェクトが、モニター・イベントを正常に起動する状態を示していても、公式に誤った属性が指定されているためにシチュエーションが true でない場合があります。

「式」タブで、次のように述部を分析します。

1. 「式」領域の「fx」アイコンをクリックします。「式の表示」ウィンドウが表示されます。

a. このウィンドウの「式」領域で、次の詳細を確認します。

v モニターする属性が、公式に指定されている。

v モニターするシチュエーションが公式に指定されている。

v 公式の論理演算子がモニターの目的に一致している。

v 公式の数値がモニターの目的に一致している。

b. (オプション) 「詳細な式を表示」チェック・ボックスを選択して、モニターしているアプリケーションまたはオペレーティング・システムの属性の元の名前を確認します。

c. 「OK」をクリックし、「式の表示」ウィンドウを閉じます。

2. (オプション) 「式」タブの「式」領域に、モニター・イベントを即時起動する数値を一時的に割り当てます。イベントを起動することで、式のその他の述部が有効であることが確認されます。注: このテストを完了したら、一時的な設定に基づいて過剰なモニター・データが生成されることを避けるために、数値を有効なレベルに戻す必要があります。

起動しないシチュエーションについて詳しくは、「IBM

Tivoli Monitoring トラブルシューティング・ガイド」の『シチュエーションが実行されていない』を参照してください。

ワークスペースのイベント・コンソール・ビューにシチュエーション・イベントが表示されない。

シチュエーションをナビゲーター項目に関連付けてください。注: シチュエーションはワークスペースに表示されなくても構いません。シチュエーションをナビゲーター項目に関連付けるだけで十分です。



問題解決方法

シチュエーションへのアクセス権がない。注: 以下のステップを実行するには管理者特権が必要です。

1. 「編集」 > 「ユーザー管理」をクリックして、「ユーザー管理」ウィンドウにアクセスします。

2. 「ユーザー」領域で、権限を変更するユーザーを選択します。

3. 「許可」タブ、「アプリケーション」タブ、および「ナビゲーター・ビュー」タブで、ユーザー・ロールに対応する許可または特権を選択します。

4. 「OK」をクリックします。

管理対象システムがオフラインのように見える。 1. 「物理ビュー」を選択して、ナビゲーター・ツリーのエンタープライズ・レベルをクリックします。

2. 「表示」 > 「ワークスペース」 > 「管理対象システム状況」をクリックして、管理対象システムとその状況を確認します。

3. システムがオフラインの場合、ネットワークの接続性、および特定のシステムまたはアプリケーションの状況を確認します。

アクション実行コマンドのトラブルシューティングアクション実行コマンドに関する問題が発生する場合があります。

アクション実行コマンドに関して発生する可能性がある問題および解決方法を表 15 に示します。

各アクション実行コマンドが実行されると、 114ページの表 6 にリストしたログ・ファイルが生成されます。

表 15. アクション実行コマンドの問題および解決方法

問題解決方法

アクション実行コマンドが完了するのに数分かかる。数分待ってください。完了を促すメッセージを表示したくない場合は、コマンドを手動で実行してください。

シチュエーションがアクション実行コマンドのトリガーに失敗する。

Tivoli Enterprise Portal で、アクション実行コマンドを手動で実行してみてください。アクション実行コマンドが動作する場合は、シチュエーションに構成上の問題がないかを調べます。 145ページの『シチュエーションのトラブルシューティング』を参照してください。アクション実行コマンドが失敗する場合は、アクション実行コマンドのトラブルシューティングに関する一般情報について「IBM

Tivoli Monitoring トラブルシューティング・ガイド」を参照してください。


サポート情報IBM ソフトウェアに問題がある場合は、迅速に解決する必要があります。

IBM は、必要なサポートをユーザーに提供するために以下の方法を用意しています。

オンライン以下の Web サイトにトラブルシューティング情報があります。

v IBM ソフトウェア・サポート Web サイト (http://www.ibm.com/support/entry/portal/software) にアクセスし、指示に従ってください。

v 「Application Performance Management Wiki」(http://www.ibm.com/developerworks/

servicemanagement/apm/index.html) にアクセスしてください。この wiki は自由に寄稿していただけます。

IBM Support AssistantIBM Support Assistant (ISA) は、IBM ソフトウェア製品に関する疑問や問題の解決に役立つ、無料のローカル・ソフトウェア保守ワークベンチです。 ISA により、問題判別のためのサポート関連情報および保守容易性ツールに迅速にアクセスできます。ISA ソフトウェアをインストールするには、IBM Support Assistant website (http://www.ibm.com/software/support/isa) にアクセスしてください。


http://www.ibm.com/support/entry/portal/software

http://www.ibm.com/developerworks/servicemanagement/apm/index.html

http://www.ibm.com/software/support/isa

付録 A. イベント・マッピング

Tivoli Event Integration Facility (EIF) インターフェースは、シチュエーション・イベントを Tivoli

Netcool/OMNIbus または Tivoli Enterprise Console に転送するために使用されます。

EIF イベントはイベント・クラスを指定し、イベント・データは、イベント・スロットの名前とそのスロットの値を識別する名前と値の組として指定されます。イベント・クラスはサブクラスを持つことができます。IBM Tivoli Monitoring では、すべてのモニター・イベントに組み込まれる、基本イベント・クラス定義と一連の基本スロットが提供されます。エージェントは基本イベント・クラスを拡張して、エージェント固有のスロットが組み込まれたサブクラスを定義します。Log File Agent イベントの場合、イベント・クラスはエージェント属性グループに対応し、エージェント固有のスロットは属性グループの属性に対応します。

Tivoli Enterprise Portal のシチュエーション・エディターを使用すると、このトピックで説明するデフォルト・マッピングを使用する代わりに、データから EIF スロットへのカスタム・マッピングを実行できます。EIF スロットのカスタマイズについて詳しくは、「Tivoli Enterprise Portal ユーザーズ・ガイド」を参照してください。

Tivoli Enterprise Console では、イベント・クラスとそのスロットは BAROC (Basic Recorder of Objects in

C) ファイルに定義されている必要があります。各エージェントには、そのエージェントのイベント・クラス定義を格納した BAROC ファイルが用意されており、それらのファイルは、エージェントのアプリケーション・サポートのインストール時に Tivoli Enterprise Monitoring Server の TECLIB ディレクトリー(Windows の場合は install_dir/cms/TECLIB、UNIX システムの場合は install_dir/tables/

TEMS_hostname/TECLIB) にインストールされます。Tivoli Monitoring と共に提供される、エージェントのBAROC ファイルおよび基本 BAROC ファイルは、Tivoli Enterprise Console 上にもインストールする必要があります。詳しくは、「IBM Tivoli Monitoring インストールおよび設定ガイド」の『Tivoli Enterprise

Console へのイベント転送のセットアップ』を参照してください。

各イベント・クラスは KLO_Base の子となっており、klo.baroc (バージョン 06.30.00) ファイルに定義されています。KLO_Base イベント・クラスは、Tivoli Log File Agent からのあらゆるイベントに対する汎用ルール処理で使用できます。

LFAProfiles 属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_LFAPROFILES イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v subnode_msn: STRING

v subnode_affinity: STRING

v subnode_type: STRING

v subnode_resource_name: STRING

v subnode_version: STRING

v subnode_config_file: STRING

v subnode_description: STRING


v subnode_description_enum: STRING

ログ・ファイル正規表現統計属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_LOG_FILE_REGEX_STATISTICS イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v table_name: STRING

v attrib_name: STRING

v filter_number: INTEGER

v average_processor_time: REAL

v average_processor_time_enum: STRING

v total_processor_time: REAL

v total_processor_time_enum: STRING

v max_processor_time: REAL

v max_processor_time_enum: STRING

v min_processor_time: REAL

v min_processor_time_enum: STRING

v filter_count: REAL

v filter_count_matched: REAL

v filter_count_unmatched: REAL

v regex_pattern: STRING

v last_matched_time: STRING

v last_matched_time_enum: STRING

v last_unmatched_time: STRING

v last_unmatched_time_enum: STRING

v result_type: INTEGER

v result_type_enum: STRING

ログ・ファイル状況属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_LOG_FILE_STATUS イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v table_name: STRING

v file_name: STRING

v regex_pattern: STRING

v file_type: INTEGER

v file_type_enum: STRING

v file_status: INTEGER

v file_status_enum: STRING

v num_records_matched: INTEGER


v num_records_not_matched: INTEGER

v num_records_not_matched_enum: STRING

v num_records_processed: INTEGER

v current_file_position: REAL

v current_file_position_enum: STRING

v current_file_size: REAL

v current_file_size_enum: STRING

v last_modification_time: STRING

v last_modification_time_enum: STRING

v codepage: STRING

LogfileEvents 属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_LOGFILEEVENTS イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v klo_class: STRING

v logname: STRING

v eifevent: STRING

v klo_msg: STRING

v customslot1: STRING










v occurrence_count: INTEGER

v occurrence_count_enum: STRING

v event_type: INTEGER

v event_type_enum: STRING

v custominteger1: REAL

v custominteger1_enum: STRING





v remotehost: STRING

付録 A. イベント・マッピング 153

LogfileProfileEvents 属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_LOGFILEPROFILEEVENTS イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v klo_class: STRING

v logname: STRING

v eifevent: STRING

v klo_msg: STRING











v occurrence_count: INTEGER

v occurrence_count_enum: STRING

v event_type: INTEGER

v event_type_enum: STRING







v remotehost: STRING

パフォーマンス・オブジェクト状況属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_PERFORMANCE_OBJECT_STATUS イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v query_name: STRING

v object_name: STRING

v object_type: INTEGER

v object_type_enum: STRING

v object_status: INTEGER


v object_status_enum: STRING

v error_code: INTEGER

v error_code_enum: STRING

v last_collection_start: STRING

v last_collection_start_enum: STRING

v last_collection_finished: STRING

v last_collection_finished_enum: STRING

v last_collection_duration: REAL

v average_collection_duration: REAL

v average_collection_duration_enum: STRING

v refresh_interval: INTEGER

v number_of_collections: INTEGER

v cache_hits: INTEGER

v cache_misses: INTEGER

v cache_hit_percent: REAL

v intervals_skipped: INTEGER

pro パフォーマンス・オブジェクト状況属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_PRO_PERFORMANCE_OBJECT_STATUS イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v query_name: STRING

v object_name: STRING

v object_type: INTEGER

v object_type_enum: STRING

v object_status: INTEGER

v object_status_enum: STRING

v error_code: INTEGER

v error_code_enum: STRING

v last_collection_start: STRING

v last_collection_start_enum: STRING

v last_collection_finished: STRING

v last_collection_finished_enum: STRING

v last_collection_duration: REAL

v average_collection_duration: REAL

v average_collection_duration_enum: STRING

v refresh_interval: INTEGER

v number_of_collections: INTEGER

v cache_hits: INTEGER

v cache_misses: INTEGER

付録 A. イベント・マッピング 155

v cache_hit_percent: REAL

v intervals_skipped: INTEGER

スレッド・プール状況属性グループのシチュエーションによってイベントが生成される場合は、ITM_KLO_THREAD_POOL_STATUS イベント・クラスを使用してイベントが送信されます。このイベント・クラスには、以下のスロットが含まれます。

v node: STRING

v timestamp: STRING

v thread_pool_size: INTEGER

v thread_pool_size_enum: STRING

v thread_pool_max_size: INTEGER

v thread_pool_max_size_enum: STRING

v thread_pool_active_threads: INTEGER

v thread_pool_active_threads_enum: STRING

v thread_pool_avg_active_threads: REAL

v thread_pool_avg_active_threads_enum: STRING

v thread_pool_min_active_threads: INTEGER

v thread_pool_min_active_threads_enum: STRING

v thread_pool_max_active_threads: INTEGER

v thread_pool_max_active_threads_enum: STRING

v thread_pool_queue_length: INTEGER

v thread_pool_queue_length_enum: STRING

v thread_pool_avg_queue_length: REAL

v thread_pool_avg_queue_length_enum: STRING

v thread_pool_min_queue_length: INTEGER

v thread_pool_min_queue_length_enum: STRING

v thread_pool_max_queue_length: INTEGER

v thread_pool_max_queue_length_enum: STRING

v thread_pool_avg_job_wait: REAL

v thread_pool_avg_job_wait_enum: STRING

v thread_pool_total_jobs: INTEGER

v thread_pool_total_jobs_enum: STRING


付録 B. Windows 2008 イベント・ログ

このセクションでは、Tivoli Log File Agent が Windows イベント・ログからのイベントをモニターする方法について説明します。

Tivoli Log File Agent は従来どおり、WINEVENTLOGS 構成 (.conf) ファイル・オプションを使用して、Windows イベント・ログからのイベントをモニターします。エージェントは、以下の例に示すように、イベント・ログのコンマ区切りリストをモニターします。

WINEVENTLOGS=System,Security,Application

また、Tivoli Log File Agent は従来どおり、WINEVENTLOGS=All 設定を使用します。 All 設定は、2008 より前の Windows バージョンで提供される標準イベント・ログ (セキュリティー、アプリケーション、システム、ディレクトリー、ドメイン・ネーム・システム (DNS)、およびファイル複製サービス (FRS)) を意味します。しかし、システム上のすべてのイベント・ログが検査されるわけではありません。

UseNewEventLogAPI という名前の構成ファイル・タグがあります。このタグを指定すると、イベント・ログ(Windows イベント・ログ 2008 以降) は、Microsoft によって追加されたすべての新規ログ、および他のアプリケーションまたはユーザーによって作成されたすべての Windows イベント・ログにアクセスできます。新規ログは、WINEVENTLOGS キーワードによってリストされます。

以下の例では、UseNewEventLogAPI タグは y に設定されます。

UseNewEventLogAPI=yWINEVENTLOGS=Microsoft-Windows-Hyper-V-Worker-Admin

この例では、Hyper-V 役割を持つ Windows システム上で Microsoft-Windows-Hyper-V/Admin がモニターされます。

Windows イベント・ログ内では、各イベントに以下のフィールドがあり、この順序で配列されています。

v 日付 (フォーマット: 月、日、時刻、および年)

v イベント・カテゴリーは整数です。

v イベント・レベル

v Windows セキュリティー ID。構成 (.conf) ファイル内で SpaceReplacement=TRUE である場合、Windows セキュリティー ID 内のすべてのスペースは下線に置き換えられます。

注: SpaceReplacement=TRUE は、(.conf) ファイル内で UseNewEventLogAPI を y に設定した (2008 イベント・ログを使用していることを指定した) 場合のデフォルトです。

v Windows ソース。構成 (.conf) ファイル内で SpaceReplacement=TRUE である場合、Windows ソース内のすべてのスペースは下線に置き換えられます。

v Windows イベント・ログ・キーワード。構成 (.conf) ファイル内で SpaceReplacement=TRUE である場合、Windows イベント・ログ・キーワード内のすべてのスペースは下線に置き換えられます。

注: ここで説明するキーワード・フィールドは、Windows 2008 バージョンのイベント・ログでは新規です。このキーワード・フィールドは前のイベント・ログには存在しなかったため、これが含まれている場合、古いイベント・ログ・フォーマット指定ステートメントをそのまま再使用することはできません。この追加のフィールドに対応するようにステートメントを変更する必要があります。

v Windows イベント ID


v メッセージ・テキスト

例えば、管理ユーザーが Windows 2008 システムにログオンすると、新規ユーザー・セッションに割り当てられた特権を示すイベントがセキュリティー・ログ内で生成されます。

Mar 22 13:58:35 2011 1 Information N/A Microsoft-Windows-Security-Auditing Audit_Success 4672 Special privileges assigned to new logon.S-1-5-21-586564200-1406810015-1408784414-500 Account Name:Administrator Account Domain: MOLDOVA Logon ID:0xc39cb8e Privileges: SeSecurityPrivilegeSeBackupPrivilege SeRestorePrivilegeSeTakeOwnershipPrivilege SeDebugPrivilegeSeSystemEnvironmentPrivilege SeLoadDriverPrivilegeSeImpersonatePrivilege

Microsoft-Windows-Security-Auditing イベント・ソースによって作成されたすべてのイベントを取り込むには、以下に示すように、フォーマット指定ステートメントを記述します。

REGEX BaseAuditEvent^([A-Z][a-z]{2} [0-9]{1,2} [0-9]{1,2}:[0-9]{2}:[0-9]{2} [0-9]{4}) [0-9] (¥S+) (¥S+) Microsoft-Windows-Security-Auditing (¥S+)([0-9]+) (.*)timestamp $1severity $2login $3eventsource "Microsoft-Windows-Security-Auditing"eventkeywords $4eventid $5msg $6END

以下の例は、上記のイベント例のスロットに割り当てられる値を示します。

timestamp=Mar 22 13:58:35 2011severity=Informationlogin=N/Aeventsource=Microsoft-Windows-Security-Auditingeventid=4672msg="Special privileges assigned to new logon.S-1-5-21-586564200-1406810015-1408784414-500 Account Name:Administrator Account Domain: MOLDOVA Logon ID:0xc39cb8e Privileges: SeSecurityPrivilegeSeBackupPrivilege SeRestorePrivilegeSeTakeOwnershipPrivilege SeDebugPrivilegeSeSystemEnvironmentPrivilege SeLoadDriverPrivilegeSeImpersonatePrivilege

これらのイベントがどのように表示されるかを正確に予測するのは難しいため、正規表現を記述するときには、実際のイベントをファイル内に取り込む手法を使用することをお勧めします。その後、このファイルを確認し、エージェントに取り込ませるイベントを選択し、これらのイベントと一致する正規表現を記述することができます。Windows イベント・ログからすべてのイベントを取り込むには、以下のステップを実行します。

1. 以下の例に示すように、どのイベントとも一致しない 1 つのパターンのみを含むフォーマット・ファイルを作成します。

REGEX NoMatchThis doesn’t match anythingEND

2. 以下の設定を構成 (.conf) ファイルに追加します。

UnmatchLog=C:/temp/evlog.unmatch

3. エージェントを実行し、いくつかのサンプル・イベントを取り込みます。


付録 C. 文書ライブラリー

Tivoli Log File Agent の使用法に関して、さまざまな資料が用意されています。

「IBM Tivoli Monitoring、OMEGAMON XE、および Composite Application Manager 製品: ドキュメント・ガイド」には、資料の入手および使用に関する情報が記載されています。「ドキュメント・ガイド」は、以下のインフォメーション・センターで見つけることができます。

v IBM Tivoli Monitoring and OMEGAMON® XE (http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/

index.jsp)

v IBM Tivoli Composite Application Manager (http://publib.boulder.ibm.com/infocenter/tivihelp/v24r1/index.jsp)

インフォメーション・センターの「ドキュメント・ガイド」を開くには、「目次」ペインの『マニュアルの使用法』を選択してください。

新規資料および変更された資料のリストについて確認するには、IBM Tivoli Monitoring and OMEGAMON

XE のインフォメーション・センターのウェルカム・ページにある「What's new in the informationcenter」をクリックしてください。

旧バージョンの製品の資料について確認するには、「目次」ペインで製品名の下にある「前のバージョン」をクリックしてください。

Tivoli Log File Agent ライブラリー

このエージェントおよびその他の製品コンポーネントの資料は、IBM Tivoli Monitoring インフォメーション・センター (http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/index.jsp) にあります。

Log File Agent専用の資料があります。「Tivoli Log File Agent ユーザーズ・ガイド」には、Log File

Agentの構成、使用、およびトラブルシューティングに関するエージェント固有の情報が記載されています。

「オファリング・ガイド」にも、このオファリングのコンポーネント製品のインストールと構成に関する情報が記載されています。

インフォメーション・センターの『Prerequisites』トピックには、各コンポーネントの前提条件に関する情報が記載されています。

アプリケーション・ログ・ファイル・リソースをモニターするには、エージェントのユーザーズ・ガイドの情報と「Tivoli Enterprise Portal ユーザーズ・ガイド」を併せて使用してください。

前提資料本書の情報を有効に活用するには、いくつかの前提知識が必要です。

必要な前提知識を得るためには、以下の資料を参照してください。

v IBM Tivoli Monitoring 管理者ガイド

v IBM Tivoli Monitoring Agent Builder ユーザーズ・ガイド

v IBM Tivoli Monitoring コマンド・リファレンス


http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp

http://publib.boulder.ibm.com/infocenter/tivihelp/v24r1/index.jsp

http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/index.jsp

http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/index.jsp

v IBM Tivoli Management Services on z/OS: Tivoli Enterprise Monitoring Server on z/OS の構成

v IBM Tivoli Monitoring インストールおよび設定ガイド

v IBM Tivoli Monitoring 分散システム用高可用性ガイド

v IBM Tivoli Monitoring: メッセージ

v IBM Tivoli Monitoring トラブルシューティング・ガイド

v IBM Tivoli Monitoring Universal Agent ユーザーズ・ガイド

v IBM Tivoli Universal Agent API およびコマンド・プログラミングのリファレンス

v IBM Tivoli Monitoring: i5/OS™ Agent ユーザーズ・ガイド

v IBM Tivoli Monitoring: Linux OS Agent ユーザーズ・ガイド

v IBM Tivoli Monitoring: UNIX OS Agent ユーザーズ・ガイド

v IBM Tivoli Monitoring: UNIX Logs OS Agent ユーザーズ・ガイド

v IBM Tivoli Monitoring: Windows OS Agent ユーザーズ・ガイド

v Tivoli Enterprise Portal ユーザーズ・ガイド

v IBM Tivoli Performance Analyzer ユーザーズ・ガイド

v IBM Tivoli Warehouse Proxy Agent ユーザーズ・ガイド

v IBM Tivoli Warehouse Summarization and Pruning Agent ユーザーズ・ガイド

関連資料関連のインフォメーション・センターにある資料により、役に立つ情報が得られます。

以下の各インフォメーション・センターを参照してください。これらのインフォメーション・センターを参照するには、 Tivoli Documentation Central (http://www.ibm.com/tivoli/documentation) にアクセスしてください。

v IBM Tivoli Monitoring

v IBM Tivoli Netcool/OMNIbus

v IBM Tivoli Application Dependency Discovery Manager

v IBM Tivoli Enterprise Console

その他の文書の入手先その他のソースからモニター製品に関する追加の技術文書を入手することができます。

モニター製品に関する技術文書については、以下のソースを参照してください。

v Service Management Connect (SMC)

SMC に関する入門情報 (http://www.ibm.com/developerworks/servicemanagement/) を参照してください。

Tivoli 製品については、SMC の Application Performance Management コミュニティー(http://www.ibm.com/developerworks/servicemanagement/apm/index.html) を参照してください。

サービス管理の専門家との連絡、学習、および共有を行います。開発者や製品サポートの技術者と交流して、見解や専門知識を得ることができます。SMC は以下の目的で使用できます。


http://www.ibm.com/tivoli/documentation

http://www.ibm.com/developerworks/servicemanagement/

http://www.ibm.com/developerworks/servicemanagement/apm/index.html

– 透過的な開発、つまり外部ユーザーと Tivoli 製品の開発者の間で進められているオープンな連携に参加する。これにより、初期設計、スプリント・デモ、製品ロードマップ、プレリリース・コードにアクセスできます。

– エキスパートに直接連絡を取って、Tivoli および統合サービス管理に関するコラボレーションやネットワーク化を行う。

– ブログを使用している他のユーザーの専門知識や経験を取り入れる。

– Wiki やフォーラムを使用して幅広いユーザー・コミュニティーとコラボレーションする。

v IBM Integrated Service Management Library (http://www.ibm.com/software/brandcatalog/ismlibrary/) は、統合資料、およびその他のダウンロード可能な製品の拡張機能を含むオンライン・カタログです。

v IBM Redbook 資料 (http://www.redbooks.ibm.com/) には、プラットフォームとソリューションの観点から見た製品情報を提供する Redbooks® 資料、Redpapers、および Redbooks 技術情報が用意されています。

v IBM サポート・ホーム Web サイトからアクセスできる技術情報 (http://www.ibm.com/support/entry/

portal/software) では、製品に関連した既知の制限および回避策に関する最新情報が提供されます。

v Tivoli wiki

Tivoli Wiki Central (http://www.ibm.com/developerworks/wikis/display/tivoli/Home) は、Tivoli 製品を使用するためのベスト・プラクティスおよびシナリオを提供する、対話式 wiki のホームです。 wiki には、IBM 社員が投稿したホワイト・ペーパーや、お客様およびビジネス・パートナーが作成したコンテンツが含まれています。

以下の 2 つの wiki は、IBM Tivoli Monitoring に特に関連があります。

– Tivoli Distributed Monitoring and Application Management Wiki (http://www-10.lotus.com/ldd/

tivmonitorwiki.nsf) では、IBM Tivoli Monitoring、および IBM Tivoli Composite Application Manager

製品などの関連配布製品に関する情報が提供されます。

– Tivoli System z® Monitoring and Application Management Wiki (http://www.ibm.com/developerworks/

wikis/display/tivoliomegamon/Home) には、OMEGAMON XE 製品、Tivoli NetView® for z/OS®、Tivoli

Monitoring Agent for z/TPF、およびその他の System z モニターおよびアプリケーション管理製品に関する情報が記載されています。

付録 C. 文書ライブラリー 161

http://www.ibm.com/software/brandcatalog/ismlibrary/

http://www.redbooks.ibm.com/

http://www.ibm.com/support/entry/portal/software

http://www.ibm.com/developerworks/wikis/display/tivoli/Home

http://www-10.lotus.com/ldd/tivmonitorwiki.nsf

http://www.ibm.com/developerworks/wikis/display/tivoliomegamon/Home


特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものであり、本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510

東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

以下の保証は、国または地域の法律に沿わない場合は、適用されません。

IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。

国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Corporation

2Z4A/101

11400 Burnet Road

Austin, TX 78758 U.S.A.


本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

表示されている IBM の価格は IBM が小売り価格として提示しているもので、現行価格であり、通知なしに変更されるものです。卸価格は、異なる場合があります。

本書はプランニング目的としてのみ記述されています。記述内容は製品が使用可能になる前に変更になる場合があります。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

著作権使用許諾:

本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。お客様は、IBM のアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。

それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作物にも、次のように、著作権表示を入れていただく必要があります。

© IBM 2009. このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。© Copyright

IBM Corp. 2009. All rights reserved.


この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。

商標IBM、IBM ロゴおよび ibm.com® は、世界の多くの国で登録された International Business Machines

Corporation の商標です。他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、「Copyright and trademark information」(www.ibm.com/legal/copytrade.shtml) をご覧下さい。

インテル、Intel、Intel ロゴ、Xeon は、Intel Corporation または子会社の米国およびその他の国における商標または登録商標です。

Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。

Linux は、Linus Torvalds の米国およびその他の国における商標です。

Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。

UNIX は The Open Group の米国およびその他の国における登録商標です。

特記事項 165

http://www.ibm.com/legal/copytrade.shtml


索引日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］アクション実行コマンド概要 107

事前定義 107, 109

追加情報 107

問題および解決方法 149

アクティビティー 109

一致しなかった正規表現ワークスペース 63

一致レコード数属性 76

イベントマッピング 151

イベントの転送Tivoli Netcool OMNIbus ObjectServer への 19, 21

イベントのフィルタリング 52

イベント・タイプ属性 80, 84

イベント・フィルタリングおよび要約 51

要約間隔 52

要約属性 53

Tivoli Enterprise Portal での表示 53

インストールコマンド

tacmd addSystem 18


リモート・インストールおよび構成 18

tacmd addSystem コマンド 18

インターフェースユーザー 3

エージェント機能 1


エージェント管理サービス 3

エージェントの開始 19

エラー・コード属性 87, 93

オブジェクト状況属性 87, 92

オブジェクト名属性 86, 92

オブジェクト・タイプ属性 87, 92

［カ行］解決方法 125

概要IBM Tivoli Monitoring 1

カスタム整数型 1 属性 80, 85



カスタム・スロット 1 属性 78, 83










技術情報 160

機能拡張 1

キャッシュで未検出属性 90, 96

キャッシュ・ヒット属性 90, 95

キャッシュ・ヒット率属性 91, 96

キャパシティー・プランニング、ヒストリカル・データの 100

クラス属性 78, 82

計算、ヒストリカル・データのディスク・スペースの 100

結果タイプ属性 73

現行ファイル位置属性 76

現行ファイル・サイズ属性 76

コード・ページ属性 77

合計 CPU の高い正規表現ワークスペース 62

合計プロセッサー時間属性 71

構成一元化された構成 14

インストール後の 9

構成パネル 9

構成ファイル 12, 27

コマンド行 11

モニター・エージェントの構成 9


リモート・インストールおよび構成 18

構成ファイル 12, 27

変更 13

このリリースの新機能 1

コマンドアクション実行 107

コンポーネント 2

IBM Tivoli Monitoring 2

［サ行］最終一致時刻属性 73

最終収集開始属性 89, 94

最終収集完了属性 89, 95

最終収集期間属性 90, 95

最終不一致時刻属性 73

最終変更時刻属性 77

最小プロセッサー時間属性 72

最新表示間隔属性 90, 95


最大プロセッサー時間属性 72

サブノード動作方法 23

モニター・プロファイル 23

Log File Agent サブノード 23

サブノード MSN 属性 69

サブノードの構成ファイル属性 70

サブノードの説明属性 70

サブノードのバージョン属性 69

サブノード・アフィニティー属性 69

サブノード・タイプ属性 69

サブノード・リソース名属性 69

シチュエーション 104

概要 103

事前定義 104

シチュエーション・エディター 103

追加情報事前定義、定義 103


KLO_Log_Agent_Config_Error 104

KLO_PRO_Log_Agent_Config_Error 105

シチュエーション、属性の使用 67

収集の数属性 90, 95

照会、属性の使用 67

照会名属性 86, 91

詳細 119

処理レコード数属性 76

資料 159, 160

関連 160

技術情報 160

前提 159

developerWorks Web サイト 160

IBM Tivoli Monitoring 159

Integrated Service Management Library 160

Redbooks 160

Wiki 160

スキップされた間隔属性 91, 96

すべての正規表現の統計ワークスペース 61

スレッド・プール合計ジョブ属性 99

スレッド・プール最大サイズ属性 97

スレッド・プールのアクティブ・スレッド属性 97

スレッド・プールの最小アクティブ・スレッド属性 98

スレッド・プールの最大アクティブ・スレッド属性 98

スレッド・プールの状況属性グループ 96

スレッド・プールの平均アクティブ・スレッド属性 97

スレッド・プールの平均ジョブ待機属性 99

スレッド・プール・キューの最小の長さ属性 99

スレッド・プール・キューの最大の長さ属性 99

スレッド・プール・キューの長さ属性 98

スレッド・プール・キューの平均の長さ属性 98

スレッド・プール・サイズ属性 96

正規表現パターン属性 73, 74

説明 104

前提資料 159

属性 68

一致レコード数 76

属性 (続き)

イベント・タイプ 80, 84

エラー・コード 87, 93

オブジェクトの状況 87, 92

オブジェクト名 86, 92

オブジェクト・タイプ 87, 92

概要 67

カスタム整数型 1 80, 85



カスタム・スロット 1 78, 83










キャッシュで未検出 90, 96

キャッシュ・ヒット 90, 95

キャッシュ・ヒット率 91, 96

クラス 78, 82

結果タイプ 73

現行ファイル位置 76

現行ファイル・サイズ 76

コード・ページ 77

合計プロセッサー時間 71

最終一致時刻 73

最終収集開始 89, 94

最終収集完了 89, 95

最終収集期間 90, 95

最終不一致時刻 73

最終変更時刻 77

最小プロセッサー時間 72

最新表示間隔 90, 95

最大プロセッサー時間 72

サブノード MSN 69

サブノードの構成ファイル 70

サブノードの説明 70

サブノードのバージョン 69

サブノード・アフィニティー 69

サブノード・タイプ 69

サブノード・リソース名 69

収集の数 90, 95

照会名 86, 91

処理レコード数 76

スキップされた間隔 91, 96

スレッド・プール合計ジョブ 99

スレッド・プール最大サイズ 97

スレッド・プールのアクティブ・スレッド 97

スレッド・プールの最小アクティブ・スレッド 98

スレッド・プールの最大アクティブ・スレッド 98

スレッド・プールの状況 96

スレッド・プールの平均アクティブ・スレッド 97


属性 (続き)

スレッド・プールの平均ジョブ待機 99

スレッド・プール・キューの最小の長さ 99

スレッド・プール・キューの最大の長さ 99

スレッド・プール・キューの長さ 98

スレッド・プール・キューの平均の長さ 98

スレッド・プール・サイズ 96

正規表現パターン 73, 74

属性名 71

タイム・スタンプ 69, 70, 74, 78, 82, 86, 91, 96

追加情報 67

ノード 69, 70, 74, 78, 82, 86, 91, 96

発生回数 80, 84

パフォーマンス・オブジェクトの状況 86

表の名前 71, 74

ファイル状況 75

ファイル名 74

ファイル・タイプ 74

不一致レコード数 76

フィルター一致回数 72

フィルター回数 72

フィルター番号 71

フィルター不一致回数 72

平均収集期間 90, 95

平均プロセッサー時間 71

リモート・ホスト 77, 81, 86

ログ名 78, 82

ログ・ファイル状況 74

ログ・ファイル正規表現統計 70

EIF イベント 78, 82

LFA プロファイル 69

LogFile イベント 77

LogfileProfile イベント 82

msg 78, 83

pro パフォーマンス・オブジェクト状況 91

属性グループ 68

概要 67

スレッド・プールの状況 96

全リスト 67

パフォーマンス・オブジェクトの状況 86

ログ・ファイル状況 74

ログ・ファイル正規表現統計 70



LogfileProfile イベント 82

pro パフォーマンス・オブジェクト状況 91

属性名属性 71

ソフトウェア製品互換性レポート 8

［タ行］タイム・スタンプ属性 69, 70, 74, 78, 82, 86, 91, 96

重複イベント検出およびフィルタリング 51

追加情報アクション実行コマンド 107

追加情報 (続き)


属性 67

ワークスペース 59

データ収集 5

データ収集状況 (リモート) ワークスペース 61

データ収集状況ワークスペース 61

データ・ソース 5, 8

ディスク・キャパシティー・プランニング、ヒストリカル・データの 100

ディスク・スペース 7

トラブルシューティング 111, 140, 141

アクション実行コマンド 149

アンインストール 125

インストール 125

エージェント固有 132

エージェント固有のワークスペース 142


トレースをオフにする 124

トレースをオンにする 123


リモート・デプロイメント 131


トレース 119

オフにする 124

オンにする 123

トレース設定 121

［ナ行］ノード属性 69, 70, 74, 78, 82, 86, 91, 96

［ハ行］発生回数属性 80, 84

パフォーマンスの考慮事項 145

パフォーマンス・オブジェクト状況属性グループ 86

パフォーマンス・オブジェクトの状況シチュエーション 104

ヒストリカル・データディスク・キャパシティー・プランニング 100

ディスク・スペースの計算 100

ビュー一致しなかった正規表現ワークスペース 63

合計 CPU の高い正規表現ワークスペース 62

すべての正規表現の統計ワークスペース 61

データ収集状況 (リモート) ワークスペース 61

データ収集状況ワークスペース 61

平均 CPU の高い正規表現ワークスペース 62

ログ・ファイル・ワークスペース 61

LFA プロファイル・ワークスペース 64

Logfile イベント (リモート) ワークスペース 62

Logfile イベント (v6) ワークスペース 63, 64

LogFile イベント・ワークスペース 64

Tivoli Log File Profile (リモート) ワークスペース 63

索引 169

表の名前属性 71, 74

ファイル状況属性 75

ファイル名属性 74

ファイル・タイプ属性 74

不一致レコード数属性 76

フィルター一致回数属性 72

フィルター回数属性 72

フィルター番号属性 71

フィルター不一致回数属性 72

フォーマット・ファイル 39

キーワード 47

継承 43

最大メッセージ長 49

フォーマット・ファイル仕様 39

複数行 44

変更 13

マッピング 45

値指定子 46

文書参照：資料

平均 CPU の高い正規表現ワークスペース 62

平均収集期間属性 90, 95

平均プロセッサー時間属性 71

ポリシー 109

［マ行］メッセージ属性 78, 83

モニター・エージェントの要件 7

モニター・プロファイル 23


アクション実行コマンド 149

インストール 125

エージェント固有 132

エージェント固有のワークスペース 142

構成 125


リモート・デプロイメント 131


［ヤ行］ユーザー・インターフェースのオプション 3

要件インストール 7

構成 7

ソフトウェア製品互換性レポート 8

［ラ行］リモートインストールおよび構成 18

リモート・デプロイメント問題および解決方法 131

リモート・ホスト属性 77, 81, 86

リモート・ログ・ファイル・モニター 15

暗号化パスフレーズ 17

パスワード 17

トラブルシューティング 141

ログ名属性 78, 82

ログ・ファイルワークスペース説明 61

ログ・ファイル状況属性グループ 74

ログ・ファイル正規表現統計属性グループ 70

ログ・ファイル・ワークスペース 61

［ワ行］ワークスペース一致しなかった正規表現 63

概要 59

合計 CPU の高い正規表現 62

事前定義 60

すべての正規表現の統計 61

説明 61

追加情報 59

データ収集状況 (リモート) 61

データの収集状況 61

平均 CPU の高い正規表現 62


ログ・ファイル 61



Logfile イベント (リモート) 62

Logfile イベント (v6) 63, 64

Tivoli Log File Profile 65

Tivoli Log File Profile (リモート) 63

ワークフロー・エディター 109

CCPU

CPU スロットル 14

CPU スロットル 140

DdeveloperWorks Web サイト 160

EEIF イベント属性 78, 82

IIBM Tivoli Monitoring 2

概要 1


IBM Tivoli Monitoring バージョン 7

Integrated Service Management Library の資料 160

KKLO_Log_Agent_Config_Error シチュエーション 104

KLO_PRO_Log_Agent_Config_Error シチュエーション 105

LLFA プロファイルワークスペース説明 64

LFA プロファイル属性グループ 68

LFA プロファイル・ワークスペース 64

Linux 互換性ライブラリー 7

Log File Agent

パフォーマンスの考慮事項 145

LogFile イベントワークスペース説明 64

Logfile イベント (リモート) ワークスペース 62

Logfile イベント (v6) ワークスペース 63, 64

LogFile イベント属性グループ 77

LogFile イベント・ワークスペース 64

LogfileProfile イベント属性グループ 82

OObjectServer の構成 20

Ppro パフォーマンス・オブジェクト状況シチュエーション 105

pro パフォーマンス・オブジェクト状況属性グループ 91

Probe for Tivoli EIF 22

プロパティー 22

UNIX 上での実行 22

Windows 上での実行 22

Rras1 121

Redbooks 160

TTivoli Enterprise Console

イベント・マッピング 151

Tivoli Log File Profile

ワークスペース説明 65

Tivoli Log File Profile (リモート) ワークスペース 63

Tivoli Netcool/OMNIbus バージョン 7

WWiki 160

Windows 2008 イベント・ログ 157

索引 171


��

Printed in Japan

SA88-4868-01

Documents

Tivoli Log File Agentください。Log File Agent 固有のソフトウェア製品互換性レポートを実行する方法については、8 ペー ジの『Log File Agent 用のソフトウェア製品互換性レポートの生成』を参照してください。v

Tivoli Log File Agentください。Log File Agent 固有のソフトウェア製品互換性レポートを実行する方法については、8 ページの『Log File Agent 用のソフトウェア製品互換性レポートの生成』を参照してください。v