Solved: Issue with syslogging

Report Inappropriate Content · 09-11-2015 04:58 PM

Hi,

I have observed, that if the host for syslog server is invalid while deploying proxies, then the proxy is not deployed. Which is fine.

However, during runtime if the syslog server has an interruption and goes down, the proxy also starts erroring out and is undeployed.

Is there a way to avoid this? I dont want my APIs to be interrupted if the logging server goes down.

adas

@jaskaran.rm You are correct about the first behaviour that if the server IP or hostname is invalid it would not let you deploy. For the second case, I am not sure what exactly do you mean by "if the syslog server has an interruption and goes down, the proxy also starts erroring out and is undeployed". That should not happen. If its happening for you, we need to review your proxy bundle.

We have a PostClientFlow, where we encourage people to attach the Message Logging policy because that doesn't come in the path of the regular request-response path of the client. Here's an example:

    <PostClientFlow name="PostClientFlow">
        <Request/>
        <Response>
            <Step>
                <Name>MessageLogging</Name>
            </Step>
        </Response>
    </PostClientFlow>

Try making this change and move your message logging policy to the PostClientFlow and see if that helps. You would not find the PostClientFlow as an option in the UI, so you would have to type it into the xml proxy editor.

View solution in original post

adas

@jaskaran.rm You are correct about the first behaviour that if the server IP or hostname is invalid it would not let you deploy. For the second case, I am not sure what exactly do you mean by "if the syslog server has an interruption and goes down, the proxy also starts erroring out and is undeployed". That should not happen. If its happening for you, we need to review your proxy bundle.

We have a PostClientFlow, where we encourage people to attach the Message Logging policy because that doesn't come in the path of the regular request-response path of the client. Here's an example:

    <PostClientFlow name="PostClientFlow">
        <Request/>
        <Response>
            <Step>
                <Name>MessageLogging</Name>
            </Step>
        </Response>
    </PostClientFlow>

Try making this change and move your message logging policy to the PostClientFlow and see if that helps. You would not find the PostClientFlow as an option in the UI, so you would have to type it into the xml proxy editor.

Report Inappropriate Content

Thanks @arghya das

We are currently logging messages at 5 places. as shown below + error flow.

Would you suggest that we put messages in context and log them all together in postclient flow.

Also, I think if the issue with deployment is related to policy, it might still happen if the policy is included in the postclient flow. Thoughts?

adas

Logging at multiple places is not desirable. I would suggest you collect all of that in context and then log it in the postclientflow. I am still not sure why you see the proxy getting undeployed when your syslogger is down. Does that happen always ?

Report Inappropriate Content

I would need to test it a bit more. Need an operations person from our team to play with this.

Will update you. Thanks

adas

@jaskaran.rm Any luck with this one ? I am really keen to know, why you ran into proxy undeployment issue when your syslog server was down.

Report Inappropriate Content

Hi @arghya das . I had been trying it for a little while, but couldnt replicate it. So, I might have raised a false alarm.

I will update you if I find anything else 🙂

Report Inappropriate Content

HI @arghya das . This happened again.

I had left the proxy deployed after stopping the syslog server for few days. After 3-4 days, it started failing -

{"fault":{"faultstring":"Internal server error APIProxy revision 10 of TestProxy does not exist in environment dev of organization orgName","detail":{"errorcode":"messaging.adaptors.http.ServerError"}}}

Could it be that the message processors were restarted or any other background process that caused it?

Its not a critical issue for me now, since the proxy doesnt go down immediately. If our syslog server does go down, we should be able to fix it pretty quickly.

adas

Yeah looks like the proxy got undeployed from the message processor for some reason. If you see a pattern to it, maybe we can take a look at it. Next time you see something like this, can you capture the message-processor logs.