On Mon, Aug 10, 2020 at 2:37 PM Shammi Jayasinghe <sha...@wso2.com> wrote:
> Hi Arshardh, > > Thanks for looking into this. > > This is definitely usable in a system where we can modify , re-deploy > APIs. But practically, In production systems it is not possible. Production > deployments are mission critical where they need to go through various > approval processes to modify the existing APIs, redeploy, Restart etc. So, > this is kind of work around which we can suggest to get the timings. > > Here what i am proposing is > - Without modifying the existing APIs > - Without restarting the running servers > - Just by a change for log4j2 properties file or any other management > console option ( Without restarting) > we should have a way to measure as we required. That is the production > system requirement we should have. > +1 for this proposal. This is an important requirement when it comes to production system troubleshooting. It will benefit greatly if we can have options to enable this level of observability with some configuration option for given API/resource. > Thanks > shammi > > On Fri, Aug 7, 2020 at 7:40 PM Arshardh Ifthikar <arsha...@wso2.com> > wrote: > >> Hi Shammi, >> >> Yes, if one's intention is only to acquire backend latency kind of >> information, using observability is definitely an overkill. >> One way we can achieve this in APIM will be to utilize some properties we >> inject to the message context in certain milestones a request passes. >> These properties are as follows: >> >> *api.ut.backendRequestEndTime* - The timestamp the response triggers the >> first APIM synapse handler (APIMgtLatencyStatsHandler) >> *api.ut.requestTime* - The timestamp the request triggers the first >> APIM synapse handler (APIMgtLatencyStatsHandler) >> >> This is a sample sequence file we have used before to obtain these stats. >> This can be deployed as an out sequence for the relevant api. >> If these stats are required for all apis, a global handler can be >> deployed with this logic, but also adding some api identifier information >> to the log as well. >> >> <sequence xmlns="http://ws.apache.org/ns/synapse"; name="out"> <property >> name="CURRENT_TIME" expression="get-property('SYSTEM_TIME')"/> >> <property name="BACKEND_TIME_PROP" >> expression="evaluate($ctx:api.ut.backendRequestEndTime) - >> evaluate($ctx:api.ut.backendRequestTime)"/> >> <property name="RESPONSE_TIME_PROP" expression="evaluate($ctx:CURRENT_TIME) >> - evaluate($ctx:api.ut.requestTime)"/> >> <log level="custom"> >> <property name="BACKEND_TIME" expression="$ctx:BACKEND_TIME_PROP"/> >> <property name="RESPONSE_TIME" expression="$ctx:RESPONSE_TIME_PROP"/> >> <property name="SERVICE_TIME" >> expression="evaluate($ctx:RESPONSE_TIME_PROP) - >> evaluate($ctx:BACKEND_TIME_PROP)"/> >> </log> >> </sequence> >> >> >> In here: >> BACKEND_TIME : Time taken by the backend >> RESPONSE_TIME : Total roundtrip time within our gateway >> SERVICE_TIME : Time taken by our handlers >> >> Of course this does not give the exact time a backend took on the dot, >> but it gives a clear picture of the latency consumed by our handlers and >> the backend. >> >> Hope this helps >> >> Thanks, >> Arshardh >> -- >> *Arshardh Ifthikar* >> Senior Software Engineer | WSO2 Inc. >> >> Email: arsha...@wso2.com >> Mobile: +94777218551 >> Web: http://wso2.com >> >> <http://wso2.com/signature> >> > > > -- > Best Regards, > > * Shammi Jayasinghe* > > > *Associate Director/ Architect* > *WSO2, Inc.* > *+1-812-391-7730* > *+1-812-327-3505* > > *http://shammijayasinghe.blogspot.com > <http://shammijayasinghe.blogspot.com>* > > Thank You. Ranga. -- Ranga Siriwardena Senior Lead Technology Specialist WSO2 Inc.
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
