ここでは、ログの運用方法について、設計時に検討しておくべきことについて説明します。
管理サーバ/統合管理サーバでの検討項目
Systemwalker Desktop Keeperを運用し、ログを収集し続けると、保存領域が足りなくなります。このため、管理サーバ/統合管理サーバ上のログを定期的に退避し、データベース領域を削除していくことにより、データベース領域を枯渇させることなく、安定した運用を行うことができます。
管理サーバ/統合管理サーバで決定しておく項目は以下のとおりです。
作成するデータベース(運用データベース、従来版のログ閲覧データベース、統合ログ閲覧データベース)
データベース容量(運用データベース、従来版のログ閲覧データベース、統合ログ閲覧データベース)
ログの退避方法・削除方法
付帯データの退避方法
退避したログ情報データの取り扱い方法
メール内容データの退避方法
ログ閲覧データベース(従来版のログ閲覧データベース、統合ログ閲覧データベース)へのデータ移行方法
運用データベース
運用データベースは、日々の運用情報(管理情報、操作ログ情報)を管理するデータベースです。
運用データベースは必ず作成する必要があります。
ログ閲覧データベース
退避したログ情報を復元して参照を目的にしたデータベースです。
V16.2.0では、V14.2.0より提供されていた従来版のログ閲覧データベースと、V16.2.0より提供される統合ログ閲覧データベースの2種類があり、どちらか一方を使用する事ができます。
この2つのデータベースは、格納できるデータ量や、運用面によって以下の違いがあるため、どちらのログ閲覧データベースを使用するかを事前に決定してください。
ログ閲覧データベースを使用しない運用も可能です。
比較項目 | 従来版のログ閲覧データベース | 統合ログ閲覧データベース |
使用目的 | 任意のタイミングで任意の期間の運用データベースのログを保存し参照するデータベース。 CTごとの検索や、ユーザーIDによるCT横串検索が行える。 | 前日までの全管理サーバの運用データベースのログを1つにまとめて保存し、かつ長期間のログ参照が可能なデータベース。 CTごとの検索や、ユーザーIDによるCT横串検索が行える。 |
設置基準 | 2階層構成の場合 またはCT5000台以下の場合 | 3階層構成の場合 またはCT5000台以上の場合 |
データベースを定義する管理サーバ | 管理サーバに定義 なお、3階層構成で利用したい場合は統合管理サーバに定義 | 統合管理サーバに定義 なお、頻繁にログ参照する場合は、運用側への影響を避けるために別途ログ参照専用サーバを用意して統合ログ閲覧データベースを作成する |
格納可能なログのデータ量 | 30億ログ程度まで | 100億ログ程度まで |
ログの保存期間 | 任意の期間のログを保存 | 直近2～14カ月の期間のログを保存(保存期間はデータベース作成時に指定) |
ログ保存の管理サーバ | 任意の管理サーバのログを格納 | 基本的に全管理サーバのログを格納 |
ログの参照 | ログビューアで[ログ閲覧データベース]を選択して参照 | ログビューアで[ログ閲覧データベース]を選択して参照 |
ログの検索速度 | 従来通り | 従来版に比較して高速(※) |
データベースの構築・削除 | サーバ設定ツールの[データベース構築・削除・情報表示]画面で実施 | DTKDBCREATE.EXE(データベース作成・削除)コマンドで実施 |
データベースの月次処理 | 不要 | DTKDBSPACE.EXE(データベース環境切り替え)コマンドを毎月1回実行 |
データのリストア方法 | ログ閲覧用データベースリストアツール、または、 | DTKTBLRESTORREF.EXE(統合版データベースリストア)コマンドで実施 |
ログのリストアの実施タイミング | 任意のタイミング | 毎日0時過ぎに運用データベースの前日1日分のログをリストアする なお、リストア時は管理サーバのサービス停止が必要 |
ログデータの追加と追加時間 | 可能、DTKTBLRESTOR.EXEコマンドで実施、格納済ログ量に比例して処理時間が長くなる | 可能、DTKTBLRESTORREF.EXEコマンドで実施、格納済ログ量が多くても処理時間は比較的一定 |
ログデータの削除 | 全件削除のみ可能(リストア時に指定) | DTKDBSPACE.EXE実行時に保存期間外の古いログは自動で削除 |
旧バージョンでバックアップした管理情報、ログ情報の利用 | 可能 | 可能 |
※ PCの性能(CPUのコア数が多い)や検索条件(複数日を指定、ファイル操作ログ/ファイル持出しログでドライブ種別を指定しての検索、等)によって、高速検索が可能です。
なお、CT台数/ログ数が少ない環境では性能が変わらない可能性があります。
運用データベースの容量を決定します
運用データベースは、日々の運用情報(管理情報、操作ログ情報)を管理するデータベースです。
以下の情報を設計時に検討し、運用データベース構築時の容量試算の要素を決定してください。
管理するクライアント(CT)の台数
ファイル操作ログ件数
ファイル操作以外のログ件数
保存月数
特に、保存月数については、ログの退避や削除の期間と連動する情報になるので、常にどれだけの期間のログを参照するかの決定が必要です。
ログ閲覧データベースの容量を決定します
ログ閲覧データベースは、過去の操作ログを移入して参照するためのデータベースです。
以下の情報を設計時に検討し、ログ閲覧データベース構築時の容量試算の要素を決定してください。
管理するクライアント(CT)の台数
保存月数
ファイル操作ログ件数、ファイル操作以外のログ件数については、運用データベースの値を元に容量試算を行います。
3階層でのシステム構成で、ログ閲覧データベースで下位の管理サーバも含め1度に検索を行いたい場合には、管理するクライアント(CT)の台数には下位管理サーバのクライアント(CT)台数も含めた台数を設定してください。
ログの退避／削除は、GUI、およびコマンドによるタスク実行などにより行います。定常的な運用を行う場合は、退避コマンドを実行するバッチを作成し、定期的に実行するようにしてください。GUI、コマンド、およびバッチ作成例は“3.1.2 ユーザー資産を退避する”を参照してください。また、設定変更ログについても、退避／削除を行う必要があります。設定変更ログの退避／削除は、コマンドによるタスク実行などにより行います。使用するコマンドおよび使用方法については“3.1.2 ユーザー資産を退避する”を参照してください。
ログの退避の考え方
ログの退避するタイミングは、以下の2つの考え方があります。
保存期間を過ぎたログを退避し、退避したログを削除します
直近のログを退避し、保存期間を過ぎたログを削除します
データベース容量はログ量が一時的に多くなる場合を想定して、保存月数に余裕をもって構築しておく必要があります。
付帯データはデータベースには保存されていません。またバックアップツールでの退避対象でないため、設定によってはサーバ(またはクライアント(CT))に画面キャプチャデータ、原本保管データが大量に蓄積され、ディスク容量が枯渇する可能性があります。このため上記のログ運用とは別に、定期的な容量確認とバックアップおよび削除を行ってください。
付帯データである画面キャプチャデータ、原本保管データの格納先フォルダの構成は、以下のとおりです。付帯データの格納先については、“2.2.4.11 保存先フォルダを設定する”を参照してください。
【構成】
付帯データの格納先フォルダ
+-日単位のフォルダ
+-CT単位のフォルダ
【例】
自動バックアップ機能やバッチ等でログ情報を定期的に退避する運用の場合、長期間運用すると退避先のディスク容量が枯渇する可能性があります。このため、退避したログ情報をどのように扱うかをあらかじめ決めておく必要があります。
【例】
退避してから1年を経過したログ情報データはテープ装置にバックアップして削除する。
メール内容データはデータベースには保存されていません。またバックアップツールでの退避対象ではないため、設定によってはサーバ(またはクライアント(CT))にメール本文、添付ファイルが大量に蓄積され、ディスク容量が枯渇する可能性があります。このため上記のログ運用とは別に、定期的な容量確認とバックアップおよび削除を行ってください。
削除する場合は、DTKMLDL.BAT(メール内容削除)コマンドを使用してください。使用方法の詳細は、“リファレンスマニュアル”の“DTKMLDL.BAT(メール内容削除)”を参照してください。
メール本文、添付ファイルの格納先フォルダの構成は、以下のとおりです。メール内容データの格納先については、“2.2.4.11 保存先フォルダを設定する”を参照してください。
【構成】
メール内容データの格納先フォルダ
+-日単位のフォルダ
+-CT単位のフォルダ
【例】
ログ閲覧データベースへは、同じタイミングで取得した管理情報、ログ情報の両方のデータを移行する必要があります。
なお、3階層構成の場合は管理情報は統合管理サーバのデータを使用します。
管理サーバが2階層構成の場合、同じ管理サーバ上で運用データベースのバックアップデータをログ閲覧データベースにリストアします。そのため、バックアップとリストアを連続して実施するようなタスクスケジューラを用意してください。
管理サーバが3階層構成の場合、複数の下位管理サーバの運用データベースのバックアップデータを統合管理サーバに転送し、統合管理サーバ上のログ閲覧データベースにリストアします。そのため、下位管理サーバではバックアップと統合管理サーバへのデータ転送を実施するようなタスクスケジューラを用意してください。また、統合管理サーバでは、自身の運用データベースのバックアップと、全ての下位管理サーバからのデータ転送の完了を待ってからバックアップデータをログ閲覧データベースにリストアするようなタスクスケジューラを用意してください。
なお、従来版のログ閲覧データベースは、任意のタイミングで手動でデータを移行する事もできます。
リストアの方法については、“3.1.3.2 リストアコマンドを使用する”を参照してください。
ログアナライザサーバでの検討項目
ログアナライザサーバを構築し、ログの分析機能やレポート出力機能を使用する場合、管理サーバ/統合管理サーバが収集したログは、ログアナライザサーバの共有フォルダに転送されます。
共有フォルダに格納されたログは、分析・集計され、ログアナライザサーバのデータベースに格納されますが、共有フォルダ上のログはそのまま保持されています。
このため、ログアナライザサーバ上の共有フォルダ上に格納されたログを定期的に退避し、退避済みのログを削除していくことにより、共有フォルダ領域を枯渇させることなく、安定した運用を行うことができます。
また、共有フォルダへの転送(データ転送)、ログアナライザサーバのデータベースへの格納(データ移入)は、1日1回行われる必要があるため、それぞれのコマンドをタスク登録して運用します。このタスク登録の際、タスクが実行される時刻についても検討しておく必要があります(移入は転送完了後に行う必要があるため十分な時間を空ける、転送/移入処理は負荷がかかるため夜間に行うなど)。
共有フォルダが枯渇した場合、管理サーバ/統合管理サーバからログの転送に失敗します。このため定期的に共有フォルダの容量確認を行い、分析・集計済みのログについては退避した上で、削除を行ってください。
ログアナライザサーバの共有フォルダは以下のような構成になっています。
ログアナライザサーバでの分析・集計が完了していないログは、退避・削除しないでください。
転送元ログ収集日のフォルダの配下で“ログ転送完了確認用ファイル(conv_end) ”が作成されているフォルダは、ログ分析・集計が完了し、ログアナライザサーバ上のデータベースに格納済みです。
上図の“転送コマンド実行日”フォルダ配下の“転送元管理サーバ名”フォルダに存在するすべての“転送元ログ収集日フォルダに“ログ転送完了確認用ファイル(conv_end) ”が作成されている場合は退避・削除ができます。“転送コマンド実行日”フォルダ単位で、退避および削除を実施してください。
