tutorial

Monitoring LogicMonitor-Managed Infrastructure with Vigilmon: External Health Checks, API Uptime & Synthetic Probes

Practical guide to complementing LogicMonitor's hybrid infrastructure monitoring with Vigilmon's external uptime checks — health endpoints, synthetic HTTP monitors, and independent alerting.

LogicMonitor is a powerful hybrid observability platform — it monitors on-premises servers, cloud instances, network devices, containers, and applications through a collector-based architecture. What it monitors exceptionally well is everything inside your network perimeter: CPU, memory, disk I/O, container health, and SNMP-polled network gear. What it doesn't provide is an independent, external health check — a synthetic probe that measures whether your public-facing services are reachable and responding correctly from the outside world. Vigilmon fills that gap. It sits entirely outside your infrastructure and probes your services from multiple external locations, alerting you independently of whether your LogicMonitor collectors are healthy.

This tutorial covers adding external uptime monitoring to infrastructure already managed by LogicMonitor.

What You'll Build

  • A /health endpoint on your application for external synthetic probing
  • A Vigilmon HTTP monitor with response-body assertions
  • A heartbeat monitor for scheduled jobs and batch processes
  • An alert routing strategy that keeps LogicMonitor infrastructure alerts and Vigilmon uptime alerts separate but correlated

Prerequisites

  • A LogicMonitor account with collectors deployed and monitoring your infrastructure
  • At least one web application or API reachable via a public HTTPS URL
  • A free account at vigilmon.online

Step 1: Add a Health Endpoint to Your Application

LogicMonitor's collectors poll your infrastructure from inside your network. Vigilmon needs an HTTP endpoint it can reach from the outside. Make it check real dependencies — not just a static 200 that would pass even when your database or cache is down.

Java (Spring Boot)

// HealthController.java
import org.springframework.http.ResponseEntity;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.data.redis.core.RedisTemplate;

import java.util.HashMap;
import java.util.Map;

@RestController
public class HealthController {

    private final JdbcTemplate jdbcTemplate;
    private final RedisTemplate<String, String> redisTemplate;

    public HealthController(JdbcTemplate jdbcTemplate, RedisTemplate<String, String> redisTemplate) {
        this.jdbcTemplate = jdbcTemplate;
        this.redisTemplate = redisTemplate;
    }

    @GetMapping("/health")
    public ResponseEntity<Map<String, Object>> health() {
        Map<String, String> checks = new HashMap<>();
        boolean ok = true;

        // Database probe
        try {
            jdbcTemplate.queryForObject("SELECT 1", Integer.class);
            checks.put("database", "ok");
        } catch (Exception e) {
            checks.put("database", "error: " + e.getMessage());
            ok = false;
        }

        // Redis probe
        try {
            redisTemplate.opsForValue().set("__health__", "probe", java.time.Duration.ofSeconds(30));
            checks.put("cache", "ok");
        } catch (Exception e) {
            checks.put("cache", "error: " + e.getMessage());
            ok = false;
        }

        Map<String, Object> response = new HashMap<>();
        response.put("status", ok ? "ok" : "degraded");
        response.put("checks", checks);

        return ok
            ? ResponseEntity.ok(response)
            : ResponseEntity.status(503).body(response);
    }
}

.NET (ASP.NET Core)

// HealthEndpoint.cs
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;

[ApiController]
[Route("[controller]")]
public class HealthController : ControllerBase
{
    private readonly AppDbContext _db;
    private readonly IHttpClientFactory _http;

    public HealthController(AppDbContext db, IHttpClientFactory http)
    {
        _db = db;
        _http = http;
    }

    [HttpGet]
    public async Task<IActionResult> Get()
    {
        var checks = new Dictionary<string, string>();
        var ok = true;

        try
        {
            await _db.Database.ExecuteSqlRawAsync("SELECT 1");
            checks["database"] = "ok";
        }
        catch (Exception ex)
        {
            checks["database"] = $"error: {ex.Message}";
            ok = false;
        }

        try
        {
            var client = _http.CreateClient();
            var resp = await client.GetAsync(Environment.GetEnvironmentVariable("UPSTREAM_URL") + "/ping");
            checks["upstream"] = resp.IsSuccessStatusCode ? "ok" : $"http_{(int)resp.StatusCode}";
            if (!resp.IsSuccessStatusCode) ok = false;
        }
        catch (Exception ex)
        {
            checks["upstream"] = $"error: {ex.Message}";
            ok = false;
        }

        var body = new { status = ok ? "ok" : "degraded", checks };
        return ok ? Ok(body) : StatusCode(503, body);
    }
}

Verify the endpoint is reachable before configuring Vigilmon:

curl -s https://your-app.example.com/health | jq .
# {"status":"ok","checks":{"database":"ok","cache":"ok"}}

Step 2: Configure Vigilmon HTTP Monitor

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://your-app.example.com/health
  3. Check interval: 60 seconds — appropriate for most production services.
  4. Response timeout: 10 seconds.
  5. Expected status code: 200.
  6. JSON body assertion:
    • Path: status
    • Expected value: ok
  7. Click Save.

Vigilmon immediately begins probing your endpoint from multiple external probe locations. A non-200 response or a failed JSON assertion triggers an alert to your configured channels.

Multiple tiers and environments

LogicMonitor typically monitors multiple tiers: web, application, and database layers. Mirror that granularity in Vigilmon with one monitor per public-facing endpoint:

| Tier | Vigilmon monitor URL | Interval | |---|---|---| | Public API | https://api.example.com/health | 60 s | | Customer portal | https://app.example.com/health | 60 s | | Admin dashboard | https://admin.example.com/health | 120 s | | Staging API | https://api-staging.example.com/health | 120 s |

Group related monitors under a single Monitor group in Vigilmon to keep the dashboard organized.

Step 3: Complementary Alert Routing

LogicMonitor alerts on infrastructure metrics: CPU above threshold, disk running out, collector going offline. Vigilmon alerts on user-facing availability: the endpoint is down or degraded. These are distinct failure modes that warrant separate notification paths.

| Failure mode | Source | Route to | |---|---|---| | Server CPU / disk threshold breach | LogicMonitor | Ops Slack #infra-alerts + ticket | | Network device unreachable | LogicMonitor | NOC team | | External API uptime failure | Vigilmon | PagerDuty on-call + Slack #prod-alerts | | Batch job heartbeat missed | Vigilmon | Slack #ops-critical |

Configure Vigilmon alert channels under Alerts → Add channel:

  • Email: your on-call distribution list.
  • PagerDuty webhook: wire to your primary on-call rotation for user-facing outages.
  • Slack webhook: a dedicated channel for uptime-specific alerts.

Use a separate Slack channel for Vigilmon alerts than the one LogicMonitor posts to. During an incident, being able to quickly distinguish "infrastructure resource exhausted" from "service unreachable externally" saves critical minutes.

Step 4: Heartbeat Monitor for Scheduled Jobs

LogicMonitor can monitor Windows Task Scheduler and Linux cron jobs through its agent — but only if the collector is deployed on the host running the job. For containerized or serverless batch workloads that LogicMonitor doesn't cover, use Vigilmon heartbeats.

# jobs/nightly_report.py
import os
import requests

def run_report():
    generate_report()
    send_to_recipients()

if __name__ == "__main__":
    try:
        run_report()
        # Ping Vigilmon on success
        requests.post(os.environ["VIGILMON_HEARTBEAT_URL"], timeout=5)
        print("Report job complete — heartbeat sent")
    except Exception as exc:
        # Deliberate silence — missed heartbeat fires alert
        print(f"Report job failed: {exc}")
        raise

In Vigilmon, create a Heartbeat monitor and set the grace period to 25 hours for a nightly job (24-hour interval + 1-hour buffer). Store the heartbeat URL in your secrets vault and inject it as VIGILMON_HEARTBEAT_URL.

Kubernetes CronJob example

# k8s/report-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-report
spec:
  schedule: "0 2 * * *"  # 2 AM daily
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: report
            image: your-registry/report-job:latest
            env:
            - name: VIGILMON_HEARTBEAT_URL
              valueFrom:
                secretKeyRef:
                  name: vigilmon-secrets
                  key: heartbeat-url
          restartPolicy: Never

Step 5: Correlating LogicMonitor and Vigilmon During Incidents

When Vigilmon fires a downtime alert, use this quick correlation checklist to determine root cause:

  1. Check Vigilmon probe regions — did all probe locations fail or just one? All failing = likely application/infra issue. One region failing = possible network routing issue.
  2. Open LogicMonitor → check the relevant host for CPU, memory, and disk alerts in the same time window.
  3. Check LogicMonitor network devices — is the firewall or load balancer upstream of your application showing any anomalies?
  4. Compare timestamps — did the LogicMonitor infrastructure alert precede the Vigilmon downtime alert? If so, the infrastructure issue likely caused the downtime.

Keep this checklist in your runbook and link to both dashboards from your incident management tool.

Step 6: Public Status Page

LogicMonitor dashboards are private infrastructure views. Give customers and partners a public-facing status page using Vigilmon.

  1. In Vigilmon, go to Status Pages → Create.
  2. Add your production HTTP monitors and any critical heartbeat monitors.
  3. Configure a custom domain (e.g., status.example.com) or use the Vigilmon subdomain.
  4. Embed the badge in your product documentation:
<img src="https://vigilmon.online/badge/<monitor-id>.svg" alt="Service Status" />

Your customers get real-time uptime visibility without requiring any access to LogicMonitor or your internal infrastructure.

What Vigilmon Adds to a LogicMonitor Stack

| Capability | LogicMonitor | Vigilmon | |---|---|---| | Server/VM resource metrics | Yes | No | | Network device polling (SNMP) | Yes | No | | Container and Kubernetes health | Yes | No | | External synthetic HTTP probing | No | Yes | | DNS resolution failure detection | No | Yes | | TLS/SSL certificate expiry alerts | No | Yes | | Scheduled job heartbeat monitoring | Partial (agent required) | Yes | | Public status page | No | Yes | | Independent of your cloud provider | No (collectors inside your network) | Yes |

LogicMonitor gives you deep visibility into the health of your infrastructure from the inside. Vigilmon gives you the external, synthetic view that tells you what your users actually experience. Together they cover every dimension of service reliability: from server metrics to customer-facing uptime.

Add external uptime monitoring to your LogicMonitor-managed infrastructure today — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles