tutorial

Monitoring Apache Answer with Vigilmon

Apache Answer is a self-hosted Q&A platform for internal knowledge bases and developer communities. Here's how to monitor every layer — Go backend, database, Redis cache, and email notifications — with Vigilmon before a silent failure stops your team from sharing knowledge.

Apache Answer is a self-hosted Q&A platform that brings Stack Overflow-style knowledge sharing to your organization — built by the SegmentFault team and now an Apache Incubator project. It's a Go backend with a React SPA frontend, backed by MySQL or PostgreSQL, Redis for caching, and SMTP for notification emails. When it's healthy, your engineering team's institutional knowledge flows freely. When it degrades — a slow database query, a crashed Redis instance, a broken SMTP configuration — question threads go unanswered and email engagement drops to zero. Vigilmon gives you external visibility into every layer of your Apache Answer deployment before users notice something is wrong.

What You'll Set Up

  • HTTP uptime monitor for the Apache Answer web application
  • Database health indicator via the Answer API
  • Redis cache health via the Answer health endpoint
  • Search functionality response-time monitor
  • Email notification delivery check via heartbeat
  • SSL certificate expiry alert for your Answer domain

Prerequisites

  • Apache Answer deployed and accessible over HTTPS
  • MySQL or PostgreSQL running as the Answer database
  • Redis running for session management and caching
  • SMTP configured for notification emails
  • A free Vigilmon account

Step 1: Monitor the Apache Answer Web Application

Apache Answer's Go backend serves the React SPA and all API routes from the same process. A process crash or OOM kill takes down both the UI and the API simultaneously. Start with a basic uptime monitor:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter your Answer URL: https://answers.yourdomain.com.
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Enable Monitor SSL certificate and set Alert when certificate expires in less than 21 days.
  7. Click Save.

For a more precise health signal, target the Answer health endpoint if your deployment exposes one. Apache Answer (as of recent versions) provides internal health checks accessible via the admin API. You can also use the question list API as a lightweight liveness check:

https://answers.yourdomain.com/answer/api/v1/questions?page=1&page_size=1

This endpoint returns a JSON response with questions and is an accurate proxy for application + database health:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: https://answers.yourdomain.com/answer/api/v1/questions?page=1&page_size=1
  3. Set Expected HTTP status to 200.
  4. Under Keyword check, enable Response must contain: "list"
  5. Set Check interval to 2 minutes.
  6. Click Save.

A non-200 response or missing "list" key means the Go backend cannot query the database — covering both app failure and database failure in one monitor.

Step 2: Monitor Response Time for the Question API

The question list and individual question pages are the highest-traffic paths in any Answer deployment. Slow API responses manifest as page load timeouts for active community members. Add a response-time monitor:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: https://answers.yourdomain.com/answer/api/v1/questions?page=1&page_size=10
  3. Set Check interval to 2 minutes.
  4. Under Response time alerts, enable Alert when p95 response time exceeds 1000 ms (1 second).
  5. Click Save.

A p95 latency spike on the questions endpoint typically indicates:

  • Slow database queries from missing indexes on the questions or answers tables
  • Redis cache miss storm after a Redis restart (the cache is cold and every request hits the DB)
  • High Go runtime GC pressure from a memory growth pattern

When you see a latency alert, check the Answer admin dashboard at /admin for slow query logs, and verify Redis connectivity:

redis-cli ping    # should return PONG immediately

Step 3: Monitor the Search Endpoint

Apache Answer's full-text search is a critical feature — users rely on it to find existing questions before posting duplicates. A broken search doesn't throw errors visible in the UI; it silently returns zero results. Monitor it explicitly:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: https://answers.yourdomain.com/answer/api/v1/search?q=test&page=1&page_size=5
  3. Set Expected HTTP status to 200.
  4. Set Check interval to 5 minutes.
  5. Under Response time alerts, enable Alert when p95 response time exceeds 2000 ms.
  6. Click Save.

Replace q=test with a keyword that reliably returns results in your Answer instance (a common technology term used in your community). If the search endpoint starts returning empty results or timing out, it indicates:

  • ElasticSearch/OpenSearch connectivity failure (if you've enabled the search plugin)
  • MySQL FULLTEXT index corruption (for native database search)
  • The Answer search plugin is in a failed state

Step 4: Monitor User Authentication

Apache Answer requires users to log in to post questions and answers. A broken authentication layer — expired JWT secret, broken session Redis, or a corrupt users table — silently prevents all community participation. Monitor the login endpoint:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: https://answers.yourdomain.com/answer/api/v1/user/login
  3. Set Method to POST.
  4. Set Request body: 
    {"e_mail": "monitor@example.com", "pass": "wrongpassword"}
  5. Set Request header: Content-Type: application/json
  6. Set Expected HTTP status to 400 (intentional wrong password — confirms the auth layer is reachable and processing requests).
  7. Set Check interval to 5 minutes.
  8. Click Save.

Sending a deliberately incorrect password means you don't need a live test account. A 400 response confirms the authentication endpoint is healthy and performing credential validation. A 500 response or a timeout indicates a backend failure in the auth layer.

Step 5: Heartbeat Monitor for Email Notification Delivery

Apache Answer sends email notifications for new answers, comment mentions, and daily digests. Broken SMTP configuration is one of the most common and least visible Apache Answer failure modes — users stop receiving notifications, engagement drops, and questions go unanswered.

Set up a heartbeat that pings Vigilmon after confirming SMTP is reachable:

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to 60 minutes.
  3. Copy the heartbeat URL: https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID.

Create an hourly SMTP connectivity check script:

#!/bin/bash
# /etc/cron.hourly/answer-smtp-check

HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID"
SMTP_HOST="mail.yourdomain.com"
SMTP_PORT="587"

# Test TCP connectivity to SMTP server
if timeout 5 bash -c "echo '' > /dev/tcp/${SMTP_HOST}/${SMTP_PORT}" 2>/dev/null; then
  curl -s "$HEARTBEAT_URL" > /dev/null
else
  echo "SMTP connectivity check failed: ${SMTP_HOST}:${SMTP_PORT}" >&2
  exit 1
fi

Make it executable:

chmod +x /etc/cron.hourly/answer-smtp-check

If the SMTP server becomes unreachable, the heartbeat stops arriving and Vigilmon alerts your team before users notice that notifications have gone silent.

Step 6: Configure Alert Channels and Thresholds

  1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook to your team's communication tool.
  2. Set Consecutive failures before alert to 2 on the web root monitor — the Go binary occasionally takes 1–2 seconds to restart after an OOM kill, which may cause a single probe to fail.
  3. Set Consecutive failures before alert to 1 on the search and authentication monitors — these endpoints have no expected transient failures in production.
  4. Configure Maintenance windows during Answer upgrades (Answer releases require database migrations):
# Before running migrations
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "YOUR_MONITOR_ID", "duration_minutes": 10}'

# Run the Answer migration
docker compose exec answer answer migration

# Window expires automatically; Vigilmon resumes monitoring

Summary

| Monitor | Target | Alert Threshold | What It Catches | |---|---|---|---| | Web root | / | Non-200 | Go process crash | | Questions API | /answer/api/v1/questions | Non-200 or missing "list" | App + database failure | | API response time | Questions endpoint | p95 > 1 s | Database query slowness | | Search endpoint | /answer/api/v1/search | Non-200 or p95 > 2 s | Search engine failure | | Auth endpoint | /answer/api/v1/user/login | Non-400 | Auth layer failure | | SMTP heartbeat | Hourly cron | Missed ping | Email notification failure | | SSL certificate | Answer domain | Expiry < 21 days | TLS renewal failure |

Apache Answer is the kind of tool that becomes invisible when it works — engineers just use it. Vigilmon's external monitoring keeps it that way, alerting your team before a database slowdown, broken search, or silent SMTP failure turns an invisible platform into an actively complained-about one.

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