Problem/Motivation

Hello,

I've recently developed a bridge module (ohdear_integration) between monitoring module and ohdear monitoring app. Upon first testing we noticed that current hook requirements sensors where not suitable for Ohdear healthchecks. A more suitable one would be to recap all reports of specific severity.

We could've included it in our ohdear_integration module since monitoring is its dependency but I believe monitoring module is more suitable for it.

Proposed resolution

I've written that sensor.

See PR.

Issue fork monitoring-3307528

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

useernamee created an issue. See original summary.

useernamee’s picture

Assigned: useernamee » Unassigned
Status: Active » Needs review
useernamee’s picture

I've implemented one of the MR comments. Thanks @jjchinquist for review.

fago’s picture

Status: Needs review » Needs work

Code looks pretty good, I only add a minor casing remark.

Not 100% sure about the naming, I probably would have called a summary, but I think "recap" also cuts it.

I also tested it, it generally seems to work fine, but I noted the detailed description contains HTML-encode chars, e.g. as in this example:

> 6 warnings in status report, exceeds 1, Configuration files: Protection disabled, Deprecated modules enabled: Deprecated modules found: <em class="placeholder"><a href="https://www.drupal.org/node/3223395#s-ckeditor">CKEditor 4 (contrib)</a></em>., Drupal core update status: No update data available, Field Group: jQuery UI Accordion not enabled, GD library FreeType support: Not installed, Media

I'd assume that's not displayed / supposed to be HTML, thus it should do html-decoding.

useernamee’s picture

I've added html decoding. Thanks for review and testing, @fago.

useernamee’s picture

Status: Needs work » Needs review
fago’s picture

Status: Needs review » Needs work
useernamee’s picture

@fago Thank you for your comment. I've implemented it.

useernamee’s picture

Status: Needs work » Needs review
fago’s picture

Status: Needs review » Reviewed & tested by the community
fago’s picture

great, works well now and code is all good

fago’s picture

discussed with berdir that it would be good to add the possibility to ignore certain requirements from this checking via plugin configuration. as I understood there is some prior-art of this pre-existing in monitoring.

useernamee’s picture

Status: Reviewed & tested by the community » Needs review

I've implemented plugin selection in configuration form. It requires some not so nice detour for storing plugins so I am setting this issue state as needs review again.

The problem was that some plugin ids have dot in their id and that is invalid character to store in configuration so I've replaced dots with double underscore

  protected function getAllRequirements() {
    $requirements = $this->systemManager->listRequirements();
    $all_requirements = [];
    foreach ($requirements as $id => $requirement) {
      if (strpos($id, '.') !== FALSE) {
        $id = str_replace('.', '__', $id);
      }
      $all_requirements[$id] = is_string($requirement['title']) ? $requirement['title'] : $requirement['title']->__toString();
    }
    return $all_requirements;
  }

and then convert underscore back to dot again:

  public function runSensor(SensorResultInterface $sensor_result) {
    $severity = (int) $this->sensorConfig->getSetting('severity');
    $enabled_requirements = $this->sensorConfig->getSetting('requirements');
    // Configuration keys can't have dots in them and are replaced with `__`.
    array_walk($enabled_requirements, function (&$val) {
      $val = str_replace('.', '__', $val);
    });
    $requirements = array_intersect_key($this->systemManager->listRequirements(), array_flip($enabled_requirements));
    $requirements = array_filter($requirements, function ($requirement) use ($severity) {
      return isset($requirement['severity']) && $requirement['severity'] === $severity;
    });

Does anyone have a better idea/solution?

fago’s picture

Status: Needs review » Needs work

thanks. That underscore-workaround seems reasonable.

While the feature works fine, I don't think it's very practical to store a list of requirements-to-cover in config since it must be maintained and updated for every module with requirements being added. Instead I think we should only configure and store an ignore list, e.g. make the setting
"Requirements to ignore"
so when kept empty it would just use all. Makes sense?

useernamee’s picture

@fago Thanks for your response! I've implemented the code you suggest.

useernamee’s picture

Status: Needs work » Needs review
ciprian.stavovei’s picture

Status: Needs review » Reviewed & tested by the community

Everything looks good now.

useernamee’s picture

I have to add some error checking in the code:

The website encountered an unexpected error. Please try again later.
TypeError: array_walk(): Argument #1 ($array) must be of type array, null given in array_walk() (line 49 of modules/contrib/monitoring/src/Plugin/monitoring/SensorPlugin/RequirementsRecapSensorPlugin.php).

array_walk(NULL, Object) (Line: 49)
Drupal\monitoring\Plugin\monitoring\SensorPlugin\RequirementsRecapSensorPlugin->runSensor(Object) (Line: 175)
Drupal\monitoring\SensorRunner->runSensor(Object) (Line: 135)
Drupal\monitoring\SensorRunner->runSensors() (Line: 117)
Drupal\ohdear_integration\OhdearHealthcheckGenerator->getData() (Line: 79)
useernamee’s picture

Assigned: Unassigned » useernamee
Status: Reviewed & tested by the community » Needs work
useernamee’s picture

Assigned: useernamee » Unassigned
Status: Needs work » Reviewed & tested by the community

Error won't happen again.

Marko Cvetkovic’s picture

I have just tested this successfully!

I've created 2 requirements recap sensors - one for warnings and one for errors.

fago’s picture

I checked the PR and code + approach seems all good now. Also tested ignoring a requirement, works fine.

berdir’s picture

Thanks for working on this, this is interesting.

Didn't do a full code review, but some thoughts and questions:
* initialize_requirements_sensors() has a special case for update module because we have dedicated sensors for that and don't want to duplicate it. should probably be added to ignored sensors by default here?
* Similarly we have a special case for system cron requirements check because that too has a dedicated sensor
* the exclude settings on the existing sensor uses a textfield and a link on the verbose output to quickly add them. this uses options. I'm generally fine with that, but I could imagine a problem with dynamically define keys that are not always there. editing a sensor while that is not defined will lose that exclude.
* requirements checks can be quite slow and because you split be level, if you have error and warning sensors, you'll run them all twice. maybe add a static cache?

useernamee’s picture

@berdir, thank you for code review.
I've implemented caching, improved disabled sensor config and added update and cron to default values (and tested that everything still works).

useernamee’s picture

I've improved caching and "improved" status message output as well.

I've tried to have html in the status messages in monitoring report, but this was simply to hard to achieve, because html is escaped in sensor list. Html still shows up in detailed view.

useernamee’s picture

useernamee’s picture

@berdir would you care to check my implementation of your comments? I'm not sure about the caching part.

useernamee’s picture

Status: Reviewed & tested by the community » Needs review
useernamee’s picture

Hello.
Any chance of getting this ticket reviewed?

fago’s picture

Status: Needs review » Needs work

code changes look all good to me despite that small phpcs warning:

>src/Plugin/monitoring/SensorPlugin/RequirementsRecapSensorPlugin.php ✗ 1 more
>line 196 Description for the @return value is missing

also, we are using this for a while now and works all good. let's fix the phpcs issue, then I think this is ready

useernamee’s picture

Status: Needs work » Needs review

I've fixed this phpcs issue.

petar_basic’s picture

Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

This now seems all good. As mentioned in #31 we are using this for a while now and works all good.

  • Berdir committed 9c3a2252 on 8.x-1.x authored by useernamee
    Issue #3307528 by useernamee: New sensor: Requirements recap
    
berdir’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -monitoring

Sorry for the slight delay :)

Merged.

Status: Fixed » Closed (fixed)

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