Приведение типов и transformation script

Victor Kirhenshtein

A kak opredelen tip dannih v samom DCI (na zakladke General)? Kakoe original'noe znachenie, poluchaemoe s hosta?

Ogranichenij na kolichestvo DCI net.

SKYnv

ну наиболее стабильная работа идет на стандартных настройках.
то есть тип определяется как unsigned integer,никак не интерпретируется больше, ясно что это недостаточно, потому как на больших значениях данные ожидаемо падают в 0 и нужно использовать unsigned integer64, у этого же наоборот данные падают в нереальный плюс, если тип ансигнед, если сигнед то еще и в минус могут.
Отдаваемый тип явно int64

The total number of octets received on the
            interface, including framing characters.

Вообще мне конечно хотелось бы использовать real для более точного отображения данных, но с ним та же беда, провалы в отрицательные значения.
Причем даже если transformation script

sub main()
{
return uint32((($1*8)/1024)/1024);
}

точки на графике real, хотя в истории они ожидаемо uint32

SKYnv

И еще вопрос в догонку я подозреваю что использовать сдвиги выгоднее деления или не принципиально?
Например для перевода байтов в мегабиты.

sub main()
{
return ($1*8)/(1 << 20);
}

Victor Kirhenshtein

@skynv said in Приведение типов и transformation script:

И еще вопрос в догонку я подозреваю что использовать сдвиги выгоднее деления или не принципиально?

Dlja interpretiruemogo skripta eto ne principial'no

Victor Kirhenshtein

@skynv said in Приведение типов и transformation script:

ну наиболее стабильная работа идет на стандартных настройках.
то есть тип определяется как unsigned integer,никак не интерпретируется больше, ясно что это недостаточно, потому как на больших значениях данные ожидаемо падают в 0 и нужно использовать unsigned integer64, у этого же наоборот данные падают в нереальный плюс, если тип ансигнед, если сигнед то еще и в минус могут.
Отдаваемый тип явно int64
The total number of octets received on the
            interface, including framing characters.

Esli rech' idet o standartnih OIDah dlja trafika na interfeisah (.1.3.6.1.2.1.2.2.1.16 naprimer), to oni imejut SNMP tip Counter, t.e. unsigned 32bit integer. Zaschet togo chto znachenie unsigned, vichislenie delta budet prohodit' pravil'no daze pri perehode cherez 0.

Victor Kirhenshtein

@skynv said in Приведение типов и transformation script:

столкнулся с проблемой что выпадают некорректные значения при сборе и обработке значение.

скрипты примерно такие
sub main()
{
return int64((($1*8)/1024)/1024);
}
выпадают отрицательные значения там где их не может быть, собирается параметр .1.3.6.1.2.1.2.2.1.16.1

Poskol'ku original'noe znachenie 32 bit, to pri pervom umnozenii na 8 mi mozem vijti za predeli vozmoznih znacenij dlja 32 bitnogo celogo, i poluchit' perepolnenie. Ja bi predlozil delat' snachala privedenie znachenija k 64 bitam, chtobi interpretator vse dal'nejshie matematicheskie operacii delal kak s 64 bit znacheniem. Vot malen'kij skript, kotorij pokazivaet raznicu:

println int64((($1 * 8) / 1024) / 1024);
println int64(((int64($1) * 8) / 1024) / 1024);

Rezul'tat:

C:\Source\NetXMS\debug>nxscript math.nxsl 100000000
NetXMS Scripting Host  Version 1.1.10
Copyright (c) 2005-2012 Victor Kirhenshtein

762
762

C:\Source\NetXMS\debug>nxscript math.nxsl 1000000000
NetXMS Scripting Host  Version 1.1.10
Copyright (c) 2005-2012 Victor Kirhenshtein

-562
7629

SKYnv

спасибо за ответ, на области и думал. Просто если counter это uint32 то каким образом он тогда корректно будет отрабатывать значения за диапазоном, которые постоянно поидее сыпятся так-как считаются байты на гигабитном порту.
А то что что на граффике значения не те что в истории это видимо отрабатывает delta processing?

Victor Kirhenshtein

Все счетчики - это беззнаковые целые, и при достижении максимума переходят через 0. Например, если у меня 8-ми битовый счетчик, то при значении 254 прибавив 3 я получу 1. Обычно для счетчиков абсолютные значения не важны, и собирают обычно дельту. В истории должно хранится уже значение после вычисления дельты и обработки transformation скриптом. Что касается быстрых интерфейсов, то переполнение счетчиков происходит очень быстро, и чтобы получить осмысленные значения, надо собирать данные часто, каждые 5-10 секунд, иначе между двумя опросами может произойти несколько переполнений и переходов через 0, и тогда дельта, вычисленная сервером, даст неправильный результат. Можно также использовать 64-битные счетчики из ifXTable (.1.3.6.1.2.1.31.1.1.1.6 и другие), если устройство их поддерживает.

SKYnv

@victor said in Приведение типов и transformation script:

Все счетчики - это беззнаковые целые, и при достижении максимума переходят через 0. Например, если у меня 8-ми битовый счетчик, то при значении 254 прибавив 3 я получу 1. Обычно для счетчиков абсолютные значения не важны, и собирают обычно дельту. В истории должно хранится уже значение после вычисления дельты и обработки transformation скриптом. Что касается быстрых интерфейсов, то переполнение счетчиков происходит очень быстро, и чтобы получить осмысленные значения, надо собирать данные часто, каждые 5-10 секунд, иначе между двумя опросами может произойти несколько переполнений и переходов через 0, и тогда дельта, вычисленная сервером, даст неправильный результат. Можно также использовать 64-битные счетчики из ifXTable (.1.3.6.1.2.1.31.1.1.1.6 и другие), если устройство их поддерживает.

Огромное спасибо, окончательно разобрался в данном вопросе. Немножко обнаглею, а за драйвера на скриптах не брались ::) ?

SKYnv

по .1.3.6.1.2.1.31.1.1.1.6 тип uint64
average delta per sec
polling interval 30

и таким скриптом трансформации

sub main()
{
return ((uint64($1)*8)/(1 << 20));
}

переодически вылазят непонятные максимумы.

SKYnv

а для average delta per sec какой скрипт трудится? может он некорректно с uint64 работает?

может стоит их куда-нибудь вынести для легко редактирования или добавления каких-либо под свои нужды?

Victor Kirhenshtein

это встроенний код, не скрипт. выглядит он так:

      case DCM_AVERAGE_PER_MINUTE:
         nElapsedTime /= 60;  // Convert to minutes
      case DCM_AVERAGE_PER_SECOND:
         // Check elapsed time to prevent divide-by-zero exception
         if (nElapsedTime == 0)
            nElapsedTime++;

         switch(m_dataType)
         {
            case DCI_DT_INT:
               value = ((LONG)value - (LONG)m_prevRawValue) / (LONG)nElapsedTime;
               break;
            case DCI_DT_UINT:
               value = ((DWORD)value - (DWORD)m_prevRawValue) / (DWORD)nElapsedTime;
               break;
            case DCI_DT_INT64:
               value = ((INT64)value - (INT64)m_prevRawValue) / (INT64)nElapsedTime;
               break;
            case DCI_DT_UINT64:
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;
            case DCI_DT_FLOAT:
               value = ((double)value - (double)m_prevRawValue) / (double)nElapsedTime;
               break;
            case DCI_DT_STRING:
               // I don't see any meaning in "average delta per second (minute)" for string
               // values, so result will be 0 if there are no difference between
               // current and previous values, and 1 otherwise
               value = (LONG)((_tcscmp((const TCHAR *)value, (const TCHAR *)m_prevRawValue) == 0) ? 0 : 1);
               break;
            default:
               // Delta calculation is not supported for other types
               break;
         }

SKYnv

@victor said in Приведение типов и transformation script:

это встроенний код, не скрипт. выглядит он так:

      case DCM_AVERAGE_PER_MINUTE:
         nElapsedTime /= 60;  // Convert to minutes
      case DCM_AVERAGE_PER_SECOND:
         // Check elapsed time to prevent divide-by-zero exception
         if (nElapsedTime == 0)
            nElapsedTime++;

         switch(m_dataType)
         {
            case DCI_DT_INT:
               value = ((LONG)value - (LONG)m_prevRawValue) / (LONG)nElapsedTime;
               break;
            case DCI_DT_UINT:
               value = ((DWORD)value - (DWORD)m_prevRawValue) / (DWORD)nElapsedTime;
               break;
            case DCI_DT_INT64:
               value = ((INT64)value - (INT64)m_prevRawValue) / (INT64)nElapsedTime;
               break;
            case DCI_DT_UINT64:
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;
            case DCI_DT_FLOAT:
               value = ((double)value - (double)m_prevRawValue) / (double)nElapsedTime;
               break;
            case DCI_DT_STRING:
               // I don't see any meaning in "average delta per second (minute)" for string
               // values, so result will be 0 if there are no difference between
               // current and previous values, and 1 otherwise
               value = (LONG)((_tcscmp((const TCHAR *)value, (const TCHAR *)m_prevRawValue) == 0) ? 0 : 1);
               break;
            default:
               // Delta calculation is not supported for other types
               break;
         }

Угу приведение вижу, странно, на первый взгляд никаких проблем не должно быть.

case DCI_DT_INT64:
               value = ((INT64)value - (INT64)m_prevRawValue) / (INT64)nElapsedTime;
               break;
case DCI_DT_UINT64:
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;

Не может быть проблемы в платформе? (win32)
Может отказаться от uint64 в пользу int64?

Можно ли предусмотреть какой либо лог который будет отрабатывать флуктуации?
Например

if (DCI_DT_PREV*4) < DCI_DT_NEXT then

пишем в лог

DCI_RAW
DCI_RAW_PREV
DCI_DT_PREV
DCI_DT_NEXT

И тут в голову пришло во время написания.

Когда поле .1.3.6.1.2.1.31.1.1.1.6 достигает максимального значения uint64 он не сбрасывается на 0, либо в других предусмотренных ситуациях? Полез в документацию,из описания поля

The total number of octets received on the interface,
including framing characters. This object is a 64-bit
version of ifInOctets.

Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime.

то есть теоретически у нас может получится ситуация когда
value будет меньше m_prevRawValue

может добавить проверку?

сase DCI_DT_UINT64:
if (QWORD)value < (QWORD)m_prevRawValue then
{
value = m_prevPrevValue;
}
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;

Ну как?

Victor Kirhenshtein

Da, pozaluj smisl v etom est'. Po idee v bol'shinstve situacij propustit' odin poll luchshe chem poluchit' pik na grafike. Ja dumaju sdelat' tak:

Dobavit' flazok "is counter" v DCI - poskol'ku eto mozet bit' naprimer temperatura, i plavat' vverh-vniz - togda sled. znacjenie men'she prediduschego eto ok;
Esli new value < prev value, to libo propustit' poll (net dannih voobsche), libo sdelat' delta value = prev delta value. V ljubom sluchae pik uberem.

SKYnv

@victor said in Приведение типов и transformation script:

Da, pozaluj smisl v etom est'. Po idee v bol'shinstve situacij propustit' odin poll luchshe chem poluchit' pik na grafike. Ja dumaju sdelat' tak:

Dobavit' flazok "is counter" v DCI - poskol'ku eto mozet bit' naprimer temperatura, i plavat' vverh-vniz - togda sled. znacjenie men'she prediduschego eto ok;

Esli new value < prev value, to libo propustit' poll (net dannih voobsche), libo sdelat' delta value = prev delta value. V ljubom sluchae pik uberem.

Спешил, и опечатался в своём сообщении ( даже не опечатался а откровенный бред набрал )
конечно же

if (QWORD)value < (QWORD)m_prevRawValue then
{
value = m_prevPrevValue;
}

Да, это самый лучший вариант, а про флажок, да, забыл ).
спасибо, ждём )
Думаю с этим решаться все проблемы.

Akira

@victor said in Приведение типов и transformation script:

Da, pozaluj smisl v etom est'. Po idee v bol'shinstve situacij propustit' odin poll luchshe chem poluchit' pik na grafike. Ja dumaju sdelat' tak:

Dobavit' flazok "is counter" v DCI - poskol'ku eto mozet bit' naprimer temperatura, i plavat' vverh-vniz - togda sled. znacjenie men'she prediduschego eto ok;

Esli new value < prev value, to libo propustit' poll (net dannih voobsche), libo sdelat' delta value = prev delta value. V ljubom sluchae pik uberem.

2 лучше. Особенно для подсчета DCI значений, где считается просто дельта.

NetXMS Forum

Приведение типов и transformation script