Re: keepalived.data and keepalived.stats json output
Damien Clabaut <[email protected]> Wed, 19 Jul 2017 09:57:46 -0400
| Newsgroups | gmane.linux.keepalived.devel |
|---|---|
| Message-ID | <[email protected]> |
Btw, usage:
# rm -f /tmp/keepalived*
# kill -s 36 $(cat /var/run/keepalived.pid)
# cat /tmp/keepalived.json
[ { "data": { "iname": "41588", "version": 2, "last_transition":
1500471430, "dont_track_primary": 0, "skip_check_adv_addr": 0 },
"stats": { "advert_rcvd": 0, "advert_sent": 771, "become_master": 1,
"release_master": 0, "packet_len_err": 0, "advert_interval_err": 0,
"ip_ttl_err": 0, "invalid_type_rcvd": 0, "addr_list_err": 0,
"invalid_authtype": 0, "authtype_mismatch": 0, "auth_failure": 0,
"pri_zero_rcvd": 0, "pri_zero_sent": 0 } }, { "data": { "iname":
"61588", "version": 3, "last_transition": 1500471430,
"dont_track_primary": 0, "skip_check_adv_addr": 0 }, "stats": {
"advert_rcvd": 0, "advert_sent": 771, "become_master": 1,
"release_master": 0, "packet_len_err": 0, "advert_interval_err": 0,
"ip_ttl_err": 0, "invalid_type_rcvd": 0, "addr_list_err": 0,
"invalid_authtype": 0, "authtype_mismatch": 0, "auth_failure": 0,
"pri_zero_rcvd": 0, "pri_zero_sent": 0 } } ]
Duckduckgo's json validator tells me this is valid json.
Regards,
On 19/07/17 09:54 AM, Damien Clabaut wrote:
>
> Hello,
>
> Please find attached a first version of the patch.
>
> It applies to master branch at latest commit.
>
> What it does: Create a SIGJSON (kill -s 36) signal which calls a
> vrrp_print_json function which write json data to /tmp/keepalived.json.
>
> I chose to have only one function instead of 2 (data / stats) as it is
> needed to dump instance name from 'data' into 'stats' anyway.
>
> So far I do not dump much data; this can be changed easily. I dump all
> stats though.
>
> I tried to find a way to descript de structure of _vrrp_t and
> _vrrp_stats once to generate dump_stats. dump_data and dump_json from it.
>
> However, the dump_stats function uses heritage that is not in the C
> struct (advertisements->sent in the text, advert_sent in the struct),
> so I do not see a way to generate it from a structure description.
>
> To compile, I pushed the debian/ folder from latest deployed on debian
> (1.3.2-1) and use these commands:
>
> DEB_CFLAGS_SET="-I/usr/include/json-c/" DEB_LDFLAGS_SET="-ljson-c"
> MACVLAN_SUPPORT=yes ./configure --enable-sha1 --enable-debug
>
> DEB_CFLAGS_SET="-I/usr/include/json-c/" DEB_LDFLAGS_SET="-ljson-c"
> MACVLAN_SUPPORT=yes dpkg-buildpackage -us -uc -b -j4
>
> Todo:
>
> - Finish dumping in json all the data that is dumped with -USR1
>
> - Make the entire patch deployed only if specific compilation option
> is set, as is adds dependency to json-c
>
> This is a work in progress and my first attempt at contributing to
> Keepalived, so I am assuming it does not match your code standards.
> Please tell me what you think of it.
>
> Regards,
>
>
> On 18/07/17 09:11 AM, Damien Clabaut wrote:
>>
>> Hello,
>>
>> To be clear, we are talking about opening a AF_UNIX socket at
>> keepalived startup, and be able to ask for json through it ?
>>
>> The Bird router has something similar, I will check how it is
>> implemented and how long it would take to implement it for Keepalived.
>>
>> However, since the work with POSIX signals is already quite advanced,
>> in case this is too long / complicated to implement, can we consider
>> keeping the signal handling solution for now ?
>>
>> I am doing this on my work time and will be expected to provide
>> results soon.
>>
>> Regards,
>>
>>
>> On 17/07/17 04:39 PM, Alexandre Cassen wrote:
>>> Hi Guys,
>>>
>>> Well, maybe designing a req/rep json protocol to request keepalived
>>> states & related would be more futur proof instead of signal handling ?
>>>
>>> Best regs,
>>> Alexandre
>>>
>>> On Mon, Jul 17, 2017 at 9:53 PM, Damien Clabaut
>>> <[email protected] <mailto:[email protected]>>
>>> wrote:
>>>
>>> Hello,
>>>
>>> I have made some progress on the matter. I did not know much
>>> about POSIX signals a few days ago, so I spent a lot of time
>>> figuring out how to manipulate them.
>>>
>>> To keep the code explicit, I defined two constants SIGDATAJS and
>>> SIGSTATJS. They are currently defined this way:
>>>
>>> --- configure.ac <http://configure.ac> 2017-02-18
>>> 12:52:10.000000000 +0100
>>> +++ configure.ac <http://configure.ac> 2017-07-17
>>> 21:07:37.994953146 +0200
>>> @@ -46,6 +46,8 @@
>>> [
>>> #ifndef _CONFIG_H
>>> #define _CONFIG_H
>>> +#define SIGDATAJS ( __SIGRTMIN + 4 )
>>> +#define SIGSTATJS ( __SIGRTMIN + 5 )
>>> ])
>>> AH_BOTTOM(
>>> [
>>>
>>>
>>> __SIGRTMIN to ( __SIGRTMIN + 3 ) are reserved on Linux so I
>>> started at +4.
>>>
>>> The file configure.ac <http://configure.ac> being really long, I
>>> am not yet sure this is the best place to define those
>>> constants. It looks like I need them in config.h for the code to
>>> compile.
>>>
>>> Can you confirm this is a clean place to define those constants ?
>>>
>>> Meanwhile, I am starting to work on the functions that will
>>> actually write the json output (so far they create files and
>>> write one static string in it).
>>>
>>> Regards,
>>>
>>>
>>> On 14/07/17 01:28 PM, Damien Clabaut wrote:
>>>>
>>>> Hello Quentin and thank you for your answer.
>>>>
>>>> I believe we will add two extra signals (USR3 and USR4, or
>>>> something else) and use them to write output to
>>>> /tmp/keepalived_data.json and /tmp/keepalived_stats.json.
>>>>
>>>> This way users can keep using existing scripts with existing
>>>> behaviour, and develop future scripts on new behaviour, at the
>>>> same time.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> On 14/07/17 09:47 AM, Quentin Armitage wrote:
>>>>> On Fri, 2017-07-14 at 08:35 -0400, Damien Clabaut wrote:
>>>>>> Hello Keepalived developers,
>>>>>>
>>>>>> My team and I are considering modifying the file
>>>>>> https://github.com/acassen/keepalived/blob/master/keepalived/vrrp/vrrp_print.c
>>>>>> <https://github.com/acassen/keepalived/blob/master/keepalived/vrrp/vrrp_print.c>
>>>>>> in order to make the /tmp/keepalived.data and /tmp/keepalived.stats a
>>>>>> valid json.
>>>>>>
>>>>>> In your opinion, what would be the best way to do this ?
>>>>>>
>>>>>> - Patching current functions so that kill -USR1 and kill -USR2 return
>>>>>> valid json ?
>>>>>>
>>>>>> - Adding handlers for kill -USR3 and kill -USR4 to return valid json,
>>>>>> leaving -USR1 and -USR2 in their current states ?
>>>>>>
>>>>>> The idea would be to port this patch to the master branch in the end.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>> I don't think we can alter the current functionality - there
>>>>> might be users who have scripts that parse the output files.
>>>>>
>>>>> Of course, there are no signals USR3 and USR4, but there is no
>>>>> reason why you can't use other signals that aren't currently used.
>>>>>
>>>>> I can see three ways of doing this, each of which I would be
>>>>> happy with:
>>>>> 1. Use 2 new signals (this seems to offer the greatest
>>>>> flexibility)
>>>>> 2. Have a global configuration option, e.g. dump_json, which
>>>>> if set will make USR1 and USR2 write json output
>>>>> 3. Use 1 additional signal that each time it is invoked
>>>>> toggles between the current format and json (the default would
>>>>> need to be the current format); this probably isn't the best
>>>>> approach.
>>>>>
>>>>> Depending on how much overhead in terms of code size there is
>>>>> with the json output, it might be useful to make the inclusion
>>>>> of json output a compile time option enabled by a configure
>>>>> option --enable-json.
>>>>>
>>>>> It would be good not to duplicate the existing code, since at
>>>>> the moment when a new option is added we already have to
>>>>> update vrrp_print.c, vrrp_data.c and vrrp_snmp.c, and to have
>>>>> to update a fourth place in the code would be somewhat
>>>>> excessive. In fact I have in mind that at sometime the code in
>>>>> vrrp_print.c and the dump_vrrp() code in vrrp_data.c should be
>>>>> merged.
>>>>>
>>>>> I hope that helps,
>>>>>
>>>>> Quentin Armitage
>>>>>
>>>>>
>>>>
>>>> --
>>>> Damien Clabaut
>>>> R&D vRouter
>>>> ovh.qc.ca <http://ovh.qc.ca>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>>>
>>>>
>>>> _______________________________________________
>>>> Keepalived-devel mailing list
>>>> [email protected]
>>>> <mailto:[email protected]>
>>>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>>>> <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
>>>
>>> --
>>> Damien Clabaut
>>> R&D vRouter
>>> ovh.qc.ca <http://ovh.qc.ca>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Keepalived-devel mailing list
>>> [email protected]
>>> <mailto:[email protected]>
>>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>>> <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
>>>
>>>
>>
>> --
>> Damien Clabaut
>> R&D vRouter
>> ovh.qc.ca
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> Keepalived-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>
> --
> Damien Clabaut
> R&D vRouter
> ovh.qc.ca
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
--
Damien Clabaut
R&D vRouter
ovh.qc.ca
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel