[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-21 UTC。"],[[["\u003cp\u003eThe MessageLogging policy in Apigee allows API proxy developers to log custom messages to Cloud logging or syslog, but using it multiple times within the same API proxy can lead to performance issues due to the overhead of establishing connections.\u003c/p\u003e\n"],["\u003cp\u003eEmploying multiple MessageLogging policies, especially in flows other than PostClientFlow, can result in increased networking overhead, back pressure on the message processor, and potential loss of log data if failures occur before the policy executes.\u003c/p\u003e\n"],["\u003cp\u003eA best practice is to use a single MessageLogging policy within the PostClientFlow to ensure all data is logged regardless of API success or failure, avoiding the issues associated with multiple connections and non-guaranteed execution.\u003c/p\u003e\n"],["\u003cp\u003eUtilize ExtractVariables or JavaScript policies to aggregate all data needed for logging into context variables, making them readily available to the single MessageLogging policy in the PostClientFlow.\u003c/p\u003e\n"],["\u003cp\u003eConsider using UDP protocol instead of TCP for syslog if message delivery guarantees are not needed and TLS/SSL is not mandatory, as this will reduce overhead.\u003c/p\u003e\n"]]],[],null,["*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/messagelogging-multiple-times) documentation.*\n\nApigee's [MessageLogging policy](/apigee/docs/api-platform/reference/policies/message-logging-policy) lets API Proxy developers log custom messages to\n[Cloud logging](https://cloud.google.com/logging) or syslog endpoints. Any important information related to the API\nrequest such as input parameters, request payload, response code, error messages (if any),\nand so on, can be logged for later reference or for debugging. While the policy uses a\nbackground process to perform the logging, there are caveats to using the policy.\n\nAntipattern\n\nThe [MessageLogging policy](/apigee/docs/api-platform/reference/policies/message-logging-policy) provides an efficient way to get more information about an\nAPI request and debugging any issues that are encountered with the API request.\nHowever, using the same MessageLogging policy more than once or having multiple\nMessageLogging policies log data in chunks in the same API proxy in flows other than the\nPostClientFlow may have adverse implications. This is because Apigee opens a connection\nto an external endpoint for a MessageLogging policy.\nIf the policy uses TLS over TCP, as with syslog endpoints, there is the additional overhead\nof establishing a TLS connection.\n\nLet's explain this with the help of an example API Proxy.\n\nAPI proxy\n\nIn the following example, a MessageLogging policy named \"LogRequestInfo\" is placed in the\nRequest flow, and another MessageLogging policy named \"LogResponseInfo\" is added to the\nResponse flow. Both are in the ProxyEndpoint PreFlow. The LogRequestInfo policy executes\nin the background as soon as the API proxy receives the request, and the LogResponseInfo\npolicy executes *after* the proxy has received a response from the target server\nbut *before* the proxy returns the response to the API client. This will consume\nadditional system resources as two TLS connections are potentially being established.\n\nIn addition, there's a MessageLogging policy named \"LogErrorInfo\" that gets executed only\nif there's an error during API proxy execution. \n\n```text\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n\u003cProxyEndpoint name=\"default\"\u003e\n ...\n\u003cFaultRules\u003e\n \u003cFaultRule name=\"fault-logging\"\u003e\n \u003cStep\u003e\n \u003cName\u003eLogErrorInfo\u003c/Name\u003e\n \u003c/Step\u003e\n \u003c/FaultRule\u003e\n\u003c/FaultRules\u003e\n\u003cPreFlow name=\"PreFlow\"\u003e\n \u003cRequest\u003e\n \u003cStep\u003e\n \u003cName\u003eLogRequestInfo\u003c/Name\u003e\n \u003c/Step\u003e\n \u003c/Request\u003e\n \u003c/PreFlow\u003e\n \u003cPreFlow name=\"PreFlow\"\u003e\n \u003cResponse\u003e\n \u003cStep\u003e\n \u003cName\u003eLogResponseInfo\u003c/Name\u003e\n \u003c/Step\u003e\n \u003c/Response\u003e\n \u003c/PreFlow\u003e\n ...\n\u003c/ProxyEndpoint\u003e\n```\n\nMessage Logging policy\n\nIn the following example policy configurations, the data is being logged to third-party\nlog servers using TLS over TCP. If more than one of these policies is used in the same API proxy,\nthe overhead of establishing and managing TLS connections would occupy additional\nsystem memory and CPU cycles, leading to performance issues at scale. Similar\nnegative effects occur if using MessageLogging to log to Cloud logging endpoints.\n\n**LogRequestInfo policy** \n\n```text\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n\u003cMessageLogging name=\"LogRequestInfo\"\u003e\n \u003cSyslog\u003e\n \u003cMessage\u003e[3f509b58 tag=\"{organization.name}.{apiproxy.name}.{environment.name}\"] Weather request for WOEID {request.queryparam.w}.\u003c/Message\u003e\n \u003cHost\u003elogs-01.loggly.com\u003c/Host\u003e\n \u003cPort\u003e6514\u003c/Port\u003e\n \u003cProtocol\u003eTCP\u003c/Protocol\u003e\n \u003cFormatMessage\u003etrue\u003c/FormatMessage\u003e\n \u003cSSLInfo\u003e\n \u003cEnabled\u003etrue\u003c/Enabled\u003e\n \u003c/SSLInfo\u003e\n \u003c/Syslog\u003e\n \u003clogLevel\u003eINFO\u003c/logLevel\u003e\n\u003c/MessageLogging\u003e\n```\n\n**LogResponseInfo policy** \n\n```text\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n\u003cMessageLogging name=\"LogResponseInfo\"\u003e\n \u003cSyslog\u003e\n \u003cMessage\u003e[3f509b58 tag=\"{organization.name}.{apiproxy.name}.{environment.name}\"] Status: {response.status.code}, Response {response.content}.\u003c/Message\u003e\n \u003cHost\u003elogs-01.loggly.com\u003c/Host\u003e\n \u003cPort\u003e6514\u003c/Port\u003e\n \u003cProtocol\u003eTCP\u003c/Protocol\u003e\n \u003cFormatMessage\u003etrue\u003c/FormatMessage\u003e\n \u003cSSLInfo\u003e\n \u003cEnabled\u003etrue\u003c/Enabled\u003e\n \u003c/SSLInfo\u003e\n \u003c/Syslog\u003e\n \u003clogLevel\u003eINFO\u003c/logLevel\u003e\n\u003c/MessageLogging\u003e\n```\n\n**LogErrorInfo policy** \n\n```text\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n\u003cMessageLogging name=\"LogErrorInfo\"\u003e\n \u003cSyslog\u003e\n \u003cMessage\u003e[3f509b58 tag=\"{organization.name}.{apiproxy.name}.{environment.name}\"] Fault name: {fault.name}.\u003c/Message\u003e\n \u003cHost\u003elogs-01.loggly.com\u003c/Host\u003e\n \u003cPort\u003e6514\u003c/Port\u003e\n \u003cProtocol\u003eTCP\u003c/Protocol\u003e\n \u003cFormatMessage\u003etrue\u003c/FormatMessage\u003e\n \u003cSSLInfo\u003e\n \u003cEnabled\u003etrue\u003c/Enabled\u003e\n \u003c/SSLInfo\u003e\n \u003c/Syslog\u003e\n \u003clogLevel\u003eERROR\u003c/logLevel\u003e\n\u003c/MessageLogging\u003e\n```\n\nImpact\n\n- Increased networking overhead due to establishing connections to the log endpoints multiple times during API Proxy flow.\n- If the syslog server is slow or cannot handle the high volume caused by multiple syslog calls, then it will cause back pressure on the message processor, resulting in slow request processing and potentially high latency or 504 Gateway Timeout errors.\n- If the MessageLogging policy is placed in flows other than PostClient flow, there's a\n possibility that the information may not be logged, as the MessageLogging policy will not\n be executed if any failure occurs before the execution of this policy.\n\n In the previous [ProxyEndpoint example](#proxyendpoint), the information will\n not be logged under the following circumstances:\n - If any of the policies placed ahead of the LogRequestInfo policy in the request flow fails. \n or\n - If the target server fails with any error (HTTP 4XX, 5XX). In this situation, when a successful response isn't returned, the LogResponseInfo policy won't get executed.\n\n In both cases, the LogErrorInfo policy will get executed and log only the error-related\n information.\n\nBest practice\n\n- Within the proxy flow, use one or more instances of the [ExtractVariables policy](/apigee/docs/api-platform/reference/policies/extract-variables-policy) or the [JavaScript policy](/apigee/docs/api-platform/reference/policies/javascript-policy) to set all the flow variables that are to be logged into a context variable; this will make them available for the MessageLogging policy that executes later.\n- Use a single MessageLogging policy to log all the required data in the PostClientFlow, which gets executed unconditionally.\n- If you are using syslog, use the UDP protocol if guaranteed delivery of messages to the syslog server is not required and TLS/SSL is not mandatory.\n\nThe MessageLogging policy was designed to be decoupled from actual API functionality,\nincluding error handling. Therefore, invoking it in the PostClientFlow, which is outside\nof request/response processing, means that it will always log data regardless of whether\nthe API succeeded or not.\n\nHere's an example invoking MessageLogging Policy in PostClientFlow: \n\n```text\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n ...\n\u003cPostClientFlow\u003e\n \u003cRequest/\u003e\n \u003cResponse\u003e\n \u003cStep\u003e\n \u003cName\u003eLogInfo\u003c/Name\u003e\n \u003c/Step\u003e\n \u003c/Response\u003e\n\u003c/PostClientFlow\u003e\n ...\n```\n\nHere's an example of a MessageLogging policy, LogInfo, that logs all the data: \n\n```text\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n\u003cMessageLogging name=\"LogInfo\"\u003e\n \u003cSyslog\u003e\n \u003cMessage\u003e[3f509b58 tag=\"{organization.name}.{apiproxy.name}.{environment.name}\"] Weather request for WOEID {woeid} Status: {weather.response.code}, Response {weather.response}, Fault: {fault.name:None}.\u003c/Message\u003e\n \u003cHost\u003elogs-01.loggly.com\u003c/Host\u003e\n \u003cPort\u003e6514\u003c/Port\u003e\n \u003cProtocol\u003eTCP\u003c/Protocol\u003e\n \u003cFormatMessage\u003etrue\u003c/FormatMessage\u003e\n \u003cSSLInfo\u003e\n \u003cEnabled\u003etrue\u003c/Enabled\u003e\n \u003c/SSLInfo\u003e\n \u003c/Syslog\u003e\n \u003clogLevel\u003eINFO\u003c/logLevel\u003e\n\u003c/MessageLogging\u003e\n```\n\nBecause [response\nvariables](/apigee/docs/api-platform/reference/variables-reference#response) are not available in PostClientFlow following an Error Flow, it's important\nto explicitly set `woeid` and `weather.response*` variables using\nExtractVariables or JavaScript policies.\n\nFurther reading\n\n- [JavaScript policy](/apigee/docs/api-platform/reference/policies/javascript-policy)\n- [ExtractVariables policy](/apigee/docs/api-platform/reference/policies/extract-variables-policy)\n- Having code execute after proxy processing, including when faults occur, with the [PostClientFlow](/apigee/docs/api-platform/fundamentals/what-are-flows#postclientflow)"]]
