Guidance on VA Critical Error Disk volume / at 10% free

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

VA: ccg.log grew to 79G — safe to clear?

On our IdentityNow VA, /home/sailpoint/log/ccg.log ballooned to ~79 GB, filling the root disk.

79G/home/sailpoint/log/ccg.log
15G/home/sailpoint/log/fluent.log.0

I don’t see debugging enabled.

Is it supported/safe to truncate? ccg.log

Also, what’s the best way to identify which component is spamming the log so we can stop it from regrowing?”

VA_Critical Error
VA_Critical Error1991×282 16.6 KB

I found this support document on clearing the log. I just was not sure if that would cause any issues.

Any guidance would be greatley appreciated.

2

The ccg.log truncates on a regular bases, unless the debugging for the cluster is turned on.

One way to see what might be overwhelming the logs is to use a command similar to this, which can give you a count of entries per source (substitute source name for each connected source):

cat /home/sailpoint/log/ccg.log | grep -v OOTB | grep -v 'CCG CACHE' | grep <source name> | wc -l

If you want to better analyze the logs for a specific source, try this (replace timestamp with a datetime like 2025-09-21T13:02):

cat /home/sailpoint/log/ccg.log | grep -v OOTB | grep -v 'CCG CACHE' | grep <source name> | grep <timestamp> | jq | grep ==color=always 'message\|timestamp\|Application' | less -R

I like to pipe the output to less -R so that I can easily move up and down, using forward and reverse search. The more specificity you put into the timestamp (i.e., to the hour, to the minute…) you will reduce the number of log entries to review.

Hope that helps.

Matt

3

Hi Matt,

Thanks so much for getting back to me; I really appreciate it. I’ll give your suggestion a try.

Quick question: could this issue be related to a change I made last month?

On August 12, 2025, SailPoint Support asked me to update the logger settings specific to Okta using the following documentation:
:link: Enable Connector Logging

Here’s what I configured:

{

  "clientId": "null",

  "durationMinutes": 60,

  "expiration": "2025-08-12T22:25:29.597356Z",

  "rootLevel": "TRACE",

  "logLevels": {

    "openconnector.connector.okta": "TRACE"

  }

}

I assumed the logging duration was only 60 minutes, but I’m wondering if it might have persisted longer or caused any side effects.

Let me know what you think.

Joe