このセクションでは、GT.Mメッセージのモニタリングに関する情報をカバーしています。メッセージにはいくつかのタイプがあります。

システム管理ツールは、メッセージのモニタリングの自動化に役立ちます。

GT.Mは、LOG_USER機能のLOG_INFOレベルで、システムログにメッセージを送信します。GT.Mメッセージは、 -s-が重要度の指標であり、abcdefが識別子である GTM-s-abcdef 形式のフォームの署名によって識別されます。重要度の指標は：情報メッセージの -I- 、警告の-W- 、エラーの-E- 、異常終了するGT.Mプロセスを引き起こすイベントの -F- です。あなたのモニタリングは、リアルタイムで重要なイベントを、そして、適切な時間内に警告のイベントを認識する必要があります。すべてのメッセージは、診断的価値を持っています。- 予期しないメッセージの有無、予想されるメッセージ（ファイル拡張子のような）の通常の数、または、予想されるメッセージの欠如 - それが起こる時に異常な動作を認識可能なこのベースラインからの偏差となるように、システムの正常な動作のsignature：署名 としてメッセージのベースラインのパターンを作成することが重要です。リアルタイムで重要なイベントに応答するために加えて、定期的に、情報と警告メッセージをレビューし、ベースラインからの偏差を説明できるように確認できるようにする必要があります。

いくつかのメッセージ識別子については、次の表で説明します：

システムログ内のメッセージとアプリケーションプログラムによって作成されたデータベースファイルとファイルが離れていることに加えて、GT.Mはファイルのいくつかのタイプを作成します：ジャーナルファイル、レプリケーションログファイル、gtmsecshr ログファイル、プロセス間通信のソケットファイル、リカバリ / ロールバックからのファイル、JOBプロセスからの出力とエラーファイル。あなたは、レビューと保持ポリシーを開発する必要があります。ジャーナルファイルとリカバリ/ ロールバックからのファイルには、ビジネスや法律上の要件を満たすために特別な処理を必要とする機密情報が含まれている可能性があります。ベースラインでセットされた予測とは大幅に異なるそのファイル番号またはサイズの増大のために、これらのファイルのすべてをモニターしてください。特に、ファイルサイズのモニタリングは、計算コストが安く定期モニタリングがあります。例えば、1時間に一度など、システムの crontab で簡単に達成されます。

ジャーナルファイルが上限に達する時に新しいファイルに自動的に切り替えている間、ログファイルはチェックのない増大があります。定期的にログファイルのサイズをチェックし、それらが大きな時にそれらを切り替える必要があります - または、定期的にそれらを単に切り替えます。

データベースの健全性が重要なので、データベースの増大には特別な注意をする根拠があります。データベースファイルを保持するすべてのファイルシステムが、それが保持するファイルの予想される増大を処理するのに十分なスペースがあることを確認してください。UNIXファイルシステムで使用される遅延割り当て(lazy allocation)で、システム内のすべてのファイルがそのスペースのために完全になることを、覚えておいてください。GT.Mは、それがデータベースファイルを拡張する毎に、情報メッセージを発行します。もし残りのスペースが拡張サイズの3倍より少ない場合は、ファイルを拡張する時に、それはまた警告を発行します。データベース内のブロックの合計数だけでなく、空きブロックの数を調べるために、$VIEW() 関数を使用することができます。

ジャーナルファイルは更新毎に増大するにつれ、データベースファイルより高速なディスクを使用してください。ジャーナルファイルが自動ジャーナルファイルのスイッチ制限からブロックの拡張サイズの数が、3、2、１に達した時に、GT.Mはメッセージを発行します。ジャーナルファイルは、その指定された最大サイズに達する時に、GT.Mもメッセージを発行し、GT.Mはそのときにそれをクローズし、それをリネームし、新しいジャーナルファイルを作成します。最後のデータベースバックアップより以前（またはレプリケーションしているセカンダリインスタンスのバックアップより以前）の期間をカバーしているジャーナルファイルは、ビジネスの継続性のためには必要とされていなくてポリシーの持続に依存している削除やアーカイブができます。ファイルシステム内の空き容量は少なくとも毎時そしておそらくもっと頻繁にチェックしてください、特にファイルシステムがジャーナリングを使用していて、もしそれがしきい値を下回る場合にアクションを取ってください。

GT.Mは、トランザクション番号と呼ばれる、単調に増加する相対的なタイムスタンプを使用しています。DSE DUMP -FILEHEADER でデータベースのトランザクション番号の増加をモニターできます。増大率のベースラインからの偏差のために十分な説明について、調査し取得してください。

MUPIP JOURNAL -ROLLBACK（レプリケートのないアプリケーションの設定）または MUPIP JOURNAL -RECOVER -FETCHRESYNC（レプリケートされたアプリケーションの設定）の後に、壊れていてレプリケートされていない（ロストされた）トランザクションファイルでの更新をレビューし処理または調停する必要があります。

レプリケートされた環境で、頻繁に（少なくとも毎時、それが実質的にシステムリソースを取らないので、より頻繁に助言）、MUPIP REPLICATE -CHECKHEALTH と -SHOWBACKLOGで、レプリケーションとバックログの状態をチェックしてください。バックログのベースラインを確立し、もしバックログがしきい値を超えた場合にアクションを取ってください。

GT.Mプロセスが異常終了する時、それは、Mの実行コンテキストのダンプを含んでいるGTM_FATAL_ERROR.ZSHOW_DMP_* ファイルと、ネイティブプロセスの実行コンテキストのダンプを含んでいるコアファイルを作成しようと試みます。 Mの実行コンテキストのダンプは、プロセスの現在の作業ディレクトリに作成されます。お使いのオペレーティングシステムでは、コアファイルの名づけと配置をコントロールする手段を提供します；デフォルトでそれらは、core.* の名前を持つプロセスの現在の作業ディレクトリに作成します。プロセスのコンテキスト情報は、問題が発生し、そして/または、アプリケーションの状態で障害の結果をどのように対処する状況下で、事実を理解する上で役に立つかもしれません。コアファイルは、主にGT.Mのサポートチャネルに有用であると考えられます。もしあなたがプロセスの失敗を経験するが、予想されるファイルが見つからない場合は、ファイルのアクセス権とクオータをチェックしてください。プロセスにSIGILLを（ほとんどのUNIX/ Linuxシステムでは kill -ILL または kill -4 が付く）送信することによりプロセスの異常終了をシミュレートすることができます。

JOBコマンドで発行されたGT.Mプロセスが、STDERRとSTDOUTのためのそれぞれ .mje と .mjo ファイルを作成します。空でない .mjeファイルを分析してください。いったんそれらが不要になるような .mjo ファイル を削除またはアーカイブするための、アプリケーション、および/または、運用プロセスをデザインしてください。

予想外に長時間リソースを保持しているプロセス用にモニタリングをトリガするために、環境変数 gtm_procstuckexe を使用してください。$gtm_procstuckexe は、次のいずれかの条件が発生したときに実行するシェルコマンドまたはスクリプトを指定します。

gtm_procstuckexec によってポイントされたシェルスクリプトやコマンドが、アラートを送信でき、修正アクションを取ることができ、ログ情報をとることができます。