7.2.2 SNMP képletek szintakszisa

A rendszer segítségével kétféle képletet használhatunk: az első esetben egy SNMP OID-t adhatunk meg, amely vagy csupa számból áll, vagy tartalmazhat prexif-ként valamelyik feltöltött MIB-ből változót. A program ez esetben az adott OID.port-ot méri (ha nem tábla mérésről van szó, akkor a port értéke 0). A fejezet további részében a sokkal általánosabb és nagyobb funkcionalitású második, képlet alapú lehetőségről lesz szó.

A mérés képlet egy szöveges kifejezés, amelynek a kiértékelésével a PVSR meghatározza a mérés értékét. A képlet alapvetően a Perl programozási nyelv szabályait követi, azzal a különbséggel, hogy speciális PVSR elemeket lehet benne felhasználni. Ezen elemek egy része a mérési képlet számítását befolyásolja illetve segít, mások pedig azt határozzák meg, hogy a PVSR hogyan kérdezze le az SNMP értékeket a mért eszköztől. A 7.2.2.1 fejezet az előbbiekkel, a 7.2.2.2 fejezet pedig az utóbbiakkal foglalkozik.

Fontos azt is megemlíteni, hogy a PVSR a mérés képletet alapesetben nem csak a mérés végzésekor használja, hanem a lehetséges mérések felderítésekor is. Amennyiben azonban a mérés képlet első sora ez

#no_discovery#

úgy a PVSR nem végez próba mérés a discovery futtatása során, így ebben az esetben a discovery teljes egészében csak a Leíró OID-nál megadott OID-(ok)ra támaszkodik. Amennyiben ilyen OID nincsen megadva, úgy azt a mérés nem lehet discovery segítségével felvenni. Ilyenkor a nem SNMP típusú eszközökhöz hasonlóan az eszköz szerkesztése során az Egyéb mérések táblázat fejlécében megjelenik egy [add new] link is, aminek a segítségével az ilyen típusú mérést is fel lehet venni.

7.2.2.1 Általános kifejezés elemek

Az alábbi speciális változók használhatóak a képletben. Fontos megjegyezni, hogy a Perl programozási nyelv változókkal ellentétben itt nem kell és nem is szabad használni a $ jelet!

• OUT: A mért érték az OUT változó értéke lesz. A program a kiértékelés során automatikusan hozzárak a kifejezéshez egy „return OUT;” sort, de természetesen lehetőség van a kiértékelésben is használni ezt
• NO_LINEAR_OUT: A szerepe ugyanaz, mint az OUT-nak, a különbség a visszaadott érték feldolgozásában van: az OUT használata esetén az alkalmazás ugyanúgy lineáris nyújtást végez a kapott értéken, mint az interfész mérések esetében, tehát ha a visszaadott érték X, az előző érték pedig Y, akkor az eltárolt érték (X-Y)*INTERVAL/(INTERVAL+DIFFTIME)+Y. Ha a képletben NO_LINEAR_OUT szerepel, akkor nem történik ilyen feldolgozás
• FLOAT_OUT: A szerepe ugyanaz,  mint a NO_LINEAR_OUT-nak, kivéve, hogy ennek a használatával a mérés értéke nem csak egész szám lehet
• NEGATIVE_OUT: Ugyanaz, mint az OUT, csak az értéke negatív is lehet. Csak akkor használható, ha a Számláló mező értéke Nem
• NEGATIVE_NO_LINEAR_OUT: Ugyanaz, mint a NO_LINEAR_OUT, csak az értéke negatív is lehet. Csak akkor használható, ha a Számláló mező értéke Nem
• NEGATIVE_FLOAT_OUT: Ugyanaz, mint a FLOAT_OUT, csak az értéke negatív is lehet. Csak akkor használható, ha a Számláló mező értéke Nem
• UPTIME: Az eszköz sysUptime-a, Unix time alakban
• TIME: A mérés tényleges ideje Unix time alakban
• DIFFTIME: A mérés tényleges ideje és a referencia ideje közötti érték másodpercben. A mért értékek mindig egész mérési intervallumhoz kerülnek eltárolásra, tehát ha a tényleges mérés 7 perckor született, és az intervallum 5 perc, akkor a DIFFTIME értéke 120
• PREVDIFFTIME: A DIFFTIME értéke az előző mérési ciklusban
• INTERVAL: A mérési intervallum értéke másodpercben
• PREVINVAL: A mérési képlet első kifejezésének az eredménye az előző mérési ciklusban. Ha nem volt akkor sikeres mérés, akkor ha nem lehet negatív a mérés eredménye, akkor értéke -1, amúgy undef
• PREVOUTVAL: Hasonló, mint a PREVINVAL, de a második kifejezés eredményével
• PREVVAL: Ha az első mérési kifejezésben használjuk, akkor ugyanaz, mint a PREVINVAL, amúgy pedig ugyanaz, mint a PREVOUTVAL

7.2.2.2 SNMP OID-ok lekérdezése

A lekérdezendő SNMP változók meghatározására két lehetőség is van: egyszerű lekérdezés, amikor az alkalmazás egy adott SNMP OID-ot kérdez le, illetve összetett lekérdezések, amikor többféle OID lekérdezések eredményén valamilyen analitikus függvény számítást (például átlag) végez az alkalmazás és ennek a számításnak az eredményét adja vissza a mérés képlet kiértékelésnek.

Mindkét SNMP lekérdezés esetében vannak azonban közös elemek. A lekérdezés definíciót mindkét esetben két # karakter közé kell behelyezni. A kifejezés végén, azaz közvetlenül a második # karakter előtt használható a .PRE szöveg: ilyenkor a PVSR nem az aktuálisan lemért értéket helyettesíti be, hanem az előző mérési ciklusban kapott értéket. Legvégül mindegyik esetben használható a PORT illetve a PORT(i[,j[,k…]]) jelölés, ahol az i, j, k … helyére számjegyeket kell írni. Ezek mindegyike a mérés Index paraméterére vonatkozik. SNMP esetében a mérés Index-ek általában pont karakterrel elválasztott számokból állnak. A PORT jelölés ennek az Index-nek az értékével helyettesítődik a mérés során; a PORT(i) az i-edik elemre az Index-en belül, ahol az i 1-től számozódik, a PORT(i,j) helyére az i-edik és a j-edik elem kerül, … Például ha az Index értéke 123.25.1.5, akkor a PORT értéke 123.25.1.5 lesz, a PORT(2) értéke 25, a PORT(4,2,3,1)-é pedig 5.25.1.123

7.2.2.2.1 Egyszerű SNMP OID lekérdezések

Ha csak egy adott OID-ot akarunk lekérdezni, akkor az OID számábrázolását vagy a MIB::változó formátumát lehet beírni, mint kifejezést a # karakterek közé. Ez utóbbi feltételezi azt, hogy a MIB feltöltésre kerül a PVSR-be. Például:

·       #1.3.6.1.2.1.2.2.1.10.PORT#

·       #RFC1213-MIB::ifInOctets.PORT(1)#

7.2.2.2.2 Összetett SNMP OID lekérdezések

Az egyszerű lekérdezésen kívül többféle tömeges lekérdező függvényt is lehet alkalmazni, majd ezek eredményén számításokat végezni és a számítások eredményét visszaadni a PVSR mérés képletnek. Az összetett SNMP lekérdezések konfigurációja igen hosszú kifejezéseket is eredményezhet, ezért fontos külön is kihangsúlyozni, hogy a # karakterek között lévő kifejezésben nem lehet ilyenkor sem sortörés, azaz egy sorba kell beírni a mérés képlet szerkesztésekor az egész kifejezést.

Fontos: Amennyiben összetett SNMP OID lekérdezést használunk, úgy a PVSR a mérés képlet alapján nem képes discovery funkcióra, ennek megfelelően a mérés képletet mindig a

#no_discovery#

sorral kell kezdeni

7.2.2.2.2.1 Lekérdező függvények

Három lekérdező függvény közül lehet választani. A lekérdező függvények mindegyikére igaz, hogy több paramétert is meg lehet adni, ezek között vannak kötelezőek és opcionálisak is. A paramétereket kétféleképpen lehet megadni: megadásra kerül mindegyik paraméter a megfelelő sorrendben, esetleg üres értékkel, hogy a PVSR az alapértelmezett értéket válassza, illetve a lista végén lévő üres elemeket el is lehet hagyni. Választhatjuk azonban azt is, hogy a paraméterek tetszőleges sorrendben kerüljenek megadásra, ilyenkor a NÉV=>ÉRTEK alakot kell használni. Mindkét esetben pontos vessző karakterrel kell elválasztani egymástól a paramétereket. Példa hívásokra:

·       VALUE(CISCO-STACK-MIB::portIfIndex.PORT(1,2))

·       LAST(OID=>1.3.6.1.4.1.9.9.42.1.3.1.1.7.PORT;MAX_VALUE=>2147483647;OID_ELEMENT=>1)

Az egyes lekérdező függvények a következőek. A paraméter nevek úgy kerültek feltüntetésre, ahogy a NÉV => ÉRTÉK esetben is használandóak

·       VALUE(OID;CONDITION;QUERY): lekérdezi az adott OID-ot SNMPWALK és/vagy SNMPGET segítségével. A kapott elemek közül azokat veszi, amelyek megfelelnek az opcionális CONDITION feltételnek (formátumát lásd később). Az alkalmazás alapból mind SNMPWALK mind SNMPGET segítségével megpróbálja lekérdezni az OID értékét; az előbbi esetben több, az utóbbi esetben pedig csak egy eredményt adhat a kifejezés. Ez megfelel annak, mintha a QUERY paraméter értékét BOTH-ra állítanánk, míg csak SNMPWALK lekérdezéshez a WALK, csak SNMPGET lekérdezéshez pedig a GET értéket kell megadni. .Mintapéldák:

o   Ugyanazt jelenti a két hívás

VALUE(CISCO-STACK-MIB::portIfIndex.PORT)

VALUE(QUERY=>BOTH;OID=>CISCO-STACK-MIB::portIfIndex.PORT)

o   A kérdéses CISCO-STACK-MIB::portIfIndex SNMP változónak két indexe is van: portModuleIndex és portIndex. Ha a mérés definíció úgy lett kialakítva, hogy a PORT paraméter csak a portModuleIndex értéket tartalmazza (azaz egy modulra vonatkozzon a mérés), úgy a behelyettesítések után a CISCO-STACK-MIB::portIfIndex.PORT nem egy konkrét OID lesz, így biztos, hogy nem az SNMPGET hanem az SNMPWALK hívás lesz a sikeres. Ezért ha akarjuk, akkor meg is adhatjuk a PVSR-nek, hogy csak azzal próbálkozzon:

VALUE(CISCO-STACK-MIB::portIfIndex.PORT;;WALK)

o   Azokat az interfész indexeket adja vissza, amelyek 1-essel kezdődnek

VALUE(1.3.6.1.2.1.2.2.1.1;=~/^1/;WALK)

·       VALUE(VALUE(…)…) illetve VALUE(oid.VALUE(…)…): a VALUE lekérdezéseket egymásba is lehet ágyazni, azaz az OID paraméternek akár egy másik VALUE lekérdezést vagy egy olyan OID-ot is megadhatunk, amiben szerepel egy VALUE hívás. Ilyenkor a legbelső VALUE-t kivéve alapesetben csak SNMPGET üzenettel próbálkozik az alkalmazás. Mintapéldák:

o   A CISCO-STACK-MIB::portIfIndex változókban SNMP interfész index-ek szerepelnek, így ha a korábbi példához hasonlóan egy adott portModuleIndex-hez akarjuk lekérdezni a hozzá tartozó interfészek sebességét:

VALUE(RFC1213-MIB:: ifSpeed.VALUE(CISCO-STACK-MIB::portIfIndex.PORT))

·       INDEX(OID;CONDITION;ONLY_HEX): lekérdezi az OID-ot SNMPWALK segítségével, majd veszi azoknak az eredményül kapott OID-oknak az index-ét, ahol a kapott eredmény megfelel az opcionális CONDITION feltételnek (formátumát lásd később). Az OID paraméter értéke egy vagy több OID is lehet, utóbbi esetben vessző karakterrel kell őket elválasztani. Ha több OID is megadásra kerül, akkor a kapott eredményeket szóközzel választja el az alkalmazás a feltétel vizsgalat során. Ha az ONLY_HEX paraméter értéke 1 és a visszakapott SNMP sztring típusú, akkor a PVSR akkor is a 0x… hexadecimális formátumot (például 0xfa92bc) alkalmazza, hogyha a szövegben csak normál karakterek szerepelnek. Mintapéldák:

o   Azoknak az interfészeknek adja vissza az index-ét, amelyiknél az ifDescr Gigab-vel kezdődik és az ifAdminStatus-a 1 (up), azaz az eredménye például egy lista 10101, 10102, 10103 elemekkel

INDEX(1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.7;=~/^Gigab.+ 1$/)

o   Azoknak az interfészeknek adja vissza az index-ét, amelyek típusa ethernetCsmacd, azaz az OID értéke 6

INDEX(OID=>1.3.6.1.2.1.2.2.1.3;CONDITION => == 6)

·       LAST(OID;CONDITION;ORDER_BY;ORDER_TYPE;OID_ELEMENT;MAX_VALUE;TOP_N;RESULTS;ONLY_HEX): a függvény az OID-hoz tartozó legutolsó elemek megkeresését végzi, majd a találatban szereplő index-eket vagy azok bizonyos elemeit adja vissza. Ezt úgy teszi, hogy először lekérdezi az OID-ot SNMPWALK segítségével, majd veszi azokat, amelyeknél az érték megfelel az opcionális CONDITION feltételnek. Az INDEX függvényhez hasonlóan több SNMP OID is megadható vessző karakterrel elválasztva az OID paraméter értékében. Ha az ONLY_HEX paraméter értéke 1 és a visszakapott SNMP sztring típusú, akkor a PVSR akkor is a 0x… hexadecimális formátumot (például 0xfa92bc) alkalmazza, hogyha a szövegben csak normál karakterek szerepelnek. A kapott index-eket ezek után sorbarendezi, a rendezést az ORDER_BY, ORDER_TYPE és MAX_VALUE elemek szabályozzák:

o   ORDER_BY: ha nincsen megadva, akkor az index-eket olyan sorrendbe rakja, amely megfelel a szabványos SNMP OID sorrendnek (pl 1.1, 1.2, 1.10, 2.1, majd végül 10.2), ilyenkor az ORDER_TYPE paraméternek nem is lehet értéket megmondani. Ha az ORDER_BY-nak egy SNMP OID értéket adunk, akkor azt is lekérdezi SNMPWALK segítségével az alkalmazás majd a sorrendet az ORDER_BY OID-okhoz tartozó értékek és az ORDER_TYPE paraméter alapján állapítja meg. Fontos, hogy mindegyik olyan index értékhez, amelyet rendezni akarunk tartozzon érték az ORDER_BY-ban beállított OID lekérdezésekor, mert ha nem létezik, úgy az az index automatikusan kiszűrésre kerül, hasonlóan a CONDITION-ban lévő feltételeknek nem megfelelőekhez

o   ORDER_TYPE: mi legyen a sorbarendezési elv, azaz az ORDER_BY lekérdezéskor kapott értékeket milyen módon hasonlítsa össze. A lehetséges értékek int (szám sorrend), string (szöveges rendezés) vagy oid (OID index rendezési szabály alapján, lásd a példát az ORDER_BY leírásánál). Ha nincsen megadva, úgy az értéke int

o   MAX_VALUE: ha int a rendezési elv, akkor meg lehet adni azt is, hogy az értéknek mi lehet a maximuma. Erre akkor lehet szükség, hogyha egy olyan SNMP táblát kérdezünk le, amiben folyamatosan keletkeznek új sorok, és például a 4 byte-os sysUptime értékkel vannak indexelve. Ilyenkor be kell állítani azt, hogy a MAX_VALUE értéke 4294967295 (2^32-1), mivel egy idő után a sysUptime értéke "körbe fog fordulni", azaz a 4294967295 indexű sor után időben a 0-ás index következi. Ilyenkor ha a MAX_VALUE nem lenne megadva, akkor a PVSR addíg amíg a 4294967295 index látszódna az SNMP táblában, azt feltételezné, hogy az az utolsó elem a listában. Ha viszont a MAX_VALUE meg van adva és vannak ahhoz képest kicsi és nagy értékek is, akkor érzékeli, hogy ez a sor index körbefordult, és a fenti példában a 0-ás indexet fogja a legutolsónak tekinteni. A MAX_VALUE akkor is megadható, hogyha nincsen megadva ORDER_BY, ilyenkor az index-ek első elemére értelmezi a MAX_VALUE-t, azaz ha például az index értéke 32132.1.1, akkor a 32132-re értelmezi azt

A sorrend megállapítása után megkeresi, hogy milyen elemeket kell visszaadnia. Ez alapesetben az index értéke, de ez állítható is az OID_ELEMENT változóval. Ennek az értéke lehet all vagy vesszővel elválasztott számok. Ez utóbbi esetben az indexet felbontja elemeire, és csak a számokkal jelzett elemeket adja vissza a számok sorrendjében. Azaz például ha egy visszaadható index 4.78.5.3 és az OID_ELEMENT értéke 3,1, akkor az 5.4 értéket fogja majd visszaadni. A függvény az utolsó RESULTS darab egyedi elemet adja vissza a TOP_N elemtől kezdve. Az egyediség hangsúlyozása azért fontos, mivel bár az index-ek mindenképpen egyediek, az OID_ELEMENT változó hatására lehetséges, hogy két vagy több index-nél is ugyanazt az értéket kell visszaadni, ilyenkor ezeket a PVSR összevonja és egynek tekinti a listában. Mindkét változónak 1 az értéke, azaz ha nincsen külön egyik sem megadva, akkor a legutolsó elemet adja vissza, ha a TOP_N értéke pl 2 míg a RESULTS értéke 3, akkor az utolsó előtti, az az előtti és az az előtti index-eket adja vissza.

Mint látható, a LAST függvény sokféle beállítási lehetőséggel rendelkezik, így a mintapélda során a következő feltételezésekkel fogunk élni: a lekérdezett eszköz válaszol - az amúgy nem létező - 1.2.3.4.5 OID-ra mégpedig a következő értékekkel:

1.2.3.4.5.2.5.1:    30

1.2.3.4.5.2.6.1:    12

1.2.3.4.5.2.92.1:   5

1.2.3.4.5.2.101.1:  51

1.2.3.4.5.2.101.2:  52

1.2.3.4.5.3.5.1:    33

1.2.3.4.5.3.6.1:    1

1.2.3.4.5.3.92.1:   4

1.2.3.4.5.3.101.1:  12

1.2.3.4.5.4.5.1:    aaa

1.2.3.4.5.4.6.1:    ccc

1.2.3.4.5.4.92.1:   bbb

Ebben az esetben a következő LAST paraméterek esetében a visszaadott értékek a következőek lesznek:

·       Az utolsó elem az 1.2.3.4.5.2 indexek között

LAST(OID=>1.2.3.4.5.2): 101.2

·       Az utolsó elem az 1.2.3.4.5.2 indexek között, de úgy hogy az index első eleme a 103 értéknél körbefordul. Mivel van a körbeforduláshoz és a 0-hoz közeli index is, ezért a legfrissebnek nem a 101.2-őt, hanem a 6.1-et tekinti a rendszer

LAST(OID=>1.2.3.4.5.2;MAX_VALUE=>103): 6.1

·       Az utolsó előtti elem az 1.2.3.4.5.2 indexek között

LAST(OID=>1.2.3.4.5.2;TOP_N=>2): 101.1

·       Az utolsó és az utolsó előtti elem az 1.2.3.4.5.2 indexek között

LAST(OID=>1.2.3.4.5.2;TOP_N=>1;RESULTS=>2): 101.2 és 101.1

·       Az utolsó és az utolsó előtti elem az 1.2.3.4.5.2 indexek között, de úgy hogy az index-nek csak az első elemét adja vissza. Mivel az index sorrendben az utolsó három érték 101.2, 101.1 és 92.1, de az index első eleme kiválasztása után ez 101, 101 és 92-re módosul, ezért a két 101 értéket a rendszer ugyanannak tekinti, így a második érték nem 101 hanem 92 lesz

LAST(OID=>1.2.3.4.5.2;OID_ELEMENT=>1;RESULTS=>2): 101 és 92

·       Az utolsó két elem, de az 1.2.3.4.5.3 OID értékei alapján határozza meg a sorrendet

LAST(OID=>1.2.3.4.5.2;ORDER_BY=>1.2.3.4.5.3;RESULTS=>2): 5.1 és 101.1

·       Az utolsó, de az 1.2.3.4.5.4 OID értékei szövegesen meghatározva a sorrendet

LAST(OID=>1.2.3.4.5.2;ORDER_BY=>1.2.3.4.5.4;ORDER_TYPE=>string): 6.1

·       Hátulról az ötödik elem az 1.2.3.4.5.2 értéke és nem az index alapján

LAST(OID=>1.2.3.4.5.2;ORDER_BY=>1.2.3.4.5.2;TOP_N=>5): 92.1

·       Hátulról a negyedik elem az 1.2.3.4.5.4 értéke alapján. Az eredmény lista üres lesz, mivel hiába van az 1.2.3.4.5.2 alatt öt index, az ORDER_BY OID-nál csak háromnak van értéke

LAST(OID=>1.2.3.4.5.2;ORDER_BY=>1.2.3.4.5.4;TOP_N=>4): üres lista

Mindhárom függvény esetében lehetőség van a CONDITION változó használatára, amellyel szűrni lehet az eredmények között. Ezek a következők lehetnek:

·       Matematikai operátor és operandus. Az operátor lehet ==, !=, >=, <=, > és <. Példák:

== 123

>= 23

!= 12

·       Szöveges operátor és operandus: egyezőséget (eq) vagy nem egyezőséget (ne) viszgál az alkalmazás, az viszgált értéket pedig dupla idézőjelek közé kell tenni. Példák

eq "sample1"

ne "ccc"

·       Reguláris kifejezés illesztése. A kifejezés végén használható az i jelzés arra, hogy a kisbetű-nagybetű különbséget ne vegye figyelembe a rendszer. Az első három feltétel igaz az Alma értékre, a negyedik azonban nem

=~/Alma/

=~/a.+a/i

!~/a.+a/

!~/a.+a/i

7.2.2.2.2.2 Az ALL függvény

Az ALL(i) függvény nem végez tényleges számítást, csupán index felépítéssel kapcsolatos információt közöl a PVSR-rel. A jelentése i darab tetszőleges index elem. Azaz például az RFC1213-MIB::ifInOctets.ALL(1) azt fogja jelenti a PVSR-nek, hogy az RFC1213-MIB::ifInOctets OID alatti OID-okat kérdezi le és az alatt még egy elemet (jelen esetben az interfész index-ét) fogja megtalálni. Példákat a függvény használatára a számításokat végző függvényeknél lehet találni

7.2.2.2.2.3 Számításokat végző függvények

A lekérdező függvények eredményképpen nulla, egy vagy több értéket tartalmazó lista áll elő. Az így kapott listát számításokat végző függvényekkel kell feldolgozni. Ezeknek a függvényeknek csak egy paraméterük van, az a kifejezés, amely segítségével előálltak a kívánt OID-ok vagy közvetlenül maguk a kifejezések. A függvény eredménye kerül átadásra a PVSR mérés képlete számára, így a mintapéldákban a kezdő és vég # is szerepeltetésre került

A mintapéldákban a korábban már használt nem létező 1.2.3.4.5 OID tábla lesz felhasználva:

1.2.3.4.5.2.5.1:    30

1.2.3.4.5.2.6.1:    12

1.2.3.4.5.2.92.1:   5

1.2.3.4.5.2.101.1:  51

1.2.3.4.5.2.101.2:  52

1.2.3.4.5.3.5.1:    33

1.2.3.4.5.3.6.1:    1

1.2.3.4.5.3.92.1:   4

1.2.3.4.5.3.101.1:  12

1.2.3.4.5.4.5.1:    aaa

1.2.3.4.5.4.6.1:    ccc

1.2.3.4.5.4.92.1:   bbb

·       COUNT: megszámolja, hogy a kifejezés hány eredményt tartalmazott. Ez az egyedüli függvény, amely akkor is sikeres mérést produkál, hogyha a listának egy eleme sincsen. A 1.2.3.4.5 táblának 12 eleme van, míg az 1.2.3.4.5.2.101-nek kettő és a példában szereplő LAST értéke 101 lesz

#COUNT(1.2.3.4.5.ALL(3))#: 12

#COUNT(1.2.3.4.5.2.LAST(OID=>1.2.3.4.5.2;OID_ELEMENT=>1).ALL(1))#: 2

·       FIRST: veszi a lista első elemét. Amennyiben nem adunk meg számítási függvényt, akkor a PVSR ezt fogja használni. A tábla első elemének az értéke 30, míg a 1.2.3.4.5.2.101 táblájé 51

#FIRST(VALUE(1.2.3.4.5;;WALK))#: 30

#1.2.3.4.5.2.LAST(OID=>1.2.3.4.5.2;OID_ELEMENT=>1).ALL(1)#: 51

·       SUM: összeadja a kapott értékeket

#SUM(1.2.3.4.5.2.LAST(OID=>1.2.3.4.5.2;OID_ELEMENT=>1).ALL(1))#: 103

·       AVG: átlagolja a kapott értékeket

#AVG(1.2.3.4.5.2.LAST(OID=>1.2.3.4.5.2;OID_ELEMENT=>1).ALL(1))#: 51.5

·       MIN: a legkisebb értéket veszi

#MIN(1.2.3.4.5.2.LAST(OID=>1.2.3.4.5.2;OID_ELEMENT=>1).ALL(1))#: 51

·       MAX: a legnagyobb értéket veszi

#MAX(1.2.3.4.5.2.LAST(OID=>1.2.3.4.5.2;OID_ELEMENT=>1).ALL(1))#: 52

7.2.2.2.2.4 Index halmaz függvények

A lekérdező függvények által előállított listát még tovább is feldolgozhatjuk, mielőtt a számításokat végző függvényeket alkalmaznánk. A plusz feldolgozás összeveti a számítások előtt a most és az előző mérési ciklusban kapott index-eket és azok alapján előzetes szűrést illetve számítást végez. A függvény egyik paramétere az hogy a halmaz feldolgozás után milyen számítási függvény hajtódjon végre, azaz a halmaz függvény eredménye kerül közvetlenül átadásra a PVSR mérés képlete számára, így a mintapéldákban a kezdő és vég # is szerepeltetésre került

Két ilyen függvény létezik: a DIFF és a NEW.

A DIFF függvény használható arra, hogy vegye azokat az index-eket, amelyek már az előző mérési ciklusban is jelentkeztek, illetve a mostani ciklusban is megtalálhatóak; számítsa ki az értékekben bekövetkezett változásokat, majd ezekre a változásokra alkalmazza a számítás függvények valamelyikét. A függvénynek egy kötelező és két opcionális paramétere van, de a lekérdező függvényekkel ellentétben itt nem lehet rájuk névvel hivatkozni. Sorrendben a három paraméter az alábbi:

·       Maga a kifejezés, ahogy az a számító függvényeknél is látható

·       Mivel a függvény különbséget számol, ezért arra is fel van készítve, hogy a kapott érték körbefordulhat, így a mérés típusnál megadható maximum értéket itt is meg lehet adni. A mérés típushoz hasonlóan itt is használható a 0 érték, a mérés típusnál leírtaknak megfelelően

·       A különbség számítás után milyen számító függvényt alkalmazzon a rendszer. Azaz a lista operációs és a számító függvényeket nem egymásba ágyazni kell, hanem a lista függvénynél kell meghatározni a számító függvényt is. A paraméter azért csak opcionális, mert a számító függvényeknél leírtakhoz hasonlóan az alapértelmezett a FIRST függvény

Példa: korábbi példákban már szerepelt, hogy egy Cisco modulhoz a VALUE(CISCO-STACK-MIB::portIfIndex.PORT) kifejezéssel lehet lekérdezni a rajta lévő portokhoz tartozó interfészeket (amennyiben a PORT értéke csak a modult azonosítja). Ha ezek után ezekre az interfészekre összegzett forgalom mérést akarunk definiálni, akkor a DIFF függvényt kell használni, hiszen először egyenként ki kell számolni az interfész byte számlálókban történt változást, majd csak utána kell őket összegezni. A kiválaszott interfész számláló 4 byte-os, azaz 4294967295-nél (2^32-1) nagyobb értéket nem tud ábrázolni, így az előző mérés ciklus óta forgalmazott byte-ok száma az alábbi:

#DIFF(RFC1213-MIB::ifOutOctets.VALUE(CISCO-STACK-MIB::portIfIndex.PORT);4294967295;SUM)#

A NEW függvény az ellenkező szűrést valósítja meg: csak azokat az eredményeket választja ki, amelyeket az előző mérési ciklusban még nem látott a rendszer. A függvény akkor lehet hasznos, hogyha egy SNMP táblában folyamatosan keletkeznek új bejegyzések, és mi csak az újakra vagyunk kiváncsiak közülük. A függvénynek egy kötelező és egy opcionális paramétere van:

·       Maga a kifejezés, ahogy az a számító függvényeknél is látható

·       A szűrés után milyen számító függvényt alkalmazzon a rendszer. Azaz a lista operációs és a számító függvényeket nem egymásba ágyazni kell, hanem a lista függvénynél kell meghatározni a számító függvényt is. A paraméter azért csak opcionális, mert a számító függvényeknél leírtakhoz hasonlóan az alapértelmezett a FIRST függvény

7.2.2.3 Nem sikeres mérések

A mérés képletek kiértékelése során az OUT, NO_LINEAR_OUT és FLOAT_OUT esetekben „-1” értéket vesznek fel az egyes OID változók, ha a lekérdezésük nem volt sikeres, illetve ha a mérést nem tekintjük sikeresnek, úgy -1 értéket kell visszaadni. Ezzel szemben ha a NEGATIVE_OUT, NEGATIVE_NO_LINEAR_OUT vagy a NEGATIVE_FLOAT_OUT esetet használjuk, úgy nem definiált (undef) értéket vesznek fel az egyes OID változók, ha a lekérdezésük nem volt sikeres, illetve ha a mérést nem tekintjük sikeresnek, úgy szintén nem definiált (undef) értéket kell visszaadni.

7.2.2.4 Mintapéldák

A mérés képletben a # közötti részeknek egy sorban kell szerepelniük, itt csupán a helyhiány miatt lettek bizonyos részeknél a sorok megtörve