cms-health-project / 健康检查-rfc
CMS健康检查RFC
Requires
- php: ^8.1
Requires (Dev)
- friendsofphp/php-cs-fixer: ^3.51
README
简介
此软件包提供了一系列接口和枚举类型,用于定义构建最终JSON结构所需的信息。它不提供具体的实现。
用法
要使用此定义,请将其添加到您的项目中
composer require "cms-health-project/health-check-rfc"
项目定义和目标
在应用托管领域,网站和电子商务商店的运行时间监控一直是传统的保护方法。虽然这种方法确实有效且简单,但现代应用日益复杂的特性使得这种方法在专业环境中显得不足。
为了解决现代应用操作中的这一缺陷,我们的关注点从仅仅运行时间监控扩展到了在线应用的真正关键方面,如更新、用户管理、商店订单以及其他关键健康指标。应用某些部分的功能缺陷往往在标准的监控实践中不易被发现。
该项目旨在收集、分析和提供有关网站健康状况的额外数据,以便各自的运营商更好地理解其健康状况。网站运营商或托管公司通常需要保持总体情况,但缺乏跨众多CMS平台的标准健康检查格式,这使得解决这个问题变得非常困难。
基于这一想法,在2024年CloudFest黑客马拉松中创建了一个初步的概念验证,目标是共同开发一个适用于如Drupal、TYPO3、Joomla!、WordPress和框架的开源系统的健康检查格式。初始阶段包括对CMS健康检查标准格式的构思和开发,该格式适应不同开源系统的独特需求,并具有灵活性和可扩展性。此外,我们还在努力实现参与CMS系统的第一个基本实现,可以以安全和隐私友好的方式报告基本健康数据。
格式
该接口基于HTTP通信,并以JSON格式返回响应。该格式基于IETF草案“HTTP API的健康检查响应格式”(https://datatracker.ietf.org/doc/html/draft-inadarei-api-health-check-06)。以下是一个示例和解释
{ "status": "pass", "version": "1", "serviceId": "example.org", "description": "Health of WordPress website example.org", "checks": { "WordPress:Version": [ { "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d1", "componentType": "system", "observedValue": "6.4.3", "status": "info", "time": "2018-01-17T03:36:48Z", "output": "" } ], "WordPress:DirectorySize": [ { "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d1", "componentType": "system", "observedValue": "25", "observedUnit": "GB", "status": "warn", "time": "2018-01-17T03:36:48Z", "output": "Directory size of installation exceeds defined threshold" } ], "WordPress:FailedLogins": [ { "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d1", "componentType": "system", "observedValue": "20", "status": "warn", "time": "2018-01-17T03:36:48Z", "output": "Number of failed login attempts in the last 24 hours exceeded defined threshold" } ], "WordPress:OutdatedPlugins": [ { "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d1", "componentType": "system", "observedValue": "5", "status": "fail", "time": "2018-01-17T03:36:48Z", "output": "Some plugins are outdated and need to be updated" } ], "WordPress:UserMfaActivated": [ { "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d1", "componentType": "system", "observedValue": "username1", "status": "pass", "time": "2018-01-17T03:36:48Z", "output": "" }, { "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d1", "componentType": "system", "observedValue": "username2", "status": "warn", "time": "2018-01-17T03:36:48Z", "output": "User username2 has not activated MFA" } ], "WordPress:LastUserLoginTime": [ { "componentId": "identifier7", "componentType": "system", "observedValue": "2018-01-17T03:36:48Z", "observedUnit": "time", "status": "info", "time": "2018-01-17T03:36:48Z", "output": "" } ], "Yoast:Check1": [ { "componentId": "identifier6", "componentType": "component", "status": "pass", "time": "2018-01-17T03:36:48Z", "output": "" } ], "SecurityPlugin:FilePermissions": [ { "componentId": "identifier6", "componentType": "component", "status": "fail", "time": "2018-01-17T03:36:48Z", "output": "File permissions are not correctly set" } ] } }
字段解释
状态
(必需)所有检查的整体状态。其值为“通过”、“失败”或“警告”。
状态应设置为
- “通过”,如果CMS完全正常运行并且所有检查都通过;
- “失败”,如果CMS无法工作或一个或多个检查失败;
- “警告”,如果CMS存在管理员应该注意的问题,但仍然可以运行或一个或多个检查警告但无检查失败。
版本
(可选)健康检查API的公共版本。
服务ID
(可选)服务的唯一标识符,在本例中是响应网站的URL。
描述
(可选)服务的人性化描述。
检查
(必需)包含所有单个检查数据的检查对象。 "检查"包含一个或多个检查结果作为数组。
名称
(必需)检查的名称。其构建形式为"componentName:checkName",其中"componentName"是单个组件或类别的名称,"checkName"是检查本身的名称。
组件ID
(可选)组件的唯一ID。
组件类型
(可选) 如果名称包含 "componentName",则必须存在。只能是 "system" 或 "component" 之一。
观察值
(可选) 检查确定的作为有效 JSON 值的值。
观察单位
(可选) 观察值报告的测量单位。
状态
(必需) 此检查的状态,值为 "通过"、"失败"、"警告" 或 "信息"。
时间
(可选) 是记录观察值读取或检查本身发生的日期时间的 ISO8601 格式。
输出
(可选) 原始错误或警告信息,可能可读。对于 "通过" 状态应省略。也可以包含 "信息" 状态的附加信息。
JSON Schema 定义
提供了一个 JSON Schema 定义 [health-check-schema.json],可用于验证 JSON 值是否符合该模式,例如使用 https://www.jsonschemavalidator.net/。
您可以在以下链接找到验证示例 JSON 的定义的演示: https://www.jsonschemavalidator.net/s/HK5eMqkh
安全
出于提供的信息的安全原因,实现 CMS 健康检查 API 应仅对 HTTPS POST 请求做出响应,并且只有在请求包含安全令牌的情况下。安全令牌应至少由三组(大写字母、小写字母、数字)的 16 个字符组成。CMS 的实现应提供一个函数来撤销安全令牌。
CMS 集成
为了处理 CMS 集成,可以使用不同的客户端插件/扩展/模块。这些定义了与监控服务器通信所需的端点,并根据在客户端组件或 CMS 中实现的检查提供基于应用程序的检查结果。
WordPress
对于 WordPress,"站点健康检查" 已经作为一个核心组件存在。客户端插件的实现旨在采用该实现,并提供了通过 CMS 健康检查 API 交付 WordPress 站点健康检查所有结果的可能性。新的检查可以直接注册为 WordPress 站点健康检查,然后可以自动在 CMS 健康检查 API 中使用。
有关 WordPress 站点健康检查的更多信息,请参阅 https://wordpress.org/documentation/article/site-health-screen/。
TYPO3
TYPO3 使用 reactions API(自 TYPO3 v12 以来可用)来生成健康检查响应。通过在 TYPO3 后端创建相应的反应,管理员可以自由选择应执行并包含在健康检查响应中的各个检查。此外,由于使用了 reactions API,安全令牌已经自动生成,并且可以通过相应的反应记录进行更改或撤销。
第一个实现可以在公共 health-checks 扩展中找到。
贡献
目前,此包仅包含一个基于 php-cs-fixer
的 cgl 检查。
composer install
composer cgl:fix