When an event is triggered, it should always generate a log record. This log should be separate from watchdog or any
other logging system since it will have different requirements placed on it for how long data should be stored and what
values are saved.
Monitor Logs will be stored in a custom log that tracks the following fields:
|
Field |
Description |
Type |
Required |
|
log_id |
Drupal internal ID |
int |
Yes (autoassigned) |
|
event_id |
The ID of the logged event that triggered this log. If left as NULL, then generate an ID value. |
int |
Yes (autoassigned/manual) |
|
title |
The short blurb title of the issue |
textfield |
Yes |
|
description |
The longtext copy of the issue (plaintext) |
textarea |
No |
|
code |
The RFC log level code value. (0-7 where 0 is “system is unusable” |
textfield |
No |
|
state |
The initial status of this log (OK, Warning, Error, Pending, or Resolved) |
select list |
Yes |
|
monitor_task_name |
The task that triggered this log |
textfield |
Yes |
|
monitor_type |
The type of task that triggered this log |
textfield |
Yes |
|
created |
When the log was created |
int |
Yes |
The above fields should be stored directly against the entity and not through Field API in order to restrict all of the
monitor logs into a single table.
Checklist items
- ✓ Create custom Monitor Log structure
- ✓ Create administration page for Monitor Logs
- ✗ Create PHP Unit tests for Monitor Logs
- ✗ Create functional tests for Monitor Logs
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | system_monitor--add_logging_structure--3074962--12.patch | 12.22 KB | merauluka |
Comments
Comment #2
merauluka commentedComment #3
merauluka commentedThe more I've reviewed this, the more I believe that this should be restructured to use the Logger Channel structure that is currently in Drupal core. This provides a standardized way to look at the log data that is coming from System Monitor and should make sharing it with external systems easier via RFC logging structure.
Updating ticket description to match this new direction.
Comment #4
merauluka commentedComment #5
merauluka commentedComment #6
merauluka commentedHere is my first go at the logging structure. It's just the framework for now. I'm sure we'll find bugs in it as we add in actual system monitors. But this should give us a good baseline.
Gitlab diff link
https://git.drupalcode.org/project/system_monitor/compare/8.x-1.x...task...
Patch is also attached for testing.
TODO:
Make tests for this new framework structure. I will probably split that into a separate ticket to prevent holding up this ticket since we are still in the early phase of development.
Comment #7
merauluka commentedAdded links in ticket description to child issue that is tracking testing for the Logging system.
Comment #8
merauluka commentedUpdate to resolve issue with function that was moved.
Gitlab link:
https://git.drupalcode.org/project/system_monitor/compare/8.x-1.x...task...
Comment #9
merauluka commentedActually attaching the patch to kick off tests.
Comment #11
merauluka commentedTrying again.
Comment #13
merauluka commentedUpdated the logger service so it's no longer included in the system-wide log system by the "logger" tag. This is desirable since we only want to log what we want to log, rather than everything under the sun.
Comment #15
merauluka commentedWith a passing test, and since this module is still under early development, I've merged this issue's work and will move to the test coverage.