jmonitor/jmonitor-bundle

Integration of jmonitor monitoring library in symfony.

Installs: 201

Dependents: 0

Suggesters: 0

Security: 0

Stars: 0

Watchers: 0

Forks: 0

Open Issues: 0

Type:symfony-bundle

pkg:composer/jmonitor/jmonitor-bundle

v1.0.0 2025-08-22 14:36 UTC

This package is auto-updated.

Last update: 2026-01-27 21:44:00 UTC


README

Integration of the jmonitor/collector library into Symfony to collect metrics from your stack (Php, MySQL, Apache / Nginx / Caddy / FrankenPHP, Redis...) and send them to Jmonitor.io.

Requirements

  • PHP 8.1+ for this bundle. (The standalone collector library supports PHP 7.4.)
  • Symfony 6.4+.

Quick Start

  1. Install the bundle:
composer require jmonitor/jmonitor-bundle
  1. Create a project on https://jmonitor.io and copy your Project API key.
  2. Configure your API key and collectors.
# .env
JMONITOR_API_KEY=your_api_key
# config/packages/jmonitor.yaml
jmonitor:
    project_api_key: '%env(JMONITOR_API_KEY)%'

when@prod:
    jmonitor:
        # Optional: use a specific logger service (Symfony's default is "logger").
        # See "Debugging" section below for more informations.
        # logger: 'logger'
    
        # Optional: provide a custom HTTP client service
        # http_client: 'http_client'
        
        # Enable the collectors you want to use (remove the unused ones).
        # Refer to the collector library for deeper collector-specific doc: https://github.com/jmonitor/collector
        collectors:
            
            # Cpu, Ram, Disk of the server. Linux only.
            system: ~
            # You can use a RandomAdapter on Windows for testing purpose.
            # system:
            #     adapter: 'Jmonitor\\Collector\\System\\Adapter\\RandomAdapter'
            
            # Apache via mod_status module.
            # for more information, see https://github.com/jmonitor/collector?tab=readme-ov-file#apache
            apache:
                server_status_url: 'http://localhost/server-status'

            # Nginx via stub_status module.
            # for more information, see https://github.com/jmonitor/collector?tab=readme-ov-file#nginx
            nginx:
                endpoint: 'http://localhost/nginx_status'
            
            # MySQL variables and status
            mysql:
                db_name: 'your_db_name'
                
            # PHP : some ini keys, apcu, opcache, loaded extensions... 
            # /!\ See below for more informations about CLI vs Web-context metrics
            # use this to collect web metrics
            php: 
                endpoint: 'http://localhost/php-metrics'
            # of for CLI only
            # php: ~
            
            # symfony: some infos, loaded bundles, flex recipes, schedules...
            # you can disable some components by setting them to false
            # symfony
            #     flex: false
            #     scheduler: true
            #     messenger: true
            # or let the bundle auto-detect
            symfony: ~
            # you can provide the recipes command if the default one does not suit you
            # symfony:
            #     flex:
            #         command: "composer.phar recipes -o" # default is "composer recipes -o"
            
    
            # Redis metrics via INFO command
            redis:
                # you can use either DSN or a service name (adapter). 
                # dsn: '%env(SOME_REDIS_DSN)%'
                # adapter: 'some_redis_service_name'
                
            # Metrics from Caddy / FrankenPHP
            # see https://caddyserver.com/docs/metrics
            caddy:
                endpoint: 'http://localhost:2019/metrics'
  1. Run a collection manually to verify. You may prefer doing this in the production environment, as configuring the bundle in development isn't always possible.
php bin/console jmonitor:collect -vvv --dry-run

PHP metrics: CLI vs Web context

  • PHP settings and extensions can differ significantly between CLI and your web server context.
  • If you want metrics that reflect your web runtime, you must expose a tiny HTTP endpoint that returns PHP metrics from within that web context.

To do that, create a route config file:

# config/routes/jmonitor.yaml
jmonitor_expose_php_metrics:
    path: '/jmonitor/php-metrics'
    controller: Jmonitor\JmonitorBundle\Controller\JmonitorPhpController

# Secured route in production with localhost host restriction
# Refer to symfony docs for more information about security
when@prod:
    jmonitor_expose_php_metrics:
        path: '/jmonitor/php-metrics'
        controller: Jmonitor\JmonitorBundle\Controller\JmonitorPhpController
        host: localhost

Set up a firewall for this route before the main firewall to prevent your app from interfering with it:

# config/packages/security.yaml
security:
    firewalls:
        jmonitor:
            pattern: ^/jmonitor/php-metrics$
            security: false
            # instead of disabling security, you can use a stateless firewall if you plan to use ip security or something
            # stateless: true
        main:
        # ...

Wire it in your bundle config

# config/packages/jmonitor.yaml
jmonitor:
    # ...
    collectors:
        php:
            endpoint: 'http://localhost/jmonitor/php-metrics'

Running the collector

php bin/console jmonitor:collect -vvv

This command runs as a long-lived worker: it periodically collects metrics from the enabled collectors and sends them to Jmonitor.io.

You can also limit how long it runs:

  • --memory-limit: stop when the process memory usage exceeds the given limit (e.g. 128M)

  • --time-limit: stop after the given number of seconds

    php bin/console jmonitor:collect --memory-limit=32M --time-limit=3600

In production, it is recommended to run this command under a process manager (e.g. Supervisor or systemd) to ensure it is kept running and restarted if necessary. For practical guidance, you can follow Symfony Messenger's recommendations: https://symfony.com/doc/current/messenger.html#deploying-to-production

Logging and Debugging

  • The command is resilient: individual collector failures do not crash the whole run; errors are logged (logging must be enabled in config).
  • Log levels:
    • Errors (collector exceptions, HTTP responses with status >= 400): error
    • Collected metrics: debug
    • Summary: info

Useful commands:

# Verbose with debug logs
php bin/console jmonitor:collect -vvv

# Dry-run (collect but do not send)
php bin/console jmonitor:collect -vvv --dry-run

# Only summary
php bin/console jmonitor:collect -vv

Troubleshooting

Apache

mod_status is enabled, but my endpoint is not reachable.

Don't forget to let the request pass through your index.php.
For example, if you use .htaccess :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !=/server-status    <---- add this
RewriteRule ^ %{ENV:BASE}/index.php [L]

Need help?