vfs.fs.size アイテムは、第２引数に
「total / free / used」のいずれかを設定する場合は「数値（整数）」
「pfree / pused」のいずれかを設定する場合は「数値（浮動小数）」
と、得られるデータの型が異なるようです
https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/z...

■問題が発生した原因について（内部処理的な観点）
zabbix 内部的には zabbix_agent 内部での filesystem / size 関連処理は
unsiged-int-64bit で処理されているようです
　※：参照：ソースコード：src/libs/zbxsysinfo/linux/diskspace.c
収集された値が zabbix_agent から zabbix_server へ引き渡される段階においては
文字列的な表現でやりとりされているようです
そのため、server へ渡された時点での収集結果値は「1968870047744」といった表現と
なっていたと思われます
さらに今回の場合には、アイテム設定に応じて「浮動小数」のテーブルへ格納するために
小数点以下が付与されて「1968870047744.000000」といった扱いとなっているようです
　※：ログに記載されているのはこの時点での値‥のはず

DB側に着目すると「整数」を格納する「history_uint」テーブルでは
mysql の場合は「bigint unsigned」型、pgsql だと「numeric(20)」型
となっているようで、実質 20桁前後の有効精度がある様子ですが、
「浮動小数」を格納する「history」テーブルでは
mysql の場合は「double(16,4)」型、pgsql だと「numeric(16,4)」型
となっているようです
　※：参照：ソースパッケージ内：schema.sql
　※：参照：DB側、データ型ごとの有効精度については以下
　http://www.cgis.biz/others/mysql/16/
　https://www.postgresql.jp/document/8.2/html/datatype-numeric.html
　https://www.dbonline.jp/mysql/type/index2.html

この場合DB的には、全16桁、うち４桁が小数点以下、という扱いになるため
「1968870047744.000000」の場合、小数点以下の精度不足は「丸め」で捨てられたうえで
「1968870047744.0000」となるまでは良いのですが、
整数部分の桁数が「13桁」となってしまい、DBへ格納可能なデータ桁数を超えてしまいます

そのため、DB格納時にエラーとなっている模様です‥

■問題の解消には
現状、total の取得であるにも関わらず、「数値（整数）」ではなく「数値（浮動小数）」を
設定されているご様子ですので、この問題が発生しています
アイテム設定を「数値（整数）」へ修正されれば、問題は発生しません