Solved! Go to Solution.
There are primarily 2 different kinds of “Health”/”Heartbeat” checks that be used to assess the health of your Apigee resources:
The first kind of “Health Check” listed above would likely be a frequently used API call, or set of calls, to resources that your Client Apps)/Users normally make. Calls can be made manually in one-off as needed fashion (a typical test-driven development practice), scripted and automated, or using any of a multitude of testing tools available. In any of these scenarios, the key operations would be to make a given call, process its response, matching on the response HTTP code (where 2xx usually denotes success, 4xx failure, etc.), and evaluate other conditional content of the response. Please note that this very much dependent on your specific API Proxy, and its respective requests and responses.
If the intent of your “Health Check” mechanism is to determine if your Apigee configuration/resources are up and running as expected, a way to do this is to develop an bare-bones API Proxy that simply returns a 200 in the case of success. The proxy code would look something like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows/> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <HTTPProxyConnection> <BasePath>/health_check</BasePath> <VirtualHost>default</VirtualHost> </HTTPProxyConnection> <RouteRule name="noroute"/> </ProxyEndpoint>
Please note that there is no target in this proxy.
If you would like something a little more interactive, you can slightly adjust this proxy to return whatever request data you send:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows> <Flow name="/"> <Description/> <Request/> <Response/> <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "POST")</Condition> </Flow> </Flows> <PostFlow name="PostFlow"> <Request/> <Response> <Step> <FaultRules/> <Name>Assign-Message-1</Name> </Step> </Response> </PostFlow> <HTTPProxyConnection> <BasePath>/health_check_echo</BasePath> <VirtualHost>default</VirtualHost> </HTTPProxyConnection> <RouteRule name="noroute"/> </ProxyEndpoint>
Where the Assign Message policy is:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AssignMessage async="false" continueOnError="false" enabled="true" name="Assign-Message-1"> <DisplayName>Assign Message 1</DisplayName> <FaultRules/> <Properties/> <Copy source="request"> <Payload>true</Payload> </Copy> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="response"/> </AssignMessage>
There are also health checks that you can perform by actively polling the backend service URLs defined in the TargetServer configurations. For more, see:
http://apigee.com/docs/api-services/content/load-balancing-across-backend-servers#healthmonitoring
Stephen
There are primarily 2 different kinds of “Health”/”Heartbeat” checks that be used to assess the health of your Apigee resources:
The first kind of “Health Check” listed above would likely be a frequently used API call, or set of calls, to resources that your Client Apps)/Users normally make. Calls can be made manually in one-off as needed fashion (a typical test-driven development practice), scripted and automated, or using any of a multitude of testing tools available. In any of these scenarios, the key operations would be to make a given call, process its response, matching on the response HTTP code (where 2xx usually denotes success, 4xx failure, etc.), and evaluate other conditional content of the response. Please note that this very much dependent on your specific API Proxy, and its respective requests and responses.
If the intent of your “Health Check” mechanism is to determine if your Apigee configuration/resources are up and running as expected, a way to do this is to develop an bare-bones API Proxy that simply returns a 200 in the case of success. The proxy code would look something like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows/> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <HTTPProxyConnection> <BasePath>/health_check</BasePath> <VirtualHost>default</VirtualHost> </HTTPProxyConnection> <RouteRule name="noroute"/> </ProxyEndpoint>
Please note that there is no target in this proxy.
If you would like something a little more interactive, you can slightly adjust this proxy to return whatever request data you send:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows> <Flow name="/"> <Description/> <Request/> <Response/> <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "POST")</Condition> </Flow> </Flows> <PostFlow name="PostFlow"> <Request/> <Response> <Step> <FaultRules/> <Name>Assign-Message-1</Name> </Step> </Response> </PostFlow> <HTTPProxyConnection> <BasePath>/health_check_echo</BasePath> <VirtualHost>default</VirtualHost> </HTTPProxyConnection> <RouteRule name="noroute"/> </ProxyEndpoint>
Where the Assign Message policy is:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AssignMessage async="false" continueOnError="false" enabled="true" name="Assign-Message-1"> <DisplayName>Assign Message 1</DisplayName> <FaultRules/> <Properties/> <Copy source="request"> <Payload>true</Payload> </Copy> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="response"/> </AssignMessage>
Are you saying that client can monitor the same apiproxy that serves the production traffic or this monitor will be on a different apiproxy altogether with the same BE ?
There are also health checks that you can perform by actively polling the backend service URLs defined in the TargetServer configurations. For more, see:
http://apigee.com/docs/api-services/content/load-balancing-across-backend-servers#healthmonitoring
Stephen