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. 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>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
