Zabbix Documentation 3.2

3.04.04.45.0 (current)| In development:5.2 (devel)| Unsupported:1.82.02.22.43.23.44.2Guidelines

User Tools

Site Tools


ru:manual:discovery:low_level_discovery

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ru:manual:discovery:low_level_discovery [2016/01/07 23:34]
dotneft
ru:manual:discovery:low_level_discovery [2020/01/06 05:55] (current)
dotneft
Line 23: Line 23:
 <​note>​Элементы данных низкоуровневого обнаружения - vfs.fs.discovery,​ net.if.discovery поддерживаются Zabbix агентом начиная с версии 2.0.\\ Элемент данных низкоуровневого обнаружения "​system.cpu.discovery"​ поддерживается Zabbix агентом начиная с версии 2.4.\\ Обнаружение SNMP OID'​ов поддерживается Zabbix сервером и прокси начиная с версии 2.0.\\ Обнаружение с использованием SQL запросов ODBC поддерживается Zabbix сервером и прокси начиная с версии 3.0.</​note>​ <​note>​Элементы данных низкоуровневого обнаружения - vfs.fs.discovery,​ net.if.discovery поддерживаются Zabbix агентом начиная с версии 2.0.\\ Элемент данных низкоуровневого обнаружения "​system.cpu.discovery"​ поддерживается Zabbix агентом начиная с версии 2.4.\\ Обнаружение SNMP OID'​ов поддерживается Zabbix сервером и прокси начиная с версии 2.0.\\ Обнаружение с использованием SQL запросов ODBC поддерживается Zabbix сервером и прокси начиная с версии 3.0.</​note>​
  
-<​note>​Zabbix прокси на IBM DB2 базе данных имеет ограничение в 2048 байт на возвращаемое значение правил низкоуровневого обнаружения. Это ограничение не распространяется на Zabbix сервер,​ так как возвращаемые значения обрабатываются без предварительной записи в базу данных.</​note>​ +Эти макросы затем используются в именах,​ ключах и в других полях прототипов,​ которые являются основой для создания реальных элементов данных,​ триггеров и графиков каждому обнаруженному объекту. Смотрите полный список [[:​ru/​manual/​config/macros/lld_macros|опций]] по использованию макросов в низкоуровневом обнаружении.
- +
-Эти макросы затем используются в именах,​ ключах и в других полях прототипов,​ которые являются основой для создания реальных элементов данных,​ триггеров и графиков каждому обнаруженному объекту. Смотрите полный список [[:​ru/​manual/​appendix/macros/supported_by_location#​макросы_используемые_в_низкоуровневых_обнаружениях|опций]] по использованию макросов в низкоуровневом обнаружении.+
  
 Когда сервер получает значение элемента данных обнаружения,​ он смотрит на пару макрос -> значение и для каждой пары создает реальные элементы данных,​ триггеров и графиков,​ основанных на их прототипах. В приведенном выше примере с "​net.if.discovery",​ сервер будет создавать один набор элементов данных,​ триггеров и графиков для локального интерфейса "​lo"​ и другой набор для интерфейса "​eth0"​. Когда сервер получает значение элемента данных обнаружения,​ он смотрит на пару макрос -> значение и для каждой пары создает реальные элементы данных,​ триггеров и графиков,​ основанных на их прототипах. В приведенном выше примере с "​net.if.discovery",​ сервер будет создавать один набор элементов данных,​ триггеров и графиков для локального интерфейса "​lo"​ и другой набор для интерфейса "​eth0"​.
  
 Следующий раздел иллюстрирует весь процесс,​ описанный выше, в деталях и служит руководством,​ как осуществлять все упомянутые выше типы обнаружений. Последний раздел описывает формат JSON элементов данных обнаружения и дает пример того, как реализовать ваш собственный скрипт для обнаружения файловых систем,​ используя Perl скрипт. Следующий раздел иллюстрирует весь процесс,​ описанный выше, в деталях и служит руководством,​ как осуществлять все упомянутые выше типы обнаружений. Последний раздел описывает формат JSON элементов данных обнаружения и дает пример того, как реализовать ваш собственный скрипт для обнаружения файловых систем,​ используя Perl скрипт.
 +
 +== Ограничения данных для возвращаемых значений ==
 +
 +Ограничения для JSON данных низкоуровневого правила обнаружения отсутствуют,​ если эти данные получены напрямую Zabbix сервером,​ так как полученные значения обрабатываются без сохранения в базу данных. Также ограничения отсутствуют и для пользовательских правил низкоуровневого обнаружения,​ однако,​ если предполагается получение пользовательских LLD данных при помощи пользовательского параметра,​ тогда накладывается ограничение по размеру значения (512 КБ) на сам пользовательский параметр.
 +
 +Если данные поступают от Zabbix прокси,​ этот прокси вынужден сначала записать их в базу данных. В таком случае накладываются ​ [[:​ru/​manual/​config/​items/​item#​ограничения_текстовых_данных|ограничения к базе данных]],​ например,​ 2048 байт для Zabbix прокси,​ который работает с IBM DB2 базой данных.
  
 === - Обнаружение файловых систем === === - Обнаружение файловых систем ===
Line 66: Line 70:
  
 <note important>​База данных Zabbix в MySQL должна быть создана чувствительной к регистру,​ если имена файловых систем различаются только по регистру,​ чтобы обнаружение сработало корректно.</​note>​ <note important>​База данных Zabbix в MySQL должна быть создана чувствительной к регистру,​ если имена файловых систем различаются только по регистру,​ чтобы обнаружение сработало корректно.</​note>​
- + 
 +<note important>​Ошибка или опечатка в регулярном выражении,​ которое используется в LLD правиле элементов конфигурации,​ значений истории и событий по большому количеству узлов сети. Например,​ некорректное регулярное выражение "File systems for discovery"​ может привести к удалению тысяч элементов данных,​ триггеров,​ данных истории и событий.</​note>​ 
 <​note>​История правил обнаружения не сохраняется.</​note>​ <​note>​История правил обнаружения не сохраняется.</​note>​
  
Line 73: Line 79:
 {{manual:​discovery:​low_level_discovery:​item_prototype_fs.png|}} {{manual:​discovery:​low_level_discovery:​item_prototype_fs.png|}}
  
-<​note>​Если прототип элемента данных создан с состоянием //Деактивирован//, ​то он будет добавлен как обнаруженный объект, но в деактивированном состоянии.</​note>​+Атрибуты, которые специфичны для прототипов элементов данных:
  
-//Прототип группы элементов данных// ​является опцией, которая указывается в свойствах ​прототипов элементов данных. В свойствах группы элементов данных вы можете использовать макросы низкоуровневого обнаружения,​ которые,​ после выполнения обнаружения,​ будут заменены реальными значениями при создании групп элементов данных,​ которые специфичны для обнаруженного объекта. Смотрите также [[ru:​manual:​discovery:​low_level_discovery:​notes|заметки по обнаружению групп элементов данных]] для получения более подробной информации.+^Параметр^Описание^ 
 +|//Новый прототип группы элементов данных// ​ |Вы можете ​добавить новый прототип ​группы ​элементов данных.\\ В прототипах групп элементов данных вы можете использовать макросы низкоуровневого обнаружения,​ которые,​ после выполнения обнаружения,​ будут заменены реальными значениями при создании групп элементов данных,​ которые специфичны для обнаруженного объекта. Смотрите также [[ru:​manual:​discovery:​low_level_discovery:​notes|заметки по обнаружению групп элементов данных]] для получения более подробной информации. ​ | 
 +|//​Прототипы групп элементов данных// ​ |Выберите из существующих прототипов групп элементов данных. ​ | 
 +|//​Создать активированным// ​ |Если выбрано,​ элемент данных будет создан в активированном состоянии.\\ Если не выбрано,​ элемент данных будет добавлен как обнаруженный объект,​ но в деактивированном состоянии. ​ |
  
 Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики файловой системы:​ Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики файловой системы:​
Line 84: Line 93:
  
 {{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}} {{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}}
 +
 +Атрибуты,​ которые специфичны для прототипов триггеров:​
 +
 +^Параметр^Описание^
 +|//​Создать активированным// ​ |Если выбрано,​ триггер будет создан в активированном состоянии.\\ Если не выбрано,​ триггер будет добавлен как обнаруженный объект,​ но в деактивированном состоянии. ​ |
 +
 +Когда реальные триггера создаются из прототипов,​ возможно потребуется некая гибкость в отношении того какая константа ('​20'​ в нашем примере) в выражении используется для сравнения. Смотрите как [[:​ru/​manual/​discovery/​low_level_discovery#​Использование_макросов_LLD_в_контекстах_пользовательских_макросов|пользовательские макросы с контекстом]] могут быть полезны для получения подобной гибкости.
  
 Также вы можете задать [[:​ru/​manual/​config/​triggers/​dependencies|зависимости]] между прототипами триггеров (поддерживается начиная с Zabbix 3.0). Чтобы это сделать,​ перейдите на вкладку //​Зависимости//​. Прототип триггеров может зависеть от другого прототипа триггеров из этого же правила низкоуровневого обнаружения (LLD) или от обычного триггера. Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом триггеров. Прототип триггеров узла сети не может зависеть от триггера из шаблона. Также вы можете задать [[:​ru/​manual/​config/​triggers/​dependencies|зависимости]] между прототипами триггеров (поддерживается начиная с Zabbix 3.0). Чтобы это сделать,​ перейдите на вкладку //​Зависимости//​. Прототип триггеров может зависеть от другого прототипа триггеров из этого же правила низкоуровневого обнаружения (LLD) или от обычного триггера. Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом триггеров. Прототип триггеров узла сети не может зависеть от триггера из шаблона.
Line 107: Line 123:
 Обратите внимание,​ что обнаруженные объекты не будут созданы в случае,​ если объекты с такими же условиями уникальности уже существуют,​ например,​ элемент данных с таким же ключем или график с таким же именем. Обратите внимание,​ что обнаруженные объекты не будут созданы в случае,​ если объекты с такими же условиями уникальности уже существуют,​ например,​ элемент данных с таким же ключем или график с таким же именем.
  
-Элементы данных (а также, триггеры и графики) созданые с помощью низкоуровневого правила обнаружения ​невозможно удалить вручную. Тем не менее, они ​будут удалены автоматически,​ если обнаруженный объект (файловая система,​ интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле //​Период сохранения потерянных ресурсов//​.+Элементы данных (а также, триггеры и графики) созданные с помощью низкоуровневого правила обнаружения будут удалены автоматически,​ если обнаруженный объект (файловая система,​ интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле //​Период сохранения потерянных ресурсов//​.
  
 Когда обнаруженный объект становится '​Более не обнаруживается',​ в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных. Когда обнаруженный объект становится '​Более не обнаруживается',​ в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных.
Line 114: Line 130:
  
 Если объекты отмечены на удаление,​ но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся при следующем выполнении правила обнаружения. Если объекты отмечены на удаление,​ но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся при следующем выполнении правила обнаружения.
 +
 +Объекты содержащие другие объекты,​ которые отмечены к удалению,​ не будут обновляться при изменениях на уровне правила обнаружения. Например,​ триггеры обнаруженные при помощи низкоуровневого обнаружения не будут обновляться,​ если они содержат элементы данных,​ которые помечены к удалению.
  
 {{manual:​discovery:​low_level_discovery:​discovered_triggers.png|}} {{manual:​discovery:​low_level_discovery:​discovered_triggers.png|}}
Line 132: Line 150:
 Обнаружение CPU основано на процессе коллектора агента,​ чтобы поддерживать соответствие с данными,​ которые поставляются коллектором и сохранить ресурсы на получение данных. Такое поведение дает эффект,​ что этот ключ элемента данных не работает с флагом командой строки тестирования (-t) бинарного файла, который возвращает состояние NOT_SUPPORTED и сопутствующее сообщение о том, что процесс коллектора не запущен. Обнаружение CPU основано на процессе коллектора агента,​ чтобы поддерживать соответствие с данными,​ которые поставляются коллектором и сохранить ресурсы на получение данных. Такое поведение дает эффект,​ что этот ключ элемента данных не работает с флагом командой строки тестирования (-t) бинарного файла, который возвращает состояние NOT_SUPPORTED и сопутствующее сообщение о том, что процесс коллектора не запущен.
  
-Прототипы элементов данных,​ которые можно создать на основе обнаружения CPU включают в себя "​system.cpu.load[{#​CPU.NUMBER},​ <​режим>​]"​"​system.cpu.util[{#​CPU.NUMBER},​ <тип>, <режим>​]" ​и другие.+Прототипы элементов данных,​ которые можно создать на основе обнаружения CPU включают в себя, например, ​"​system.cpu.util[{#​CPU.NUMBER}, <​тип>​, <​режим>​]" ​и "​system.hw.cpu[{#​CPU.NUMBER},​ <информация>​]"​.
  
 === - Обнаружение SNMP OID'​ов === === - Обнаружение SNMP OID'​ов ===
Line 174: Line 192:
               "​{#​SNMPINDEX}":​ "​2",​               "​{#​SNMPINDEX}":​ "​2",​
               "​{#​IFDESCR}":​ "​LAN1",​               "​{#​IFDESCR}":​ "​LAN1",​
-              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​75"+              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​76"
           },           },
           {           {
Line 250: Line 268:
 Когда сервер работает,​ он создаст реальные элементы данных,​ триггеры и графики на основе значений,​ полученных от SNMP правила обнаружения. В настройках узлов сети они будут иметь префикс ссылку оранжевого цвета, которая ведет к правилу обнаружения,​ их создавшего. Когда сервер работает,​ он создаст реальные элементы данных,​ триггеры и графики на основе значений,​ полученных от SNMP правила обнаружения. В настройках узлов сети они будут иметь префикс ссылку оранжевого цвета, которая ведет к правилу обнаружения,​ их создавшего.
  
-{{manual:​discovery:​low_level_discovery:​discovered_items_snmp.png?600|}}+{{manual:​discovery:​low_level_discovery:​discovered_items_snmp.png|}}
  
-{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png?600|}}+{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png|}}
  
-{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png?600|}}+{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png|}}
  
 === - Обнаружение с использованием SQL запросов ODBC === === - Обнаружение с использованием SQL запросов ODBC ===
Line 282: Line 300:
 Благодаря внутреннему механизму обработки элемента данных "​db.odbc.discovery[]",​ результат этого запроса автоматически преобразуется в следующий JSON: Благодаря внутреннему механизму обработки элемента данных "​db.odbc.discovery[]",​ результат этого запроса автоматически преобразуется в следующий JSON:
  
-<​code ​js>+<​code ​java>
 { {
     "​data":​ [     "​data":​ [
Line 346: Line 364:
  
 Макросы {#​SERVICE.STATE} и {#​SERVICE.STATENAME} возвращают одинаковое содержимое,​ однако,​ {#​SERVICE.STATE} возвращает числовое значение (0-7), тогда как {#​SERVICE.STATENAME} возвращает текст (//​running//,​ //paused//, //start pending//, //pause pending//, //continue pending//, //stop pending//, //stopped// или //​unknown//​). То же самое относится и к {#​SERVICE.STARTUP} и {#​SERVICE.STARTUPNAME},​ где первый возвращает числовое значение (0-4), тогда как второй - текст (//​automatic//,​ //automatic delayed//, //manual//, //​disabled//,​ //​unknown//​). Макросы {#​SERVICE.STATE} и {#​SERVICE.STATENAME} возвращают одинаковое содержимое,​ однако,​ {#​SERVICE.STATE} возвращает числовое значение (0-7), тогда как {#​SERVICE.STATENAME} возвращает текст (//​running//,​ //paused//, //start pending//, //pause pending//, //continue pending//, //stop pending//, //stopped// или //​unknown//​). То же самое относится и к {#​SERVICE.STARTUP} и {#​SERVICE.STARTUPNAME},​ где первый возвращает числовое значение (0-4), тогда как второй - текст (//​automatic//,​ //automatic delayed//, //manual//, //​disabled//,​ //​unknown//​).
 +
 +=== - Настройка нескольких LLD правил по одному элементу данных ===
 +
 +Начиная с Zabbix агента версии 3.2 имеется возможность изменения ключей элементов данных низкоуровневого обнаружения при помощи "​Alias"​ параметра в [[ru/​manual/​appendix/​config/​zabbix_agentd|zabbix_agentd.conf]] файле, чтобы была возможность настройки нескольких LLD правил по одному элементу данных.
 +
 === - Создание пользовательских LLD правил === === - Создание пользовательских LLD правил ===
  
Line 365: Line 388:
 { {
     ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;     ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
-    $fsname =~ s!/!\\/!g; 
  
     print "​\t,​\n"​ if not $first;     print "​\t,​\n"​ if not $first;
Line 387: Line 409:
     "​data":​[     "​data":​[
     ​     ​
-    { "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​rootfs" ​  }, +    { "​{#​FSNAME}":"/", ​                          "​{#​FSTYPE}":"​rootfs" ​  }, 
-    { "​{#​FSNAME}":"​\/​sys", ​                       "​{#​FSTYPE}":"​sysfs" ​   }, +    { "​{#​FSNAME}":"/​sys", ​                       "​{#​FSTYPE}":"​sysfs" ​   }, 
-    { "​{#​FSNAME}":"​\/​proc", ​                      "​{#​FSTYPE}":"​proc" ​    }, +    { "​{#​FSNAME}":"/​proc", ​                      "​{#​FSTYPE}":"​proc" ​    }, 
-    { "​{#​FSNAME}":"​\/​dev", ​                       "​{#​FSTYPE}":"​devtmpfs"​ }, +    { "​{#​FSNAME}":"/​dev", ​                       "​{#​FSTYPE}":"​devtmpfs"​ }, 
-    { "​{#​FSNAME}":"​\/dev\/​pts", ​                  ​"​{#​FSTYPE}":"​devpts" ​  }, +    { "​{#​FSNAME}":"/​dev/​pts", ​                   "​{#​FSTYPE}":"​devpts" ​  }, 
-    { "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​lib/​init/​rw", ​               "​{#​FSTYPE}":"​tmpfs" ​   }, 
-    { "​{#​FSNAME}":"​\/lib\/init\/​rw", ​             "​{#​FSTYPE}":"​tmpfs" ​   }, +    { "​{#​FSNAME}":"/​dev/​shm", ​                   "​{#​FSTYPE}":"​tmpfs" ​   }, 
-    { "​{#​FSNAME}":"​\/dev\/​shm", ​                  ​"​{#​FSTYPE}":"​tmpfs" ​   }, +    { "​{#​FSNAME}":"/​home", ​                      "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​home", ​                      "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​tmp", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​tmp", ​                       "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​usr", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​usr", ​                       "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​var", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​var", ​                       "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​sys/​fs/​fuse/​connections", ​   "​{#​FSTYPE}":"​fusectl" ​ }
-    { "​{#​FSNAME}":"​\/sys\/fs\/fuse\/​connections",​ "​{#​FSTYPE}":"​fusectl" ​ }+
     ​     ​
     ]     ]
Line 408: Line 429:
  
 <​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся.</​note>​ <​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся.</​note>​
 +
 +Обратите внимание на то, что при использовании пользовательского параметра,​ возвращаемые данные ограничены 512 КБ. Для получения более подробных сведений смотрите [[:​ru/​manual/​discovery/​low_level_discovery#​ограничения_данных_для_возвращаемых_значений|ограничения данных для возвращаемых значений LLD]].
 +
 +=== - Использование макросов LLD в контекстах пользовательских макросов ===
 +
 +Пользовательские макросы [[:​ru/​manual/​config/​macros/​usermacros#​контекст_макросов|с контекстом]] можно использовать для получения более гибких порогов в выражениях триггеров. Можно задать разные пороги на уровне пользовательского макроса и затем использовать в константах триггеров в зависимости от обнаруженного контекста. Обнаруженный контекст появляется тогда, когда [[:​ru/​manual/​appendix/​macros/​supported_by_location#​macros_used_in_low-level_discovery|макрос низкоуровневого обнаружения]],​ используемый в макросах,​ раскрывается в реальные значения.
 +
 +Для иллюстрации мы модем взять данные из примера выше и предположить,​ что будут обнаружены следующие файловые системы:​ ''/'',​ ''/​home'',​ ''/​tmp'',​ ''/​usr'', ​ ''/​var''​.
 +
 +Мы можем добавить прототип триггера,​ который проверяет свободное место на диске, на узел сети, где порог задается при помощи пользовательского макроса с контекстом:​
 +
 +''​{host:​vfs.fs.size[{#​FSNAME},​pfree].last()}<​**{$LOW_SPACE_LIMIT:<​nowiki>"</​nowiki>​{#​FSNAME}<​nowiki>"</​nowiki>​}**''​
 +
 +Затем добавим пользовательские макросы:​
 +  * ''​{$LOW_SPACE_LIMIT}''​ **10**
 +  * ''​{$LOW_SPACE_LIMIT:/​home}''​ **20**
 +  * ''​{$LOW_SPACE_LIMIT:/​tmp}''​ **50**
 +
 +Теперь,​ когда файловые системы будут обнаружены,​ события будут сгенерированы,​ если файловые системы ''/'',​ ''/​usr''​ и ''/​var''​ имеют менее **10**% свободного места на диске, файловая система ''/​home''​ - менее **20**% свободного места на диске или файловая система ''/​tmp''​ - менее **50**% свободного места на диске.
 +
 +<note important>​LLD макросы не поддерживаются внутри контекстов пользовательских макросов в [[ru:​manual:​config:​triggers:​expression#​параметры_функций|параметрах функций триггеров]].</​note>​