Eelco Chaudron <echau...@redhat.com> writes:
> On 20 Jun 2023, at 16:57, Ilya Maximets wrote:
>
>> On 6/20/23 16:10, Aaron Conole wrote:
>>> Adrian Moreno <amore...@redhat.com> writes:
>>>
>>>> On 6/19/23 10:36, Eelco Chaudron wrote:
>>>>> On 16 Jun 2023, at 19:19, Aaron Conole wrote:
>>>>>
>>>>>> Martin Kennelly <mkenn...@redhat.com> writes:
>>>>>>
>>>>>>> Hey ovs community,
>>>>>>>
>>>>>>> I am a developer working on ovn-kubernetes and I want to
>>>>>>> programmatically consume long poll information
>>>>>>> i.e:
>>>>>>> ovs|00211|timeval(handler25)|WARN|Unreasonably long 52388ms poll
>>>>>>> interval (752ms user, 209ms system)
>>>>>>>
>>>>>>> This is currently exposed via journal logs but it's not practical
>>>>>>> to consume it there programmatically and I was
>>>>>>> hoping you could add it to coverage metrics.
>>>>>>
>>>>>> I think it could be useful. I do want to be careful about exposing
>>>>>> these kinds of data in a way that could be misinterpreted. Already,
>>>>>> that log in particular gets misinterpreted quite a bit, and RH gets
>>>>>> customers claiming OVS is misbehaving when they've oversubscribed the
>>>>>> system.
>>>>> +1
>>>>>
>>>>
>>>> Maybe it's a good time to start documenting coverage counters?
>>>
>>> I agree - we should have at least some kind of documentation. Actually,
>>> it would be really nice if we could do something during
>>> COVERAGE_DEFINE() that would be like:
>>>
>>> COVERAGE_DEFINE(ctr, "description")
>>>
>>> and then we can generate documentation from the COVERAGE_DEFINE()s as
>>> well as querying for it with an ovs-appctl command.
>
> I think this might be the only way to keep the doc in sync, however,
> who is going to document the 320+ existing ones?
That becomes a bit of a retro-fit challenge I think. Regardless, maybe
the effort would be worth it.
>>> That might be trying to be too fancy, though.
>>
>>
>> The problem with documenting coverage counters is that we can't
>> and shouldn't claim that these are in any way a stable API.
>> They are mainly for developers. Code can change and there might
>> be no meaningful way preserve current counters or their names.
>> They can change in each release including minor ones without
>> prior notice.
>
> +1000 as even if the direct code near the counter does not changes, it
> could still be impacted the actual counter. Which I have seen before.
>
>> Best regards, Ilya Maximets.
>>
>>>
>>>>>> Mechanically, it would be pretty simple to do something like:
>>>>>>
>>>>>> ---
>>>>>> diff --git a/lib/timeval.c b/lib/timeval.c
>>>>>> index 193c7bab17..00e5f2a74d 100644
>>>>>> --- a/lib/timeval.c
>>>>>> +++ b/lib/timeval.c
>>>>>> @@ -40,6 +40,7 @@
>>>>>> #include "openvswitch/vlog.h"
>>>>>>
>>>>>> VLOG_DEFINE_THIS_MODULE(timeval);
>>>>>> +COVERAGE_DEFINE(long_poll_interval);
>>>>>>
>>>>>> #if !defined(HAVE_CLOCK_GETTIME)
>>>>>> typedef unsigned int clockid_t;
>>>>>> @@ -645,6 +646,8 @@ log_poll_interval(long long int last_wakeup)
>>>>>> struct rusage rusage;
>>>>>>
>>>>>> if (!getrusage_thread(&rusage)) {
>>>>>> + COVERAGE_INC(long_poll_interval);
>>>>>> +
>>>>>> VLOG_WARN("Unreasonably long %lldms poll interval"
>>>>>> " (%lldms user, %lldms system)",
>>>>>> interval,
>>>>>> ---
>>>>>>
>>>>>> This would at least expose the coverage data via the coverage framework
>>>>>> and it can be queried via ovs-appctl. Actually, the advantage here is
>>>>>> that the coverage counter can track some details about X/sec over the
>>>>>> last 5 seconds, minute, hour, in addition to the total, so we can see
>>>>>> whether the condition is ongoing.
>>>>> _______________________________________________
>>>>> dev mailing list
>>>>> d...@openvswitch.org
>>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>
>> _______________________________________________
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
