README

A Symfony 5/6/7 bundle that adds an /internal/health and /internal/info endpoint to your application.

The endpoints return JSON responses. The /internal/info endpoint tries to give as much information about the currently installed version of the application as possible. This information is based on the build path of the installation. But also includes the Symfony environment that is currently active and whether the debugger is enabled.

The /internal/health endpoint reports on the health of the application. This information could be used for example by a load balancer. Example output:

{"status":"UP"}

When a health check failed the HTTP Response status code will be 503. And the JSON Response is formatted like this:

{"status":"DOWN", "message":"Lorem ipsum dolor sit"}

❗ Please note that only the first failing health check is reported.

❗ As of version 3.1.0 we started exposing the health and info routes on /internal/. On the next major version we will stop serving the info and health endpoints on /

Installation

Add the package to your Composer file

composer require openconext/monitor-bundle

If you don't use Symfony Flex, you must enable the bundle manually in the application:

// config/bundles.php
// in older Symfony apps, enable the bundle in config/bundles.php
return [
// ...
 OpenConext\MonitorBundle\OpenConextMonitorBundle::class => ['all' => true],
];

Include the routing configuration in config/routes.yaml by adding:

open_conext_monitor:
    resource: "@OpenConextMonitorBundle/src/Controller"
    type: attribute
    prefix: /

Note: this is currently done by the bundle itself, with an external dependency called https://github.com/endroid/installer

Add security exceptions in config/packages/security.yaml (if this is required at all)

security:
    firewalls:
        monitor:
            pattern: ^/internal/(info|health)$
            security: false

The /internal/info and /internal/health endpoints should now be available for everybody. Applying custom access restriction is up to the implementer of this bundle.

Adding Health Checks

The Monitor ships with two health checks. These checks are a

Database connection check based on Doctrine configuration
Session status check

Create the checker

A HealthCheckInterface can be implemented to create your own health check. The example below shows an example of what an implementation of said interface could look like.

use OpenConext\MonitorBundle\HealthCheck\HealthCheckInterface;
use OpenConext\MonitorBundle\HealthCheck\HealthReportInterface;
use OpenConext\MonitorBundle\Value\HealthReport;

class ApiHealthCheck implements HealthCheckInterface
{
    public function __construct(private readonly MyService $service)
    {
    }

    public function check(HealthReportInterface $report): HealthReportInterface
    {
        if (!$this->service->everythingOk()) {
            // Return a HealthReport with a DOWN status when there are indications the application is not functioning as
            // intended. You can provide an optional message that is displayed alongside the DOWN status.
            return HealthReport::buildStatusDown('Not everything is allright.');
        }
        // By default, return the report that was passed along as a parameter to the check method
        return $report;
    }
}

❗ Please note that the check method receives and returns a HealthReport. The Health report is passed along in the chain of registered health checkers. If everything was OK, just return the report that was passed to the method.

Register the checker

By implementing the HealthCheckInterface you can register your own health check. This interface is tagged automatically, so you don't have to do it yourself.

Overriding a default HealthCheck

To run a custom query with the DoctrineConnectionHealthCheck you will need to override it in your own project.

For example in your ACME bundle that is using the monitor bundle:

services.yaml

    # Override the service in `/src/config/services.yaml`
    OpenConext\MonitorBundle\HealthCheck\DoctrineConnectionHealthCheck:
        # Point to your own implementation of the check
        class: Acme\GreatSuccessBundle\HealthCheck\DoctrineConnectionHealthCheck

The rest of the service configuration is up to your own needs. You can inject arguments, factory calls and other service features as need be.

Release strategy

Please read: https://github.com/OpenConext/Stepup-Deploy/wiki/Release-Management for more information on the release strategy used in Stepup projects.

openconext / monitor-bundle

Maintainers

Details