Syslog Message Reference — One Sample per Event Type

This page lists a sample Syslog message for every event type MDSS can emit to an external logger. Use it to build parsers, field extractions and detection rules without having to generate each event first.

MDSS emits 98 distinct event types across 12 categories. Each is listed below with its LogType value, the fields it carries, and a complete sample message.

For how to configure a Syslog destination, see External Loggers — Streaming the MDSS Audit Trail to a SIEM.

1. Message anatomy

Every message is a standard RFC 5424 line with five parts:

What is inside [meta ...]

Two groups of fields, in one element:

1. Message fields — one pair for every placeholder in the message text. These vary by event type and are listed per event below.

2. Envelope fields — present on every event: TenantId, UserName, UserId, EventTimestamp, Category, LogType, Namespace, Id.

Key on names, not position

Field order inside [meta ...] is not part of the contract and may change between releases. Always parse by key name. Likewise, treat message fields as optional — the same event type carries different fields depending on what MDSS knows at the time.

Two conventions to note

All values are quoted strings. RFC 5424 structured data has no types, so fileSize="48213" is a string even though it is a number. Cast in your parser.

String values are quoted in the message text too. The message reads ... fileName: "invoice.docx" ..., with the quotes present. Numeric values appear unquoted. This affects regular expressions written against the message body — prefer the structured data.

A complete example

The most detailed event in the product, with nothing elided — a blocked file, LogType 1:

For readability, the samples in sections 3 to 14 show the message text and the message fields, with the eight envelope fields abbreviated to <envelope>. Substitute the envelope from the example above; only Category, LogType, UserName and UserId change between event types, and those are stated in each entry.

Sample environment

All samples use one consistent fictional deployment:

2. Reading the actor fields

UserName and UserId identify who caused the event.

• For an administrator action, both carry that account's values — UserName="jdavis".

• For anything MDSS does on its own — discovery, scanning, remediation, notification delivery — both carry the literal string system.

This is the fastest way to separate operator activity from automated processing: filter on UserName="system".

3. Category 0 — Scan activities

Category="0". File discovery and scanning, scan process lifecycle, and scan and schedule configuration changes.

LogType 0 — File discovered

A file was found in storage and registered. UserName="system".

Message fields: fileName, filePath, fileHash, fileSize, fileId, lastModified, storageName, storageType, storageId, scanId, scanName, scanType.

Real-time variant. When the scan is real-time, the message gains a discovery mode and a HandlingType field:

LogType 1 — File scanned

The verdict for a file. UserName="system". See the complete example in section 1.

Field composition depends on the outcome:

Allowed file:

Scan failure — emitted at error severity, PRI <107>, with a different message and no verdict fields:

Scanned with identity. When MDSS reuses a previous result instead of rescanning, the text reads was successfully scanned with identity in place of was successfully scanned.

File version variant. On storages that keep versions, the label becomes File version and the fields are fileVersionName, fileId, fileVersionPath, fileVersionHash, fileVersionSize, fileVersionId, createdAt.

LogType 2 — File discovery failed

Discovery could not complete for one file. Emitted at error severity, PRI <107>. UserName="system".

Message fields: ObjectId, objectPath, storage, scan, FailureReason.

File skipped uses this same event type

When a file is skipped rather than failed — excluded by a filter, for example — MDSS emits LogType="2" at warning severity, PRI <108>, with the same message shape and the skip reason in FailureReason. Distinguish the two by severity, not by event type.

LogType 3 — File cancelled

A user cancelled processing for a file. Carries that user's identity, not system.

Message fields: file identity fields.

LogType 100 to 103 — Scan process lifecycle

One event per scan run and storage. UserName="system". The ScanType field holds the lifecycle action, lower-cased.

Substitute ScanType="completed" with LogType="101", ScanType="cancelled" with LogType="102", and ScanType="failed" with LogType="103" and PRI <107>.

Two fields named for the scan type

scanType (lower case s) is the kind of scan — Scheduled Process, Real Time Process or Instant Process. ScanType (upper case S) is the lifecycle action on these four event types. They are different fields.

LogType 1500 to 1503 — Scan configuration changed

An administrator added, updated, deleted or imported a scan.

Message fields: Scan, Type, Action, User. Add and update also carry WorkflowName, UserAgent, WorkflowRule, ScanPoolName, ScanInstances. Add, update and delete also carry the storage fields.

Failure variant — error severity, PRI <107>, fields User, Action, Scan, ResponseMessage:

LogType 1900 to 1904 — Scan schedule changed

Message fields: scanName, scanId, Action, User, storage fields, WorkflowId, WorkflowName.

LogType="1904" uses Action="skipped" and is emitted by the system when a scheduled run is skipped, so UserName="system".

Failure variant — error severity, PRI <107>:

4. Category 1 — Post actions

Category="1". What MDSS did about each file after scanning. All are emitted by the system, so UserName="system".

Every post-action event shares one message shape:

PostAction holds one of: Tagging, Blocked file remediation, Allowed file remediation, Discovered file remediation, Scan file versions.

LogType 200 — File tagged

Message fields: PostAction, file identity, storage, scan.

LogType 205 — Blocked file moved

Move and copy actions add three destination fields: destinationStorageName, destinationStorageType, destinationStorageId, and RelativeObjectName for the path written at the destination.

LogType 206 — Blocked file deleted

No destination fields. Outcome sentence: The blocked file was deleted.

LogType 207 to 215 — Remaining move, copy, delete and keep actions

All share the shape above. The differences are PostAction, LogType, and the outcome sentence.

PostAction does not distinguish sanitised from allowed

Sanitised-file remediations report PostAction="Allowed file remediation". Use LogType to identify the specific action, not the PostAction text.

LogType 216 — File versions scanned

PostAction="Scan file versions", no destination fields, no outcome sentence beyond the base text.

LogType 217 to 220 — Discovered file actions

Applied without scanning, by a discovery-only workflow. PostAction="Discovered file remediation".

Post-action failure

Any post action that fails is emitted at error severity, PRI <107>, with the same LogType and a different message:

LogType 419 — Empty folders deleted

Folder paths are embedded directly in the message text, not as a field.

5. Category 2 — Storage units

Category="2".

LogType 300 to 302 — Storage added, updated, removed

Message fields: storageName, storageType, storageId, Action, User.

Failure variant — error severity, PRI <107>. was becomes could not be:

LogType 400 — Real-time processing changed

Real-time protection enabled, disabled or reconfigured on a storage.

Enabled, with a backfill start date:

Disabled — same shape with Action="disabled" and no RealTimeStartDate.

Handling type changed — a different message and a NewHandlingType field:

Failure variant — error severity, PRI <107>, was becomes could not be.

6. Category 3 — Authentication

Category="3".

LogType 600 — Signed in

Message field: User, the account's full name and user name.

Failed sign-ins are not emitted

MDSS 4.5 emits this event only on a successful sign-in. There is no event for a rejected sign-in attempt, so this feed cannot be used for brute-force detection. Where MDSS runs behind SSO, the identity provider's own logs carry authentication failures.

LogType 601 — Signed out

A sign-out that does not complete cleanly is emitted at warning severity, PRI <108>, with the text "John Davis (jdavis)" encountered an issue while logging out.

7. Category 4 — Settings

Category="4". Configuration changes across the product.

LogType 700 to 703 — Scan engine instance changed

Message fields: ScanInstance (the engine URL), Action.

Failure variant — error severity, PRI <107>, with ResponseMessage:

LogType 750 to 753 — Scan pool changed

Message fields: ScanPool (the pool name), Action. Same actions and failure shape as scan instances.

LogType 800 to 802 — Licence activation

Message fields: Action, User.

Failure variant — error severity, PRI <107>. was becomes failed to be.

LogType 900 — Configuration imported

Message fields: Action, User. The inclusion summary is part of the message text.

Failure variant — error severity, PRI <107>, with FailureReason:

Other failure reasons: the configuration file could not be upgraded, the configuration file is empty, the license could not be activated, the deserialization of the configuration file has failed, the provided configuration file version is not supported, the configuration file has an invalid structure.

LogType 901 — Configuration exported

Identical shape with Action="exported".

LogType 950 — Notification settings changed

Message fields: NotificationType, Action, User.

NotificationType is one of: Email notifications for scan reports, Email notifications scan reports recipients, Blocked file notifications, Blocked file notifications recipients, User request notifications, Webhook Scan completed notifications, Webhook Scan completed notifications details, Webhook File scanned notifications details, RabbitMq file scanned notifications details, Email notifications settings, Webhook notifications settings, RabbitMQ notifications settings.

Action is enabled, disabled or updated. Failure variant — error severity, PRI <107>, were becomes could not be.

LogType 950 appears in two categories

With Category="4" it is a settings change, as above. With Category="8" it is a notification delivery result — see section 9. Filter on both fields together.

LogType 975 — SMTP configuration changed

Message fields: Action (enabled, disabled, updated), User.

Failure variant — error severity, PRI <107>, was becomes could not be.

LogType 1000 — External logger added

The server details are embedded in the message text. Message fields: Action, User.

LogType 1001 — External logger updated

Also used when a destination is enabled or disabled, with Action="enabled" or Action="disabled".

LogType 1002 — External logger deleted

Action="removed".

Failure variants — error severity, PRI <107>. Six distinct messages, all with fields User and Action in present tense (adding, updating, removing, enabling, disabling):

LogType 1100 — Data retention changed

Message field: User. The detail sentence is part of the message text.

Detail sentences, by action:

On failure, severity is error, PRI <107>, and was successfully becomes could not be.

LogType 1200 to 1202 — API key changed

The key value is truncated to its first six characters. Message fields: TruncatedAPIKey, Action, User.

Failure variant — error severity, PRI <107>, with FailureReason:

Other failure reasons: an unexpected error occurred, the requested user was not found, the requested API Key was not found, a key rotation is currently in progress.

API key usage is not audited

These events cover the key's lifecycle only. Requests authenticated with an API key do not produce audit events.

LogType 1300 — SSO configuration changed

Enabled or reconfigured — fields User, SsoType, SsoProvider, Authority:

Disabled — field User only:

Failure variant — error severity, PRI <107>:

LogType 1410 — Workflow scanning modules changed

Message fields: WorkflowId, Technologies.

LogType 1600 — On-demand scan requested

Single file — file identity fields plus UserName:

Filtered rescan of many files — scan fields instead of file fields:

LogType 2000 — Encryption key event

Key generation — fields Action and ActionAndUser:

Completion reads Key generation "was completed". Failure reads Key generation "failed". at error severity, PRI <107>.

Request cancelled during key rotation — field Request:

LogType 2200 — HTTPS certificate changed

Message fields: ActionMessage, User.

Disabling reads HTTPS was "disabled" by "John Davis (jdavis)".

LogType 2300 — Telemetry configuration changed

Message field: Status. Emitted by the system on startup reconciliation, or by an administrator.

8. Category 6 — Users

Category="6".

LogType 602 to 606 — User account changed

Message fields: Username (the account acted on), Action.

Role update:

Removal uses LogType="606" with Action="removed".

Password reset shares LogType 605 with user update

Both are LogType="605". Distinguish them by the message text or the Action field — reset versus updated.

Failure variant — error severity, PRI <107>:

The actor is the account acted on, not the administrator

On these events UserName and UserId identify the user being created, updated or removed. The administrator who performed the action appears in the message text only when MDSS has it, so do not rely on the envelope to identify the operator here.

LogType 1800 — Product tour finalised

Message fields: UserName, TourType.

9. Category 8 — Notifications

Category="8". Delivery results for outbound notifications. All emitted by the system, so UserName="system".

LogType 950 — Email notification sent

Recipients and the notification description are embedded in the message text; there are no message fields.

Notification descriptions, by type:

Partial delivery failure — the message names both sets of recipients:

Total delivery failure — error severity, PRI <107>:

No recipient configured — error severity, PRI <107>:

LogType 950 — Webhook notification sent

Message field: ScanName or FileName.

Failure variants — error severity, PRI <107>: Failed to send webhook notification for scan "Nightly Finance" and Failed to send webhook notification for scanned file "invoice.docx".

LogType 950 — Message-queue notification sent

Message field: FileName.

Failure variant — error severity, PRI <107>: Failed to send RabbitMQ notification for scanned file "invoice.docx".

LogType 1700 — Report generated

Message fields: scan fields.

10. Category 9 — Group units

Category="9".

LogType 320 to 322 — Group added, updated, removed

Message fields: groupName, groupId, Action, User.

Failure variant — error severity, PRI <107>, was becomes could not be.

11. Category 10 — Account units

Category="10".

LogType 330 to 332 — Account added, updated, removed

Message fields: accountName, accountId, Action, User.

Failure variant — error severity, PRI <107>, was becomes could not be.

12. Category 11 — Remediations

Category="11". Changes to remediation rules. Rule execution appears in category 1.

LogType 2101 to 2103 — Remediation rule added, updated, deleted

Message fields: Type, HandlingType, WorkflowId, WorkflowName, Action, UserName.

Type is one of FileTagging, BlockedFileRemediation, AllowedFileRemediation, AllowedSanitizedFileRemediation, BlockedSanitizedFileRemediation, DiscoveredFileRemediation, DeepCdr, DeleteEmptyFoldersRemediation, ScanFileVersions. HandlingType is Move, Copy, Delete, Keep or NotApplicable.

Rule disabled — no HandlingType:

Empty-folder remediation — adds a Depth field:

Failure variant — error severity, PRI <107>:

13. Category 12 — Workflows

Category="12".

LogType 1400 to 1404 — Workflow changed

Message fields: WorkflowId, WorkflowName, Action, UserName, and — except on delete — FileDefinitionMode.

With the configurable blocking strategy, FileDefinitionMode="Configurable" and the message lists the individual blocking options.

Failure variant — error severity, PRI <107>, with ErrorMessage:

14. Category 13 — Access control

Category="13". Role and permission assignment. Message field: User. The description is part of the message text.

LogType 2400 to 2412

Failure variants are emitted at error severity, PRI <107>.

The affected user is not a field

These events name the administrator who made the change, not the user whose access changed. The target user is not carried on the event.

15. Reserved event types

The schema defines 112 event types. The 14 below are reserved and are not emitted by MDSS 4.5. Do not build rules that depend on them.

Category 7 (security checklist) is reserved for the same reason, and category 5 is not defined.

Parsers should handle unrecognised LogType and Category values without failing — new values may be added in later releases.

16. Quick index