+1 it would be helpful to have a mechanism to enable/disable correlation
logs in the runtime.
How about enabling correlation logs by default? so that we can analyze the
correlation log file right away, once an issue occurs.

Thanks,
Arshardh


On Tue, Oct 22, 2019 at 10:56 PM Dushan Silva <[email protected]> wrote:

> Sounds like an awesome idea supun, +1 for enabling it during run time. Are
> we providing a mechanism in carbon console to enable it?
>
> On Tue, Oct 22, 2019 at 10:26 PM Asela Pathberiya <[email protected]> wrote:
>
>>
>>
>> On Tue, Oct 22, 2019 at 10:12 PM Supun Perera <[email protected]> wrote:
>>
>>> Reduced Audience
>>>
>>>
>>>
>>> On Tue, Oct 22, 2019 at 9:03 PM Supun Perera <[email protected]> wrote:
>>>
>>>> Hi All,
>>>>
>>>> As the correlation logs is a wonderful feature for troubleshooting the
>>>> issues, It was very helpful in support, However, we have noticed that it
>>>> could be made better if we could enable the same in the server runtime
>>>> rather doing the server restart to apply the same. Hence we believe that it
>>>> would be really great if we could implement a mechanism to *enable and
>>>> disable the correlation logs in run time*.
>>>>
>>>> Further, we have noticed that we could improve the logging events
>>>> details more with the following 4 items. which we believe is certainly
>>>> required for drill down the issues further.
>>>>
>>>> 1. Work on a mechanism to enable and disable the correlation logs in
>>>> runtime without server downtime.
>>>>
>>>
>> Shall we provide an admin API to enable this as developers need to enable
>> this to verify the applications behavior ?
>>
>> Thanks
>> Asela.
>>
>>
>>> 2. Print the Get connection / Close connection time taken (database,
>>>> LDAP) in the correlation logs.
>>>> 3. Print the records iteration (if the LDAP or Database returns many
>>>> records, the time taken for the record iteration is not visible.) - While
>>>> investigating the same we have noticed that each iteration completed with a
>>>> network call as well.
>>>> 4. Print the missing details in between two correlation log event (some
>>>> correlation logs we could notice that the LDAP/ DATABASE query has returned
>>>> within *1 - 2 ms*, however the next line of the correlation log prints
>>>> after several *seconds*. Further investigating the same could notice
>>>> that some of them are caused by triggering event listens. Hence, it would
>>>> be easy to track it further if we could print the correlation ID along with
>>>> the debug/info logs for each component.)
>>>>
>>>> *Supun Perera*
>>>> *Senior Software Engineer | WSO2*
>>>>
>>>> Email   : [email protected]
>>>> Mobile  : +94712235101
>>>> Web     : http://wso2.com
>>>>
>>>> <http://wso2.com/signature>
>>>>
>>>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> Mobile : +94 777 625 933
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
> --
> Best Regards
> Dushan Silva
> Software Engineer
>
> *WSO2, Inc. *
>
> lean . enterprise . middleware
> Mob: +94 774 979042
>


-- 
*Arshardh Ifthikar*
Software Engineer | WSO2 Inc.

Email: [email protected]
Mobile: +94719806525
Web: http://wso2.com

<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to