ログを定義
- 最終更新日2020/05/04
ログを定義
ログを設計する場合は、読みやすくて解析しやすいものにします。
ログ ファイルには、さまざまなアプリケーションやシステム コンポーネントから発行されたメッセージが保存されています。
ログは読みやすく、理解しやすく、解析しやすいものである必要があります。ログ ファイルを読みやすく、クリーンで、十分な説明を含む状態に維持します。処理されるデータとその意味を表示します。Bot が実際に行う内容を表示します。優れたログは Bot 自身の優れたドキュメントとして機能します。
ログは、ユーザーやマシンにとって次のために役立ちます。
- プロセスが正常に完了したかどうかを判断します。
- プロセスが完了しない場合は、プロセスが完了しなかった理由についての情報を確認します。
- Bot が想定どおりに機能しているかどうかを判断します。
- ログをインタラクティブに追跡します。
- ツールを使ってログを解析するか、またはログを Excel にインポートして、メトリックを収集し分析します。
- ログをデータベースにインポートします。
ログ記録が適切に実行されるようにするための一連の標準を次に示します。
ログのタイプ
- プロセス/情報—プロセス ログは情報を記録するものです。タスクの正常な動作を監視するために使用することができます。さらに重要なことに、監査に使用することができます。監査証跡にプロセス ログを使用することは、ビジネス プロセスが適切に完了したかどうかを判断するための、優れた方法です。たとえば、注文があったか、チケットがエラーなく完了したか、などです。
- エラー—エラー ログは詳細なエラー メッセージを記録します。タスクでエラーが発生した場合に、エラーが発生した通知をプロセス ログに記録します。エラーに関する詳細な情報をエラー ログに記録します。
- デバッグ—デバッグ情報を独自のログ ファイルに保存し、実稼働モードではデバッグ情報の収集をオフにします。
isProductionMode
変数を使うと、Bot が実稼働に移行した場合に、これらのステートメントをオフにすることができます。 - パフォーマンス—パフォーマンス ログは、プロセス/情報ログまたはパフォーマンス ログのいずれかに記録することができます。場合によっては、パフォーマンス メッセージを独自のログ ファイルに保存して活用できます。
メッセージのタイプ
- エラー—大きな問題が発生しました。直ちに調査する必要があります。タスクがその機能を適切に実行できません。たとえば、データベースが利用できない、ミッション クリティカルなユースケースを継続できない、ファイルが使用中で開くことができないなどです。
- 警告—タスクを継続できる場合もありますが、特に注意が必要です。例:
タスクは開発モードで実行されています
。タスクは継続して機能しますが、常にメッセージを確認して調査します。 - 情報—重要なビジネス プロセスが終了しました。情報メッセージはアプリケーションに関する情報を示します。情報が暗示されている場合もあります。例:
- アプリケーションのアクションが完了しました。航空予約アプリケーションでの場合、各チケットにつき 1 つの INFO ステートメントのみを発行し、
[誰] が [出発地] から [目的地] を予約しました
と記載されます。 - アプリケーションの状態が大きく変化しました。
データベースの更新
または外部システムのリクエスト
- アプリケーションのアクションが完了しました。航空予約アプリケーションでの場合、各チケットにつき 1 つの INFO ステートメントのみを発行し、
- デバッグ—Bot をデバッグするために役立つ情報です。通常は Bot 開発者が利用します。これらのメッセージはプロセス ログには記録されません。
isProductionMode
変数を使うと、Bot が実稼働に移行した場合に、これらのステートメントをオフにすることができます。 - パフォーマンス—パフォーマンス ログは、プロセス/情報ログまたはパフォーマンス ログ (パフォーマンス ログが別途作成されている場合) のいずれかに記録することができます。パフォーマンスは、特定の手順を実行するためにかかる時間を追跡しますが、詳細すぎないようにします。ほとんどの場合では、パフォーマンス ログはビジネス プロセス全体に限定します。たとえば、注文の完了にかかった時間、請求書の処理にかかった時間などです。
ログ作成のヒント
-
コンシューマー
ログ ファイルの利用者には人間とマシンの 2 つのコンシューマーがいます。
ユーザーがコンシューマー—ユーザーがコンシューマーの場合、ユーザーの役割によって必要な情報の種類が決まります。たとえば、開発者には、デバッグ、パフォーマンスの分析、エラーの特定などの情報が必要となります。アナリストには、監査情報、パフォーマンス情報などの情報が必要となります。
マシンがコンシューマー—マシンは通常、システム管理者が作成するシェル スクリプトを介してログ ファイルを読み取ります。設計ログは、これら両者のログ ファイル コンシューマーに適しています。
-
コンテンツ
オブジェクトを含む—良いログにはタイムスタンプ、ログ レベル、マシン名、タスク名、メッセージが含まれています。
エラー ログ ステートメント— 行番号および Automation Anywhere エラー処理ブロックからのエラーの説明を含めます。
デバッグ ステートメント—サブタスク間で変数を受け渡す場合には、デバッグ ログ ステートメントを使用します。サブタスクに出入りするときの変数値を含めます。
isProductionMode
変数を使うと、Bot が実稼働に移行した場合に、デバッグ ステートメントをオフにすることができます。インターフェース呼び出し—Bot が、MetaBot、API、REST、SOAP 呼び出しなど、他のシステムと連携する場合、これらの呼び出しを記録し、必要な場合には応答を記録します。
- フォーマット
区切り文字—コンテンツの値を区切ります。ログ ファイルのインポートと解析を容易にするため、タブ区切りを使用して値を区切ります。
ファイルに記録—Automation Anywhere に組み込まれている、[ファイルに記録] 機能を使用します。
タイムスタンプ—[ファイルに記録] コマンドで、組み込みのタイムスタンプを使用します。
注: Excel 用を含め、タイムスタンプのための独自の方法やフォーマットを作成しないでください。特定の別のタイムスタンプが必要な場合には、組み込みバージョンでの変更のみを行ってください。
- セキュリティとショートカット
パスワード—パスワードやあらゆる個人情報は決して記録しないでください。
ショートカット—少数の人しか理解できないような、ショートカット文字やスクリプト (マジック コード) を追加しないでください。
数値—数値フォーマットを避けてください。正規表現で容易に認識できるパターンを使用してください。
パフォーマンス
過度のログ—通常のログ コマンド自体では、パフォーマンスの負荷はかかりません。ただし、過度のログは行わないでください。たとえば、小さなループ内での複数回の反復などです。
頻度—24 時間ごとに新しいログを作成します。現在の日付を確認するためのコードを追加します。日が変わった場合は、新しいログを作成します。必要に応じて、古いログ ファイルを圧縮して、アーカイブします。これにより、過度に大きなログ ファイルを防ぐことができます。