| 开发者 | klarsmith |
|---|---|
| 更新时间 | 2026年9月10日 16:36 |
| PHP版本: | 8.3 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
admin-ajax.php and the usual
health.php stubs all return 200 while the database is down, the object cache is gone, or
WordPress is serving its "database update required" interstitial. Every probe in common
use calls that pod ready.
Klarsmith Ops Kit gives a containerised WordPress site three things operators actually need:
GET /wp-json/ops/v1/readyz returns 200 only when the database
answers, the schema matches the running core version, the object cache round-trips, and
the uploads directory is writable. Anything else is a 503 with the failing check names.
Liveness is deliberately left alone: a database outage must drain pods, never restart
them.GET /wp-json/ops/v1/metrics serves the text exposition
format from a snapshot that wp ops collect writes to the object cache on a schedule.
Nothing expensive runs on scrape. wp_ops_snapshot_age_seconds tells you when the
collector has stopped. Pod-level series (wp_ops_pod_*) and site-level series
(wp_ops_site_*) are split so replicas do not duplicate site numbers.WP_OPS_LOG_JSON=true, PHP errors and fatals go to
stderr as one JSON object per line, ready for a log pipeline./metrics is disabled until a token is configured, and the
anonymous readiness response names failing checks without leaking detail.
Configuration is by environment variable, which is how containers are configured:
WP_OPS_TOKEN — bearer token for /metrics (Authorization: Bearer or
X-Ops-Token). Unset disables the endpoint.WP_OPS_SITE_NAME — site label on JSON log records (metrics carry no site
label; the scraper's own labels identify the site).WP_OPS_EXPECT_OBJECT_CACHE — fail readiness when no external object cache is active.WP_OPS_REQUIRED_PLUGINS — comma-separated plugin files (dir/plugin.php) that
must be active for readiness.WP_OPS_REST_BYPASS_AUTH — set to false to stop the plugin allowing anonymous
access to its own REST namespace.WP_OPS_LOG_JSON — set to true to emit JSON log lines on stderr.wp ops check (exit 1 on any failing check), wp ops collect
(refresh the snapshot), wp ops metrics (print the exposition locally).
Source, issue tracker and Kubernetes manifests for probes, the collector CronJob and
scraping live at https://github.com/klarsmith/wp-ops-kit.
composer require klarsmith/wp-ops-kit; the Composer package installs as
wp-content/plugins/wp-ops-kit)./wp-json/ops/v1/readyz.wp ops collect on a schedule (a five-minute CronJob is the reference setup).WP_OPS_TOKEN and scrape /wp-json/ops/v1/metrics with that bearer token.ops/v1
namespace through at priority 1 unless WP_OPS_REST_BYPASS_AUTH=false. Add ops to the
security plugin's allowlist as well where it has one.Because it returns 200 while the site is broken. The database-upgrade interstitial, a missing object cache and a read-only uploads volume all serve a 200 front page.
If liveness consulted the database, one database blip would fail liveness on every pod of every site at once and restart-storm the fleet. Readiness drains; liveness restarts. Only readiness should depend on WordPress.
Walking the cron array and summing autoloaded option sizes on every scrape would load a shared database for no benefit. The collector does the work once; scrapes read the result. If the collector dies the snapshot age climbs, which is alertable.
Yes. Route detection uses the REST route query variable with a request-URI fallback, so
/en/wp-json/ops/v1/readyz works the same as /wp-json/ops/v1/readyz.
klarsmith-ops-kit);
Composer/GitHub name unchanged.examples/ for Kubernetes, stock Prometheus,
VictoriaMetrics and a Grafana dashboard./metrics no longer appends its exposition to a response another handler has already
served.publish is always exported
so a drop to zero stays alertable.ops/v1 REST namespace through site-level anonymous-REST
lockdowns (hooked at priority 1, never overriding an earlier decision).
Escape hatch: WP_OPS_REST_BYPASS_AUTH=false.wp ops check|collect|metrics commands.