Download the PHP package akondas/symfony-actuator-bundle without Composer
On this page you can find all versions of the php package akondas/symfony-actuator-bundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download akondas/symfony-actuator-bundle
More information about akondas/symfony-actuator-bundle
Files in akondas/symfony-actuator-bundle
Package symfony-actuator-bundle
Short Description Production-ready features for your Symfony application
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package symfony-actuator-bundle
SymfonyActuatorBundle
Production-ready features for your Symfony application. Actuator endpoints let you monitor and interact with your application
Features
- REST API endpoints (
/api/actuator) - UI console (not implemented)
Endpoints
-
/health (
componentsin progress) - /info
Install
Add ActuatorBundle to config/bundles.php
Add actuator.yaml to config/routes directory (you can change prefix):
Security
⚠️Be aware that this bundle provides information and functionalities that may be potentially dangerous for your application.
Use the built-in symfony/security component to secure api.
Example configuration (security.yaml) for Basic Authentication:
Extending
Health indicator
You can write your own health indicator and implement your own logic to determine the state of your application. To do so, you have to implement the interface HealthIndicator and tag your service with the tag akondas.health_indicator.
So for example, add following class under src/Health/CustomHealthIndicator.php:
Then add following definition to config/services.yaml:
Information Collector
Similar to a health indicator, you can write also a service which exposes informations. To do so, you have to implement the interface Collector and add the tag akondas.info_collector.
Then add following definition to config/services.yaml:
Configuration reference
The bundle works out of the box with no configuration. If you want to change the default configuration, create a configuration file under config/packages/actuator.yaml. The default configuration is as follows:
Following table outlines the configuration:
| key | default | description |
|---|---|---|
| actuator.health.enabled | true | if the health endpoint should be enabled |
| actuator.health.disk_space.enabled | true | if the builtin disk_space health endpoint should be enabled |
| actuator.health.disk_space.threshold | 52428800 | Size in bytes which has to be free in order that this health endpoint is "UP" |
| actuator.health.disk_space.path | '%kernel.project_dir%' | The directory which should be monitored |
| actuator.health.database.enabled | true | if the database health endpoint should be enabled |
| actuator.health.database.connections | Array | Contains a list of names, where each represents an connection to e database. The name itself can be chosen at will |
actuator.health.database.connections.name.enabled |
true | If the connection associated with this name should monitored |
actuator.health.database.connections.name.service |
'Doctrine\DBAL\Connection' | The service name inside the dependency injection container. You can lookup your connection name with bin/console debug:container |
actuator.health.database.connections.name.check_sql |
'Select 1' | The SQL which will be executed to determine if the database is up. The response will be ignored, it only matters if the sql can be executed without error. If you set this to ~ it will only check if a connection to the database can be established |
| actuator.info.enabled | true | if the info endpoint should be enabled |
| actuator.info.builtin.php.enabled | true | if the php info endpoint should be enabled |
| actuator.info.builtin.symfony.enabled | true | if the symfony info endpoint should be enabled |
| actuator.info.builtin.git.enabled | true | if the git info endpoint should be enabled |
| actuator.info.builtin.database.enabled | true | if the database info endpoint should be enabled |
| actuator.info.builtin.database.connections | Array | List of connections which for which the info endpoint should return the database informations. The list contains of a key which can be choosen at your own will. The second argument is the service in the DIC. You can lookup your service with bin/console debug:container |
Roadmap
- flex recipe
- status for components (database, mailer, notifier, etc.)
- endpoints for components:
- messenger: show failed message, retry by message class (most wanted feature!)
- mailer: send email,
- cache: clear cache maybe?
- notifier: trigger test notification
- UI: same as rest api but presented in the beauty of the admin panel. In particular, I care about the messenger component, because at the moment retrying erroneous messages is very clunky
License
SymfonyActuatorBundle is released under the MIT Licence. See the bundled LICENSE file for details.
