Extractors sending too much to server.log

We’ve recently added Raw Text extractors for our Firewalls. These generate on average 250 messages per sec. They are working great.

However, I notice that our /var/log/graylog-server/server.log is recording each successful extraction in full, which fills the log file in a minute or so and causes it to rotate. This is not the kind of information I want in server.log, it’s way too much. I would only want to see failed extractions.

Is there any option to exclude these successful extractor messages from server.log?

Thanks in advance

Could you provide some examples?

Hi Jochen,

Most entries in server.log look like this (it’s an entry from our firewall, I have replaced some IPs with X’s)

2018-06-05T10:46:47.740-04:00 INFO [LoggingOutput] Writing message: source: 192.168.XX.X | message: <30>2018:06:05-10:46:55 XXX-rtrXX ulogd[6375]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2. 16" outitf="eth3.10" srcmac="1c:87:2c:5e:9a:9a" dstmac (...) { fw_proto: 6 | fw_name: Packet dropped | gl2_remote_ip: XX.XX.240.5 | gl2 _remote_port: 58672 | fw_srcport: 49353 | fw_outitf: eth3.10 | fw_dstip_geolocation: XX.3394,-XX.895 | fw_fwrule: 60002 | fw_srcmac: 1c: 87:2c:5e:9a:9a | gl2_source_input: 5addddcd2bf9e640243a3ba4 | fw_tcpflags: SYN | fw_sys: SecureNet | fw_dstmac: 90:e2:ba:4f:48:28 | gl2_s ource_node: a002c9da-98ce-4e77-9564-89915b10fd30 | fw_sub: packetfilter | fw_id: 2001 | timestamp: 2018-06-05T14:46:47.737Z | fw_dstip_co untry_code: US | fw_tos: 0x00 | fw_action: drop | fw_severity: info | fw_dstip: XX.XX.54.253 | fw_prec: 0x00 | fw_ttl: 127 | fw_dstip_city _name: San Jose | fw_length: 52 | _id: 460a28b5-68cf-11e8-922f-0cc47a5ec270 | fw_initf: eth2.16 | fw_srcip: 192.168.XX.XX | fw_dstport: 4

In server.log I also see entries coming in from our Windows boxes via GELF:

2018-06-05T10:46:25.792-04:00 INFO  [LoggingOutput] Writing message:  source: XXX-services01.XXXXX.com | message: Special privileges assigned to new logon.        ^M^MSubject:^MSecurity { Task: 12548 | Keywords: -9214364837600034816 | Category: Special Logon | EventType: AUDIT_SUCCESS | gl2_remote_ip: 10.1.XX.XX | gl2_re        mote_port: 55587 | Opcode: Info | gl2_source_input: 5665f0e49008ae049d6a3dcd | SeverityValue: 2 | Version: 0 | SubjectDomainName: XXXXXXX | gl2_source_node:         a002c9da-98ce-4e77-9564-89915b10fd30 | ProcessID: 560 | PrivilegeList: SeSecurityPrivilege^M
     14                         SeBackupPrivilege^M
     15                         SeRestorePrivilege^M
     16                         SeTakeOwnershipPrivilege^M
     17                         SeDebugPrivilege^M
     18                         SeSystemEnvironmentPrivilege^M
     19                         SeLoadDriverPrivilege^M
     20                         SeImpersonatePrivilege | timestamp: 2018-06-05T14:46:32.000Z | OpcodeValue: 0 | SourceModuleType: im_msvistalog | level: 6 | Channel: Se        curity | SourceName: Microsoft-Windows-Security-Auditing | Severity: INFO | SubjectLogonId: 0x49eb7422 | EventReceivedTime: 2018-06-05 10:46:33 | SourceModuleNa        me: in | ProviderGuid: {54849625-5478-4994-A5BA-3E3B0328C30D} | SubjectUserName: XXXXXXXXX | full_message: Special privileges assigned to new logon.^M

Is this normal behavior?

You should probably stop the Logging/STDOUT output. :wink:

Check System/Outputs in the web interface.

Oooooooh :slight_smile:

There was a “test” STDOUT Output in there, I guess we were testing something and completely forgot about it.

Thanks again Jochen, your help is appreciated

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.