診断用ログの進化
年々、機能ごとに、診断ログは、忙しいサーバーで巨大なファイルに成長しました。4D v19R5では、診断ログファイルのログレベルを選択することができる新しいデータベースパラメータを搭載しました。これは、本当に必要なものだけを記録することで、診断ログのサイズをコントロールするのに役立ちます。
ロギングを一時停止し、設定ファイルを記録する
4D v19では、ログの長期的な改良を開始しました。最初の取り組みは、より良い、より明確な情報を提供するために、その形式を改善することでした。4D v19 R3では、2つの新機能を追加しました。ログを瞬時に一時停止する機能と、サポートチームが設定ファイルを通じて簡単にお客様のログを設定する方法を提供する機能です。
誰が何をしたか：ジャーナルにユーザーの別名を保存する
コマンドのおかげで、ユーザーを特定するための新しい機能を発見したことでしょう。 SET USER ALIASコマンドのおかげで、ユーザーを特定する新しい機能を発見したことでしょう。4D v18 R2では、コマンドの動作が拡張されました。どのように？読み進めてください。
リクエストロギングによるORDAコードの最適化
クライアントと4Dサーバー間のORDAリクエストのトラフィックを分析する必要があることはありませんか？時々、サーバーから応答を受け取るのに時間がかかることがあり、それがネットワークトラフィックのせいなのか、それともあなたが書いた最適化されていないリクエストのせいなのか、疑問に思うことがあるかもしれません。ありがたいことに、4D v17 R6 では、この遅延の原因を、新しい ORDA メソッドで判断することができます。 dsオブジェクトで利用できる新しいORDAメソッドで、この遅延の原因と思われるものを特定することができます。これらはデバッグ機能だけでなく、送信されたリクエストをよりよく理解することで、ORDAコードを最適化することができます。
デバッグログを解析するための新ツールが登場
4D v17 R5では、デバッグログにメソッドを追加し、各プロセスを独立してトレースできるように改善しました。このR-リリースでは、さらに一歩進んで、プロセスの実行を監視するのに役立つデバッグログアナライザツールを出荷しました。どのプロセスが最も消費されているか、コールチェーンとそれに対応する実行時間などを見ることができるようになります。
これらの改善により、デバッグログが改善されました。
4D開発者として、あなたはすでに問題のトラブルシューティングのためにデバッグログを有効にしたことがあるかもしれません。4D v17 R5では、現在のプロセスのみをログし、メンバーメソッド（コレクションまたはオブジェクトメソッド）の呼び出しをログするなど、これらのファイルを分析するのに役立ついくつかの改良が導入されています。
SMTPの会話を記録する
以前の記事で約束したように、各R-releaseにはメール機能に関するより多くの進歩が含まれ、その隠れたパワーを解き放ちます。
4D v17 R5では、メールログに関する興味深い新機能が提供されています。開発中はすべてうまくいっていたのに、顧客にデプロイしたときに、メール配信に問題が発生することがあります。通信は暗号化されており、SMTPサーバのログファイルにアクセスできないことが多いため、どこで障害が発生したかを発見するのは難しいかもしれません。問題はSMTPサーバーに関連している可能性が非常に高いのですが、どうすれば確認できるのでしょうか？アプリケーションでSMTPログを開始するだけです。このログには、接続の停止を含む、実行されたすべてのアクションの記録が含まれています。さらに良いことに、このログはSMTPサーバーとの通信を暗号化されていないプレーンなテキストで表示するので、分析が容易になります。
ログファイルへの容易なアクセス
ログファイルはトラブルシューティングに非常に有効です。また、インシデントの根本的な原因を突き止めるのにも大きな助けになります。ログは、いつ、どこで問題が発生したかを追跡することができます。以前は Get 4D folderコマンドで、すべてのログを含むフォルダーに簡単にアクセスできました。4D v16 R6では、コマンドの強化により、 特定のログファイルを簡単に見つけることができるようになりました。 Get 4D fileコマンドの強化により、特定のログファイルを簡単に見つけることができます。