Hi,
On Mon, Nov 14, 2016 at 03:29:58PM +, Mirek Svoboda wrote:
> What if we have the descriptions in the source code, serving as a single
> source of truth, and generate the JSON schema file from the source code
> upon build?
... or on the fly. That's what I was thinking as well. Ie
"show
Hi
> > OK. So does this mean that a schema will have to be maintained by hand in
> > parallel or will it be deduced from the dump ? I'm starting to be worried
> > about something not being kept up to date if we have to maintain it, or
> > causing a slow down in adoption of new stats entries.
>
>
On Mon, Nov 14, 2016 at 08:50:54AM -0500, hapr...@stormcloud9.net wrote:
> Might help to see an example of what the results look like when using
> this schema, however I do have one comment below.
Yes, agreed. I plan to work on making that so.
> On 2016/11/14 03:09, Simon Horman wrote:
> > Hi
Hi Willy,
On Mon, Nov 14, 2016 at 03:10:18PM +0100, Willy Tarreau wrote:
> On Mon, Nov 14, 2016 at 11:34:18AM +0100, Simon Horman wrote:
> > > Sometimes a description like above appears in your example, is it just
> > > for a few fields or do you intend to describe all of them ? I'm asking
> > >
Hi Simon,
On Mon, Nov 14, 2016 at 09:09:21AM +0100, Simon Horman wrote:
> I took a first pass at defining a schema.
>
> * The schema follows what is described on json-schema.org (or at least
> tries to). Is this a suitable approach?
I'll let others respond as I have no idea since I never need
Hi Willy, Hi All,
On Thu, Nov 10, 2016 at 04:52:56PM +0100, Willy Tarreau wrote:
> Hi Simon!
>
> On Thu, Nov 10, 2016 at 04:27:15PM +0100, Simon Horman wrote:
> > My preference is to take things calmly as TBH I am only just getting
> > started on this and I think the schema could take a little
Hi,
On 16-11-10 16:56:33, Willy Tarreau wrote:
> I removed you from the To in this response, but just as a hint we
> generally recommend to keep people CCed since most of us subscribed
> to lists have filters to automatically place them in the right box,
> and some people may participate without
On Thu, Nov 10, 2016 at 04:30:57PM +0100, ge...@riseup.net wrote:
> (Please don't Cc: me, I'm subscribed to the list.)
I removed you from the To in this response, but just as a hint we
generally recommend to keep people CCed since most of us subscribed
to lists have filters to automatically place
Hi Simon!
On Thu, Nov 10, 2016 at 04:27:15PM +0100, Simon Horman wrote:
> My preference is to take things calmly as TBH I am only just getting
> started on this and I think the schema could take a little time to get
> a consensus on.
I totally agree with you. I think the most difficult thing is
(Please don't Cc: me, I'm subscribed to the list.)
On 16-11-10 16:12:31, Willy Tarreau wrote:
> That's cool!
>
> The only thing is that I don't want to delay the release only for this,
> and at the same time I'm pretty sure it's possible to do something which
> will not impact existing code
On Thu, Nov 10, 2016 at 04:12:31PM +0100, Willy Tarreau wrote:
> Hi Malcolm,
>
> On Thu, Nov 10, 2016 at 12:53:13PM +, Malcolm Turnbull wrote:
> > Georg,
> >
> > That's a timely reminder thanks:
> > I just had another chat with Simon Horman who has kindly offered to
> > take a look at this
Hi Malcolm,
On Thu, Nov 10, 2016 at 12:53:13PM +, Malcolm Turnbull wrote:
> Georg,
>
> That's a timely reminder thanks:
> I just had another chat with Simon Horman who has kindly offered to
> take a look at this again.
That's cool!
The only thing is that I don't want to delay the release
On Thu, 10 Nov 2016, at 13:53, Malcolm Turnbull wrote:
> Georg,
>
> That's a timely reminder thanks:
> I just had another chat with Simon Horman who has kindly offered to
> take a look at this again.
Sounds great!
I'm very interested in logging this continually via chrooted unix
socket,
into
Georg,
That's a timely reminder thanks:
I just had another chat with Simon Horman who has kindly offered to
take a look at this again.
On 10 November 2016 at 10:54, ge...@riseup.net wrote:
> Hi all,
>
> On 16-07-05 10:05:13, Mark Brookes wrote:
>> I wondered if we could
Hi all,
On 16-07-05 10:05:13, Mark Brookes wrote:
> I wondered if we could start a discussion about the possibility of
> having the stats socket return stats data in JSON format.
After the discussion we had in July, I'm wondering what's the current
status regarding this topic?
Thanks and all
Hi,
On 16-07-26 21:47:55, Willy Tarreau wrote:
> I'd like to wait for other people to have the time to participate to
> this discussion, I know that some people are very careful about the
> relevance and accuracy of the stats, some people may want to report
> other suggestions.
I can't add that
On Tue, Jul 26, 2016 at 09:06:05PM +0200, Pavlos Parissis wrote:
> > You probably have not looked at the output of "show stats typed", it
> > gives you the nature of each value letting you know how to aggregate
> > them (min, max, avg, sum, pick any, etc).
> >
>
> I have seen it but it isn't
On 26/07/2016 06:56 μμ, Willy Tarreau wrote:
> On Tue, Jul 26, 2016 at 05:51:08PM +0200, Pavlos Parissis wrote:
>> In all my setups I have nbproc > 1 and after a lot of changes and on how I
>> aggregate HAProxy
>> stats and what most people want to see on graphs, I came up that with
>> something
On Tue, Jul 26, 2016 at 05:51:08PM +0200, Pavlos Parissis wrote:
> In all my setups I have nbproc > 1 and after a lot of changes and on how I
> aggregate HAProxy
> stats and what most people want to see on graphs, I came up that with
> something like the following:
>
> {
> "frontend": {
>
On 26/07/2016 03:30 μμ, Willy Tarreau wrote:
> Hi Pavlos!
>
> On Tue, Jul 26, 2016 at 03:23:01PM +0200, Pavlos Parissis wrote:
>> Here is a suggestion { "frontend": { "www.haproxy.org": { "bin":
>> "", "lbtot":
>> "55", ... }, "www.haproxy.com": { "bin": "", "lbtot":
On Tue, Jul 26, 2016 at 03:06:35PM +0100, Mark Brookes wrote:
> Could we perhaps group by the node then process_num then?
> {nodename:value:
> {pid: pid1: {
> haproxy: {
> Uptime_sec:100,
> PoolFailed:1
> }
> stats: { "frontend": {
>
Could we perhaps group by the node then process_num then?
{nodename:value:
{pid: pid1: {
haproxy: {
Uptime_sec:100,
PoolFailed:1
}
stats: { "frontend": {
"www.haproxy.org": {
"bin": "",
"lbtot":
Hi Pavlos!
On Tue, Jul 26, 2016 at 03:23:01PM +0200, Pavlos Parissis wrote:
> Here is a suggestion
> {
> "frontend": {
> "www.haproxy.org": {
> "bin": "",
> "lbtot": "55",
> ...
> },
> "www.haproxy.com": {
>
On 26/07/2016 03:08 μμ, Willy Tarreau wrote:
> On Tue, Jul 26, 2016 at 02:05:56PM +0100, Mark Brookes wrote:
>>> So for sure I definitely support this proposal :-)
>>
>> Thats great news. Do you have a JSON structure in mind?
>> Or would you like me to come up with something?
>
> I'm probably the
On Tue, Jul 26, 2016 at 02:05:56PM +0100, Mark Brookes wrote:
> >So for sure I definitely support this proposal :-)
>
> Thats great news. Do you have a JSON structure in mind?
> Or would you like me to come up with something?
I'm probably the worst ever person to suggest a JSON structure. If you
>So for sure I definitely support this proposal :-)
Thats great news. Do you have a JSON structure in mind?
Or would you like me to come up with something?
On 5 July 2016 at 18:04, Willy Tarreau wrote:
> Hi Mark,
>
> On Tue, Jul 05, 2016 at 10:05:13AM +0100, Mark Brookes wrote:
>>
Hi Mark,
On Tue, Jul 05, 2016 at 10:05:13AM +0100, Mark Brookes wrote:
> Hi Willy/All
>
> I wondered if we could start a discussion about the possibility of
> having the stats socket return stats data in JSON format.
>
> Im primarily interested in the data that is returned by issuing a
> 'show
Hi Willy/All
I wondered if we could start a discussion about the possibility of
having the stats socket return stats data in JSON format.
Im primarily interested in the data that is returned by issuing a
'show stat' which is normally returned as a csv.
I wont go into specifics as to how the
28 matches
Mail list logo