deploy-felhom-compose/TASK.md

TASK.md — v0.5.1: Monitoring Page Bugfixes

Version bump: v0.5.1 Scope: 4 bugs in the monitoring page

---

Bug 1: Hostname shows container ID instead of host hostname

Problem

"Gépnév" displays 75f2f2a113f3 — the Docker container ID. os.Hostname() inside a container returns the container's hostname, not the host's.

Root cause

sysinfo.go line: info.Hostname, _ = os.Hostname()

Inside a Docker container, os.Hostname() returns the container ID unless hostname: is set in docker-compose.yml.

Fix — Two options (use both for robustness)

Option A: Mount host's /etc/hostname (preferred — works for all cases):

In controller/docker-compose.yml, add:

volumes:
  - /etc/hostname:/host/etc/hostname:ro

In sysinfo.go, read host hostname first:

// Hostname — try host mount first, fall back to os.Hostname()
if data, err := os.ReadFile("/host/etc/hostname"); err == nil {
    info.Hostname = strings.TrimSpace(string(data))
} else {
    info.Hostname, _ = os.Hostname()
}

Option B: Set hostname in docker-compose.yml (simpler but requires per-customer config):

hostname: ${HOSTNAME:-felhom}

But this requires the env var to be set. Option A is better — it reads the actual host hostname dynamically.

Use Option A. It's consistent with the /etc/os-release mount pattern already in place.

---

Bug 2: Tooltip timestamps show "1970. 01. 01. 01:00"

Problem

Hovering over chart data points shows 1970. 01. 01. 01:00 instead of the actual timestamp.

Root cause

In the tooltip callback:

callbacks: {
    title: function(items) {
        if (!items.length) return '';
        return formatTimestamp(items[0].parsed.x || items[0].label);
    }
}

The chart uses a category x-axis (default), not a time axis. items[0].parsed.x returns the category index (0, 1, 2, 3...), not the timestamp. When the index is > 0, parsed.x || label evaluates to the index (truthy). Then formatTimestamp(5) does new Date(5 * 1000) → 1970-01-01 01:00:00.005.

When the index is 0, 0 || label falls through to label, which works correctly. That's why the first data point shows the right time.

Fix

Always use items[0].label instead of parsed.x:

callbacks: {
    title: function(items) {
        if (!items.length) return '';
        return formatTimestamp(items[0].label);
    }
}

items[0].label is the raw label value from the labels array, which IS the timestamp in milliseconds.

Files

internal/web/templates/monitoring.html — tooltip callback in chartOpts function.

---

Bug 3: Range selector appears non-functional / 24h shows empty

Problem

Default range is 24h but the system has only ~20 minutes of data. On page load, charts appear empty (Y-axis 0-1.0, no visible lines). Clicking "1 óra" shows data. User perceives buttons as "not doing anything" because the initial state is already broken.

Root cause (likely)

Two contributing factors:

1. Default range too wide: systemRange = '24h' — for a newly deployed system with minutes of data, this either shows nothing or shows a barely visible sliver at the right edge.

2. Downsampling compression: 24h range with resolution=200 → bucketSeconds = 432. Twenty data points spanning 20 minutes (~1200s) get grouped into ~3 buckets. Three data points CAN render as a line chart, but if Chart.js's auto-scaling or the bucket timestamps are at the very edge, the chart might not render visibly.

Fix

A. Change default range to 1h:

let systemRange = '1h';

And move the active class to the 1h button:

<button class="filter-btn active" data-range="1h">1 óra</button>
<button class="filter-btn" data-range="6h">6 óra</button>
<button class="filter-btn" data-range="24h">24 óra</button>

Same for container detail range:

let detailRange = '1h';

B. Smart default: After the system has been running for 24+ hours, 24h makes more sense as a default. But for v0.5.1, just use 1h — it's always reasonable.

C. Add diagnostic logging: To understand if 24h truly returns empty, add a temporary console.log in the JS:

async function loadSystemMetrics() {
    try {
        const resp = await fetch('/api/metrics/system?range=' + systemRange + '&resolution=200');
        const json = await resp.json();
        console.log('[metrics] system range=' + systemRange + ', data points=' + (json.data?.labels?.length || 0));
        // ... rest of handler

This helps debug if the issue is no data returned vs. data not rendering.

Troubleshooting commands (run on demo node)

Before implementing the fix, verify the data is in SQLite:

# Check how many system metric rows exist
docker exec -it felhom-controller sh -c "cat /app/data/metrics.db" | strings | head -5
# Or directly via the API from the browser:
# https://felhom.demo-felhom.eu/api/metrics/system?range=1h&resolution=200
# https://felhom.demo-felhom.eu/api/metrics/system?range=24h&resolution=200

Compare the JSON responses. If 24h returns labels but cpu/memory arrays are zeros, it's a rendering issue. If labels are empty, it's a query issue.

---

Bug 4: Charts empty on initial page load

Problem

When navigating to the monitoring page, all four system charts show empty (no data) until the user clicks a range button.

Root cause

Same as Bug 3 — the initial loadSystemMetrics() call uses the 24h default range, which returns no visible data for a new system. Fixing Bug 3 (changing default to 1h) should also fix this.

Additional fix — race condition protection

Ensure the init sequence is robust. Currently:

initSystemCharts();
initContainerCharts();
initDetailCharts();
loadSysInfo();
loadSystemMetrics();
loadContainerSummary();

This looks correct — charts are initialized before data is loaded. No race condition here.

Edge case: very first load (0 data points)

If the monitoring page is loaded before the collector has stored even 1 sample (within the first 60 seconds of controller start), the "Még nincsenek adatok" message should appear. Verify this works correctly.

---

Implementation order

Step 1: Fix hostname

1. Add /etc/hostname:/host/etc/hostname:ro to controller/docker-compose.yml
2. Update sysinfo.go — read from /host/etc/hostname first

Step 2: Fix tooltip timestamps

1. Change items[0].parsed.x || items[0].label to items[0].label in monitoring.html

Step 3: Fix default range + empty charts

1. Change systemRange = '1h' and detailRange = '1h'
2. Move active class to "1 óra" button in both range bars
3. Add console.log diagnostic for data loading

Step 4: Build, deploy, verify

1. Build v0.5.1
2. Deploy to demo node (sync docker-compose.yml for new volume mount)
3. Verify hostname shows "demo-felhom"
4. Verify tooltip shows correct timestamp
5. Verify charts show data on page load
6. Test all range buttons (1h → 6h → 24h → 7d → 30d)

---

Files to modify

controller/docker-compose.yml                  — add /etc/hostname mount
internal/metrics/sysinfo.go                    — read hostname from /host/etc/hostname
internal/web/templates/monitoring.html         — fix tooltip callback + default range

---

Verification checklist

• Hostname shows "demo-felhom" (not container ID)
• Tooltip shows correct timestamp (e.g., "2026. 02. 16. 10:21")
• Charts show data on initial page load (1h default)
• "1 óra" button is active/highlighted by default
• Clicking each range button updates charts
• "24 óra" shows data if there are 1+ hours of collected metrics
• Container bar charts still render correctly
• Container detail panel still works
• No console errors in browser devtools