Include standard vendor header such as "GitLab" in syslog header when forwarding GitLab logs
Summary
Syslog header doesn't cleanly define the log product source, e.g. it is not clear this a GitLab log versus another generic Unix log.
Proposal
Users follow the given guide below to configure syslog to ship things like the production_json.log and application_json.log to an external SIEM.
https://about.gitlab.com/blog/2014/12/08/ship-log-data-off-site-using-udp/
The log format looks like this:
<13>Jun 26 06:33:46 ubuntu1204-test production.log: Started GET "/root/my-project/import" for 127.0.0.1 at 2014-06-26 06:33:46 -0700
Many SIEMs require a good key in the log header to determine the the type of parser to use to parse this log. production.log or filename.log is too generic for this purpose.
I suggest a standard hard coded string in the header such as:
<13>Jun 26 06:33:46 ubuntu1204-test GitLab production.log: Started GET "/root/my-project/import" for 127.0.0.1 at 2014-06-26 06:33:46 -0700
The format here is PRI Month Day Time HostName GitLab filename:
It is incredibly clear here this is a GitLab log to anyone who parses it, and standardized log parsers can key off of this to select the correct parser to use.
A workaround we have for users is to use rsyslog instead to hard code the tag:
input(type="imfile" File="/path/to/application_json.log"
Tag=" GitLab_Application:"
Severity="info"
Facility="local6")
Which produces:
<13>Feb 21 13:07:48 gitlab-test.example.com GitLab_Application: {"severity":"INFO","time":"2024-02-21T21:07:48.922Z","correlation_id":"01HQ6QXZPDZARVY2F2TJCHNJC1","meta.caller_id":"PipelineProcessWorker","meta.remote_ip":"192.168.1.2","meta.feature_category":"continuous_integration","meta.root_namespace":"devops","meta.client_id":"client/1122","meta.root_caller_id":"POST /api/:version/jobs/request","message":"Enqueuing hooks for Pipeline 772217: running","class":"Ci::Pipeline","pipeline_id":772217,"project_id":2642,"pipeline_status":"running"}
Note: I tried to bold the log header in this issue, if you see literal double asterisks that is not part of the log.