Telemetria to nie to samo co monitoring zatem i konfiguracja telemetrii przebiega nieco inaczej. To nie system monitorujący odpytuje urządzenia o ich stan, lecz to same urządzenia przesyłają strumień danych, w których zawierają się informacje o statystykach czy zdarzeniach. O tym teoretycznej stronie telemetrii napisałem w pierwszej części. Teraz czas na trochę praktyki, czyli zajmiemy się konfiguracją Model Driven Telemetry w IOS XE.
Konfiguracja telemetrii w IOS XE
Telemetria oparta na modelu to nowe podejście do monitorowania sieci. Dane są przesyłane strumieniowo z urządzeń sieciowych w sposób ciągły przy użyciu modelu push. Zapewnia to dostęp do statystyk operacyjnych niemal w czasie rzeczywistym. Aplikacje mogą subskrybować określone elementy danych, których potrzebują. Wykorzystują w tym celu modele danych YANG. Telemetria strumieniowa Cisco IOS XE umożliwia wypychanie danych z urządzenia do zewnętrznego kolektora ze znacznie wyższą częstotliwością, niż działoby się to przy odpytywaniu choćby za pomocą SNMP. Dzięki temu mechanizm ten działa wydajniej.
Telemetria w modelu dial-in, który opisałem w pierwszej części, nie wymaga konfiguracji po stronie urządzenie. To kolektor łączy się z routerem, aby zainicjować strumień danych. W modelu dial-out odpowiednią konfigurację musimy wprowadzić na urządzeniu. Zdefiniowane w niej są takie parametry jak adres IP kolektora, sposób kodowania danych czy protokół wykorzystywany do komunikacji. Konfigurację wprowadzimy zarówno tradycyjnie z CLI, jak i za pomocą modelu YANG.
telemetry ietf subscription 503
encoding encode-kvgpb
filter xpath /memory-ios-xe-oper:memory-statistics/memory-statistic
stream yang-push
update-policy periodic 2000
receiver ip address 10.10.20.50 57500 protocol grpc-tcp
"mdt-config-data": {
"mdt-subscription":[ {
"subscription-id": "503",
"base": {
"stream": "yang-push",
"encoding": "encode-kvgpb",
"period": "500",
"xpath": "/memory-ios-xe-oper:memory-statistics/memory-statistic"
}
"mdt-receivers": {
"address": ”10.10.20.50"
"port": "57500" }
}
]
}
Weryfikacja działania
Pierwszą czynnością weryfikacyjną jest potwierdzenie, że konfiguracja została poprawnie przyjęta przez urządzenie i subskrypcja jest widoczna.
csrv1000#show telemetry ietf subscription 503
Telemetry subscription brief
ID Type State Filter type
--------------------------------------------------------
503 Configured Valid xpath
W szczegółach subskrypcji znajdują się informacje o włączonych filtrach oraz skonfigurowanych kolektorach, które będą odbierać dane
csrv1000#show telemetry ietf subscription 503 detail
Telemetry subscription detail:
Subscription ID: 503
Type: Configured
State: Valid
Stream: yang-push
Filter:
Filter type: xpath
XPath: /memory-ios-xe-oper:memory-statistics/memory-statistic
Update policy:
Update Trigger: periodic
Period: 2000
Encoding: encode-kvgpb
Source VRF:
Source Address:
Notes:
Receivers:
Address Port Protocol Protocol Profile
-----------------------------------------------------------------------------------------
10.10.20.50 57500 grpc-tcp
Niezwykle ważne jest sprawdzenie stanu połączenia z kolektorem. Jeżeli nie jest on jeszcze poprawnie skonfigurowany to oczekiwaną wartością stanu jest Connecting. Jeżeli kolektor jest skonfigurowany, lecz status jest Disconnected, to oznacza, że mamy problemy z poprawną rejestracją. W takim wypadku pierwszą czynnością, którą wykonamy, będzie usunięcie i ponowne wprowadzenie konfiguracji telemetrii na routerze. Trochę jest dla mnie niezrozumiałe, dlaczego nie ma polecenia clear pozwalającego na zresetowanie takiego połączenia.
csrv1000#show telemetry ietf subscription 503 receiver
Telemetry subscription receivers detail:
Subscription ID: 503
Address: 10.10.20.50
Port: 57500
Protocol: grpc-tcp
Profile:
State: Connecting
Explanation:
Jest jeszcze druga metoda sprawdzenia stanu połączenia.
csrv1000#show telemetry internal connection
Telemetry connection
Peer Address Port VRF Source Address Transport State Profile
--------------- ----- --- --------------- ---------- ------------- -------------
10.10.20.50 57500 0 10.10.20.30 grpc-tcp Connecting
Konfiguracja telemetrii po stronie kolektora
Cisco przygotowało w ramach CiscoDevNet na GitHub repozytorium telemetry_collector. Projekt zawiera skrypt przygotowujący kontenery z aplikacjami Telegraf, InfluxDB i Grafana, o których pisałem w pierwszej części. Jednak projekt ten jest daleki od doskonałości. Nie udało mi się poprawnie skonfigurować komponentów, aby współdziałały ze sobą. Dlatego w swojej instalacji użyłem obrazu Dockera tig_mdt autorstwa Jeremy’ego Cohoe. Zawiera on w sobie wersję 1.7.7 bazy InfluxDB i odpowiednio starszą wersję Telegrafa niż zestaw narzędzi stworzonych przez Cisco. Dodatkowo wszystkie zamknięte są w jednym kontenerze, a nie w kilku oddzielnych.
Uruchomienie kontenera jest bardzo proste:
docker run -ti -p 3000:3000 -p 57500:57500 --name tig_mdt jeremycohoe/tig_mdt
Uruchomienie kontenera spowoduje, że zarejestruje się w kolektorze poprawnie nasze urządzenie. W logach Telegrafa zaś zobaczymy wpisy pokazujące okresowe odbieranie danych wysyłanych przez router.
2021-05-20T12:42:21Z D! [inputs.cisco_telemetry_mdt]: No measurement alias for encoding path: Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic
2021-05-20T12:42:21Z D! [inputs.cisco_telemetry_mdt]: No measurement alias for encoding path: Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic
2021-05-20T12:42:21Z D! [inputs.cisco_telemetry_mdt]: No measurement alias for encoding path: Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic
Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic,host=jcohoe-ubuntu,name=lsmpi_io,source=10.10.20.30,subscription=503 free_memory=824i,lowest_usage=824i,highest_usage=412i,total_memory=3149400i,used_memory=3148576i 1621514541473000000
Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic,host=jcohoe-ubuntu,name=reserve\ Processor,source=10.10.20.30,subscription=503 total_memory=102404i,used_memory=92i,free_memory=102312i,lowest_usage=102312i,highest_usage=102312i 1621514541473000000
Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic,host=jcohoe-ubuntu,name=Processor,source=10.10.20.30,subscription=503 total_memory=2130801968i,used_memory=305199420i,free_memory=1825602548i,lowest_usage=1824544024i,highest_usage=1266221860i 1621514541473000000
2021-05-20T12:42:30Z D! [outputs.file] wrote batch of 3 metrics in 93.722µs
2021-05-20T12:42:30Z D! [outputs.file] buffer fullness: 0 / 10000 metrics.
Na koniec możemy jeszcze zalogować się do bazy InfluxDB i sprawdzić, czy metryki są poprawnie w niej zapisywane
root@d3e3b4ce5e6f:~/telegraf# influx
Connected to http://localhost:8086 version 1.7.7
InfluxDB shell version: 1.7.7
> show databases
name: databases
name
----
_internal
cisco_mdt
> use cisco_mdt
Using database cisco_mdt
> show measurements
name: measurements
name
----
Cisco-IOS-XE-environment-oper:environment-sensors/environment-sensor
Cisco-IOS-XE-interfaces-oper:interfaces/interface
Cisco-IOS-XE-interfaces-oper:interfaces/interface/statistics
Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic
Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization
Cisco-IOS-XE-process-memory-oper:memory-usage-processes/memory-usage-process
ietf-interfaces:interfaces-state/interface/statistics
openconfig-interfaces:interfaces/interface
InfluxDB operuje językiem zapytań podobnym do SQL, dlatego w prosty sposób możemy odczytać czy statystyki się w niej poprawnie zapisują.
> SELECT * FROM "Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic" LIMIT 5
name: Cisco-IOS-XE-memory-oper:memory-statistics/memory-statistic
time free_memory highest_usage host lowest_usage name source subscription total_memory used_memory
---- ----------- ------------- ---- ------------ ---- ------ ------------ ------------ -----------
1571264786134000000 1089242352 1087235964 jcohoe-ubuntu 1086834752 Processor 10.85.134.65 105 1376592520 287350168
1571264786134000000 102312 102312 jcohoe-ubuntu 102312 reserve Processor 10.85.134.65 105 102404 92
1571264786134000000 824 412 jcohoe-ubuntu 824 lsmpi_io 10.85.134.65 105 6295128 6294304
1571264806134000000 102312 102312 jcohoe-ubuntu 102312 reserve Processor 10.85.134.65 105 102404 92
1571264806134000000 824 412 jcohoe-ubuntu 824 lsmpi_io 10.85.134.65 105 6295128 6294304