NetXMS Support Forum

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

скрипты примерно такие

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

выпадают отрицательные значения там где их не может быть, собирается параметр .1.3.6.1.2.1.2.2.1.16.1

Существуют ли ограничения на количество dci?

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

Ogranichenij na kolichestvo DCI net.

ну наиболее стабильная работа идет на стандартных настройках.
то есть тип определяется как 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

И еще вопрос в догонку я подозреваю что использовать сдвиги выгоднее деления или не принципиально?
Например для перевода байтов в мегабиты.
sub main()
{
return ($1*8)/(1 << 20);
}

Quote from: SKYnv on March 15, 2012, 10:12:27 AM
И еще вопрос в догонку я подозреваю что использовать сдвиги выгоднее деления или не принципиально?

Dlja interpretiruemogo skripta eto ne principial'no

Quote from: SKYnv on March 14, 2012, 02:55:59 PM
ну наиболее стабильная работа идет на стандартных настройках.
то есть тип определяется как unsigned integer,никак не интерпретируется больше, ясно что это недостаточно, потому как на больших значениях данные ожидаемо падают в 0 и нужно использовать unsigned integer64, у этого же наоборот данные падают в нереальный плюс, если тип ансигнед, если сигнед то еще и в минус могут.
Отдаваемый тип явно int64

Code Select Expand

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.

Quote from: SKYnv on March 14, 2012, 08:11:50 AM
столкнулся с проблемой что выпадают некорректные значения при сборе и обработке значение.

скрипты примерно такие

Code Select Expand


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


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

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

Quote from: Victor Kirhenshtein on March 15, 2012, 03:20:42 PM
Все счетчики - это беззнаковые целые, и при достижении максимума переходят через 0. Например, если у меня 8-ми битовый счетчик, то при значении 254 прибавив 3 я получу 1. Обычно для счетчиков абсолютные значения не важны, и собирают обычно дельту. В истории должно хранится уже значение после вычисления дельты и обработки transformation скриптом. Что касается быстрых интерфейсов, то переполнение счетчиков происходит очень быстро, и чтобы получить осмысленные значения, надо собирать данные часто, каждые 5-10 секунд, иначе между двумя опросами может произойти несколько переполнений и переходов через 0, и тогда дельта, вычисленная сервером, даст неправильный результат. Можно также использовать 64-битные счетчики из ifXTable (.1.3.6.1.2.1.31.1.1.1.6 и другие), если устройство их поддерживает.

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

по .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));
}

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

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

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

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


      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;
         }


Quote from: Victor Kirhenshtein on March 28, 2012, 01:27:02 AM
это встроенний код, не скрипт. выглядит он так:

Code Select Expand


      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;



Ну как?

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:

1. 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;
2. Esli new value < prev value, to libo propustit' poll (net dannih voobsche), libo sdelat' delta value = prev delta value. V ljubom sluchae pik uberem.