On Fri, Mar 11, 2022 at 02:06:46PM +0100, Markus Armbruster wrote:
> Mark Kanda <mark.ka...@oracle.com> writes:
>
> > Introduce QMP support for querying stats. Provide a framework for adding new
> > stats and support for the following commands:
> >
> > - query-stats
> > Returns a list of all stats per target type (only VM and vCPU to start),
> > with
> > additional options for specifying stat names, vCPU qom paths, and providers.
> >
> > - query-stats-schemas
> > Returns a list of stats included in each target type, with an option for
> > specifying the provider.
> >
> > The framework provides a method to register callbacks for these QMP
> > commands.
> >
> > The first use-case will be for fd-based KVM stats (in an upcoming patch).
> >
> > Examples (with fd-based KVM stats):
> >
> > - Query all VM stats:
> >
> > { "execute": "query-stats", "arguments" : { "target": "vm" } }
> >
> > { "return": {
> > "vm": [
> > { "provider": "kvm",
> > "stats": [
> > { "name": "max_mmu_page_hash_collisions", "value": 0 },
> > { "name": "max_mmu_rmap_size", "value": 0 },
> > { "name": "nx_lpage_splits", "value": 148 },
> > ...
> > { "provider": "xyz",
> > "stats": [ ...
> > ...
> > ] } }
> >
> > - Query all vCPU stats:
> >
> > { "execute": "query-stats", "arguments" : { "target": "vcpu" } }
> >
> > { "return": {
> > "vcpus": [
> > { "path": "/machine/unattached/device[0]"
> > "providers": [
> > { "provider": "kvm",
> > "stats": [
> > { "name": "guest_mode", "value": 0 },
> > { "name": "directed_yield_successful", "value": 0 },
> > { "name": "directed_yield_attempted", "value": 106 },
> > ...
> > { "provider": "xyz",
> > "stats": [ ...
> > ...
> > { "path": "/machine/unattached/device[1]"
> > "providers": [
> > { "provider": "kvm",
> > "stats": [...
> > ...
> > } ] } }
> >
> > - Query 'exits' and 'l1d_flush' KVM stats, and 'somestat' from provider
> > 'xyz'
> > for vCPUs '/machine/unattached/device[2]' and
> > '/machine/unattached/device[4]':
> >
> > { "execute": "query-stats",
> > "arguments": {
> > "target": "vcpu",
> > "vcpus": [ "/machine/unattached/device[2]",
> > "/machine/unattached/device[4]" ],
> > "filters": [
> > { "provider": "kvm",
> > "fields": [ "l1d_flush", "exits" ] },
> > { "provider": "xyz",
> > "fields": [ "somestat" ] } ] } }
>
> Are the stats bulky enough to justfify the extra complexity of
> filtering?
I viewed it more as a mechanism to cope with a scenario where
some stats are expensive to query. If the mgmt app only want
to get one specific cheap stat, we don't want to trigger code
that does expensive queries of other stats as a side effect.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
