Monitoring Tryton ERP with Vigilmon

Tryton is a battle-tested open source ERP framework used by SMEs across Europe. Its architecture is clean and stable by design: the trytond application server handles all business logic over JSON-RPC, PostgreSQL stores every financial record, and the Sao web client provides browser access. That stability is a strength until something silently fails — a trytond crash blocks all ERP access, a PostgreSQL connection pool exhaustion queues every transaction, and a cron failure means invoice reminders never go out. Vigilmon gives you continuous monitoring of every layer: the application server, the database, user sessions, and background jobs.

What You'll Set Up

• trytond JSON-RPC health monitor
• PostgreSQL connectivity and query latency check
• Active user session monitor during business hours
• Cron job completion heartbeat
• Sao web client HTTP health check
• Database size growth alert
• PostgreSQL connection pool utilization monitor

Prerequisites

• Tryton (trytond) 7.x or later running as a systemd service
• PostgreSQL accessible from your monitoring host
• Sao web client deployed (nginx or Apache)
• A free Vigilmon account

Step 1: Monitor trytond Server Health

The trytond application server exposes a JSON-RPC interface. The simplest health check is an unauthenticated probe of the login endpoint — a 200 response means the server is up.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the trytond URL: http://localhost:8000/ (or your configured host/port).
4. Set Expected HTTP status to 200.
5. Set Check interval to 1 minute.
6. Click Save.

For a richer check that verifies JSON-RPC is actually responding, create a lightweight probe script:

cat > /usr/local/bin/check-trytond.sh << 'EOF'
#!/bin/bash
RESPONSE=$(curl -s -X POST http://localhost:8000/ \
  -H "Content-Type: application/json" \
  -d '{"id": 1, "method": "common.server.version", "params": []}' \
  --max-time 10)

if echo "$RESPONSE" | grep -q '"result"'; then
  echo "OK: trytond responding"
  exit 0
fi
echo "CRITICAL: trytond not responding"
exit 1
EOF
chmod +x /usr/local/bin/check-trytond.sh

Serve this via a small HTTP wrapper on port 9900 and add a Keyword check in Vigilmon looking for OK: trytond responding.

Step 2: Monitor PostgreSQL Connectivity and Query Latency

All Tryton data lives in PostgreSQL. A connection failure brings the entire ERP to a halt.

Basic connectivity check

cat > /usr/local/bin/check-tryton-db.sh << 'EOF'
#!/bin/bash
DB_NAME=${TRYTON_DB:-tryton}
DB_USER=${TRYTON_DB_USER:-tryton}

START=$(date +%s%N)
RESULT=$(psql -U "$DB_USER" -d "$DB_NAME" -c "SELECT 1" -t 2>&1)
END=$(date +%s%N)

if echo "$RESULT" | grep -q "1"; then
  LATENCY_MS=$(( (END - START) / 1000000 ))
  if [ "$LATENCY_MS" -gt 500 ]; then
    echo "WARNING: DB query latency ${LATENCY_MS}ms exceeds 500ms threshold"
    exit 1
  fi
  echo "OK: DB healthy, latency ${LATENCY_MS}ms"
  exit 0
fi
echo "CRITICAL: DB connection failed"
exit 1
EOF
chmod +x /usr/local/bin/check-tryton-db.sh

Expose via an HTTP exporter and add a Vigilmon Keyword check for OK:.

Step 3: Monitor Active User Sessions During Business Hours

During business hours, a Tryton deployment should have active sessions. Zero sessions is a leading indicator of server trouble before your users call you.

Query the active sessions table:

cat > /usr/local/bin/check-tryton-sessions.sh << 'EOF'
#!/bin/bash
DB_NAME=${TRYTON_DB:-tryton}
DB_USER=${TRYTON_DB_USER:-tryton}

# Only alert during business hours (Mon-Fri, 08:00-18:00)
HOUR=$(date +%H)
DOW=$(date +%u)  # 1=Monday, 7=Sunday

if [ "$DOW" -ge 6 ] || [ "$HOUR" -lt 8 ] || [ "$HOUR" -ge 18 ]; then
  echo "OK: outside business hours"
  exit 0
fi

SESSION_COUNT=$(psql -U "$DB_USER" -d "$DB_NAME" \
  -c "SELECT COUNT(*) FROM ir_session WHERE active" -t 2>/dev/null | tr -d ' ')

if [ "${SESSION_COUNT:-0}" -eq 0 ]; then
  echo "WARNING: 0 active sessions during business hours"
  exit 1
fi
echo "OK: ${SESSION_COUNT} active sessions"
exit 0
EOF
chmod +x /usr/local/bin/check-tryton-sessions.sh

Step 4: Monitor Cron Job Completion

Tryton's ir.cron scheduler runs background tasks: invoice reminders, stock reorder triggers, and report generation. A cron failure means these never run.

Check for recent cron failures

cat > /usr/local/bin/check-tryton-cron.sh << 'EOF'
#!/bin/bash
DB_NAME=${TRYTON_DB:-tryton}
DB_USER=${TRYTON_DB_USER:-tryton}

# Count cron jobs that haven't run in 2x their expected interval
STALE=$(psql -U "$DB_USER" -d "$DB_NAME" -t << 'SQL'
SELECT COUNT(*) FROM ir_cron
WHERE active = true
  AND next_call < NOW() - (interval '1 second' * number_calls * 2);
SQL
)

STALE=$(echo "$STALE" | tr -d ' ')
if [ "${STALE:-0}" -gt 0 ]; then
  echo "CRITICAL: ${STALE} overdue cron job(s)"
  exit 1
fi
echo "OK: all cron jobs current"
exit 0
EOF
chmod +x /usr/local/bin/check-tryton-cron.sh

Additionally, configure a Cron Heartbeat in Vigilmon for critical scheduled jobs:

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set the interval to match your most important cron job frequency.
3. Add a ping to the end of the cron task in trytond's cron configuration.

Step 5: Monitor Database Size Growth

ERP systems accumulate financial records over time. Unexpected size spikes can indicate runaway logging, duplicate imports, or missing data archival.

cat > /usr/local/bin/check-tryton-dbsize.sh << 'EOF'
#!/bin/bash
DB_NAME=${TRYTON_DB:-tryton}
DB_USER=${TRYTON_DB_USER:-tryton}
THRESHOLD_GB=${SIZE_THRESHOLD_GB:-50}

SIZE_BYTES=$(psql -U "$DB_USER" -d "$DB_NAME" \
  -c "SELECT pg_database_size('$DB_NAME')" -t | tr -d ' ')
SIZE_GB=$(( ${SIZE_BYTES:-0} / 1073741824 ))

if [ "$SIZE_GB" -gt "$THRESHOLD_GB" ]; then
  echo "WARNING: DB size ${SIZE_GB}GB exceeds ${THRESHOLD_GB}GB threshold"
  exit 1
fi
echo "OK: DB size ${SIZE_GB}GB"
exit 0
EOF
chmod +x /usr/local/bin/check-tryton-dbsize.sh

Run this hourly via cron and expose through the HTTP exporter.

Step 6: Monitor PostgreSQL Connection Pool Utilization

Tryton opens PostgreSQL connections for each concurrent user session. Pool exhaustion causes all new requests to queue and eventually time out.

cat > /usr/local/bin/check-tryton-connpool.sh << 'EOF'
#!/bin/bash
DB_NAME=${TRYTON_DB:-tryton}
DB_USER=${TRYTON_DB_USER:-tryton}

RESULT=$(psql -U "$DB_USER" -d "$DB_NAME" -t << 'SQL'
SELECT
  count(*) as active,
  (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') as max_conn
FROM pg_stat_activity
WHERE datname = current_database();
SQL
)

ACTIVE=$(echo "$RESULT" | awk '{print $1}' | tr -d ' ')
MAX=$(echo "$RESULT" | awk '{print $3}' | tr -d ' ')

if [ -z "$MAX" ] || [ "$MAX" -eq 0 ]; then
  echo "OK: could not read max_connections"
  exit 0
fi

UTILIZATION=$(( ACTIVE * 100 / MAX ))
if [ "$UTILIZATION" -gt 80 ]; then
  echo "CRITICAL: connection pool ${UTILIZATION}% utilized (${ACTIVE}/${MAX})"
  exit 1
fi
echo "OK: connection pool ${UTILIZATION}% (${ACTIVE}/${MAX})"
exit 0
EOF
chmod +x /usr/local/bin/check-tryton-connpool.sh

Step 7: Monitor the Sao Web Client

The Sao browser client is the primary interface for most Tryton users. A static file serve failure blocks all browser-based ERP access even if trytond is healthy.

1. In Vigilmon, click Add Monitor → HTTP / HTTPS.
2. Enter the Sao URL: https://erp.yourdomain.com/.
3. Set Expected HTTP status to 200.
4. Enable Monitor SSL certificate and alert when expiring within 21 days.
5. Click Save.

Step 8: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and connect Slack, email, or a webhook.
2. Set Consecutive failures before alert:
   • trytond health: 2 (a brief restart shouldn't page)
   • PostgreSQL connectivity: 1 (DB down = ERP down immediately)
   • Cron overdue: 1 (missed financial tasks need immediate attention)
   • Session count: 3 (give transient login periods a grace window)
3. Add a Maintenance window covering your weekend batch import windows to suppress false positives.

Summary

| Monitor | Target | Alert Condition | |---|---|---| | trytond JSON-RPC | Port 8000 keyword check | Server not responding | | PostgreSQL connectivity | DB query latency check | Failure or latency > 500ms | | Active sessions | Session count during business hours | Zero sessions 08:00–18:00 weekdays | | Cron jobs | Overdue cron count | Any cron job overdue | | Database size | Size vs. threshold | Growth > configured limit | | Connection pool | Active / max_connections | Pool utilization > 80% | | Sao web client | HTTPS health + SSL | HTTP error or cert expiry < 21 days |

Tryton's stability philosophy means that when something does go wrong, it stays broken quietly. With Vigilmon watching every layer — from the trytond process through PostgreSQL to Sao and background cron jobs — you know about failures within minutes, not when a user reports that invoices haven't been sending for two days.