インスタンスで「SMTP Sender Job Stuck」アラートが生成されましたIssue 本番インスタンスで SMTP Sender ジョブ (メール送信ジョブ) が予想よりも長く実行されていることが検出された場合、当社のモニタリングシステムは、「SMTP Sender Job Stuck」というタイトルのケースを自動的に作成します。検証するには、インスタンスのシステム管理者である必要があります。SMTP Sender ジョブがまだ実行されていることを確認する KB0523599 - Verify that the SMTP Sender schedule job is runningを使用します。 メールは既に生成されています。これは、メール通知が遅延ジョブにもイベントプロセッサージョブにも含まれていないことを示しています。このアラートは、ターゲット SMTP サーバーへの送信準備完了メールの配信に予想以上の時間がかかっていることのみを示します。 SMTP Sender ジョブとは何ですか？ SMTP Sender ジョブは、2 分ごとに実行されるスケジュール設定済みジョブで、インスタンスに保持されているすべての送信準備完了メールを送信します。すべての送信準備完了メールがインスタンスから消去されるまで、実行が続行されます。Causeこのアラートの考えられる原因： (すべての原因がリストされているわけではありません) インスタンスによって生成されたメールの大量のバックログまたはスパイク。これは、予定されている一括メールキャンペーン、予期しない量のメールを作成するスケジュール設定済みジョブ、またはメールループが原因である可能性があります。生成されたメールに関連付けられた大きな添付ファイル。大量の受信者を含むメール。(独自の SMTP サーバーを使用している場合) SMTP メールサーバーには配信レート制限があり、送信されたメールを保持します。送信できるメールの量を減らすためにレート制限が適用され、SMTP Sender ジョブが SMTP サーバーで待機するため、実行速度が低下する場合があります。SMTP 接続の問題。インスタンスと SMTP サーバー間の接続が遅いかタイムアウトすると、接続を待機するために SMTP Sender ジョブの速度も低下します。SMTP サーバーのメール処理が遅い。たとえば、SMTP サーバーに独自のウイルス対策スキャンがあり、受信した各メールをスキャンしている場合、インスタンスから送信されるメールの速度が低下する可能性があります。Resolution ジョブがスタックする SMTP Sender の問題と推奨される解決策 検証するには、インスタンスのシステム管理者である必要があります。 SMTP Sender ジョブがまだ実行中かどうかは、次の KB から自分で確認できます: KB0523599 - SMTP センダー スケジュール ジョブが実行されていることを確認する ケース 考えられる問題 推奨ソリューション ケース 1 独自の SMTP サーバーを使用している場合 メールログテーブル (sys_email) を確認して、SMTP Sender ジョブのメールの配信に時間がかかる原因を特定してください。 次のリンクで確認できます： <instance>/sys_email_list.do?sysparm_filter_only=true&sysparm_query=type%3Dsend-ready%5Esys_created_onONLast%203%20months@javascript:gs.beginningOfLast3Months()@javascript:gs.endOfLast3Months()%5EORDERBYDESCsys_updated_on&sysparm_first_row=1&sysparm_view=& (報告されたアラートのタイミングと一致するように時間を変更します) メール管理者に連絡して、接続やインスタンスからのメール受信率に問題がないかどうかを確認する必要があります。 最後に、ネットワークチームと協力して、接続の問題の解決を支援してください。ただし、SMTP サーバーのメール処理が遅い場合は、インスタンスによって生成される通知の量を減らすこと (通知の無効化または調整)、スケジュール設定済みレポートの一部をオフピーク時間に移動し、SMTP サーバー管理者とともに改善のためのオプションを調査することを検討してください。スループットパフォーマンス。 ケース 2 準備完了ステータスのメールの受信者数が 人多い場合 * (通常はメールの量が少ない)。 メール通知を調整し、通知に「登録解除」オプションを追加して、受信者リストを減らすことを検討してください。詳細については、 (このブログ)を参照してください。 ケース 3 送信されたメールに大きな添付ファイルが関連付けられているかどうかを確認します。これを行うには、sys_attachment テーブルを開き、それらの添付ファイルを検索します。 次のリンクで確認できます： <instance>/sys_attachment_list.do?sysparm_filter_only=true&sysparm_query=table_name%3Dsys_email%5Esys_created_onONToday@javascript:gs.beginningOfToday()@javascript:gs.endOfToday()%5EORDERBYDESCsize_bytes&sysparm_first_row=1&sysparm_view=&(報告されたアラートのタイミングと一致するように時間を変更します) 問題の発生時に「サイズ (バイト)」が 10,485,760 (10MB) を超える添付ファイルが表示される場合は、遅延に関連している可能性があります。 今後これを回避するには、これらのメールの作成元を特定し、添付ファイル自体ではなく添付ファイルへのリンクを送信することを検討してください。 ケース 4 大きな添付ファイルが含まれていない場合は、 ターゲットの SMTP メールサーバーに配信レート制限 があり、送信されたメールを保持しているかどうかを確認します。 SMTP 接続の問題に関連している可能性もあります。sys_properties 名 glide.smtp.debug を値 true で短期間有効にすることを検討してください。有効にすると、インスタンスノードの wrapper.log ファイルに送信プロセスの詳細が表示されます。これらは、インスタンス [ノードログファイルのダウンロード ] セクションンで「wrapper_<YYYYMMDD>.log」という名前で入手できます。 いくつかの電子メールが送信された後、プロパティを無効にし、wrapper.logを確認します。 ターゲット SMTP サーバー管理者に連絡して、インスタンスを確認または包含リストに含める必要があります。 wrapperr_で見つかった証拠を送信することもできます.log ファイル ケース 5 送信する準備ができているメールに大量のバックログまたはスパイクがある場合は、これが計画された一括メールキャンペーンかどうかを確認します。 関連するメール通知を特定する簡単な方法は、それらのメールのいずれかを開き、[送信箱ビュー] に変更し、 イベントと通知の作成セクションを確認することです。 これらのメールの作成に関連するメール通知を識別するもう 1 つの方法は、sys_email_log テーブルを開き、アラート時に通知別にグループ化することです。 次のリンクで確認できます： <instance>/sys_email_log_list.do?sysparm_query=email.type%3Dsend-ready%5Esys_created_onONToday@javascript:gs.beginningOfToday()@javascript:gs.endOfToday()%5EGROUPBYnotification&sysparm_first_row=1&sysparm_view=&sysparm_filter_only=true (報告されたアラートのタイミングと一致するように時間を変更します) 時間の経過とともにメールの生成を分散するようにしてください。件名はこれらのメール間で類似しているため、それらを認識できます。 ケース 6 インスタンスとユーザーの間に電子メール ループがあり、自動返信メールが返送されて処理される場合。 電子メールの受信トレイ テーブルには大量の電子メールに関連するものがあり、そのほとんどが返送された電子メールのように見えるため、この問題が発生していることがわかります。 詳細はこのブログをご参照ください。 受信メールに「自動返信」するビジネスルールがあるかどうかを確認します。 通知/受信アクションを無効にするか、インスタンスでメールフィルターを使用するか、ユーザー側で対処して自動返信を停止することもできます。 詳細については、次のドキュメントを参照してください。 メール診断 (ドキュメント) 警告：本番環境に変更を加える前に、開発インスタンスで変更をテストすることが重要です。