What I'm doing locally is using ssh to run vpp_get_stats. I also modified 
vpp_get_stats to return "stat_type:val1:..:valn:string" strings instead of the 
format currently used (sort of human readable, except the entire thing is not 
that well suited to human reading), I'm not sure how useful this change was, 
but it seemed weird to be writing regex/parsing code for the results. It 
probably makes more sense if we're transporting this stuff to use some sort of 
binary encoding to be honest. Anyway I need the stats for other work, not to 
work on stats, so "good enough". :)

I think it would be useful to create an API that had the functionality of the 
dump command from vpp_get_stats (i.e., pass in a regex), and returned the data 
binary encoded, TBH. A CLI front end could be placed on this too and then one 
could look at stats from the CLI. *shrug* I guess it's really just about if 
anyone wants any of this bad enough to write the code (unless the project would 
reject the changes of course).

Thanks,
Chris.

> On Jan 9, 2020, at 1:38 PM, Ole Troan <otr...@employees.org> wrote:
> 
> Hi Paul,
> 
>> On 9 Jan 2020, at 19:10, Paul Vinciguerra <pvi...@vinciconsulting.com> wrote:
>> 
>> 
>> Sounds like a little scope creep going on there.
>> If you provide protobuf3 encoded api messages to/from vpp, I'll add a grpc 
>> listener option to vpp_papi, in the interim, I'd be glad to add a tls 
>> wrapped listener if there is interest.
> 
> Were you thinking of adding a simple tls/tcp to uds proxy? Must be something 
> off the shelf that can be used. Netcat? Then you want to amend vpp_papi to be 
> able to sit at the other end of that? What did you plan to do with security?
> 
> The grpc idea isn’t too dissimilar. Just pass vpp api messages encapsulated 
> in grpc. One request, one reply and an event message. 
> 
> Cheers 
> Ole
> 
> 
>> 
>> On Thu, Jan 9, 2020 at 12:00 PM Ole Troan <otr...@employees.org> wrote:
>> 
>> 
>>> On 9 Jan 2020, at 16:50, Paul Vinciguerra <pvi...@vinciconsulting.com> 
>>> wrote:
>>> 
>>> 
>>> Is there any objection to adding a tls listener and an instance to the 
>>> stats client to vpp_papi?
>> 
>> Use grpc as transport?
>> 
>> Cheers,
>> Ole
>> 
>>> 
>>>> On Jan 9, 2020, at 6:45 AM, Vratko Polak -X (vrpolak - PANTHEON 
>>>> TECHNOLOGIES at Cisco) via Lists.Fd.Io <vrpolak=cisco....@lists.fd.io> 
>>>> wrote:
>>>> 
>>>> 
>>>> CSIT uses VPP API via socket (tunneled over SSH) for most interactions.
>>>> 
>>>>
>>>> 
>>>> We also read stats for just one (I think) purpose,
>>>> 
>>>> reading runtime stats (/sys/node).
>>>> 
>>>> The way we do that is historical and convoluted,
>>>> 
>>>> for the result see INFO line at [1].
>>>> 
>>>>
>>>> 
>>>> Looking at the result, the appropriate API way
>>>> 
>>>> would be to use send some _dump message
>>>> 
>>>> and process the _details responses, one per node name.
>>>> 
>>>>
>>>> 
>>>> Vratko.
>>>> 
>>>>
>>>> 
>>>> [1] 
>>>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/csit-vpp-perf-verify-master-2n-clx/58/archives/log.html.gz#s1-s1-s1-s1-s1-t1-k2-k9-k1-k1-k4-k1
>>>> 
>>>>
>>>> 
>>>> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Christian 
>>>> Hopps
>>>> Sent: Thursday, January 9, 2020 12:05 PM
>>>> To: Ole Troan <otr...@employees.org>
>>>> Cc: Christian Hopps <cho...@chopps.org>; vpp-dev <vpp-dev@lists.fd.io>
>>>> Subject: Re: [vpp-dev] python api over tcp?
>>>> 
>>>>
>>>> 
>>>> 
>>>> 
>>>> > On Jan 9, 2020, at 5:44 AM, Ole Troan <otr...@employees.org> wrote:
>>>> > 
>>>> > Christian,
>>>> > 
>>>> >>> For exporting data out of the stats segment, I believe there is 
>>>> >>> already quite a few solutions.
>>>> >>> There's the (naive) prometheus example in the repo, vpp_get_stats, 
>>>> >>> there is a Telegraf plugin, a simple gNMI/gRPC plugin.
>>>> >> 
>>>> >> Right I've used vpp_get_stats and may run that with ssh and awk. I 
>>>> >> guess it just seems odd on first encountering this that the CLI 
>>>> >> provided the data, but the binary API didn't. I suppose the view is 
>>>> >> that exposing the stats segment in shared memory *is* the binary API. :)
>>>> > 
>>>> > What certainly would make sense to do, is to put a wrapper on top of 
>>>> > vpp_stats.py that gives you a higher level API of accessing the stats.
>>>> > E.g. a get_interface_counters(). The stat segment also contains the name 
>>>> > to interface index mapping (/if/names).
>>>> > Want to have a go?
>>>> 
>>>> I'm actually going to use vpp_get_stats (run remotely using ssh) for now. 
>>>> I'm using vpp_papi on a single testing server (so it connects to each of 
>>>> the VPP /run/vpp/api.sock over ssh forwarded sockets), so it doesn't have 
>>>> access to their shared memory segments.
>>>> 
>>>> > 
>>>> > I am also exploring putting much more information into the stat segment, 
>>>> > essentially making it into an operational data store (RFC8342). Don't 
>>>> > hold your breath. But any help appreciated.
>>>> 
>>>> I will be looking at doing some YANG models later this year, so if the 
>>>> timing aligns.. :)
>>>> 
>>>> Thanks,
>>>> Chris.
>>>> 
>>>> 
>>>> > Cheers,
>>>> > Ole
>>>> 
>>>> 
>>> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15124): https://lists.fd.io/g/vpp-dev/message/15124
Mute This Topic: https://lists.fd.io/mt/69538850/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
  • ... Christian Hopps
    • ... Ole Troan
      • ... Christian Hopps
        • ... Ole Troan
          • ... Christian Hopps
          • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
          • ... Paul Vinciguerra
          • ... Ole Troan
          • ... Paul Vinciguerra
          • ... Ole Troan
          • ... Christian Hopps
          • ... Paul Vinciguerra
          • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
          • ... Ole Troan
          • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
          • ... Paul Vinciguerra
          • ... Ole Troan

Reply via email to