Apigee의 MessageLogging 정책을 사용하면 API 프록시 개발자가 커스텀 메시지를 Cloud Logging 또는 syslog 엔드포인트에 로깅할 수 있습니다. 입력 매개변수, 요청 페이로드, 응답 코드, 오류 메시지(있는 경우) 등 API 요청과 관련된 중요한 정보는 추후 참조용으로 또는 디버깅을 위해 로깅할 수 있습니다. 정책은 백그라운드 프로세스를 사용하여 로깅을 수행하지만 정책 사용에 대한 주의사항이 있습니다.
안티패턴
MessageLogging 정책은 API 요청에 대한 자세한 정보를 얻고 API 요청에서 발생하는 문제를 디버깅하는 효율적인 방법을 제공합니다.
그러나 동일한 MessageLogging 정책을 두 번 이상 사용하거나 PostClientFlow 이외의 흐름에서 동일한 API 프록시의 청크에 여러 MessageLogging 정책이 데이터를 로그하면 부정적인 영향을 미칠 수 있습니다. 이는 Apigee가 MessageLogging 정책의 외부 엔드포인트에 대한 연결을 열기 때문입니다.
정책이 syslog 엔드포인트와 마찬가지로 TCP를 통해 TLS를 사용하는 경우 TLS 연결 설정 과정에서 추가 오버헤드가 발생합니다.
API 프록시 예시의 도움을 받아 설명해 봅시다.
API 프록시
다음 예시에서는 'LogRequestInfo'라는 MessageLogging 정책이 요청 흐름에 배치되고 'LogResponseInfo'라는 또 다른 MessageLogging 정책이 응답 흐름에 추가됩니다. 둘 다 ProxyEndpoint PreFlow에 있습니다. LogRequestInfo 정책은 API 프록시가 요청을 받는 즉시 백그라운드에서 실행되며 LogResponseInfo 정책은 프록시가 대상 서버로부터 응답을 받은 후, 그러나 프록시가 API 클라이언트에 응답을 반환하기 전에 실행됩니다. 2개의 TLS 연결이 잠재적으로 설정되므로 이 작업은 추가 시스템 리소스가 소비됩니다.
또한 API 프록시 실행 중에 오류가 발생한 경우에만 실행되는 'LogErrorInfo'라는 MessageLogging 정책이 있습니다.
다음 정책 구성 예시에서는 데이터가 TCP를 통한 TLS를 사용하여 타사 로그 서버에 로깅됩니다. 동일한 API 프록시에서 이러한 정책 중 둘 이상이 사용되는 경우 TLS 연결 설정 및 관리 오버헤드에 추가 시스템 메모리 및 CPU 주기가 적용되어 대규모 성능 문제가 발생할 수 있습니다. MessageLogging을 사용하여 Cloud Logging 엔드포인트에 로깅하는 경우에도 유사한 부정적인 영향이 발생합니다.
[[["이해하기 쉬움","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-09-05(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,["# Antipattern: Invoke the MessageLogging policy multiple times in an API proxy\n\n*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-----------\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\n### API 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\n### Message 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\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\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\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)"]]
