How to periodically poll a get request

[nitzan-tz]

Following #236 Some outputs are not available in subscription paths (Count the number of arp or mac addresses for example ) and I would like to collect them from CLI output as JSON. Arista has CLI origin to collect some eos command output. If I am doing a get request from CLI it gives me the results as a JSON but I would like to do the same from the config file to collect it periodically. I tried with the following configuration

targets:
  10.33.44.55:6030:
    name: leaf1
    subscriptions:
      - show_version

subscriptions:
  show_version:
    paths:
      - "cli:/show version"
    mode: POLL
    stream-mode: sample
    sample-interval: 30s
    encoding: json

And I see the following logs and I dont get any data from the device (Also verify it with tcpdump ) `

gnmic-1    | 2023/10/05 07:01:47.879547 [gnmic] version=0.32.0, commit=9168854, date=2023-09-05T15:55:35Z, gitURL=https://github.com/openconfig/gnmic, docs=https://gnmic.openconfig.net
gnmic-1    | 2023/10/05 07:01:47.879571 [gnmic] using config file "/app/gnmic.yaml"
gnmic-1    | 2023/10/05 07:01:47.879815 [config] validating processor "convert-to-uint-processor" config
gnmic-1    | 2023/10/05 07:01:47.879834 [config] validating processor "convert-to-int-processor" config
gnmic-1    | 2023/10/05 07:01:47.879860 [config] validating processor "processes_name" config
gnmic-1    | 2023/10/05 07:01:47.879873 [config] validating processor "path-base-processor" config
gnmic-1    | 2023/10/05 07:01:47.879877 [config] validating processor "remove_path" config
gnmic-1    | 2023/10/05 07:01:47.879880 [config] validating processor "convert-to-float-processor" config
gnmic-1    | 2023/10/05 07:01:47.880255 [config] validating processor "convert-to-int-processor" config
gnmic-1    | 2023/10/05 07:01:47.880268 [config] validating processor "processes_name" config
gnmic-1    | 2023/10/05 07:01:47.880271 [config] validating processor "path-base-processor" config
gnmic-1    | 2023/10/05 07:01:47.880306 [config] validating processor "remove_path" config
gnmic-1    | 2023/10/05 07:01:47.880311 [config] validating processor "convert-to-float-processor" config
gnmic-1    | 2023/10/05 07:01:47.880314 [config] validating processor "convert-to-uint-processor" config
gnmic-1    | 2023/10/05 07:01:47.880427 [gnmic] starting target "leaf1" listener
gnmic-1    | 2023/10/05 07:01:47.880503 [gnmic] queuing target "leaf1"
gnmic-1    | 2023/10/05 07:01:47.880515 [gnmic] subscribing to target: "leaf1"

gnmic-1    | failed selecting target to poll: ^D
gnmic-1    | 2023/10/05 07:01:47.883746 [gnmic] target "leaf1" gNMI client created
gnmic-1    | 2023/10/05 07:01:47.885029 [gnmic] sending gNMI SubscribeRequest: subscribe='subscribe:{subscription:{path:{origin:"cli"  elem:{name:"show version"}}}  mode:POLL}', mode='POLL', encoding='JSON', to leaf1

`

Is it possible to run such request periodically from the config file ? If yes what I am doing wrong ?

[karimra]

As mentioned in #236, poll subscriptions are only supported when running in "cli" mode. gNMIc will not poll the targets automatically, it has to be manually triggered by the user. Why not use a stream/sample subscription ?

[nitzan-tz]

Some outputs are not available via GNMI subscription, for example, I didn't find a way to get the number of arp entries per vrf but this output is available via the cli command "show ip arp vrf all summary".

So I thought to use gnmic to get it via the following gnmi path "cli:/show ip arp vrf all summary". It is working from the cli with get request but not as subscription (I think it is some eos behavior ).

If gnmic could run the same get request every X seconds and then parse the JSON output via jq processor I can do this type of monitoring,

Thanks

Nitzan

[gavmckee80]

+1 on this request

[ntwrknrd]

+1 as well

[leonnnn]

I agree this would be useful. My use case is collecting component temperatures from Nokia PSS-8 devices and export them into Prometheus.

Some values can be streamed, but component temperatures notably are only available via Get request. So ideally I could subscribe to some paths and perform a low-frequency periodic Get on some others and have all of them exposed together in /metrics for Prometheus.