Wemonit Bundle Laravel Package

Getting Started

Minimal Setup

1. Install the Bundle Add to composer.json:

   "require": {
       "20steps/wemonit-bundle": "dev-master"
   }
   

   Run:

   composer update 20steps/wemonit-bundle
   

2. Register the Bundle In AppKernel.php:

   $bundles[] = new twentysteps\Bundle\WeMonItBundle\twentystepsWeMonItBundle();
   

3. Configure API Credentials In app/config/parameters.yml:

   parameters:
       twentysteps_wemonit.url: "https://wemonit.de/api/"
       twentysteps_wemonit.api_key: "your_api_key_here"
   

4. Import Services In app/config/config.yml:

   imports:
       - { resource: "@twentystepsWeMonItBundle/Resources/config/services.yml" }
   

5. First Use Case: Fetching a Host Inject the wemonit.client service and call a method:

   use twentysteps\Bundle\WeMonItBundle\Service\WeMonItClient;
   
   class SomeController extends Controller
   {
       public function showHostAction(WeMonItClient $client)
       {
           $host = $client->getHost(123); // Replace 123 with a valid host ID
           return $this->render('host/show.html.twig', ['host' => $host]);
       }
   }
   

Implementation Patterns

Service-Oriented Workflow

1. Dependency Injection Always inject WeMonItClient into controllers/services where WeMonIt interactions are needed:

   public function __construct(WeMonItClient $client) {
       $this->client = $client;
   }
   

2. Caching Responses The bundle provides configurable caching (via twentysteps_wemonit.cache in config.yml) to avoid hitting rate limits. Defaults to 5 minutes:

   twentysteps_wemonit:
       cache: true
       cache_lifetime: 300 # 5 minutes in seconds
   

3. Batch Operations For bulk actions (e.g., fetching multiple hosts), use array-based methods if available (e.g., getHosts([1, 2, 3])). Check the service methods for batch support.

4. Error Handling Wrap API calls in try-catch blocks to handle HTTP/WeMonIt-specific errors:

   try {
       $data = $client->getHost($id);
   } catch (\RuntimeException $e) {
       $this->addFlash('error', 'WeMonIt API error: ' . $e->getMessage());
   }
   

5. Custom KPIs (Future-Proofing) Extend the bundle by creating a custom service that leverages raw WeMonIt data to compute KPIs (e.g., uptime trends). Example:

   class UptimeKpiService {
       public function __construct(WeMonItClient $client) {
           $this->client = $client;
       }
   
       public function getUptimePercentage($hostId, $days = 7) {
           $history = $this->client->getHostHistory($hostId, $days);
           // Custom logic to compute uptime percentage
       }
   }
   

Gotchas and Tips

Pitfalls

1. Rate Limiting

   • The bundle caches responses by default, but ensure cache_lifetime is set appropriately (e.g., shorter for volatile data like alerts).
   • Monitor WeMonIt’s API rate limits (e.g., 60 requests/minute) and adjust caching or batch requests accordingly.

2. API Key Exposure

   • Never commit parameters.yml to version control if it contains sensitive keys. Use environment variables or Symfony’s %kernel.root_dir%/parameters.yml.dist + .env pattern:

     # .env
     WE_MONIT_API_KEY=your_key_here
     

     # parameters.yml
     twentysteps_wemonit.api_key: "%env(WE_MONIT_API_KEY)%"
     

3. Deprecated Methods

   • The README mentions incomplete API coverage. Check the WeMonItClient service methods for available endpoints (e.g., getHost(), getAlerts()). Use Symfony’s debug:container to inspect:

     php bin/console debug:container twentystepsWeMonItBundle
     

4. Caching Quirks

   • If caching is enabled, stale data may appear during development. Clear the cache after changes:

     php bin/console cache:clear
     

   • For testing, disable caching temporarily:

     twentysteps_wemonit:
         cache: false
     

Debugging Tips

1. Enable API Debugging Add a debug endpoint to log raw WeMonIt responses:

   $client->setDebug(true); // If the bundle supports this (check source).
   

   Or inspect HTTP clients (e.g., Guzzle) via middleware.

2. Logging Errors Configure Monolog to log WeMonIt exceptions:

   monolog:
       handlers:
           wemonit:
               type: stream
               path: "%kernel.logs_dir%/wemonit.log"
               level: error
               channels: ["wemonit"]
   

3. Testing

   • Mock the WeMonItClient in PHPUnit:

     $mock = $this->createMock(WeMonItClient::class);
     $mock->method('getHost')->willReturn(['id' => 123, 'name' => 'Test Host']);
     $this->controller->setClient($mock);
     

   • Use VCR (e.g., vcrphp/vcr) to record/replay WeMonIt API calls for consistent tests.

Extension Points

1. Custom Endpoints Extend the bundle by creating a decorator for WeMonItClient:

   class CustomWeMonItClient extends WeMonItClient {
       public function getCustomMetric($hostId) {
           $data = $this->getHost($hostId);
           // Add custom logic
           return $data['custom_metric'];
       }
   }
   

   Register the decorator in services.yml:

   services:
       custom.wemonit.client:
           class: AppBundle\Service\CustomWeMonItClient
           decorates: twentystepsWeMonItBundle.service.wemonit.client
   

2. Event Listeners Listen for WeMonIt alerts or host status changes (if the bundle supports events):

   class WeMonItAlertListener implements EventSubscriberInterface {
       public static function getSubscribedEvents() {
           return [
               'wemonit.alert.created' => 'onAlertCreated',
           ];
       }
   
       public function onAlertCreated(AlertEvent $event) {
           // Handle alert (e.g., send Slack notification)
       }
   }
   

3. Configuration Overrides Override default bundle config in config.yml:

   twentysteps_wemonit:
       url: "%env(WE_MONIT_API_URL)%"
       api_key: "%env(WE_MONIT_API_KEY)%"
       cache: false
       timeout: 30 # Custom timeout in seconds