Проблемы при обновлении
Экранирование и связанные с ним аспекты
Превышение ограничения на количество символов для параметров функций после обновления
Начиная с Zabbix 7.0 обратная косая черта в параметре строкового типа в кавычках функции истории обрабатывается как управляющий символ, а не как обычный символ.
Во время обновления с версий до 7.0 такие обратные косые черты удваиваются, чтобы функция получала то же значение, что и раньше.
Например, find(/host/key,,"regexp","error \d+") преобразуется в find(/host/key,,"regexp","error \\d+").
Это приводит к увеличению длины параметров и может вызвать ошибки в функциях триггеров, если длина параметра превышает 255 символов.
Чтобы избежать этой проблемы, вручную переместите длинные параметры в пользовательские макросы до или после обновления, как показано в примере ниже.
Для удобства чтения длинные последовательности обратных косых черт в примере ниже показаны в виде заполнителей.
Каждый заполнитель обозначает указанное количество символов обратной косой черты, записанных подряд без пробелов (например, <3 backslashes> означает \\\).
Предположим, что в Zabbix 6.0 у вас есть:
- Элемент данных
vfs.file.contents[/tmp/ONE], считывающий файл/tmp/ONE, который содержит 114 обратных косых черт, за которыми следуетa:
<114 backslashes>a
- Calculated_item_228 и Trigger_228, использующие выражение для поиска 114 обратных косых черт, за которыми следует
a(в регулярных выражениях\\обозначает одну литеральную обратную косую черту):
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp","<228 backslashes>a")
- Calculated_item_232 и Trigger_232, использующие выражение для поиска 116 обратных косых черт, за которыми следует
a:
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp","<232 backslashes>a")
При такой конфигурации:
- Calculated_item_228 возвращает
1, а Trigger_228 переходит в состояние PROBLEM, поскольку файл содержит 114 обратных косых черт, за которыми следуетa, как и ищет выражение. - Calculated_item_232 возвращает
0, а Trigger_232 остается в состоянии OK, поскольку файл содержит только 114 обратных косых черт, тогда как выражение ищет 116.
Во время обновления до Zabbix 8.0 сервер Zabbix запишет предупреждение для каждого параметра функции триггера, который слишком длинный для преобразования (выполните поиск по журналу по строке MANUAL INTERVENTION IS REQUIRED, чтобы найти все затронутые параметры).
Например, для Trigger_228 будет записано следующее предупреждение:
2485502:20250228:115442.236 DBpatch_6050165(): cannot save in DB function parameter: resulting size 477 is longer than the maximum 255.
functionid:33792 function:'find'
used on host: 'Zabbix server'
in trigger: 'Trigger_228'.
Current parameter value:
'$,1m:now,"regexp","<228 backslashes>a"'
Resulting escaped value would be:
'$,1m:now,"regexp","<456 backslashes>a"'
DB upgrade and Zabbix server can continue to run, but to make sure this function works correctly
MANUAL INTERVENTION IS REQUIRED !
Need to manually reduce the size of this parameter with macro as a workaround.
После обновления вычисляемые элементы данных будут работать как раньше (например, 228 обратных косых черт превратятся в 456).
Однако оба триггера перейдут в состояние PROBLEM, поскольку их параметры не были преобразованы.
Zabbix 8.0 считывает каждые две обратные косые черты как одну, а регулярное выражение снова уменьшает их количество вдвое:
Trigger_228 ищет 57 обратных косых черт, за которыми следует a, а Trigger_232 ищет 58.
Файл содержит 114 обратных косых черт, за которыми следует a, поэтому оба шаблона будут найдены.
Чтобы исправить это, переместите длинные значения в пользовательские макросы:
| Macro | Value |
|---|---|
{$228_BACKSLASHES_A} |
<228 backslashes>a |
{$232_BACKSLASHES_A} |
<232 backslashes>a |
Затем используйте макросы в выражениях Trigger_228 и Trigger_232:
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp",{$228_BACKSLASHES_A})
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp",{$232_BACKSLASHES_A})
Теперь в состояние PROBLEM перейдет только Trigger_228, как и до обновления. Вычисляемые элементы данных изменять не требуется, но для единообразия их также можно обновить аналогичным образом.