Back to ITRS Internal Only FAQ

Internal documentation only

This page has been marked as draft.

Data too long for column

Example Error Snippet Copied 

DBD::mysql::db do failed: Data too long for column 'output' at row 1 [for Statement "INSERT INTO state_history_staging_table

The error will be displayed within /var/log/opsview/opsview.log file and may appear for different scenarios, but the reason is the same.

For this error, the table is state_history_staging_table and the field is output.

If you are unsure of the database table, you may run a show tables; within the opsview/runtime/odw databases to confirm where that table is located.

Why Copied

Other cases Copied

  1. Incoming data: For example, snmptrapd data, which is simply to long and needs to be sanitised before sending into Opsview or it will be truncated by the database.
  2. Invalid data: The data being inserted may contain unexpected characters or formatting that increases its length, such as additional whitespace or control characters.
  3. Database constraints: There may be database-level constraints or configurations that limit the size of data that can be inserted into certain columns.

Possible solution(s) Copied

  1. If your error is related to the “import_runtime” process, then applying a patch is a direction to take OpsviewImportRuntime.pm Copied

    1. Download the attachments on this article (OpsviewImportRuntime.pm and OpsviewImportRuntime1.pm) and upload them to your Orchestrator server

    2. After upload, they should be placed into /opt/opsview/corelibs/lib/

      • Move only the first patch file first, as if that works, you will not need the second file

    3. Once in the correct directory ensure the files have the correct permissions

      • “-rw-r—– and root opsview”

      • Commands if needed: – chown root.opsview opt/opsview/corelibs/lib/OpsviewImportRuntime.pm – chmod 640 /opt/opsview/corelibs/lib/OpsviewImportRuntime.pm

    4. Take a backup of /opt/opsview/coreutils/bin/import_runtime

    5. Now edit the original /opt/opsview/coreutils/bin/import_runtime to have it match the below (do not copy and paste this from this article, to avoid any dos2unix/control character issues)

      • See the reference below of how file should look after it is updated

    6. Begin the import_runtime process once more

      • Run the below as the root user
      • Depending on how large your hourly imports are, this may take different lengths of time (usually a few seconds to minutes) – /opt/opsview/coreutils/bin/cleanup_import – sudo -iu opsview . /opt/opsview/coreutils/bin/profile && /opt/opsview/coreutils/bin/import_runtime &

    7. Review the logging to see if the process is now successfully importing

      • tail -f /var/log/opsview/opsview.log | grep import_runtime
      • Within the log, the references to “Cache” may take time for each hourly import
      • Useful lines to check for contain “Importing for” and “Finished import for hour”
      • If the process is running now without error you may track the process from the UI service check itself or from the command line – $ sudo -iu opsview /opt/opsview/monitoringscripts/plugins/check_odw_status – Expected Output once up to date: ODW_STATUS OK - Last updated: xxxxxxxxxxxx

    8. If this patch file does not succeed, repeat the process for the second file

      • NOTE: The filenames are very similar, with the different of the number 1 character – Therefore the “use OpsviewImportRuntime;” will now be “use OpsviewImportRuntime1;”

  2. If your error is related to the “metricname”, related to the metricname shown when viewing a graph - The issue is likely that the plugin being used has a pipe (|) character within it and Opsview is seeing all the data after that as Performance Metric information

    • Example error: "DBD::mysql::db do failed: Data too long for column 'metricname' at row 8957 [for Statement "ALTER TABLE opsview_performance_metrics

    1. The error will provide you with the table name and ID to use (again, identify the correct database to use with the show tables; command from within the main mysql/mariadb database)

      • Table here: opsview_performance_metrics — This table is within the runtime database

      • Field: metricname

      • ID: 8957

      Database command would be: select * from opsview_performance_metrics where id = '8957'\G"

      • \G is only used to display the data in a readable format

      Example output: ** 1. row ** id: 8957 service_object_id: 4854 hostname: revtstdb2 servicename: <service check name> metricname: 2024_07_01T11_02_12_085_TUK_CheckCPUData_888140_TNZGetServer_0000683215______Analyze_correlationId__null______ConnectLdn_Server__tst1_agent1______Elapsed__341______URL__https___integratet2_utilisation_co_uk_datahub_location_3_0_information_fullVIN uom: meta_id: 0 interval_starttimev: 0 interval_seconds: 0 tmp_interval_seconds: 0

    2. Solution: A change must be made to your plugin, so that the pipe character isn’t being used in this way

Possible solution(s): Step 5 reference

BEGIN { $ENV{PAR_TMPDIR} = "/opt/opsview/tmp/coreutils" }
use strict;
use warnings;
use FindBin qw($Bin $Script);
use lib '/opt/opsview/perl/lib/perl5', '/opt/opsview/corelibs/lib';
use lib "/opt/opsview/coreutils/etc";
#use PAR '/opt/opsview/corelibs/lib/opsview-core-libs.lib';
## using patched file
use OpsviewImportRuntime;

OpsviewImportRuntime->run;
["Geneos"] ["FAQ"]

Was this topic helpful?