Now that logging is framed up and basically done, there is a need to create a structure to allow the status page to function and pull historical log data and the current status of any active incidents in the system.

@shrop recommended that we use key value storage for this which seems like a solid way to go to me.

This ticket covers the creation of that storage logic for the status page and any logic the status page needs, such as:

  • Permissions checks
  • Historical outages based on log data
  • Status of all monitors and their tasks
CommentFileSizeAuthor
#10 system_monitor--3087448--status-page-logic--10.patch48.7 KBmerauluka
#7 system_monitor--3087448--status-page-component-logic--7.patch45.15 KBmerauluka
#6 system_monitor--3087448--status-page-component-logic--6.patch45.73 KBmerauluka

Comments

merauluka created an issue. See original summary.

merauluka’s picture

merauluka commented

Started this work against the branch already prepared in #3087826: Implement logic to run monitors and tasks.

GitLab Diff
https://git.drupalcode.org/project/system_monitor/compare/8.x-1.x...task...

merauluka’s picture

merauluka commented
Assigned: Unassigned » merauluka

I'll go ahead and take this ticket since it looks like I have a good start on it.

merauluka’s picture

merauluka commented

I have started a documentation page to detail the architecture for the Status Page.
https://www.drupal.org/docs/8/modules/system-monitor/status-page/archite...

merauluka’s picture

merauluka commented
Status: Active » Needs review

Here is the first look at the logic. It's pretty basic for now and will have to be updated once we work on #3107132: Review and revamp logging system to make it pluggable.

Basically this adds the initial structure (mostly for testing purposes) for the following status page elements:

  • Historical Timeline - Pulls incident log data from previous days and stored in Drupal state.
  • Monitor "Card" data - Gathers status information for all tasks configured on a monitor. The status of the tasks determines the overall status of the monitor.
  • Issue History List - Gathers logs created in the last 3 days and organizes them based on if an event was resolved or not. Once resolved, an additional issue can be displayed for any new issue that might be reported.

The output present is pretty basic and will likely change once the front end is built for the status page. However, the actual logic to gather and format all of the data from the system logs should now be present.

merauluka’s picture

merauluka commented
StatusFileSize
new system_monitor--3087448--status-page-component-logic--6.patch45.73 KB

Attaching patch to kick off tests.

Gitlab comparison:
https://git.drupalcode.org/project/system_monitor/compare/8.x-1.x...task...

merauluka’s picture

merauluka commented
StatusFileSize
new system_monitor--3087448--status-page-component-logic--7.patch45.15 KB

Updating patch to remove schema change.

robpowell’s picture

robpowell
he/him
Location Boston
commented

Looks great! Few questions/comments:

  1. StatusPageAccessCheck.php $status_page = $request->attributes->get('sm_status_page');

    Do we have to be concerned about XSS? In other words, is this user data and if so, does Drupal clean it?

    1. StatusPageEventSubscriber.php StringTranslationTrait

      MaintenanceModeSubscriber uses TranslationInterface over the trait, should we do the same?

    2. \Drupal::service('page_cache_kill_switch')->trigger();

      MaintenanceModeSubscriber does the same thing but shouldn't this be passed by DI?

robpowell’s picture

robpowell
he/him
Location Boston
commented
Status: Needs review » Needs work
merauluka’s picture

merauluka commented
Status: Needs work » Needs review
StatusFileSize
new system_monitor--3087448--status-page-logic--10.patch48.7 KB

@robpowell I updated this patch with the latest work that was integrated from other issues that were merged this morning.

Specifically, I have updated the logger to call the "top most" logger in the system when building out log records. I'm thinking that we'll need to revisit this once we start adding more loggers, but for now this appears to work correctly.

As to you other comments, I have updated the status page event subscriber with your suggestions.

Regarding the access check, that attribute is coming in through the route object and the status page value is set from the configuration page. I'm pretty sure that it's okay as is.

robpowell’s picture

robpowell
he/him
Location Boston
commented
Status: Needs review » Reviewed & tested by the community

Melissa this looks good.

  • merauluka committed c29de73 on 8.x-1.x 
    Issue #3087448 by merauluka, robpowell: Implement status check logic for...

  • merauluka committed c29de73 on 9.x-1.x 
    Issue #3087448 by merauluka, robpowell: Implement status check logic for...
merauluka’s picture

merauluka commented
Status: Reviewed & tested by the community » Fixed

Merged!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.