enable local log storing on cluster

[saitoh]

Hi all,

GW: R81.20

SMS: R81.20, will be upgraded to R82

The management server upgrade is planned, and I would like to make sure no log lost during upgrade.

The cluster is configured to send its log to management server.

I know a gateway stores its log temporarily in case of no connection to a associated management server, but I would rather configure the gateway to do so just to make sure.

My rough draft of plan is:

1. configure GWs to store its log on themselves

2. upgrade management server.

3. check SIC status.

4. FTP locally stored logs from gateways to management server /var/log/.

5.chmod and chown log files, giving them same permission and owner.

6. cpstop/start to make sure management server recognize log files.

Do you reckon this is achievable?

not sure just putting logs to /var/log/ is enough or not..

Saitoh

[emmap · Accepted solution]

The gateway will store logs locally while the management server is not available, this is something you can rely upon. If you want though you can manually enable it for the duration.

To have locally stored the logs transfer over to the management server, open your gateway properties, expand out Logging, and go to Additional Logging Configuration. At the top of that pane you have Log Forwarding Settings. Enable this to forward logs to your management server at Midnight. This way, at midnight every day, any logs stored on the gateway will be transferred over to the management server and removed off the gateway, saving disk space on the gateway and keeping all your logs in the same place. No need to worry about manually copying files or setting permissions or any of that.

[saitoh]

Hi @emmap ,

Thanks for sharing information.

I was not sure local logging is reliable or not, but your comment made me believe I can rely on it.

I think it is not common sight to stop log forwarding to management server. Our customer wants to do so.

E/U often makes a request that does not make sense. 😞

One thing, is locally stored log sent to management server without any manual operation, after the connection is restored?

[emmap]

Locally stored logs are not automatically sent to the management server unless you configured Log Forwarding on the gateway/cluster object how I described in the earlier post, unless this is a newly setup system running R82.10, when it is enabled by default.

[saitoh]

Hi @emmap ,

I have learnt it, appreciated!

Now I am really curious about:

Does log forwarding automatically resume right after a management server become available?

How often does the cluster tries resuming log forward to management server while local logging?

If log forwarding goes well when local logging working, does the gateway switch log?

I will investigate the points above in my lab. Thanks again!

[emmap]

There's two things at play here, regular logging to the log targets, and the log forwarding configuration.

Regular logging will resume when the management server becomes available again after the upgrade The gateway will regularly retry this connection. From this point, the gateway will send new logs to the management server.

Log Forwarding occurs at the regular time interval that you configure, the default in R82.10 is at midnight every day. This means that any logs that were stored locally while the gateway was unable to talk to the log server will be transferred over at midnight daily. 

[Lesley · Accepted solution]

Hi,

This should not be needed to do before mgmt upgrade. Just make sure before upgrade you check the disk space on the firewall itself. If there is enough space in /var/log you should be OK. 

On the mgmt check the dir where the logs are located, see how much GB logs are created per day. For example if there are 10 logs files , 2 GB each for 1 day you need 20GB free on the firewall itself if your mgmt will be 24 hours down. 

[saitoh]

Hi @Lesley ,

Appreciated to your comment.

The concrete idea of storage space really helps me a lot. Thank you!

[the_rock]

Hey Saitoh,

What Lesley and Emma said is totally logical and actually fact as well.