TServer (7.5) logs persistence

[Gef Buneri]

Hello everyone, hope all fine out there.

I would like to keep logs having age <= 6 months; I have to set "expire" option to "180 day"? or there's a better way or value limitations?


Best regards,


Gef.

[cavagnaro]

Hey Gef
What do you mean?
You drunk? Lol

Jokes aside, the log settings haven't changed much in last years so, you should be quite familiar with them.

What is your need?


Enviado de meu E6633 usando Tapatalk

[Gef Buneri]

Hi Cav never drunk enough
Yes, at the moment the option expire is set to "3 day", I was wondering if there is a limit for the day number and if I can use something like "3 month", instead of 180 days.

My target is to keep tserver logs for 3 months.

[Gef Buneri]

From doc:


expire

Default Value: 10
Valid Values:

    false No expiration; all generated segments are stored.
    <number> file or <number> Sets the maximum number of log files to store. Specify a number from 1-1000.
    <number> day Sets the maximum number of days before log files are deleted. Specify a number from 1-100.

Nor by size:

segment

Default Value: 100 MB
Valid Values:

    false No segmentation is allowed.
    <number> KB or <number> Sets the maximum segment size in kilobytes. The minimum segment size is 100 KB.
    <number> MB Sets the maximum segment size in megabytes. The maximum value is 2047 MB.
    <number> hr Sets the number of hours for the segment to stay open. The minimum number is 1 hour.

Currently TServer generates something like 3,5GB of logs per day, so even a number of 100 2GB (200GB) segments does not covers 180 days (3,5*180=630GB).

[Gef Buneri]

Errata corrige, I can set segments number from 1 to 1000, so maybe I could find a combination to keep 630GB of log files.

[Gef Buneri]

Maybe the best match is to set the expire to 180, and the segment to 24 hours.

[Kubig]

I strongly suggest never use the log segmentation per day - it can cause more problems than benefits. If you want to archive the logs from any reason, use some existing product for that or just sync the files to some storage for further usage.

[Gef Buneri]

Thanks Kubig; any specific reason I could consider?

[Kubig]

In general, you never can predict the T-Server behaviour on logging level as there are many factors which affects amount of log messages written to the log files. So, in scenario traffic peak or unexpected behaviour leading to unexpected logging, T-Server can easily allocates all empty space. Last but not least, searching,working and at least maintenance on folder with thousands of logs will be very tricky.

[cavagnaro]

Agree, there are tools and scripts that search for older files, zip them and move them. That will be the best approach

Enviado de meu E6633 usando Tapatalk

[Gef Buneri]

Yes, as a second choice I could work on a non-genesys files automation, but was trying to do natively.

[cavagnaro]

Not recommended as you would put a enormous file managing task to TServer if possible... That is not a good idea. Let TServer do its job correctly

Enviado de meu E6633 usando Tapatalk

[Gef Buneri]

I see, thanks for the suggestions.

Good things to you all.

[Dionysis]

In our environment we have a requirement for all debug logs to be kept for a minimum of 3 months.

That equates to hundreds of Gb per day in logs so keeping the files on the hosts is just not practical.  So this is how we manage it.

1 - Application logs are set as follows:
- verbose = all
- segment = 100000
- expire = 10

2 - An incrond script runs on the server watching for "closed" files in the log directory.  This script gzips the files and ships them to an AWS S3 bucket.  Then that S3 bucket has retention settings configured to delete any logs older than 3 months.

This means we can keep as many logs as we want and never need to worry about the server filling up.  As mentioned above you NEVER want to keep a number of days worth of logs on the host.  Technically, most Genesys applications "should" be able to run with no space for logs, but in the real world this is rarely the case.  We also keep a small number of logs on the servers themselves so we can troubleshoot real time issues easily if we need to.

[Gef Buneri]

At the end I'm managing them from outside; a daemon does the raw work of renaming files to keep them, and deletes after 180 days.

The process is configured for 100 segments of the size of 4096KB.