oro / health-check-bundle
Oro Health Check Bundle
Requires
- liip/monitor-bundle: 2.*
- oro/platform-enterprise: 6.0.*
- dev-master / 6.1.x-dev
- 6.0.x-dev
- 6.0.1
- 6.0.0
- 6.0.0-rc
- 6.0.0-beta.1
- 5.1.x-dev
- 5.1.4
- 5.1.3
- 5.1.2
- 5.1.1
- 5.1.0
- 5.1.0-rc.2
- 5.1.0-rc.1
- 5.1.0-beta.2
- 5.1.0-beta.1
- 5.1.0-alpha.2
- 5.1.0-alpha.1
- 5.0.x-dev
- 5.0.4
- 5.0.3
- 5.0.2
- 5.0.1
- 5.0.0
- 5.0.0-rc
- 5.0.0-beta.2
- 5.0.0-beta.1
- 5.0.0-alpha.2
- 5.0.0-alpha.1
- 4.2.x-dev
- 4.2.4
- 4.2.3
- 4.2.2
- 4.2.1
- 4.2.0
- 4.2.0-rc
- 4.2.0-beta
- 4.2.0-alpha.3
- 4.2.0-alpha.2
- 4.2.0-alpha.1
- 4.2.0-alpha
- 4.1.x-dev
- 4.1.3
- 4.1.2
- 4.1.1
- 4.1.1-rc
- 4.1.0
- 4.1.0-rc4
- 4.1.0-rc
- 4.1.0-beta
- 4.0.x-dev
- 4.0.0
- 4.0.0-rc
- 4.0.0-beta
- 3.1.x-dev
- 3.1.5
- 3.1.4
- 3.1.3
- 3.1.2
- 3.1.1
- 3.1.0
- 3.1.0-rc
- 3.1.0-beta
- 3.0.x-dev
- 3.0.0
- 2.6.x-dev
- 2.6.7
- 2.6.6
- 2.6.5
- 2.6.4
- 2.6.3
- 2.6.2
- 2.6.1
- 2.6.0
- 2.3.x-dev
- 2.3.3
- 2.3.2
- 2.3.1
- 2.3.0
- dev-6.0-rc
- dev-6.0-beta
- dev-5.1-rc.1
- dev-5.1-rc.2
- dev-5.1-beta.2
- dev-5.1-alpha
- dev-5.1-alpha.2
- dev-5.1-beta.1
- dev-feature/BB-21142-5.0
- dev-5.0-beta.2
- dev-5.0-beta.1
- dev-5.0-alpha.1
- dev-5.0-alpha.2
- dev-4.2-rc
- dev-4.2-beta
- dev-4.2-alpha.3
- dev-4.2-alpha.2
- dev-4.2-alpha
- dev-4.1-rc
- dev-4.1-beta
- dev-4.0-rc
- dev-4.0-beta
This package is auto-updated.
Last update: 2024-11-05 21:53:03 UTC
README
OroHealthCheckBundle implements a set of health checks for applications built on OroPlatform. Based on the Liip Monitor Bundle, it provides a way to perform the checks using the same configuration and environment that the application uses.
Table of Contents
Purpose
With OroHealthCheckBundle, you can learn about the environment and configuration health check results via the web UI, API and CLI. It helps you to ensure that the application environment is configured correctly, the external services integrated with the application are alive and accessible from the application.
It checks the following:
- Database server connection
- Elasticsearch server connection
- FileStorage state
- Mail Transport connection
- RabbitMQ server connection
- Redis server connection
- WebSocket server connection
- Maintenance Mode state
Basic usage
You can use the health check via:
-
CLI. There are 2 available commands
- the
bin/console monitor:list --env=prod
command provides a list of configured checks
$ bin/console monitor:list --env=prod doctrine_dbal Check if Doctrine DBAL is available mail_transport Check if Mail Transport is available rabbitmq_server Check if RabbitMQ is available in case it is configured elasticsearch Check if Elasticsearch is available in case it is configured websocket Check if WebSocket server is available maintenance_mode Check if Maintenance Mode is running and not expired fs_cache_prod Check if "/var/www/var/cache/prod" is writable fs_logs Check if "/var/www/var/logs" is writable fs_var_data Check if "/var/www/var/data" is writable fs_web_media Check if "/var/www/public/media" is writable redis_cache Check if Redis cache is available redis_doctrine_cache Check if Redis doctrine cache is available redis_session_storage Check if Redis session storage is available
- the
bin/console monitor:health --env=prod
command performs health checks
$ bin/console monitor:health --env=prod OK Check if Doctrine DBAL is available OK Check if Mail Transport is available SKIP Check if RabbitMQ is available in case it is configured: RabbitMQ connection is not configured. Check Skipped. OK Check if Elasticsearch is available in case it is configured FAIL Check if WebSocket server is available: Not available FAIL Check if Maintenance Mode is running and not expired: Expired OK Check if "/var/www/var/cache/prod" is writable: The path is a writable directory. OK Check if "/var/www/var/logs" is writable: The path is a writable directory. OK Check if "/var/www/var/data" is writable: The path is a writable directory. OK Check if "/var/www/public/media" is writable: The path is a writable directory. OK Check if Redis cache is available OK Check if Redis doctrine cache is available OK Check if Redis session storage is available
- the
If all health checks were successful, the bin/console monitor:health --env=prod
command returns the 0 code. If at
least one check has failed, the 1 code is returned.
- Web Interface. All configured checks and REST API documentation are available on the page with
/healthcheck
path - HTTP Status endpoint. Pages that send only HTTP status in response
/healthcheck/http_status_checks
can be used to get status after all available checks are executed/healthcheck/http_status_check/<some_check_id>
can be used to get status of a specific check (usebin/console monitor:list --env=prod
to get check identifiers)
- REST API. Docs are available on the page with
/healthcheck
path
Note: For an OroCommerce application, make sure that the %web_backend_prefix%
parameter is used before health check
urls. This parameter has /admin
value by default. For example:
/admin/healthcheck
/admin/healthcheck/http_status_check/<some_check_id>
/admin/healthcheck/http_status_checks
HealthCheck under Maintenance mode
Keep in mind that you will NOT be able to use any http request to your web server if it has the configured maintenance page. In this case, you can use only CLI commands illustrated in the Basic usage section.
When using healthcheck, you typically receive either the 200 or 502 http status codes. However, if you have any of the configurations listed below, you receive the 503 http status code.
For the Apache web server (in the .htaccess
file)
<IfModule mod_rewrite.c>
RewriteEngine On
# Maintenance mode rewrites
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{DOCUMENT_ROOT}/../var/maintenance/maintenance_lock -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
</IfModule>
For the Nginx web server (in the host configuration)
server {
location / {
if (-f /var/www/var/maintenance/maintenance_lock) {
return 503;
}
}
# Error pages
error_page 503 /maintenance.html;
location = /maintenance.html {
root /var/www/;
}
}
Built-in checks
Database server connection
Verifies the connection to the database via the application config.
Elasticsearch server connection
Verifies if Elasticsearch server is accessible and may be connected via the application functionality.
FileStorage state
Verifies if specific directories are accessible for writing:
- cache
- logs
- data
- media
Mail Transport connection
Verifies if the mail transport is configured correctly and is accessible.
RabbitMQ server connection
Verifies the connection to the RabbitMQ server via the application config.
Redis server connection
Verifies the connection to the Redis server via the application config.
WebSocket server connection
Verifies if the service is configured correctly and is running.
Maintenance Mode state
With OroHealthCheckBundle, the maintenance mode undergoes the following changes:
Health checks in the maintenance mode
The bundle configuration keeps the /healthcheck/http_status_checks
path whitelisted as the endpoint for the API calls.
If all health checks were successful, the /healthcheck/http_status_checks
request returns the 200 response code. If at
least one check has failed, the 502 response code is returned. The /healthcheck/http_status_check/<some_check_id>
path
is used for an individual check, with the same response codes.
- The
Oro\Bundle\MaintenanceBundle\Drivers\FileDriver
class is used as maintenance driver.
The following example illustrates the configuration which can be used in config.yml to change the behavior of the maintenance mode:
oro_health_check: maintenance_driver: options: file_path: %kernel.project_dir%/var/maintenance/maintenance_lock
Build your own check
Each health check class must implement the Laminas\Diagnostics\Check\CheckInterface
interface.
<?php namespace Oro\Bundle\HealthCheckBundle\Check; use Laminas\Diagnostics\Check\CheckInterface; use Laminas\Diagnostics\Result\ResultInterface; use Laminas\Diagnostics\Result\Success; use Laminas\Diagnostics\Result\Failure; class CustomCheck implements CheckInterface { #[\Override] public function check(): ResultInterface { $result = <result of some check>; return $result ? new Success() : new Failure(); } #[\Override] public function getLabel(): string { return 'Custom check verifies ...'; } }
This class must be defined as a Symfony service and tagged as liip_monitor.check
in order to be picked up
by the health check runner.
oro_health_check.check.custom: class: Oro\Bundle\HealthCheckBundle\Check\CustomCheck tags: - { name: liip_monitor.check, alias: custom }
Alternatively, if you need to run various checks inside one service, implement the Laminas\Diagnostics\Check\CheckCollectionInterface
interface.
The getChecks()
method of this interface returns an array of checks that need to be executed.
<?php namespace Oro\Bundle\HealthCheckBundle\Check; use Laminas\Diagnostics\Check\CheckCollectionInterface; class CustomCheckCollection implements CheckCollectionInterface { #[\Override] public function getChecks(): array { return [new CustomCheck()]; } }
Then, tag it as a liip_monitor.check_collection
.
oro_health_check.check.custom_collection: class: Oro\Bundle\HealthCheckBundle\Check\CustomCheckCollection tags: - { name: liip_monitor.check_collection, alias: custom_collection }