Ad Widget

Collapse

Странное поведение vfs.file.md5sum

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • ManJak
    Member
    • Nov 2009
    • 42

    #1

    Странное поведение vfs.file.md5sum

    Логи с agentd:
    16835:20111007:042607 Requested [vfs.file.md5sum[/etc/passwd]]
    16835:20111007:042607 Sending back [d34ffef87cd2ec5e6a78462acf5a4303]
    16838:20111007:042607 In send_buffer('XXX.XXX.XXX.XXX','10051')

    Проверяем!

    $ md5 /etc/passwd
    MD5 (/etc/passwd) = d34ffef87cd2ec5e6a78462acf5a4303

    => Он отчитался правильно!

    Сервер, при этом, "говорит" ерунду .

    Тип: Zabbix агент
    Ключ: vfs.file.md5sum[/etc/passwd]
    Тип информации: Числовой (целое положительное)
    Тип данных: Десятичный


    Checksum /etc/passwd vfs.file.md5sum[/etc/passwd] 60 0 0 Zabbix агент Не поддерживается -

    Решил провести эксперимент . Меняем тип данных:

    Тип: Zabbix агент
    Ключ: vfs.file.md5sum[/etc/passwd]
    Тип информации: Числовой (целое положительное)
    Тип данных: Шестнадцатеричный

    Результат равен 18446744073709551616. Для любого файла!!!

    Т.е., реально работает, только если выставить тип данных "Текст". Но, это не правильно.

    # zabbix_server --version
    Zabbix Server v1.8.5 (revision 19050) (15 April 2011)
    Compilation time: Sep 20 2011 16:14:46

    FreeBSD 8.2-RELEASE amd64

    Может, я что-то неправильно делаю, т.к. на Заббиксе 1.6 это работало?

    Да и тут работает! Но, сервер об этом не знает .
    $ zabbix_get -s XXX.XXX.XXX.XXX -k vfs.file.md5sum[/etc/passwd]
    d34ffef87cd2ec5e6a78462acf5a4303

    Куда порыть, ума не приложу .
  • dima_dm
    Senior Member
    • Dec 2009
    • 2697

    #2
    Ничего удивительного для Числовой (целое положительное) используется тип данных:
    bigint(20) unsigned для Числовой (целое положительное) (т.е. 0 до 18,446,744,073,709,551,615) т.е. 64 битный счётчик 2^64
    А так-как у вас число больше, вот вы и видите максимальное.

    Вы определили
    Тип данных: Шестнадцатеричный
    Zabbix перевёл число в десятичный вид.

    Comment

    • ManJak
      Member
      • Nov 2009
      • 42

      #3
      Это логично, но почему не поддерживается? По логике, должен произойти перевод числа из основания 16 в 10 и все. Раньше, так и работало.

      Вот это меня и смущает .

      Comment

      • dima_dm
        Senior Member
        • Dec 2009
        • 2697

        #4
        У вас число d34ffef87cd2ec5e6a78462acf5a4303 - 128 Bit, а в MySQL базе под него выделено всего 64 bit.

        Comment

        • ManJak
          Member
          • Nov 2009
          • 42

          #5
          Опа, точно! Спасибо, не подумал об этом .
          Т.е., теперь с ним работать, только как с текстом .

          Comment

          • den_crane
            Senior Member
            • Feb 2006
            • 272

            #6
            Originally posted by ManJak
            Опа, точно! Спасибо, не подумал об этом .
            Т.е., теперь с ним работать, только как с текстом .
            может вы раньше vfs.file.chksum использовали?

            Comment

            • ManJak
              Member
              • Nov 2009
              • 42

              #7
              vfs.file.cksum

              Глянул и точно...

              Спасибо огромное. Совсем заработался

              Comment

              Working...