Bug 1344146

There is no syslogsize option (or any plugin-specific log size control) in sos-3.x.

This was replaced with a global --log-size=SIZE that will affect all plugins that implement log size limiting.

In RHEL6 we had a lot of out of tree patches for gluster as the product was still moving fairly rapidly - the changes adding the syslogsize option were never forward ported to the upstream plugin so those need to be reintroduced.

This will also affect RHEL6 since it now ships sos-3.2.

 === In Red Hat Customer Portal Case 01637872 ===
--- Comment by Ladd, Patrick on 6/9/2016 3:01 PM ---

Customer currently has sosreports coming in at 7GB compressed / 81GB expanded due to gluster log sizes.  I'll attach sample with listing of large files in a private comment to follow for illustration.

Therefore, I'd like to get the log size limits back into the gluster.py plugin.  From the comments that appears to be implementing log size limiting with --log-size. I understand that the technique for limiting has changed so the second bz 1344147 can be closed - it appeared to be a needed follow-on to make 1344146 work.

> paths don't match exactly to standard paths because gluster is running in a 
> container and things have been relocated for persistence

Is this a supported configuration? If so we would be better off adding support for it to our gluster plugin rather than helping the customer with a one-off cutom versoin.

> If you have some guidance on how to add the --log-size support, I can forward 
> to customer for their custom plugin that collects these files.

You can look at the sos-2.2 patch in dist-git (may also be attached in bugzilla somewhere) - that should show roughly which sites in gluster.py to modify and an idea of the change.

In sos 3.2 since log size limits are global the easiest thing is to look at other plugins that implement --log-size, just grep in the plugins directory (option names use '_' instead of '-'):

$ grep log_size sos/plugins/*.py
[...]

E.g. the logs plugin has:

    self.limit = self.get_option("log_size")
    self.add_copy_spec_limit("/var/log/boot.log", sizelimit=self.limit)
    self.add_copy_spec_limit("/var/log/cloud-init*", sizelimit=self.limit)

Although storing the limit in an instance variable isn't necessary unless you want to use it to pass the value among functions or subclasses.

Using globs is fine so long as they do not expand to include directories.

See https://github.com/sosreport/sos/pull/834 .

Contrary to original patch calling:

self.add_copy_spec_limit("/var/log/glusterfs/*.vol.log", limit)

I decided to call acsl method for each individual file. That should collect (tail of) /var/log/glusterfs/1.vol.log when /var/log/glusterfs/0.vol.log is bigger than specified limit - I guess the desire is to have (at least) tail of every log file.

Files with mask "/var/log/glusterfs/*log" and "/var/log/glusterfs/*/*log" are being collected.

Default log_size value is 10MB, FYI.

Please comment if either:
- it is enough to collect 10MB of files /var/log/glusterfs/*.vol.log (and 10MB of /var/log/glusterfs/bricks/*.log) with the risk some such files wont be collected at all
- the masks applied (*log and */*log) is not a good compromise between the original patch (see below) and what is expected to appear under /var/log/glusterfs
- defaut log_size should be overwritten for gluster logs



Original patch:

@@ -121,6 +118,25 @@ class gluster(sos.plugintools.PluginBase):
                 self.collectExtOutput("gluster volume geo-replication %s status" % volname)

         self.collectExtOutput("gluster volume status")
-        # collect this last as some of the other actions create log entries
-        self.addCopySpec("/var/log/glusterfs")
+
+        # all_logs takes precedence over logsize
+        if not self.getOption("all_logs"):
+            limit = self.getOption("logsize")
+        else:
+            limit = 0
+
+        if limit:
+            # collect logs last as some of the other actions create log entries
+            self.addCopySpecLimit("/var/log/glusterfs/cli.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/*.vol.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/gluster-lock.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/glustershd.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/nfs.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/quota-crawl.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/quotad.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/quotad-mount-*.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/status.log", limit)
+            self.addCopySpecLimit("/var/log/glusterfs/bricks/*.log", limit)
+        else:
+            self.addCopySpec("/var/log/glusterfs")

--

> can you have both self.addCopySpec("/var/log/glusterfs") and a bunch of
> self.addCopySpecLimit() for the same logs

No. It is one or the other (since the limits applied by add_copy_spec_limit() are not visible to callers of add_copy_spec() (they are applied at the time of the add call, not during collection).

The correct way to do this is as Pavel illustrated in comment #5. You have two branches: one that executes by default and the other only when "--all-logs" is given at the command line:

if self.get_option("all_logs"):
    self.add_copy_spec("/var/log/mylog*"
else:
    limit = self.get_option("log_size")
    self.add_copy_spec_limit("/var/log/mylog.log", sizelimit=limit)

But there isn't really any point in your working on this from scratch - sos.2.2 builds already have this feature and Pavel submitted a request upstream last 

  https://github.com/sosreport/sos/pull/834

If there are additional changes to make they should be on top of that commit.

(note that the API calls you mention are all specific to sos-2.2 - these are now obsolete and we no longer update those packages in the main RHEL release stream).

Btw. I added to the upstream PR collecting "/var/log/glusterfs/geo-replication/*/*log".

Patrick, let us know if something else (file, limit or so) is worth changing, or if the patch looks good now.

Already in 3.3... (via the global --log-size option, as well as the defaults implemented in the gluster plugin).