W mojej ciągłej eksploracji Kentik NMS nadal odkrywam nie tylko warstwy tego, co produkt może zrobić, ale także warstwy informacji, które po cichu pominąłem w moim oryginalnym przykładzie, mając nadzieję, że nikt tego nie zauważy.

Na tym blogu chcę zarówno przyznać się, jak i poprawić jedną z najbardziej rażących:

Jeśli taka jest temperatura jednego z Państwa urządzeń, powinni Państwo szukać natychmiastowej pomocy. Nie chcę Państwa niepokoić, ale jest ona sześć razy wyższa niż temperatura powierzchni Słońca.

W rzeczywistości SNMP OID, o którym mowa, podaje temperaturę w mC (mikrocelsjusz), więc wszystko, co naprawdę musimy zrobić, to podzielić przez 1000. Otwiera to jednak drzwi do wielu innych sytuacji, w których dostosowanie wskaźników przed wysłaniem ich do Kentik NMS jest nie tylko przyjemne, ale wręcz konieczne.

Starlark dla łatwo rozkojarzonych

Kentik posiada możliwość tworzenia skryptów dzięki uprzejmości Starlark (wcześniej znany jako Skylark), język podobny do Pythona stworzony przez Google.

To ostatnie zdanie albo uspokoi Państwa umysł, albo sprawi, że pobiegną Państwo do drzwi, a ja szczerze mówiąc nie jestem pewien, co o tym myślę.

Wracając jednak do omawianego zadania, Starlark pozwala pobierać wartości przychodzące za pośrednictwem OID, a następnie manipulować nimi.

Blok skryptu, który znajduje się w pliku reports musi definiować funkcję o nazwie process z dwoma parametrami: rekordem i zestawem indeksów. Zazwyczaj wygląda to następująco:

reports:
  /foo/bar/baz:
    script: !starlark |
      def process(n, indexes):
          (do stuff here)

Podsumowując, to jest nasza metryka

Jeśli przegapili Państwo oryginalny post i nie mają Państwo ochoty wracać do niego i go czytać, oto najważniejsze informacje:

• Proszę przenieść (lub utworzyć, jeśli nie istnieje) dedykowany folder w systemie, w którym uruchomiony jest agent Kentik (kagent):

/opt/kentik/components/ranger/local/config

• W tym katalogu proszę utworzyć katalogi /sources, /reports i /profiles
• Proszę utworzyć trzy określone pliki:

1. Pod /sources, plik z listą niestandardowych OID, które mają zostać zebrane
2. W obszarze /reports plik, który kojarzy niestandardowy identyfikator OID z kategorią danych, w której będzie wyświetlany w portalu Kentik.
3. Pod /profiles, plik opisujący typ urządzenia (przy użyciu identyfikatora obiektu systemu SNMP) i raporty, które mają być powiązane z tym typem urządzenia.
4. Proszę upewnić się, że wszystkie te katalogi (i pliki pod nimi) są własnością użytkownika i grupy Kentik:

sudo chown -R kentik:kentik /opt/kentik/components/ranger/

sources/linux.yml

version: 1
metadata:
  name: local-linux
  kind: sources
sources:
  CPUTemp: !snmp
    value: 1.3.6.1.4.1.2021.13.16.2.1.3.1
    interval: 60s

version: 1
metadata:
  name: local-temp
  kind: reports
reports:
  /device/linux/temp:
    fields:
      CPUTemp: !snmp
        value: 1.3.6.1.4.1.2021.13.16.2.1.3.1
        metric: true
    interval: 60s

version: 1
metadata:
  name: local-net-snmp
  kind: profile
profile:
  match:
    sysobjectid:
      - 1.3.6.1.4.1.8072.*
  reports:
    - local-temp
  include:
    - device_name_ip

Jak pokazałem wcześniej w tym poście, daje to dane, które wyglądają tak w Metrics Explorer:

Proszę zauważyć, że moje odczyty temperatury wzrosły w okolice 33 000. Musimy coś z tym zrobić.

This Is Our Metric na Starlark

Najpierw wykonamy prostą matematykę – podzielimy naszą wydajność przez 1000.

• sources/linux.yml – pozostaje bez zmian
• profiles/local-net-snmp.yml – pozostaje bez zmian

Nasz nowy plik reports/linux_temps_report.yml staje się:

version: 1
metadata:
  name: local-temp
  kind: reports
reports:
  /device/linux/temp:
    script: !starlark |
      def process(n, indexes):
        n[’CPUTemp’].value = n[’CPUTemp’].value//1000
    fields:
      CPUTemp: !snmp
        value: 1.3.6.1.4.1.2021.13.16.2.1.3.1
        metric: true
    interval: 60s

• W kategorii /device/linux/temp zadeklarujemy skrypt Starlark
• Skrypt ten będzie pobierał (jest potokowany – | ) proces, który zawiera
  • n, rekord zawierający dane
  • indexes, zestaw indeksów dla rekordu
• Pobiera i ponownie przypisuje wartość CPUTemp z rekordu, zastępując ją oryginalną wartością podzieloną przez 1000
  • Aby zagłębić się na chwilę w tajniki Starlark, dwa ukośniki (“//”) oznaczają “floored division” – które pobiera tylko część całkowitą wyniku.
• Następnie plik YAML identyfikuje sam rekord, pobierając wartość z OID 1.3.6.1.4.1 (i tak dalej).

Proszę powtórzyć, ponieważ to, co robi plik, jest w rzeczywistości odwrotnością tego, co się dzieje:

Plik script: deklaruje proces, ale go nie uruchamia. To tylko przygotowanie sceny.

The fields: to część identyfikująca dane, które pobieramy. Za każdym razem, gdy maszyna zwraca informacje o temperaturze (zestaw rekordów), proces ten jest uruchamiany, zastępując oryginalną wartość CPUTemp wartością CPUTemp/1000.

Wynikiem jest zupełnie inny zestaw wartości temperatury:

Gdy potrzebują Państwo polewy do deserów ORAZ wosku do podłóg

Czasami trzeba wykonać obliczenia matematyczne, ale także zapisać (i wyświetlić) oryginalną wartość. W takim przypadku wystarczy jedna mała zmiana:

version: 1
metadata:
  name: local-temp
  kind: reports
reports:
  /device/linux/temp:
    script: !starlark |
      def process(n, indexes):
        n.append(’CPUTempC’, n[’CPUTemp’].value//1000, metric=True)
    fields:
      CPUTemp: !snmp
        value: 1.3.6.1.4.1.2021.13.16.2.1.3.1
        metric: true
    interval: 60s

Making It More Mathy!

Opierając się na poprzednim przykładzie, wygląda to tak, gdyby chcieli Państwo przekonwertować wynik w skali Celsjusza na Fahrenheita:

version: 1
metadata:
  name: local-tempF
  kind: reports
reports:
  /device/linux/tempF:
    script: !starlark |
      def process(n, indexes):
        n.append(’CPUTempF’, n[’CPUTemp’].value//1000*9/5+32, metric=True)
    fields:
      CPUTemp: !snmp
        value: 1.3.6.1.4.1.2021.13.16.2.1.3.1
        metric: true
    interval: 60s

Starlark dla niezbyt dociekliwych

Jest o wiele więcej do powiedzenia na temat (i odkrywania) Starlark, ale na razie chcę zostawić Państwu tylko kilka ciekawostek:

• Strażnik wywoła funkcję procesu za każdym razem, gdy raport zostanie uruchomiony.
• W przypadku raportów tabelarycznych funkcja procesu będzie wywoływana raz dla każdego wiersza.
  • tworzenie nowych rekordów
  • utrzymywanie stanu przez połączenia do przetwarzania
  • łączenie danych z wielu wierszy tabeli
• Skrypty mogą być zawarte w raporcie (jak pokazano na tym blogu) lub przywoływane jako plik zewnętrzny:

script: !external
  type: starlark
  file: test.star

Building It Up

W moim najnowszym blogu dotyczącym dodawania niestandardowych identyfikatorów OID, pokazałem, jak dodać tabelę wartości zamiast pojedynczego elementu. Konkretnym przypadkiem użycia było podanie temperatur dla każdego z procesorów w systemie.

Pliki YAML do tego celu wyglądały następująco:

sources/linux.yml

version: 1
metadata:
  name: local-linux
  kind: sources
sources:
  CPUTemp: !snmp
    table: 1.3.6.1.4.1.2021.13.16.2
    interval: 60s

version: 1
metadata:
  name: local-temp
  kind: reports
reports:
  /device/linux/temp:
    fields:
      name: !snmp
        table: 1.3.6.1.4.1.2021.13.16.2
        value: 1.3.6.1.4.1.2021.13.16.2.1.2
        metric: false
      CPUTemp: !snmp
        table: 1.3.6.1.4.1.2021.13.16.2
        value: 1.3.6.1.4.1.2021.13.16.2.1.3
        metric: true
    interval: 60s

version: 1
metadata:
  name: local-net-snmp
  kind: profile
profile:
  match:
    sysobjectid:
      - 1.3.6.1.4.1.8072.*
  reports:
    - local-temp
  include:
    - device_name_ip

linux_multitemp.yml

version: 1
metadata:
  name: linux_multitemp
  kind: sources
sources:
  CPUTemp_Multi: !snmp
    table: 1.3.6.1.4.1.2021.13.16.2
    interval: 60s

linux_multitempsc_reports.yml

version: 1
metadata:
  name: local-multitempC
  kind: reports
reports:
  /device/linux/multitempC:
    script: !starlark |
      def process(n, indexes):
        n[’CPUTemp_Multi’].value = n[’CPUTemp_Multi’].value//1000
    fields:
      CPUname: !snmp
        table: 1.3.6.1.4.1.2021.13.16.2
        value: 1.3.6.1.4.1.2021.13.16.2.1.2
        metric: false
      CPUTemp_Multi: !snmp
        table: 1.3.6.1.4.1.2021.13.16.2
        value: 1.3.6.1.4.1.2021.13.16.2.1.3
        metric: true
    interval: 60s

local_net_snmp.yml

version: 1
metadata:
  name: local-net-snmp
  kind: profile
profile:
  match:
    sysobjectid:
      - 1.3.6.1.4.1.8072.*
  reports:
    - local-temp
    - local-multitempC
  include:
    - device_name_ip

Rezultatem jest zachwycająca mieszanka wszystkiego, co do tej pory przetestowaliśmy. Mamy wartości temperatury dla każdego z procesorów w danym systemie, a wartości te zostały przekonwertowane z mikroCelsjusza na Celcjusza.

Po co podsumowywać, skoro obaj wiemy, że jeszcze nie skończyłem?

Ten post, wraz ze wszystkimi poprzednimi, ponownie podkreśla niesamowitą elastyczność i możliwości Kentik NMS. Ale jest o wiele więcej rzeczy do pokazania! Jak pozyskiwać dane spoza SNMP, jak dodawać zupełnie nowe typy urządzeń i jak w ogóle zainstalować NMS.

Proszę poczekać… To jeszcze nie zostało omówione?!?!

Uff. Lepiej zacznę pisać następny post.