How to reduce amount of log output?

[HeikeU]

In an on-premise Xanadu installation I'm trying to reduce the amount of log output.

There are some questions coming up:

1) How to limit sys_trigger log output?

There are lots of entries for sys_trigger in the logs.

For example "Flow Engine Event Handler" runs every 2 seconds.

I tried to avoid the log entries by setting the sys_properties :

"com.snc.trigger_rules.log.level" set it to "warning" , it was "info"

"com.glide.schedules.log.level" set it to "warn", it was "info"

Even after setting those sys_properties and restarting the ServiceNow instance the log file still contains the log lines for the triggers.

2) Is there a documentation of correct value setting for sys_properties?

What are the correct possible values for sys_properties

- com.snc.trigger_rules.log.level (here I do not know which strings are correct, warn or warning ? err or error ? )

- com.glide.schedules.log.level (here I can find the choices in choices field, that's fine)

Is there any table or documentation where I can find that out ?

3) Are there other options to reduce log amount?

If those parameters above are not the ones responsible for the log entries, how can I limit the amount of log output to the relevant data (warnings and errors) ?

4) How to avoid the output of script of scheduled job in logs?

Another thing I found in the logs is that some scheduled jobs write their script to the log, for example "Archive Reference Copy". How can this be avoided ?

Thanks in advance,

Heike

[GlideFather]

Hi @HeikeU,

is there any specific reason why would you like to reduce the number of logs?

If the log entries are out of the box, then you should keep it - you might not need the logs but in case you will need a ServiceNow team assistance they will be checking the logs and it is better to have them than not to have them...

There are some auto-delete jobs, I am not sure if it is deleting every 7 days or 30 days... you can check the sys_log and to see the oldest record when it was created and from that you can see the history of the logs. Maybe some logs can be in your instance longer time than I said, it was just an example.

If you want to reduce the number of custom logs, navigate through your business rules, script includes, scheduled jobs and other server side scripts (you can use SNUtils browser extension and slashcommand /code to filter all the scripts that contains gs.info, gs.log, gs.warn. gs.error, etc...). In the production, there should not be any custom logs but sometimes people forget to remove that.

EDIT: remember that accessing and querying tables such as system logs can take long time, be prepare to use /cancel_my_transaction.do in case it gets stuck...
example of usage:
https://your-instance.service-now.com/cancel_my_transaction.do

[HeikeU]

Hi Kamil TEŘL,

thanks for your reply.

I was just checking why the log size is the same on weekend days when nobody works on the system.

Then I dived into the logs and found lots of information which repeats thousands of time. When you're looking for a real problem in a log, it's harder to find the pain points if there is such a lot of noise of the scheduler and trigger logs.

That's the point where I started to search for an option to lower down the log level and I found the sys_properties I mentioned in my question article. But changing their value did not change the amount of data in log.

Sure, we can manage the amount of logs. But what's the function of those sys_properties ? As I could not find any documentation about them, I decided to ask in this community.

It would be great to have a documentation from ServiceNow on all those sys_properties to understand them.

Best regards,

Heike

[GlideFather · Accepted solution]

Hi again @HeikeU,
any excessive table (logs, emails, cmdb, task, asset, etc) can be accessed without any data, it gives you chance to filter your desired outcomes and then to apply these conditions.

table_name.filter
Example 1 > syslog table, in the filter navigator type "syslog.filter" and press enter, 
Example 2 > cmdb table, in the filter navigator type "cmdb_ci.filter" and press enter, 
In this scenario you have a chance to use the funnel, apply the conditions - Created today, created by Heike, Contains "Magic string" and then apply and search for these.

Regarding the system properties, some of the existing ones will allow you to do GLOBAL changes - for example default time zone in the whole instance. The purpose of system properties is that you create one - for example "kamil.incident.assignment_group.default" and you decide what this property shall contain - true/false, string, etc., in this case a sys id of an assignment group.

Then in your configurations you can write a script that calls this system property and returns the value of it and in case that you would like to change that, you will just change the system property and you do not need to touch the code. Which is good that it does not require technical people to modify codes, it is just replacing sys id with another which can be done by managers or non-technical people who wouldnt know what code to modify and how...

If you want to get an idea about system properties, search between them using key words like email, timezone, favorite, incident, enabled, ....
and it can give you idea what kind of information is stored in system properties.

Let me know if it makes sense to you.

If you changed the system property for the amount of logs, it might take time to take effect due to the fact I mentioned that the data are deleted for example in last 30 days, so if you change this, it might take some time as many of these erasers work over night or early mornings so it is possible that you will not see it directly after saving it.

[GlideFather]

---

@HeikeU wrote:

Hi Kamil TEŘL,

thanks for your reply.

I was just checking why the log size is the same on weekend days when nobody works on the system.

Then I dived into the logs and found lots of information which repeats thousands of time. When you're looking for a real problem in a log, it's harder to find the pain points if there is such a lot of noise of the scheduler and trigger logs.

That's the point where I started to search for an option to lower down the log level and I found the sys_properties I mentioned in my question article. But changing their value did not change the amount of data in log.

Sure, we can manage the amount of logs. But what's the function of those sys_properties ? As I could not find any documentation about them, I decided to ask in this community.

It would be great to have a documentation from ServiceNow on all those sys_properties to understand them.

Best regards,

Heike

---

Try to go through this article:
https://www.servicenow.com/community/developer-articles/system-properties-it-s-usage/ta-p/2300155