Hi,
On 2015-11-27 10:23, Nathan Scott wrote:
>
> Yeah, its not an issue - I'll look into QA'ing and maybe merging pmrep early
> next week, and you can follow up with smaller delta patches to the master
> branch thereafter if you like.
that would be great, yes.
>> Unless there are any suggestions I'm starting to think that the user
>> interface should be considered stable in that sense that any possible
>> changes should be done without changing the current options and syntax
>> if at all possible.
>
> Excellent.
Except now that Frank came up with the FetchGroup API, I realized that
we could compress the compact metricspec format even further (by
combining the current unit/scale and raw fields as one, currently their
use is mutually exclusive so should make things more straightforward).
>> The only thing might be the default time format used. It's currently
>> %H:%M:%S but timestamps with microsecond precision would be somewhat
>
> I think without microseconds will make a good default - most tools tend
> to do this, and that extra precision is only rarely needed (so not worth
> cluttering default reports with usually).
Ok, let's stick with %H:%M:%S.
>> I enhanced the Zabbix reporting so that it can send metrics in batches
>> (in the spirit of zabbix_sender(8)) and it seems to work reliably. The
>> downside on that front is the the zbxsend upstream hasn't responded to
>> my zbxsend / Python 3 patches. One possibility might be to provide
>> pcpzbxsend which would essentially be zbxsend+fixes but I'm not sure
>> would this be optimal.
>
> OK, yep. How much code are we talking about, in the zbxsend module?
> (could you send me a pointer? not sure I have that code handy).
Both the original and the locally fixed versions are ~90 lines of easily
readable code (with BSD license). I've tried to contact the upstream
three times since Oct 20 to no avail. Perhaps we could try one more time
and if no response then use a local copy as long as needed.
https://pypi.python.org/pypi/zbxsend
Cheers,
--
Marko Myllynen
|