Job Arranger for Zabbix

■質問事項（追加）
4. 本事象の解決方法

本事象を解決するための対処法をご教示いただきたいです。
また、追加で確認が必要な項目があれば、併せてご教示ください

ご回答いただきありがとうございます。

既知事象として確認されております
連携いただきましたコンソールログより、 chunkloaderror: Loading css chunk 8897 failedのエラーメッセージが確認できました。
この問題は、外部の Font Awesome CSS ライブラリ、特に @import url がオフライン環境で利用できないことが原因です。
本来JAZはインターネット接続環境を前提としておりません（オフライン環境でも使用できる）ので、こちらはJob Arranger Manager のバグになります。

⇒こちらの原因及びJobarrangerのバグである旨承知しました。
　また、こちらが白画面となる原因で解消方法として、最新バージョン7.2.2へのアップグレードをすることになる旨理解しました。

===

過去のケースでのご回答内容および公開マニュアルを確認したうえで、弊社環境におけるアップグレード手順について認識合わせをさせていただきたく、追加でご質問いたします。

■前提¶

弊環境では、Job Arranger専用DBは利用しておらず、Zabbix DB（MySQL）の中にJob Arranger用テーブルを作成し、Zabbix と Job Arranger を同一DB（zabbix）で運用しております。
※バージョン7.2.2へアップグレード後も既存の運用を継続する想定

また、先日Job Arranger 6.1.0 → 7.0.0 へのアップグレードを実施した際は、

cd /usr/share/doc/jobarranger-server-mysql/database/upgrade/6.1.0-7.0.0/mysql

mysql -u DBユーザ -p zabbix < MySQL_JA_UPGRADE_TABLE-7.0.0.sql

のみを実施しており、

# cd /usr/share/doc/jobarranger-server-mysql-*.*.*/database/mysql
# mysql -u DBユーザ -pパスワード zabbixデータベース名 < MySQL_JA_CREATE_TABLE.sql
# cd /usr/share/doc/jobarranger-server-mysql-*.*.*/database/data
# mysql -u DBユーザ -pパスワード zabbixデータベース名 < JA_INSERT_TABLE.sql" 

は新規構築用作業と認識し、実施しておりません。（アップグレード手順にも掲載が無いため）
参考：https://www.jobarranger.info/jpn/jaz/6.manual/index.html?tgt=/0.upgrade/9988.ver_6.1.0-7.0.0.html

現状はバージョン6.1.0のままのサーバと7.0.0に上げて不具合が出ているサーバが混在しており、
アップグレードパスが2パターン存在する状況です。

パターンＡ：6.1.0 → 7.0.0 → 7.2.2

パターンB：6.1.0 → 7.2.2

===

■追加質問事項¶

質問①
公式HPや過去のケース（# 3818）を確認したところ、以下の認識をしています

・Job Arranger専用DBを利用しなくてもよい（バージョン7.2X以降、JAZ専用データベースが使用可能になったが、Zabbixデータベースが使用できなくなったわけではない。）
・DB系設定とJazDB系設定には同じ接続情報を設定
・migrate/config.php の jaz1 と jaz2 は同一DB（zabbix）を設定

この場合、

mysql -u DBユーザ -p < MySQL_JA_CREATE_DATABASE.sql

は Job Arranger専用DB（jobarranger）作成用の手順であり、既存の zabbix DB（zabbix） を継続利用する構成では不要という理解でよろしいでしょうか。

質問②

同一DB（zabbix）を継続利用する場合、

mysql -u DBユーザ -p zabbix < MySQL_JA_CREATE_TABLE.sql

mysql -u DBユーザ -p zabbix < JA_2_INSERT_TABLE.sql

のように、jobarranger DB ではなく既存の zabbix DB に対して実行する認識でよろしいでしょうか。

質問③
同一DB運用時のDB構成について認識確認をお願いいたします。
下記の構成イメージに認識相違はございますでしょうか。

・移行前

zabbix DB
├ Zabbix関連テーブル
└ ja_* テーブル

・ja_2_* 作成後

zabbix DB
├ Zabbix関連テーブル
├ ja_* テーブル
└ ja_2_* テーブル

・migrate.php 実施後

zabbix DB
├ Zabbix関連テーブル
├ ja_* テーブル（旧）
└ ja_2_* テーブル（移行済）

・旧テーブル削除後

zabbix DB
├ Zabbix関連テーブル
└ ja_2_* テーブル

質問④
マニュアルでは「データベース移行」と記載されていますが、弊環境のように同一DB（zabbix）を継続利用する場合、実態として

ja_* テーブル ⇒ ja_2_* テーブル

へのテーブル移行（テーブル構造移行）と理解してよろしいでしょうか。
それとも「データベース移行」という表現には別の意味がございますでしょうか。

質問⑤

別ケース（#3829）では、
6.0.0　⇒　7.2.2への直接のアップグレードの案内がされていました。

弊社環境の6.1.0⇒7.2.2へのアップグレードについても7.0.0を経由せずに直接アップグレードが可能という理解でよろしいでしょうか。

また、

6.1.0⇒7.2.2

7.0.0⇒7.2.2

のアップグレードパスでは、以下を含む移行手順や確認事項に際はありますでしょうか。

・MySQL_JA_CREATE_TABLE.sql
・JA_2_INSERT_TABLE.sql
・migrate.php
・migrate_compare.php

■追加質問事項¶

質問⑥

マニュアルには以下の記載があります。

正常な検証が完了した後、バックアップ目的で一定期間古いテーブルを保持してください。
新しいJAZテーブルが正常に機能していることが確認された場合、古いテーブルを削除することができます。

6-1：
「一定期間」とはどの程度を想定されていますでしょうか。（数日、1週間程度、月次運用確認後など）

6-2：
「新しいJAZテーブルが正常に機能していること」の確認観点として、
以下のような理解でよろしいでしょうか。
その他、推奨される確認項目がございましたらご教示ください

・migrate_compare.php による比較
・Job Arranger Manager の表示確認
・JobNet表示確認
・ジョブ実行確認
・実行履歴確認
・新規ジョブ作成確認

6-3：
この古いテーブル保持期間の考え方は、
Job Arranger 7.0.0 RPM を rpm -e にてアンインストールした後も必要な手順となるのでしょうか。

質問⑦
同一DB（zabbix）構成の場合、以下の作業順序で問題ないかご確認をお願いいたします。
順序が異なる場合やその他必要な手順がございましたらご教示ください。

① Job Arranger停止

② DBバックアップ取得

③ 設定ファイル退避

④ 既存RPM削除（rpm -e）

⑤ Job Arranger 7.2.2 RPMインストール

⑥ MySQL_JA_CREATE_TABLE.sql 実行

⑦ JA_2_INSERT_TABLE.sql 実行

⑧ migrate.php 実行

⑨ migrate_compare.php 実行

⑩ 7.2.2設定ファイル作成

⑪ Job Arranger Managerセットアップ

⑫ 動作確認

⑬ 一定期間運用確認

⑭ 旧 ja_* テーブル削除

===

以上、よろしくお願いいたします。
こちらの都合で大変恐縮ではありますが、今週中にご回答いただけますと幸いです。
引き続きどうぞよろしくお願いいたします。

更に追加の質問となり大変恐縮ですが、以下についてもご教示いただけますでしょうか。

質問⑧

別ケース #3804 を確認したところ、バージョン7.2系では jasender.sh は不要との認識を持ちました。

また、7.2マニュアルではJob Arranger Monitor の廃止およびJob Arranger Monitoring テンプレートによる監視へ変更されたように見受けられます。

弊社では現在、

・jasender.sh
・jasender_monitor.sh
・Job Monitor

を利用しております。

また、公開されている jobarranger.json をZabbixへインポートし、テンプレート内容を確認したところ、

・JobArranger Server
・JobArranger Manager
・JobArranger Notification
・JobArranger Agent Linux
・JobArranger Agent Windows

のテンプレートが作成されることを確認しました。

JobArranger Server テンプレート内には、Job Arranger Server Jobnet Monitorというアイテムが存在し、

jamonitor[
 {$JA_DBHOST},
 {$JA_DBPORT},
 {$JA_DBNAME},
 {$JA_DBUSER},
 {$JA_DBPASSWORD},
 {$JA_LOAD_SHIFT_TIME},
 {$JA_RUN_SHIFT_TIME}
]

を利用した監視となっていることも確認しております。

7.2.2へのアップグレード後、

① jasender.sh
② jasender_monitor.sh
③ Job Monitor

は停止・削除して問題ないでしょうか。

また、

・ジョブ異常終了
・ジョブ警告
・ジョブネット未投入
・ジョブネット未起動

については、7.2.2ではどのテンプレート、アイテム、トリガーへ置き換わるのかご教示ください。

特に、

・Job Arranger Monitor の後継が「Job Arranger Server Jobnet Monitor」という認識でよいか

・従来の jasender.sh による通知とJobArranger Notification テンプレートとの関係

についても併せてご教示いただけますと幸いです。

コミュニティサポートご担当者様

コミュニティサイトでは回答期限の指定はお受けできません。
期限の設定をご希望の場合は、有償サポートをご利用ください。

承知しました。
ご事情理解しておらず申し訳ありません。
期限の指定は無しとして、ご回答いただけますと幸いです。

何卒よろしくお願いいたします。

質問①～⑦について、詳細にご回答いただきありがとうございます。
アップグレード手順についてイメージができました。

再度HPに掲載されているマニュアル等を確認し、追加で質問事項がありますので、以下についてもご教示いただけますでしょうか。

===
質問⑨
アップグレードマニュアル（ver 6.0.0-7.0.0 ⇒ 6.2.X,7.2.X）上の手順1.3.2「ターゲットデータベースの状態」
について確認となります。

https://www.jobarranger.info/jpn/jaz/6.manual/index.html?tgt=/0.upgrade/9987.ver_6.0.0-7.0.0-6.2.X,7.2.X.html

「ターゲットDBがクリーンな初期状態」

とは、同一DB(zabbix)運用の場合、ja_2_* テーブルに対してジョブ実行やデータ登録が行われていない状態と理解してよろしいでしょうか。

既存の zabbix テーブルおよびja_* テーブルにデータが存在することは問題ない認識でよろしいでしょうか。

基本的には、ja_2_* テーブルを初期スクリプトで導入後すぐにmigrate.phpを実行する想定をしているため、クリーンな状態の要件は満たしている認識でいます。

質問⑩
jobarg_server.conf の設定について確認させてください。
https://www.jobarranger.info/jpn/jaz/6.manual/index.html?tgt=/7.2/1.Install/1.JobArrangerServer/04.Configuration.html

Job Arranger Server 7.2.2 の設定パラメータ一覧を確認したところ、

・MysqlDBRetryCodes
・MariaDBRetryCodes

については必須設定（○）となっていますが、

パラメータの説明欄では、

「プロセスを終了し、最初から接続を再試行させるトリガーとなるMySQL(MariaDB)のエラーコード一覧を指定します。」

と記載がされているものの、設定例や推奨値の記載が見当たりませんでした。

弊社では MySQL を利用しております。

以下についてご教示いただけますでしょうか。

① MysqlDBRetryCodes の推奨設定値 ※一般的にどのようなパラメータを設定するのかがイメージつきませんでした

② 複数指定する場合の記載方法
　（カンマ区切り等）

③ 未設定の場合の動作

④ 新規インストール時のデフォルト設定値が存在する場合、その値をそのまま利用して問題ないか

⑤ 7.0.0 から 7.2.2 への移行時に新たに追加された必須パラメータのうち、特に設定内容を検討する必要がある項目があればご教示ください。

===

再度の追加質問となってしまい大変恐縮ですが、こちらについてもご教示いただけますと幸いです。

引き続きどうぞよろしくお願いいたします。

詳細にご回答いただきありがとうございます。

質問⑧に関して補足でコメントいたします。

jasender.sh および jasender_monitor.sh につきましては、既存バージョンの Job Arranger（例：6.1.0、7.0.0） をアンインストールする際に、自動的に停止および削除されます。
そのため、お客様にて手動で停止または削除していただく必要はございません。

⇒承知しました。

また、「Job Monitor」につきまして、詳細をご教示いただけますでしょうか。
「Job Monitor」とは、monitor フォルダを指しておりますでしょうか。
「Job Monitor」が 「monitor」フォルダ を指している場合は、こちらも既存バージョンの Job Arranger （例：6.1.0、7.0.0）をアンインストールする際に削除されます。

⇒こちら言葉が足りておらず申し訳ありません。
　設定ファイルやjobarg-monitorサービスのことを指しており、総じて「Job Monitor」と表現していました。

===
Jobarrangerの監視について、認識齟齬無いかどうかもう少し確認させてください。

・「ジョブネット未投入」
・「ジョブネット未起動」

こちらについては、従来のJob Monitor＋jasender_monitor.sh
による監視から、Job Arranger Server Jobnet Monitorへ置き換わる旨理解しました。

一方で、

・「ジョブ異常終了」
・「ジョブ警告」

につきましては、従来の jasender.sh が廃止されたものの、

Job Arranger Manager の「全般設定 → Zabbix通知設定」に通知機能が統合されていることから、

従来同様に zabbix_sender を利用した通知運用を継続可能であり、必ずしも JobArranger Notification テンプレートへ移行する必要はない、という理解でよろしいでしょうか。

弊社では従来からジョブ異常終了およびジョブ警告については
情報レベル通知として運用しており、Jobnet未投入・未起動のみを監視アラートとして扱っております。

そのため、

・Jobnet未投入／未起動
　→ Job Arranger Server Jobnet Monitorへ移行

・ジョブ異常終了／警告
　→ 従来同様に通知機能を利用

※こちらで作成していた通知機能用の監視アイテムをそのまま使用する想定

という構成を想定しております。

認識に問題がないかご確認をお願いいたします。

上記の質問（昨日投稿）の件で内容に不足していた部分があるため、追記いたします。

JobArranger Notification テンプレートを使用して Zabbix に通知を送信するためには、以下のファイルにおいて、対象となるログメッセージの通知フラグを有効に設定する必要があります。
/etc/jobarranger/locale/server_logmessage_64BIT.txt

⇒「server_logmessage_64BIT.txt」ファイルに対して、通知フラグを有効に設定する必要があるのは、JobArranger Notification テンプレートを使用して Zabbix に通知を送信する場合のみといった理解でよろしいでしょうか。

・ジョブ異常終了／警告
　→ 従来同様に通知機能を利用

従来同様に通知機能を利用していく場合だとしても、通知フラグを有効にする必要があるかどうかが気になりました。
※現状、通知フラグを有効にして運用しているかが、不明のため
https://www.jobarranger.info/jpn/jaz/6.manual/index.html?tgt=/7.2/1.Install/1.JobArrangerServer/07.notification.html

こちらの件も併せてご回答いただけますと幸いです。
よろしくお願いいたします。

ご担当者様

いつもお世話になっております。
追加のご質問(note#17)について回答します。

質問⑪ MySQLライブラリについて

・JobArranger 7.2.2 を RHEL8標準MySQL環境で利用する場合、「mysql_database_v21.1.26.so」を使用する想定でしょうか

libmysqlclient.so.21 をご使用になる場合は、Job Arranger Server の設定ファイルにおいて、MysqlDBPlugin の値として mysql_database_v21.1.26.so を指定してください。
例えば、/etc/jobarranger/jobarg_server.conf では、以下のように設定してください。

MysqlDBPlugin=/usr/local/bin/jobarranger/mysql_database_v21.1.26.so

ただし、mysql_database_v21.1.26.so および libmysqlclient.so.21 を使用した場合、Job Arranger Server 自体は正常に動作いたしますが、Job Arranger の監視機能が正常に動作しないことを確認しております。
そのため、Job Arranger の監視機能をご利用になる場合は、Job Arranger Server の設定ファイルにおいて、MysqlDBPlugin の値として mysql_database.so を指定し、libmysqlclient.so.24 をご使用いただく必要がございます。
例えば、/etc/jobarranger/jobarg_server.conf では、以下のように設定してください。

MysqlDBPlugin=/usr/local/bin/jobarranger/mysql_database.so

・システム要件に記載のmysql8.0-libs*rpmまたはmysql-libs*rpmについて、今回の環境で導入すべき推奨RPM名をご教示ください
システム要件を見落としており、現状どちらのライブラリも導入されていません。
検証環境からダウンロードがすぐに可能なmysql-libs*rpmに関して、上記の通り確認したかたちとなります。

お客様の環境における推奨RPMパッケージは、以下のとおりです。
・mysql-community-libs-8.4.11-1.el8.x86_64.rpm

・JobArranger 7.2.2 が想定するlibmysqlclient.so.24を提供するRPMがある場合、そのRPM名をご教示ください。

Job Arranger 7.2.2 で必要となる libmysqlclient.so.24 ライブラリを提供するため、上記の RPM "mysql-community-libs-8.4.11-1.el8.x86_64.rpm" をインストールしていただく必要がございます。
上記のRPMパッケージをインストールすることで、libmysqlclient.so.24 が /usr/lib64/mysql/ ディレクトリにインストールされます。

・質問⑫　マイグレーション結果について

・ja_run_log_table は移行対象外の仕様でしょうか。

ja_run_log_table は、移行の対象に含まれております。

・migrate_compare で ROW_MISSING が出力されることは想定される動作でしょうか。

migrate_compare の実行結果として「ROW_MISSING」が出力されることは想定されておりません。
ご提供いただいた migrate_compare_20260807_034604.csv の内容から判断すると、今回の「ROW_MISSING」は、移行処理における不具合が原因で発生した可能性があると考えております。
完了した Job Net が設定された保持期間に達した場合、Job Arranger Server は、まず ja_run_jobnet_table から完了済み Job Net の情報を削除し、その後、対応する実行ログを ja_run_log_table から削除します。
今回のケースでは、ja_run_jobnet_table から完了済み Job Net の情報が削除された後、対応する実行ログデータが ja_run_log_table から削除される前に、移行処理が実行されたものと考えられます。
現在の migrate.php の構造では、対応する Job Net 情報が ja_run_jobnet_table に存在しない場合、ja_run_log_table に存在する関連する実行ログデータは移行されず、スキップされる仕様となっております。そのため、その時点で ja_run_log_table に残っていた実行ログデータが移行されなかったものと考えられます。
以上の理由により、今回の ROW_MISSING が発生しております。

・ja_* テーブル数と ja_2_* テーブル数が一致しないのは、テーブル統合等による仕様でしょうか。

ご認識が誤っております。
Job Arranger バージョン 7.2.2 においては、アーキテクチャの変更に伴いテーブル数に差異が生じております。
現在発生している ja_run_log_table のデータが移行されない問題につきましては、上記の理由によるものでございます。

・上記状態のままアップグレード後の運用を継続して問題ないでしょうか。

上記の状態のまま、アップグレード後も運用を継続していただいて問題ございません。また、その他のジョブネット運用への影響もございません。

ご不明な点がございましたらお気軽にお問い合わせください。
何卒よろしくお願いいたします。

ご担当者様

詳細にご回答いただきありがとうございます。
7.2.2へのバージョンアップ検証も概ね完了し、準備を進めております。

ご認識とは異なります。
server_logmessage_64BIT.txt ファイルの通知フラグを有効に設定することは、JobArranger Notification テンプレートをご利用の場合だけでなく、既存の通知用監視アイテムをご利用の場合においても必要となります。

⇒既存の通知機能仕様の際もフラグの有効化が必要になる旨承知しました。

いただいた回答を元に追加で確認をさせていただきたいです。

===
質問⑧　監視や通知機能に関する追加質問

これまでと同様に通知機能をご利用いただく場合でも、通知フラグを有効に設定していただく必要がございます。
現在ご利用中の Job Arranger バージョン（例：6.1.0、7.0.0）では、ジョブの異常終了が発生した際に Zabbix 通知を送信するための通知フラグが、デフォルトで有効に設定されております。
一方、Job Arranger バージョン 7.2.2 では、このログメッセージに対する通知フラグはデフォルトで無効に設定されております。
そのため、ジョブの異常終了イベントについて Zabbix 通知を送信する場合は、対象となるログメッセージの通知フラグを有効に設定していただく必要がございます。
恐れ入りますが、「ジョブ警告」とは #note-13 に記載されている タイムアウト警告 を指しておりますでしょうか。

⇒内部資料にてジョブ警告という文言があったため、その表現をしていましたが、改めて #note-13を見返したところ、ジョブタイムアウト警告に該当するものと理解しましたので、タイムアウト警告を指しております。

こちらの「server_logmessage_64BIT.txt」通知フラグに関して、もう少し教えてください。

Job Arranger 7.2.2では、ジョブ異常終了に関するログメッセージの通知フラグがデフォルトで無効になっているとのご説明をいただきました。

今回ご説明いただいた

・ジョブ異常終了

・ジョブタイムアウト警告

に該当するメッセージについては、通知フラグを有効化する必要があることを理解しました。

一方で、通知フラグがデフォルト無効となっているのは、これら一部のログメッセージのみでしょうか。

それとも、server_logmessage_64BIT.txt 全体として、従来バージョンと比較して通知フラグの初期設定が見直されておりますでしょうか。
（これまでデフォルトで有効であったものが無効に変更となった場合、差分の抽出に苦慮すると思い、気になりました）

また、バージョン7.2からJob Arranger Agent の設定ファイル（/etc/jobarranger/jobarg_agentd.conf）において、

JaLogMessageFile=/etc/jobarranger/locale/agent_logmessage_64BIT.txt

というパラメータが存在しております。

agent_logmessage_64BIT.txt
についても通知フラグ設定や内容確認を行う必要がありますでしょうか。

===
質問⑪ MySQLライブラリに関する追加質問

＜libmysqlclient.so.21 を使用した場合の監視機能への影響＞
バージョンアップ検証では、MysqlDBPlugin=/usr/local/bin/jobarranger/mysql_database_v21.1.26.soを指定することで、libmysqlclient.so.21環境でもJob Arranger Serverが正常起動し、ジョブ実行も問題なく行えることを確認いたしました。（ご案内いただいていたJob Arranger Server の正常起動の担保と認識）

一方、 #note-13のご回答にて、「mysql_database_v21.1.26.so および libmysqlclient.so.21 を使用した場合、Job Arranger の監視機能が正常に動作しない」と知りました。

具体的には、以下のどの機能へ影響するのでしょうか。
これまでスクリプト通知で行ってきた機能を一部監視テンプレートへ移行するのにあたり、どの程度の影響があるのかが気になりました。

・Job Arranger Server Jobnet Monitor
　（ジョブネット未投入／未起動監視）

・Job Arranger ManagerのZabbix通知機能

・JobArranger Notificationテンプレート

・その他監視関連機能

また、ジョブ実行機能および通常のJobnet運用には影響しない、という理解でよろしいでしょうか。

＜MySQLバージョン8.0.30での使用ライブラリについて＞

弊社環境のMySQL Serverは8.0.30を使用しております。
ご案内いただいた「mysql-community-libs-8.4.11-1.el8.x86_64.rpm」につきましては、
libmysqlclient.so.24 を提供するRPMであることは確認できましたが、MySQL Server 8.0.30環境へ導入することについて問題ないのでしょうか。
一見すると、MySQL Server 8.0系に対しmysql-community-libs 8.4系を利用する構成となるため、互換性の観点で問題がないか気になっております。
 
※mysql-community-libs-8.0.30及びmysql-libs-8.0.30どちらにおいても、libmysqlclient.so.21 用プラグインを使用するライブラリのようでした

また、mysql_database_v21.1.26.soという libmysqlclient.so.21 用プラグインが提供されていることから、MySQLの利用環境に応じてプラグインを使い分けることを想定しているようにも見受けられました。

===

質問⑬JobArranger Manager のログアウト動作　（新規）

Job Arranger Manager と Zabbix の連携動作について確認させてください。

Job Arranger 7.2.2では、Zabbixモジュールを利用してJob Arranger Managerへアクセスする認識です。
現在の検証環境では、Job Arranger Managerからログアウトすると、Zabbix側のセッションも同時にログアウトされる動作となっております。
こちらは仕様となりますでしょうか。

また、

/etc/jobarranger/web/jam.config.php

・ZBX_API_ROOT
・ZBX_REDIRECT_URL

/usr/share/zabbix/modules/JazManager/config/jam.module.config.php
・JAM_URL

の設定内容によって動作が変わる場合は、推奨設定をご教示いただけますでしょうか。

弊社環境では、

ZBX_API_ROOT
ZBX_REDIRECT_URL
JAM_URL

とも同一のZabbixサーバのIPアドレスを指定したURLを利用する構成を想定しております。
（バージョンアップ前の現状の実機ではIPアドレスの部分はZabbixサーバのホスト名にしてアクセスしている）

===

引き続き、ご確認いただけますと幸いです。
何卒よろしくお願いいたします。

ご担当者様

お世話になっております。
詳細にご回答いただきありがとうございます。諸々承知いたしました。

昨日、弊社のステージング環境にて、バージョンアップリトライ作業を実施し、7.0.0の時に発生した白画面となるバグも解消でき、無事にログインできました。
また、Job Managerからのジョブも実行されていることを確認しましたので、7.2.2へのバージョンアップの一連の流れを通しで実行することができました。
これまでの長期に渡りサポートいただき、御礼申し上げます。

さて、検証作業や実機作業を実施した中で、何点か疑問点が発生したため再度追加での質問をさせていただきます。

===
質問⑯ Job Arranger AgentのServer パラメータについて
Job Arranger Agent の Server パラメータについて確認させてください。

旧バージョン（ver 6.1.0）では、jobarg_agentd.conf の Server パラメータに Job Server のホスト名を設定して運用しておりました。
7.2.2へアップグレード後、同じ設定では Job Manager からのジョブ実行時に接続元チェックエラーとなり、ジョブ実行できませんでした。

その後、Server パラメータを Job Server の IP アドレスへ変更したところ正常にジョブ実行できるようになりました。

7.2.2において、Serverパラメータのホスト名解決処理や接続元認証方式に変更はありますでしょうか。
また、運用上はホスト名指定とIPアドレス指定のどちらが推奨となりますでしょうか。

===

質問⑰ Zabbix Agentの"UserParameter"を利用した監視において、アイテムキー引数に特殊文字を含む場合の挙動について

監視設定の手順通り、以下の設定をJob Server導入サーバのZabiix agent2設定ファイルに設定しました。

UserParameter=jamonitor[*],/usr/local/bin/jobarranger/jobarg_monitor_mysql -dbhost=$1 -dbport=$2 -dbname=$3 -dbuser=$4 -dbpassword=$5 -loadshift=$6 -runshift=$7

※Zabiixサーバのマクロも設定済

Job Arranger Server Jobnet Monitor の動作確認を実施したところ、
DBパスワードに特殊文字を含む場合に監視データ取得に失敗する事象を確認しました。

DBパスワードに「!」を使用していた検証環境及び DBパスワードに「&」が含まれている実機では、jamonitor の取得時にエラーとなり、Zabbix上の最新データに以下が出力され取得できません。

missing or invalid required flags: -dbuser,-dbpassword

なお、jobarg_monitor_mysql を直接実行した場合は、「!」を含むパスワードでも正常動作しました。

/usr/local/bin/jobarranger/jobarg_monitor_mysql \
-dbhost=127.0.0.1 \
-dbport=3306 \
-dbname=zabbix \
-dbuser=xxxx \
-dbpassword='!Zabbix01'

Zabiix agent経由で実行すると、以下のようなエラーが出ます。

zabbix_agent2 -t \
'jamonitor[127.0.0.1,3306,zabbix,mys-zab01,!Zabbix01,10,10]'

エラー：
[Character "!" is not allowed]

DBパスワードを「Zabbix-2026」のようにハイフンを含む値へ変更した検証環境では、jamonitor が正常取得できることを確認しています。
Job Arranger Server Jobnet Monitor において、DBパスワードで使用できない文字種や制約事項はありますでしょうか。

また、特殊文字を含むDBパスワードを利用する場合の推奨方法があればご教示ください。
※こちらについては、Zabiix側へも問い合わせております

===

以上、よろしくお願いいたします。

ご担当者様

いつもお世話になっております。
不具合が解消されたとのことで、何よりです。追加のご質問については別途回答とさせていただきたいのですが、
未回答のご質問に以下回答します。

質問⑭ libmysqlclient.so.21を使用した場合の監視機能の不具合について

先日のご回答で「監視機能が正常に動作しない」とのことでしたが、
こちらで使用を検討しているJob Arranger Server Jobnet Monitor(jamonitor)アイテムでの監視については、jobarg_monitor_mysql がlibmysqlclient.so.24 に依存しているため
利用できないという理解で正しいでしょうか。（Job Arranger Server Jobnet Monitor(jamonitor)アイテムに限らず監視機能が使用できないと捉えました）

ご認識のとおりでございます。
使用できないのは Job Arranger Server Jobnet Monitor（jamonitor）アイテムのみ であり、その他の監視機能については通常どおりご利用いただけます。

また、jobarg_monitor_mysql がJob Arranger Server Jobnet Monitorアイテム(jamonitor)監視している内容
について以下をご教示いただけますでしょうか。

＜確認事項＞
・正常時の返却値

・ジョブ未投入発生時の返却値

・ジョブ未起動発生時の返却値

・Zabbixへ通知される実際のメッセージ例

従来の Job Monitor では

[ERROR] [メッセージID] メッセージ本文(Jobnet has not～ : jobnet[ジョブネットID] scheduled time[YYYY/MM/DD HH:MM] calendar[カレンダーID] schedule[スケジュールID] user name[ユーザID])
といったメッセージがjasender_monitor.sh によりZabbixへ送信されている認識です。
ver7.2.2 の Job Arranger Server Jobnet Monitorでも同様のメッセージが返却されるのかを確認したいと考えております。

また、Job Arranger Server Jobnet Monitorアイテムには、トリガーがついておりませんでしたので、現状のjasender_monitor.shで使用しているアイテムで使用しているトリガーを一部修正して使用しようと検討しています。

※こちらで運用検討しているアイテム及びトリガーの設定キャプチャを添付いたします

・正常時の返却値
ジョブネットが正常に完了した場合、返却値は空（メッセージは返却されません）となります。

・ジョブ未投入発生時の返却値
ジョブネットが未投入の場合、以下のメッセージが返却されます。
"[ERROR] [JAMONITOR200001] Jobnet has not been pre-deployment: jobnet[Jobnet ID] scheduled time[YYYY/MM/DD HH:MM] calendar[Calendar ID] schedule[Schedule ID] user name[User name]"

・ジョブ未起動発生時の返却値
ジョブネットが起動していない場合、以下のメッセージが返却されます。
"[ERROR] [JAMONITOR200002] Jobnet has not started: jobnet[Jobnet ID] scheduled time[YYYY/MM/DD HH:MM] calendar[Calendar ID] schedule[Schedule ID] user name[User name]"

・Zabbixへ通知される実際のメッセージ例
Job Arranger Server 7.2.2のJobnet Monitorでは、上記の「ジョブ未投入」および「ジョブ未起動」のメッセージが返却され、Zabbixへ送信されます。

なお、メッセージの形式は、従来のJob Monitorと同様です。
また、テンプレートの「Job Arranger Server Jobnet Monitor」アイテムには、トリガーは設定されておりません。
そのため、添付いただいたキャプチャに記載されているアイテムおよびトリガーの設定をご利用いただけます。

質問⑮旧テーブル削除スクリプトについて

＜DB移行後に使用するDROP TABLEスクリプトについて＞
ver7.2.2のアンインストール手順に掲載されているMySQL_JA_DROP_TABLE.sqlを確認したところ、

DROP TABLE ja_2_xxx
となっており、ja_2_* テーブルを削除する内容となっていました。
アップグレード後の旧テーブル削除時に使用するDROP TABLEスクリプトと7.2.2アンインストール時に使用するDROP TABLEスクリプト
は別物であると理解しておりますが、この認識でよろしいでしょうか。

ご認識のとおりでございます。

＜「関連するバージョンのDROP TABLEスクリプト」の意味について＞
アップグレード手順には、

関連するバージョンのDROP TABLEスクリプトを使用して移行前データベースのテーブルを削除
との記載があります。
この「関連するバージョン」とは、移行元バージョン （6.1.0または7.0.0）のDROP TABLEスクリプトを指す認識でよろしいでしょうか。

ご認識のとおりでございます。

＜移行元による差異について＞
今回、アップグレードパスとして、以下両方のパターンが存在します。

・6.1.0 → 7.2.2
・7.0.0 → 7.2.2
旧テーブル削除時に使用するDROP TABLEスクリプトは、6.1.0系から移行した場合、7.0.0系から移行した場合で異なるのでしょうか。
それとも同じスクリプトを使用するのでしょうか。

6.1.0系から移行した場合と7.0.0系から移行した場合では、旧テーブル削除時に使用するDROP TABLEスクリプトが異なります。
そのため、移行元のバージョンに応じたDROP TABLEスクリプトをご使用ください。

＜旧RPM削除後のスクリプト入手について＞
旧バージョンRPMをアンインストールすると、

/usr/share/doc/jobarranger-server/
配下のSQLファイルも削除される可能性があると考えております。
その場合、旧テーブル削除に必要なDROP TABLEスクリプトは、事前にバックアップしておく必要がありますでしょうか。

または、旧バージョンのRPMアンインストール後でも入手可能な方法がございますでしょうか。

旧テーブルの削除に必要なDROP TABLEスクリプトについては、事前にバックアップしていただく必要がございます。

6.1.0では、旧バージョンのRPMをアンインストールした後にDROP TABLEスクリプトを入手する別の方法はございません。再度RPMパッケージをインストールしていただくことでのみ入手可能です。
一方、7.0.0では、Job Arrangerのダウンロードページから提供されている7.0.0のソースコード（jobarranger-7.0.0.tar.gz）に含まれている jobarranger-7.0.0/database/mysql/MySQL_JA_DROP_TABLE.sql をご利用いただけます。

＜削除対象テーブルの確認方法について＞
旧テーブル削除作業を実施する前に、
削除対象が移行前テーブルであり、現在運用中のテーブルではないことを確認する推奨方法があればご教示ください。

旧テーブルの削除対象については、DROP TABLEスクリプトファイルの内容をご確認いただく方法がございます。
MySQL_JA_DROP_TABLE.sql に記載されているテーブルが ja_ プレフィックスのテーブルである場合、移行前に使用されていた旧テーブルが削除対象となります。
一方、ja_2_ プレフィックスのテーブルが記載されている場合は、Job Arranger 7.2.2で現在運用中のテーブルが削除対象となります。
したがって、旧テーブルを削除する際は、MySQL_JA_DROP_TABLE.sql に ja_2_ プレフィックスのテーブルが含まれていないことをご確認ください。

ご不明な点がございましたらお気軽にお問い合わせください。
何卒よろしくお願いいたします。