ログ、メッセージなどユーザープログラムやシステムプログラムを実行した際に出力されるログについてご紹介します。今回は全般のご紹介にとどめています。次回以降でそれぞれの具体的な使い方等をご紹介予定です。iには大きく以下の3種類の管理インターフェースがありますが、今回ご紹介する様々なログ、メッセージはすべて3種類の管理インターフェース(図1)から参照することが可能です。以下の説明においては代表的なインターフェースからの操作画面を掲載しています。生成するログ、メッセージ類の一覧です。独自のログ、メッセージ類です。Server)等、他のプラットフォームと互換性のあるM/WやポーティングされたOSS等が出力するものです。その他のプラットフォームでも共通のフォーマットで出力されます。ログファイルのエンコードもEBCDICではなく他のプラットフォームと基本共通です。i上のプロパティファイル等から確認することが出来ます。図2のうち図3に挙げたものはアプリケーション稼働監視目的でよく使用されます。(その他のログ等も必要に応じて参照されることがあります。アプリケーション稼働監視目的でよく使用されるログ、メッセージ以下では各々のログ、メッセージについてご説明します。システム全般の活動状況がログされます。IPL時のメッセージ、また、この後説明するQSYSOPRにも出力される、システムとして重要なメッセージもログされます。活動記録ログは以下の2種類のオブジェクトで構成されています。*FILEログバージョンファイルは一定量に達すると履歴として書き出され複数世代に渡ってファイルが存在しています。*MSGQシステム操作員メッセージ待ち行列は以下のオブジェクトです。*MSGQシステムでの主要なイベント発生時や操作員への操作・応答の要求待ちメッセージ、障害時などに出力されるメッセージの出力先となるメッセージ待ち行列です。このメッセージ待ち行列を監視することで稼働全般の確認が可能です。*MSGQを運用監視対象としています。コマンド等で表示する方法が一般的ですが、ツール等を組合せて監視させることもできます。注意いただきたいのは、IPLでメッセージ待ち行例内のメッセージが初期化されてしまうことです。(※一方でQHST活動記録ログはIPL後も全て記録されたままとなります。)ちなみにメッセージ待ち行列はQSYSOPR以外のすべてのユーザープロフィールと5250端末デバイスにも自動的に作成され存在しています。それらにもメッセージが出力される場合があります。QPADEV0001,など)で表示することが出来ます。外部からのODBC/JDBC接続やプログラム実行等)やシステムが実行したあらゆるジョブのログです。(や設定によってはコマンド履歴が含まれる場合もあります)・処理に関する情報が記録されています。ジョブが終了した後スプール出力として保管することも可能です。(スプール出力しないとジョブ終了後にジョブ・ログを確認することはできません)。*OUTQにジョブ・ログが出力されます。コマンドを実行して、保管日数を指定(調整)することが出来ます。保管日数を超過した分はシステムがクリーンアップ削除してくれます。設定内容は下記のとおりです。自動クリーンアップの実行Y:クリーンアップを実行します。指定した時刻にクリーンナップを開始します。POWERコマンドでシステムのシャットダウン(PWRDWNSYS実行)を指定している場合(図8)、シャットダウン前にクリーンアップを実行します。▲図8「保存する日数」以下の項目ではそれぞれのログの保管日数を指定します。PF1キー(ヘルプキー)を押すと、詳細なクリーンアップ対象の説明が表示されますのでご参照ください。コマンドで任意に作成することが可能です。通常これらは、ユーザーアプリケーションでメッセージ等を出力しアプリケーションで利用するために作成されます。これらの*MSGQにも(サイズ的には微小かもしれませんが)メッセージが溜まることがありますので定期的にクリーンアップすることをお勧めいたします。(ESA)は、サーバーやストレージなどIBM製のハードウェアに無償標準で付属する、障害検知とIBMへの発報機能です。SystemsにもESAは装備されています。Systemsの初期導入時にESAもセットアップしておくことが一般的です。ESAは必ず導入されているお客様システムから起動され、IBMサイトへ接続しようとします。(IBMサイトからの接続要求はありません)。プロクシー経由での接続などにも対応しています。指定したメッセージ待ち行列、ジョブ・ログ、ライセンス内部コード・ログ、プロダクト活動ログなどに設定したフィルターに合致するメッセージ等の出力をモニターできます。開始時に監視セッションIDを指定することもでき、複数の監視セッションを定義し、区別してモニターすることも可能です。上での特定のユーザーによる操作や特定のオブジェクト(テーブルへのREAD/WRITE等やプログラムの変更・実行など)を指定しモニターする機能です。該当のインシデントが発生すると監査ジャーナルが出力されます。iサービスのSQLで参照することが出来ます。監査ジャーナルの設定方法は改めてご紹介したいと思います。iは標準でSNMPエージェントとMIBファイルを提供しています。ステータスを連携し監視させることが可能です。メッセージIDをモニターしてSNMPトラップを生成し出力することも可能です。これらについても別途改めてご紹介したいと思います。上記以外のログ等について以上が一般的に運用監視で用いられるログ、メッセージですが、それ以外のものについても簡単にご紹介しましょう。重要なものは改めてご紹介したいと思います。ジャーナルと呼びます。ジャーナルはデータベースレコード更新後のみ(AFTERイメージのみ)と更新前後(BEFORE/AFTERイメージ)の二つのパターンで取得できます。取得対象はライブラリー(スキーマ)やテーブル単位で指定できます。標準的なパフォーマンスデータ収集機能です。通常はこの収集サービスでのデータ取得でシステムの全般的なパフォーマンスの分析が可能です。図2にあるそれ以外のパフォーマンスデータ(パフォーマンストレース、詳細パフォーマンスデータ)は収集サービスよりも具体的、個別的で、パフォーマンス分析を深堀したい場合に利用することがあります。LANアダプターや通信アダプター経由で通信するデータを取得することができます。STRCMNTRCコマンドはNIC(アダプター)単位で通信データを記録することが出来ます。TRCCNNコマンドはWindowsや他のプラットフォームでも一般的なWireshark互換の通信トレースを取得できます。以下の記事をご参照ください。https://www.i-cafe.info/column/serials/dekiruibmi_no3TRCTCPAPPコマンドは、FTPやSMTPなどTCP/IPプロトコル単位で指定して通信トレースを取得することが可能で、特定のアプリケーションの問題判別などで有用です。上の通信トレース機能ではありませんが、ACSも通信トレース取得機能を持っています。ACS導入クライアントの両方で通信トレースを取得することもできます。H/Wログ、LICログDST画面かSTRSSTコマンドでSST画面を起動するとH/Wのエラーログ、LIC(ライセンス内部コード)のエラーログを確認できます。通常これらは何らかのエラーやH/W障害が発生した際に参照するものです。*MSGQなどにも出力されることがあります。