like we do in it for the storage section configs
we will need this to store the token for influxdbs http api
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
by providing the id or cfg to have better context in those methods
we will need that for influxdb http api
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
so that if one disables the plugin (e.g. because it is offline),
it will work even when the server is not reachable
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since some users don't even have a full 1500 (and some systems might
have links with bigger MTU and not require as much fragmentation).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
We only need to check if the next data addition brings us over the
batch send size, not if we have already at least half of that data in
there, as else we may get again over the batch sent size.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For now it only handles the plugin registration and the two recently
integrated helpers.
But, this is a prepartation to move the external metrics server
update mechanic from a stateless always-newly-connect-send-disconnect
to a statefull transaction based mechanis; see later patches
keep the PVE::Status::Plugin use in pvestatd, as we read the cfs
hosted status.cfg there, and the parser is defined by the common
status plugin base module.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
in preparation of doing real transactions, with one batch connect +
send + disconnect, and not hundreds of those per update cycle..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we allow an id like storage.cfg but leave it optional (so we do not
break existing configs):
influxdb: name
so that one can export the data to multiple servers of the same type
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This allows filtering by node in InfluxDB queries, so the statistics
of all virtual guests on a specific nodes can be queried.
While for InfluxDB this is only a tag which does changes where the
data is stored, Graphite - our other status plugin - has no such
mechanics available. If we would add it to the object hierarchy,
e.g.: "qemu.$vmid.$nodename" a migration of a VM would result in two
different datasets.
So avoid breaking setups and omit it for Graphite for now.
Suggested-by: Daniel1108 <danielgallegosanchez@gmail.com>
CC: Daniel1108 <danielgallegosanchez@gmail.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We only allowed servers with the dns-name format, as such status
server may often be in internal networks and with no hostname
(testing, small network so no dns, ...) do not limit the
configuration possibilities with no reason.
Also move the base property part to the base Status class, all
current plugins use server and port so no need for double
declaration of format/descriptions.
If a future plugin doesn't need them it can omit them by not
returning the respective properties in the options method
inherited by SectionConfig.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
