Monitoring OSRM (Open Source Routing Machine) with Vigilmon

OSRM (Open Source Routing Machine) is a C++ routing engine that loads a preprocessed OpenStreetMap road graph entirely into RAM and computes routes in milliseconds. It powers logistics platforms, food delivery apps, and self-hosted routing services that need fast, accurate routing without Google Maps pricing. But OSRM's speed comes from its in-memory graph — if the process crashes, restarts, or the host runs out of RAM, all routing stops instantly. Vigilmon keeps watch on your OSRM server health, routing latency, and infrastructure metrics so you know before your users do.

What You'll Set Up

• HTTP uptime monitor for the OSRM HTTP API server
• Route request latency checks with p95 thresholds
• Table request (distance matrix) latency monitoring
• RAM utilization tracking for the in-memory graph
• Graph data freshness heartbeat
• Error rate monitoring

Prerequisites

• OSRM backend (osrm-routed) 5.26+ running and accessible over HTTP
• OpenStreetMap graph preprocessed with MLD or CH algorithm
• A free Vigilmon account

Step 1: Monitor OSRM Server Health

The osrm-routed process serves a REST HTTP API. Your first monitor should verify the server is up and responding:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. URL: http://osrm.yourdomain.com:5000/route/v1/driving/13.388860,52.517037;13.397634,52.529407?overview=false (Berlin example coordinates — replace with coordinates known to be on your road network)
4. Check interval: 1 minute.
5. Expected HTTP status: 200.
6. Under Advanced, Response must contain: "code":"Ok".
7. Click Save.

This performs a real routing request, confirming not just that the process is alive but that the graph is loaded and routing is functional. A server that has started but not yet loaded its graph will respond with an error code.

Step 2: Monitor Route Request Latency

OSRM's key performance promise is low-latency routing. Degraded latency usually means the graph no longer fits comfortably in RAM (swapping), the server is overloaded, or the process restarted and is warming up.

Set response time thresholds on your route monitor:

• Warning threshold: 50ms (well above normal; OSRM typically responds in 5–20ms for single routes)
• Alert threshold: 100ms p95 — above this, the server is under significant pressure

In Vigilmon:

1. Open the route monitor from Step 1.
2. Under Response time alert, set threshold to 100 ms.
3. Save.

For /table (distance matrix) requests, add a separate monitor. Matrix calculations scale quadratically with waypoint count, so use a small matrix:

GET /table/v1/driving/13.388860,52.517037;13.397634,52.529407;13.428555,52.523219

Set the response time alert to 500ms for this endpoint.

Step 3: Monitor /nearest Endpoint

The /nearest endpoint snaps GPS coordinates to the road network. It is used before routing to ensure coordinates are on a navigable road. Slow nearest responses delay the routing pipeline.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://osrm.yourdomain.com:5000/nearest/v1/driving/13.388860,52.517037
3. Check interval: 2 minutes.
4. Expected HTTP status: 200.
5. Response must contain: "code":"Ok".
6. Response time alert: 50ms.
7. Save.

Step 4: Monitor RAM Utilization

OSRM loads the entire road graph into RAM using memory-mapped files. A continental-scale OSM graph (Europe) can consume 30–60 GB of RAM. If system RAM drops, the OS will start paging the memory-mapped graph files, causing routing latency to spike by orders of magnitude.

Set up a cron heartbeat script that monitors RAM utilization on the OSRM host:

#!/bin/bash
# Get RAM used by osrm-routed
OSRM_PID=$(pgrep osrm-routed)
if [ -z "$OSRM_PID" ]; then
  echo "osrm-routed process not found"
  exit 1
fi

# Read RSS from /proc
RSS_KB=$(cat /proc/${OSRM_PID}/status | grep VmRSS | awk '{print $2}')
TOTAL_KB=$(grep MemTotal /proc/meminfo | awk '{print $2}')
USAGE_PCT=$((RSS_KB * 100 / TOTAL_KB))

if [ "$USAGE_PCT" -gt 90 ]; then
  echo "osrm-routed RAM usage ${USAGE_PCT}% — risk of swap"
  exit 1
fi

curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"

In Vigilmon, create a Cron Heartbeat monitor with a 5-minute interval. If the heartbeat is missed, it means the process is not running or RAM is critically low.

Step 5: Monitor Graph Data Freshness

OSRM preprocessing converts OpenStreetMap PBF data into a binary graph. This graph ages as the road network changes. Most production deployments re-preprocess weekly or monthly. A stale graph means routes may use roads that no longer exist or miss newly built roads.

Create a cron heartbeat that validates graph freshness:

#!/bin/bash
GRAPH_FILE="/data/osrm/map.osrm"
MAX_AGE_DAYS=7

# Get file modification time in epoch seconds
MOD_TIME=$(stat -c %Y "$GRAPH_FILE")
NOW=$(date +%s)
AGE_DAYS=$(( (NOW - MOD_TIME) / 86400 ))

if [ "$AGE_DAYS" -gt "$MAX_AGE_DAYS" ]; then
  echo "OSRM graph is ${AGE_DAYS} days old (threshold: ${MAX_AGE_DAYS})"
  exit 1
fi

curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"

In Vigilmon, create a Cron Heartbeat monitor with a 24-hour interval. If the graph has not been updated within your configured refresh interval, Vigilmon alerts you.

Step 6: Monitor Request Error Rate

OSRM returns structured error codes in its JSON responses. A 4xx/5xx response rate above 1% indicates routing failures — missing graph coverage for requested coordinates, corrupted graph files, or process instability.

Use a log-monitoring approach with a heartbeat:

#!/bin/bash
# Check OSRM error rate from access log (last 100 requests)
LOG_FILE="/var/log/osrm/access.log"
TOTAL=$(tail -100 "$LOG_FILE" | wc -l)
ERRORS=$(tail -100 "$LOG_FILE" | grep -c '"code":"[^O]' || true)

if [ "$TOTAL" -gt 0 ] && [ "$((ERRORS * 100 / TOTAL))" -gt 1 ]; then
  echo "OSRM error rate ${ERRORS}/${TOTAL} in last 100 requests"
  exit 1
fi

curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"

Alternatively, if you proxy OSRM through nginx, monitor the nginx access log for 5xx responses from the upstream:

# In your nginx config, log upstream response time
log_format osrm_upstream '$remote_addr - [$time_local] "$request" '
                          '$status $upstream_response_time';
access_log /var/log/nginx/osrm.log osrm_upstream;

Step 7: Verify Graph File Integrity

OSRM preprocessing produces several interdependent binary files (.osrm, .osrm.ebg, .osrm.partition, etc.). If any file is missing or corrupted (for example, a preprocessing run was interrupted), the server will either fail to start or produce incorrect routes.

#!/bin/bash
OSRM_BASE="/data/osrm/map"

# Required files for MLD algorithm
REQUIRED_FILES=(
  "${OSRM_BASE}.osrm"
  "${OSRM_BASE}.osrm.ebg"
  "${OSRM_BASE}.osrm.partition"
  "${OSRM_BASE}.osrm.customization"
  "${OSRM_BASE}.osrm.mldgr"
)

for f in "${REQUIRED_FILES[@]}"; do
  if [ ! -s "$f" ]; then
    echo "Missing or empty graph file: $f"
    exit 1
  fi
done

curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"

Run this as a cron heartbeat immediately after each preprocessing run to confirm the output is complete before restarting the routing server.

Step 8: Configure Alerting

In Vigilmon, configure notification channels and thresholds for each monitor:

| Monitor | Alert Condition | Severity | |---|---|---| | OSRM /route health | Status ≠ 200 or code ≠ Ok | Critical | | Route latency | p95 >100ms | High | | Table latency | p95 >500ms | Medium | | /nearest latency | p95 >50ms | Low | | RAM utilization | >90% | Critical | | Graph freshness | Graph >7 days old | Medium | | Error rate | >1% in sliding window | High | | Graph file integrity | File missing or empty | Critical |

Set Critical alerts to page your on-call engineer immediately via SMS or phone call. A crashed OSRM process means zero routing availability — every map and logistics request backed by OSRM fails instantly.

For the RAM and error rate monitors, configure a 3-failure window before alerting to avoid false positives from momentary spikes.

Conclusion

OSRM's performance comes from its all-in-RAM graph — and that same characteristic makes RAM pressure and process crashes the primary failure modes to watch. With Vigilmon, you get continuous routing health checks that verify the full request path (not just TCP connectivity), latency tracking to detect degradation before it becomes user-visible, graph freshness alerts so your road network data does not silently age out, and RAM utilization monitoring to prevent swap-induced latency spikes. Configure these monitors once and let Vigilmon watch your routing infrastructure around the clock.

Get started at vigilmon.online.