Cool ... i will go ahead and submit a blueprint for these.
Wrt the compression blueprint, locally we subclassed the base python rotating
file handler class in order to optionally compress the file as part of the
“shouldRollover” stage.
Greg.
From: gordon chung <g...@live.ca>
Reply-To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>
Date: Thursday, November 16, 2017 at 1:49 PM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file'
publisher: Compression and CSV file format
On 2017-11-16 12:44 PM, Waines, Greg wrote:
1.Compression of files (within file rotation) to minimize disk usage and
minimize bandwidth in FTP-ing these files off server
oi.e. as part of file rotation, the newly rotated file would be gzip’d
to compress the file
othis would be an optional parameter in the pipeline definition in
/etc/ceilometer/pipeline.yaml
e.g.
name: meter_file
meters:
- "*"
publishers:
- file:///var/test?max_bytes=10000000&backup_count=5&compress=true
oagain,
minimizing disk usage and minimizing network bandwidth in FTP-ing these
files off server.
seems like a good idea. just curious, how would you implement this?
2.CSV (Comma Separated Values) File Format
oCSV is widely supported for many off-box Statistical Analysis-type
Tools; especially in Telecom,
oagain this would be done as an optional argument to the file publisher
§the existing format (python dictionary print) would remain as the
default format
§‘format=csv’ would be the argument added to the publisher line in order
to enable CSV format
e.g.
name: meter_file
meters:
- "*"
publishers:
- file:///var/test?max_bytes=10000000&backup_count=5&format=csv
this sounds like a good idea. i believe there was a bug previously that
suggested cleaning up the output of the file publisher/dispatcher so
it's not just dumping random blurbs of json. i think the proposed
format=csv trigger makes sense.
I think these would be valuable addons to the Ceilometer File Publisher,
agreed! thanks for suggesting them. this is me assuming you (or a
colleague) will implement this :)
--
gord
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
