Supun, is there a particular reason for not considering JMX here. JMX is a proven way to control runtime of a system as Ruwan mentioned. And probably the containers might have interfaces for MBeans exposed by the application.
On another note, there are some JMX client CLI tools [1] out there. I was able to change the tomcat access log pattern to add the response time using that tool without a server restart. [1] - https://github.com/jiaqi/jmxterm On Wed, Jan 8, 2020 at 6:43 PM Malintha Amarasinghe <[email protected]> wrote: > Getting this into attention again as this is an important improvement as > we can't get the real benefit of the observability feature in some critical > issues of live production systems as it requires a server restart. > > On Wed, Oct 23, 2019 at 8:56 AM Ruwan Abeykoon <[email protected]> wrote: > >> Hi All, >> It is not good idea to have API or Soap service to control any runtime >> feature, as it will cause security issues in default pack if accessible via >> internet. >> Yes, We have similar security issues in "shutdown", but that is >> historical. We should not add any more. >> What we can do is to have a JMX mbean and a CLI tool to call in the >> pack. This works on docker, and headless runtimes such as gateway. >> >> Not enable correlation log is not due to performance, in IAM PoV, it is >> due to fill up the log. >> We could just use the "correlation-log" appender itself to control the >> log, rather than the system flag. >> >> > +1 to control this from the appender itself. In the latest log4j2 we can > dynamically change the appender settings. How about just checking > log.isInfoEnabled() without checking the system property in places like > here [1]. We can by default set the log level to WARN. I tried this in APIM > with some tweaks and it seems it is picking that dynamically and > stars/stops logging. But I had to keep the system property as there seems > to be some lack of initializations. But enabling disabling INFO mode > controlled the logs (as well as the code executions to get additional > information) printed by APIM. > > [1] > https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/gateway/MethodTimeLogger.java#L83-L91 > > Thanks! > Malintha > > Cheers, >> Ruwan A >> >> On Tue, Oct 22, 2019 at 11:53 PM Supun Perera <[email protected]> wrote: >> >>> Hi >>> >>> @Dushan Silva <[email protected]> >>> Yes we should find a way to enable it through the mgt console >>> >>> @Arshardh Ifthikar <[email protected]> >>> I guess enabling the correlation should cause a performance impact, >>> hence not sure whether it will be a good practice to enable it by default. >>> If it doesn't cause a performance impact, yes +1 from me to enable it by >>> default, that will be the easiest solution :) >>> >>> *Supun Perera* >>> *Senior Software Engineer | WSO2* >>> >>> Email : [email protected] >>> Mobile : +94712235101 >>> Web : http://wso2.com >>> >>> <http://wso2.com/signature> >>> >>> >>> >>> On Tue, Oct 22, 2019 at 11:39 PM Arshardh Ifthikar <[email protected]> >>> wrote: >>> >>>> +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> >>>> >>> >> >> -- >> Ruwan Abeykoon | Director/Architect | WSO2 Inc. >> (w) +947435800 | Email: [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Malintha Amarasinghe > *WSO2, Inc. - lean | enterprise | middleware* > http://wso2.com/ > > Mobile : +94 712383306 > -- *Rushmin Fernando* *Technical Lead* WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware mobile : +94775615183
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
