Call StackDriver with async flag as true

[edermaxc]

Hi, i'm facing a latency of 300ms in each call to StackDriver.

Even with documentation telling that "async" is Deprecated, i`ve tried to turn it on, and this latency falls to 1ms.

Is there any problem in using this flag?

[#2]

In analytics, you can expect some latency as it operates in async.

[edermaxc]

Thanks for you reply.

This latency in analytics data is the reason for this flag to be Deprecated?

[#4]

No, sync is another property which you can see in all policies and it's deprecated long time ago by Apigee.

[dchiesa1]

Latency in Analytics is not related to the async= attribute on policies.

[dchiesa1]

how are you calling Stackdriver? Can you show some example configuration or provide more details?

[edermaxc]

Hi Dino, there is some example from config and how we are calling StackDriver:

Calling:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ConnectorCallout async="true" continueOnError="true" enabled="true" name="EC-LogResponse">
    <DisplayName>EC-LogResponse</DisplayName>
    <Connector>StackdriverLogging</Connector>
    <Action>log</Action>
    <Input>{   "logName": "logApigeeMigration",
          "metadata": {
                    "resource": {
                      "type": "api",
                      "labels": {
                        "service": "{apiproxy.name}",
                        "version": "{proxy.basepath}",
                        "location": "global"
                      }
                    }
                  },
          "timestamp": "{system.time}",
          "severity": "INFO",
    	  "message":"{messageContent}"
    	  }</Input>
</ConnectorCallout>
<br>

[dknezic]

Some options

1. Use a service callout (and other policies) to send a request to Stackdriver instead of using the Extension, this will be lower latency.

2. Use your extension in post client flow - this is after your API Response has gone back to the consumer already. You may need to request support enable the use of this policy in PostClientFlow

[#9]

even I would suggest the option 2. But option one shouldn't be used. That will have all the impacts of a service callout failure.