zabbixサーバーVer. 7.0.6
DB postgreSQL

postgreSQLで、認証時、現行md5で運用しているところですが、scram-sha-256への変更の要望を受けています。
そこで質問なのですが

・zabbix_server.confのDBPasswordの項目の変更が必要のようですが、変更が必要な場合、どのような工程(作業)が必要になりますか。
・scram-sha-256に変更した場合、zabbix側で設定変更が必要になるものはありますでしょうか。

よろしくお願いします。

バージョン：4.0.35

データ取得ができない等Zabbixの動作が非常に重くなる事象が発生いたしました。
OS再起動により解消した後、調査したところ以下のような状況でした。

・CPUおよびメモリには異常はなく、終始使用率60%程度で安定していた
・ネットワークトラフィックにも高負荷は見当たらず
・事象の発生とほぼ一致するタイミングで、history housekeeper processおよびhistory syncer processが一気に100%近くにまで上昇していた
・事象発生の約1カ月前に12台ほど監視対象機器を追加していた(アイテム数にして2000件ほどの追加)

これらの状況から、データの取得数が大幅に増加したことでhistory housekeeper processおよびhistory syncer processによる負荷が増大し、
本事象に繋がったのではないかと考えております。

(1)上記の見解に相違ありませんでしょうか？ 他に考えられる可能性などありましたらご教授いただけますと幸いです。
(2)監視対象機器やアイテム数の削減以外に本事象の再発防止となるような手段はございませんでしょうか？

以上です。
何卒お力添えいただけますと幸いに存じます。

バージョン：4.0.35

データ取得ができない等Zabbixの動作が非常に重くなる事象が発生いたしました。
OS再起動により解消した後、調査したところ以下のような状況でした。

・CPUおよびメモリには異常はなく、終始使用率60%程度で安定していた
・ネットワークトラフィックにも高負荷は見当たらず
・事象の発生とほぼ一致するタイミングで、history housekeeper processおよびhistory syncer processが一気に100%近くにまで上昇していた
・事象発生の約1カ月前に12台ほど監視対象機器を追加していた(アイテム数にして2000件ほどの追加)

これらの状況から、データの取得数が大幅に増加したことでhistory housekeeper processおよびhistory syncer processによる負荷が増大し、
本事象に繋がったのではないかと考えております。

(1)上記の見解に相違ありませんでしょうか？ 他に考えられる可能性などありましたらご教授いただけますと幸いです。
(2)監視対象機器やアイテム数の削減以外に本事象の再発防止となるような手段はございませんでしょうか？

以上です。
何卒お力添えいただけますと幸いに存じます。

#課題：Zabbixにおける大量アラートの抑制
Zabbix初心者です。現在、大量アラートを抑制するための運用課題に取り組んでいますが、要件が複雑なため、調査と検証が難航しています。

#要件（実現したいこと）
以下の要件を満たすアラート制御を実現したいと考えています。
なお、ZabbixバージョンはZabbix 6.0.14

1.規定時間内のアラート発報制御：
・「抑止時間」（例：300秒）内に、同一のログメッセージが「規定回数」（例：3回）に達するまでは、ログメッセージが検出されるたびに毎回アラートを発報する。
2.規定回数超過時のアラート抑制：
・「抑止時間」内に、同一のログメッセージの検出回数が「規定回数」を超えた場合、それ以降のアラート発報を抑制する。
例：「抑止時間」300秒、「規定回数」3回の場合、4回目以降の同一ログメッセージ検出ではアラートを発報しない。
3.時間経過後のリセットとアラート再開：
・「抑止時間」が経過したら、アラート発報回数のカウントをリセットし、リセット後に最初に同一のログメッセージが検出された時点から、再度カウントを開始する。
・リセット前のアラート発報回数に関わらず、リセット後の最初のログメッセージ検出を1回目としてカウントを再開し、上記1）からのサイクルを繰り返す。

#現状の課題

お世話になっております。
環境は以下の通りです。

Rocky Linux 9.4 + Zabbix 7.0.10
Microsoft® SQL Server® 2022 Express

Get databaseアイテムは正常に動作しているので、ODBC接続によるSQL発行自体は問題ないと考えます。

例えば Get performance counters アイテムですが、私の環境ではZabbixから習得すると [] が返ります。
同じsqlをZabbixのターミナルのisqlから実行すると値が取れます。

テンプレートのSQL冒頭に以下の様なパートがあります。

DECLARE @SQLNAME NVARCHAR(22)
SET @SQLNAME = CASE WHEN @@SERVICENAME = 'MSSQLSERVER' THEN 'SQLServer' ELSE 'MSSQL$' + @@SERVICENAME END

1. 変数 @SQLNAME 定義
2. インスタンス名 @@SERVICENAME を取ってきて、MSSQLSERVER なら@SQLNAMEを SQLServer にする。 それ以外の場合は MSSQL$<インスタンス名> にする