Dashboard quản lý proxy pool bằng Flask và Chart.js

Dashboard quản lý proxy pool cần trả lời endpoint nào đang dùng được, dữ liệu được đo lúc nào và lỗi nằm ở tầng nào. Một biểu đồ đẹp nhưng đọc số liệu cũ có thể dẫn tới quyết định sai. ProxyVN hướng dẫn anh em dựng mô hình Flask và Chart.js chỉ đọc, có kiểm tra dữ liệu và phân biệt trạng thái chưa biết với kết nối thất bại.

Dashboard quản lý proxy pool với phạm vi rõ ràng

Một dashboard nên đọc kết quả của bộ kiểm tra thay vì tự tạo hàng loạt yêu cầu mạng mỗi khi người dùng mở trang. Cách tách này giữ nhịp kiểm tra ổn định, tránh việc nhiều người xem cùng làm tăng tải lên proxy và website đích. Bộ kiểm tra chịu trách nhiệm thực hiện probe; API chịu trách nhiệm cung cấp dữ liệu đã lọc; giao diện chịu trách nhiệm trình bày trạng thái và thời gian quan sát.

Bài viết xây một ứng dụng chỉ đọc snapshot JSON do bộ kiểm tra tạo. Nó không cấp phát proxy, không tự xoay endpoint, không thực hiện mua dịch vụ và không khẳng định kiểm tra được mọi giao thức. Anh em có thể nối bộ kiểm tra đang dùng vào hợp đồng dữ liệu bên dưới. Nếu chưa có bộ kiểm tra, dùng dữ liệu mẫu để phát triển giao diện rồi bổ sung collector như một thành phần riêng.

Phân biệt quản lý pool với quan sát pool

Quản lý pool thường bao gồm chọn endpoint, duy trì phiên, cách ly endpoint lỗi và trả lại tài nguyên. Dashboard quan sát phản ánh các quyết định hoặc số đo của hệ thống đó. Nếu giao diện chỉ hiển thị một lần kiểm tra HTTP thành công, nó chưa thể kết luận endpoint được phép phục vụ mọi tác vụ. Quyền truy cập và điều kiện của ứng dụng đích vẫn cần được kiểm tra theo công việc thực tế.

Anh em có thể đọc khái niệm Proxy Pool để xác định thành phần nào đã có trong hệ thống. Phần triển khai ở đây tập trung vào hợp đồng số liệu, API và vòng cập nhật màn hình. Nhờ ranh giới đó, một thay đổi ở thư viện kiểm tra mạng không buộc giao diện phải biết mật khẩu hay cơ chế cấp phiên của từng nhà cung cấp.

Đầu ra tối thiểu nên gồm bảng trạng thái có nhãn, biểu đồ độ trễ của các lần thành công gần nhất và thông báo khi dữ liệu quá hạn. Chỉ dùng màu xanh đỏ là chưa đủ vì người đọc cần biết trạng thái có nghĩa gì. Một endpoint chưa được đo không nên bị gắn nhãn hỏng, còn một endpoint từng tốt nhưng số liệu đã cũ không nên tiếp tục xuất hiện như đang khỏe.

Dashboard quản lý proxy pool và hợp đồng dữ liệu

Mỗi bản ghi cần một định danh không chứa thông tin truy cập. Trong ví dụ, id là mã nội bộ như vn-a01. Các trường còn lại là ok, latency_ms, checked_at và error_code. Thời gian dùng Unix timestamp theo giây để API tính tuổi dữ liệu. Người vận hành cần thống nhất quy ước thời gian giữa collector và API, đồng thời kiểm tra đồng hồ máy để tránh bản ghi tương lai bị hiểu là mới mãi.

Trường ok thể hiện một probe đạt tiêu chí đã định. latency_ms chỉ có ý nghĩa khi probe thành công trong hợp đồng mẫu này; khi thất bại, dùng null để không biến timeout thành độ trễ bằng không. error_code là mã do collector chuẩn hóa như CONNECT_TIMEOUT hoặc PROXY_AUTH, không phải toàn bộ thông báo chứa URL và thông tin đăng nhập. Các mã này là thiết kế của ví dụ, không phải chuẩn bắt buộc của Flask.

Thêm trạng thái unknown theo tuổi dữ liệu

Trong mô hình minh họa, dữ liệu quá 60 giây được đánh dấu unknown. Đây là ngưỡng cấu hình để diễn giải ví dụ, không phải khuyến nghị chung cho mọi pool. Nếu collector chạy mỗi vài phút, cần chọn ngưỡng phù hợp hơn và ghi rõ chu kỳ. Một lần collector ngừng hoạt động không nên làm mọi endpoint đồng loạt chuyển sang failed, vì chưa có probe mới chứng minh chúng hỏng.

Ba trạng thái healthy, failed và unknown cần có chú giải trên màn hình. Healthy nghĩa probe gần nhất đạt và còn mới theo ngưỡng; failed nghĩa probe mới thất bại; unknown nghĩa thiếu quan sát còn hiệu lực. Người vận hành có thể dùng chúng để quyết định bước kiểm tra tiếp theo, nhưng logic cấp phát trong pool nên có quy tắc riêng. Dashboard không nên âm thầm thay đổi danh sách cấp phát chỉ vì người dùng đổi bộ lọc.

Dữ liệu snapshot cũng nên được giới hạn kích thước và số bản ghi trước khi đọc trong hệ thống thật. Một tệp bị tăng bất thường có thể làm API chậm hoặc tiêu tốn bộ nhớ. Ví dụ dưới đây kiểm tra số bản ghi, loại giá trị và khóa xuất ra, nhưng chưa phải hệ thống nhập dữ liệu từ nguồn không tin cậy. Quyền ghi tệp snapshot chỉ dành cho collector được quản lý.

Ba trạng thái có ý nghĩa

Dashboard quản lý proxy pool bằng API Flask chỉ đọc

Hướng dẫn Flask cung cấp nền tảng route, phản hồi JSON và phục vụ tệp tĩnh. Mã dưới đây là ví dụ tự viết cho dashboard nội bộ thử nghiệm. Tạo app.py trong một thư mục riêng, đặt snapshot.json bên cạnh. API chỉ trả các trường đã cho phép, vì truyền nguyên đối tượng từ collector có thể làm lộ thông tin khi schema được bổ sung password ở một thay đổi sau này.

import json
import math
import time
from pathlib import Path
from flask import Flask, jsonify

app = Flask(__name__)
SNAPSHOT = Path(__file__).with_name('snapshot.json')
MAX_AGE = 60
MAX_BYTES = 1_000_000

def finite_number(value):
    if type(value) not in (int, float):
        return False
    try:
        return math.isfinite(value)
    except OverflowError:
        return False

def read_rows(now):
    with SNAPSHOT.open('rb') as f:
        raw = f.read(MAX_BYTES + 1)
    if len(raw) > MAX_BYTES:
        raise ValueError('snapshot too large')
    source = json.loads(raw)
    if not isinstance(source, list) or len(source) > 1000:
        raise ValueError('invalid snapshot')
    rows, seen = [], set()
    for item in source:
        key, ok = item['id'], item['ok']
        stamp, latency = item['checked_at'], item['latency_ms']
        if not isinstance(key, str) or not 1 <= len(key) <= 64:
            raise ValueError('invalid id')
        if not key.strip() or any(ord(c) < 32 for c in key):
            raise ValueError('invalid id')
        if key in seen or type(ok) is not bool:
            raise ValueError('duplicate id or invalid status')
        seen.add(key)
        if not finite_number(stamp) or stamp < 0 or stamp > now + 5:
            raise ValueError('invalid timestamp')
        if ok and (not finite_number(latency) or latency < 0):
            raise ValueError('invalid latency')
        if not ok and latency is not None:
            raise ValueError('failed probe requires null latency')
        age = max(0, now - stamp)
        state = 'unknown' if age > MAX_AGE else (
            'healthy' if ok else 'failed')
        error = item.get('error_code')
        allowed = {'CONNECT_TIMEOUT', 'PROXY_AUTH',
                   'TARGET_HTTP', 'TLS_ERROR'}
        if error is not None:
            if not isinstance(error, str) or error not in allowed:
                error = 'OTHER'
        rows.append(dict(id=key, state=state, age_s=round(age, 1),
                         latency_ms=latency if ok else None,
                         error_code=error))
    return rows

@app.get('/api/pool')
def pool():
    try:
        rows = read_rows(time.time())
    except (OSError, ValueError, KeyError, TypeError):
        response = jsonify(error='snapshot_unavailable')
        response.status_code = 503
    else:
        response = jsonify(rows=rows, served_at=time.time())
    response.headers['Cache-Control'] = 'no-store'
    return response

@app.get('/')
def index():
    return app.send_static_file('index.html')

API xử lý tệp mất, JSON lỗi và dữ liệu không hợp lệ bằng phản hồi 503 có mã ngắn. Không trả traceback, đường dẫn file hoặc bản ghi gốc cho trình duyệt. Lựa chọn từ chối cả snapshot khi một dòng sai ưu tiên tính dễ hiểu của mô hình. Hệ thống lớn có thể chấp nhận các dòng tốt và báo số dòng bị loại, nhưng cần thiết kế rõ để người xem không hiểu danh sách rút ngắn là pool đã mất endpoint.

Tạo fixture trước khi nối collector thật

Để mở ứng dụng lần đầu, tạo snapshot bằng dữ liệu giả với timestamp hiện tại. Đoạn lệnh này chỉ sinh fixture giao diện, không thực hiện probe và không phải bằng chứng endpoint có độ trễ 120 mili giây. Tên endpoint cùng con số được chọn để kiểm tra hiển thị. Khi nối collector thật, thay fixture bằng kết quả đo đúng hợp đồng và giữ ranh giới thử nghiệm trong tài liệu vận hành.

import json
import os
import tempfile
import time
from pathlib import Path

target = Path(__file__).with_name('snapshot.json')
rows = [dict(id='demo-a01', ok=True, latency_ms=120,
             checked_at=time.time(), error_code=None)]
# Dữ liệu giả để thử giao diện, không phải kết quả đo proxy.
temp = None
try:
    with tempfile.NamedTemporaryFile(
            mode='w', encoding='utf-8', dir=target.parent,
            prefix='snapshot-', suffix='.tmp', delete=False) as f:
        temp = Path(f.name)
        json.dump(rows, f, ensure_ascii=False, allow_nan=False)
        f.flush()
        os.fsync(f.fileno())
    os.replace(temp, target)
finally:
    if temp is not None:
        temp.unlink(missing_ok=True)

Trong môi trường phát triển có Python và pip phù hợp, cài Flask vào môi trường ảo rồi chạy flask --app app run --host 127.0.0.1. Lệnh chỉ dành cho phát triển local. Kiểm tra API tại /api/pool trước khi thêm biểu đồ để tách lỗi backend khỏi lỗi giao diện. Nếu nhận 503, xem quyền đọc tệp, vị trí snapshot và trường dữ liệu thay vì cố sửa JavaScript trước.

Dashboard quản lý proxy pool với Chart.js và bảng trạng thái

Biểu đồ nên hỗ trợ một câu hỏi cụ thể. Ở đây, biểu đồ cột thể hiện độ trễ của những probe healthy còn mới. Các endpoint failed hoặc unknown vẫn xuất hiện trong bảng văn bản để không bị giấu đi chỉ vì không có số độ trễ. Không đưa null thành cột bằng không, vì người xem có thể hiểu endpoint hỏng là endpoint nhanh nhất trên hệ thống.

Theo hướng dẫn cài Chart.js, có thể lấy thư viện qua npm. Trong dự án, cài chart.js, giữ lockfile và sao chép bản UMD trong gói phù hợp vào static/chart.umd.js. Kiểm tra đường dẫn theo bản gói đã chọn. Phục vụ bản đã chốt từ cùng ứng dụng giúp môi trường nội bộ không phụ thuộc việc truy cập CDN mỗi lần mở dashboard.

Tạo static/index.html chứa các phần sau. Ví dụ dùng textContent khi hiển thị id và trạng thái, tránh ghép dữ liệu từ snapshot vào HTML. Một id tưởng như chỉ là mã nội bộ vẫn có thể chứa ký tự đặc biệt do lỗi cấu hình. Bảng ở đây là phần văn bản tối thiểu hỗ trợ đọc thông tin ngay cả khi canvas không thể hiện được nội dung cho người dùng.

<!doctype html>
<html lang="vi">
<meta charset="utf-8">
<title>Trạng thái proxy pool</title>
<h1>Trạng thái proxy pool</h1>
<p id="message" role="status">Đang lấy dữ liệu</p>
<pre id="rows"></pre>
<div style="max-width:900px"><canvas id="latency"></canvas></div>
<script src="/static/chart.umd.js"></script>
<script src="/static/pool.js"></script>
</html>

Tiếp theo tạo static/pool.js. Vòng cập nhật dùng setTimeout sau khi lần lấy dữ liệu trước kết thúc, vì vậy không tạo nhiều yêu cầu chồng nhau khi API chậm. Timeout phía fetch giới hạn thời gian chờ của một lượt. Khoảng mười giây là tham số minh họa cho giao diện, cần điều chỉnh theo nhịp collector và số người xem, không phải mục tiêu thời gian đáp ứng của proxy.

const message = document.querySelector('#message');
const table = document.querySelector('#rows');
let chart = null;
try {
  if (typeof Chart === 'function') {
    chart = new Chart(document.querySelector('#latency'), {
      type: 'bar',
      data: {labels: [], datasets: [{label: 'Probe latency ms', data: []}]},
      options: {animation: false, scales: {y: {beginAtZero: true}}}
    });
  }
} catch (_) { chart = null; }

function plot(rows) {
  if (!chart) return false;
  try {
    const good = rows.filter(x => x.state === 'healthy');
    chart.data.labels = good.map(x => x.id);
    chart.data.datasets[0].data = good.map(x => x.latency_ms);
    chart.update('none');
    return true;
  } catch (_) { return false; }
}

async function refresh() {
  try {
    const response = await fetch('/api/pool', {
      cache: 'no-store', signal: AbortSignal.timeout(5000)
    });
    if (!response.ok) throw new Error('snapshot unavailable');
    const payload = await response.json();
    if (!Array.isArray(payload.rows)) throw new Error('invalid rows');
    table.textContent = payload.rows.map(
      x => `${x.id}: ${x.state}; age=${x.age_s}s; ${x.error_code || '-'}`
    ).join('\n') || 'Snapshot hợp lệ nhưng không có endpoint';
    const plotted = plot(payload.rows);
    message.textContent = plotted
      ? 'Đã đọc snapshot; xem tuổi từng bản ghi'
      : 'Đã đọc snapshot; biểu đồ chưa sẵn sàng, xem bảng trạng thái';
  } catch (_) {
    plot([]);
    message.textContent = 'Không lấy được dữ liệu mới';
    table.textContent = 'Trạng thái chưa biết';
  } finally {
    setTimeout(refresh, 10000);
  }
}
refresh();

Ví dụ không giữ biểu đồ cũ khi API lỗi, nhằm tránh người vận hành nhìn hình cũ rồi coi đó là kết quả mới. Một sản phẩm thật có thể giữ dữ liệu cuối cùng nếu hiển thị thời gian và cảnh báo rõ. Quan trọng là hành vi phải có chủ đích. Khi chọn cách giữ dữ liệu cũ, đừng tiếp tục gắn nhãn hiện tại hoặc xanh mà không cho biết thời điểm quan sát gần nhất.

Bảng và biểu đồ bổ sung nhau

Giữ bảng trạng thái khi thư viện biểu đồ gặp lỗi

Mã giao diện đã tách việc đọc API khỏi việc vẽ canvas. Nếu Chart.js chưa tải hoặc khởi tạo thất bại, vòng lấy snapshot vẫn chạy và bảng văn bản vẫn cập nhật. Thông báo khi đó nói rõ biểu đồ chưa sẵn sàng. Không đổi dữ liệu hợp lệ thành trạng thái chưa biết chỉ vì một thư viện hiển thị gặp lỗi.

Nếu API lỗi, nhánh khác sẽ xóa dữ liệu biểu đồ đang có và chuyển bảng sang trạng thái chưa biết. Hai tình huống phải được thử riêng: bỏ tệp thư viện nhưng giữ API hoạt động; sau đó giữ thư viện và cho API trả 503. Chỉ ca thứ hai phản ánh việc không lấy được snapshot mới. Người trực có thể nhờ vậy tìm đúng tầng cần sửa.

Backend giới hạn cả số bản ghi lẫn số byte đọc từ tệp. Trong ví dụ, trần một triệu byte là tham số của mô hình, không phải tiêu chuẩn dung lượng cho mọi pool. Trường số được kiểm tra riêng để loại NaN, vô cực, boolean và số nguyên quá lớn không chuyển được sang phép kiểm tra hữu hạn. Một đầu vào sai không nên làm route rơi sang lỗi ngoài hợp đồng.

Khi ok là false, latency_ms phải là null theo schema đã chọn. Mã lỗi lạ được chuẩn hóa thành OTHER, còn trường ngoài danh sách cho phép không đi xuống trình duyệt. Phản hồi API thành công và phản hồi 503 đều có Cache-Control no-store để giảm nguy cơ đọc lại một trạng thái lỗi đã cũ trong môi trường có lớp cache ở giữa.

Biểu đồ lỗi và dữ liệu lỗi là hai sự cố khác nhau. Bảng trạng thái cần tiếp tục dùng được khi chỉ phần vẽ bị hỏng.

Dashboard quản lý proxy pool và collector ghi snapshot

Collector cần chạy độc lập với API. Nếu ứng dụng dùng nhiều WSGI worker, đặt vòng probe trong module app có thể làm mỗi worker tạo một lịch kiểm tra riêng. Hậu quả là lưu lượng thử tăng ngoài dự kiến và nhiều tiến trình cùng ghi tệp. Một tiến trình collector hoặc một lịch tác vụ có chủ sở hữu rõ sẽ dễ quản lý hơn, đặc biệt khi cần dừng probe trong thời gian bảo trì.

Quá trình tạo snapshot nên ghi ra tệp tạm cùng thư mục rồi thay thế tệp đích. Tài liệu Python về os.replace mô tả thao tác thay thế đường dẫn, với điều kiện và hành vi phụ thuộc hệ điều hành. Đặt tệp tạm trên cùng hệ thống tệp giúp tránh vấn đề di chuyển qua volume. Đồng thời xử lý lỗi ghi hoặc thay thế để API không đọc một tệp đang được viết dở.

Đặt tiêu chí probe trước khi thu số liệu

Một probe HTTP thành công có thể đòi mã phản hồi cụ thể và marker nội dung từ endpoint thử. Chỉ kiểm tra cổng TCP mở không đủ để xác nhận xác thực và đường tới đích. Nếu dùng HTTPS, giữ kiểm tra chứng chỉ và hostname. Đừng tắt xác minh TLS để làm biểu đồ xuất hiện nhiều trạng thái healthy hơn, vì khi đó tiêu chí đo đã bị thay đổi theo hướng khác với yêu cầu sử dụng.

Mỗi probe cần timeout và giới hạn số tác vụ đồng thời. Lịch kiểm tra nên tránh tạo đỉnh tải khi toàn bộ endpoint được thử cùng một lúc. Anh em có thể phân bố thời điểm và dùng endpoint thử do mình kiểm soát hoặc được phép sử dụng. Không gửi tần suất cao tới website bên ngoài chỉ để lấy số liệu, vì dashboard là công cụ vận hành cần tôn trọng tài nguyên của bên nhận yêu cầu.

Độ trễ cũng cần định nghĩa rõ. Tổng thời gian từ lúc bắt đầu tới lúc đọc xong phản hồi khác thời gian kết nối TCP hoặc thời gian tới byte đầu tiên. Nếu collector thay thư viện và làm định nghĩa thay đổi, biểu đồ trước sau không còn so sánh trực tiếp được. Hãy ghi phương pháp và phiên bản collector trong metadata vận hành, rồi đánh dấu khi thay đổi cách đo.

Khi cần mở rộng pool, anh em nên mua proxy tốc độ cao sau khi xác định loại tác vụ và tiêu chí đo, rồi đánh giá endpoint mới bằng cùng quy trình đang áp dụng cho pool hiện có.

Dashboard quản lý proxy pool với kiểm thử dữ liệu và lỗi

Test client của Flask cho phép gọi route mà không mở cổng server thật. Đây là cách phù hợp để kiểm tra hợp đồng API bằng snapshot giả. Các ca cần có gồm tệp hợp lệ, tệp mất, JSON sai, id trùng, timestamp tương lai và dữ liệu cũ. Kiểm tra từng trường hợp giúp phát hiện lỗi diễn giải trước khi giao diện được nối tới collector có dữ liệu công việc.

Phân biệt kiểm thử logic và kiểm thử mạng

Nếu API trả healthy cho fixture có timestamp hiện tại, kết quả chỉ chứng minh logic chuyển trạng thái và schema hoạt động với dữ liệu đó. Nó không xác nhận một proxy ngoài Internet có thể truy cập. Tương tự, kiểm tra cú pháp JavaScript không chứng minh canvas hiển thị đúng trong mọi trình duyệt. Báo cáo kiểm thử nên ghi từng lớp đã kiểm tra và những lớp cần môi trường thật để xác nhận.

Thử dữ liệu stale bằng cách đặt checked_at trước thời gian hiện tại vượt ngưỡng cấu hình. Trạng thái phải thành unknown và không được nằm trong biểu đồ healthy. Thử thất bại mới bằng ok=false, latency_ms=null và mã CONNECT_TIMEOUT; bảng phải cho thấy failed cùng mã lỗi. Không dùng một fixture duy nhất cho cả hai tình huống, vì mất dữ liệu và kết nối thất bại cần được phản ánh khác nhau.

Ca dữ liệu nhạy cảm cần đưa thêm password giả vào đầu vào rồi xác nhận API không trả trường đó. Đây là lý do dùng danh sách trường cho phép thay vì jsonify toàn bộ nguồn. Nếu schema collector được thêm mới sau này, API vẫn giữ giới hạn xuất ra. Để kiểm tra chuỗi đặc biệt trong id, dùng dữ liệu chứa dấu ngoặc hoặc thẻ giả rồi xác nhận giao diện hiển thị văn bản thay vì thực thi HTML.

Một phép thử lỗi API nên kiểm tra mã phản hồi và thông điệp ngắn, không đòi một traceback cụ thể của thư viện. Cách kiểm tra theo hợp đồng giúp mã vẫn có thể được sửa bên trong mà không làm test mất ý nghĩa. Với biểu đồ, ưu tiên kiểm tra các nhánh empty, healthy và unknown trong trình duyệt đích. Một màn hình chỉ được xem với dữ liệu đẹp sẽ bỏ sót tình huống người vận hành cần nhất.

Kiểm thử snapshot lỗi

Dashboard quản lý proxy pool khi đưa vào vận hành

Mô hình local cần được bổ sung xác thực, phân quyền và hạ tầng phục vụ trước khi dùng chung. Tài liệu triển khai Flask yêu cầu dùng server WSGI hoặc nền tảng phù hợp thay cho development server trong production. Đối với Windows, Linux hoặc container, lựa chọn cụ thể cần được kiểm tra theo môi trường. Không công khai cổng phát triển chỉ vì API hiện chỉ có route đọc dữ liệu.

Thông tin trạng thái pool vẫn có thể nhạy cảm dù không chứa mật khẩu. Nó có thể tiết lộ quy mô tài nguyên, nhãn dự án và thời điểm hệ thống gặp lỗi. Đặt dashboard sau cơ chế đăng nhập hoặc lớp truy cập nội bộ được quản lý, giới hạn người xem theo nhu cầu. Nếu bổ sung nút xóa hoặc cách ly endpoint, cần thiết kế quyền ghi, nhật ký và bảo vệ yêu cầu riêng, thay vì tái sử dụng route đọc hiện tại.

Tránh biến màn hình thành công cụ điều khiển ngoài ý muốn

Ví dụ không nhận URL tùy ý từ trình duyệt để server đi kiểm tra. Nếu thêm chức năng này mà không giới hạn đích, dashboard có thể trở thành cầu nối tới địa chỉ nội bộ ngoài phạm vi cho phép. Nên chọn probe target từ danh sách được quản trị duyệt. Mọi thao tác kiểm tra thủ công cũng cần hạn mức để nhiều người không cùng kích hoạt một đợt tải lớn lên hệ thống.

Khi biểu đồ chậm, hãy đo thời gian đọc snapshot, thời gian API và thời gian vẽ riêng. Đừng vội tăng tần suất polling để tạo cảm giác cập nhật liên tục. Với pool lớn, API cần phân trang hoặc tổng hợp, giao diện cần giới hạn số cột hiển thị và có bộ lọc có ý nghĩa. Một nghìn nhãn trên cùng canvas có thể tồn tại về mặt kỹ thuật nhưng khó hỗ trợ quyết định của người trực.

Lưu lịch sử là một yêu cầu khác với snapshot. Mô hình hiện tại chỉ phản ánh quan sát gần nhất, nên không thể tính tỷ lệ thành công theo ngày hoặc xu hướng theo giờ từ một tệp đã bị ghi đè. Nếu cần thống kê, ghi sự kiện hoặc chuỗi thời gian vào kho phù hợp và định nghĩa cửa sổ tính. Anh em có thể đối chiếu cách đo proxy success rate trước khi đặt tên chỉ số trên dashboard.

Mẫu số của chỉ số cần được công bố

Khi bổ sung tỷ lệ thành công, đếm số probe đạt trên tổng probe đã thực hiện trong cửa sổ được chọn. Endpoint chưa có probe không tự sinh một lần thất bại. Nếu collector bỏ lịch vì bảo trì, cần ghi khoảng trống thay vì điền số đẹp cho đủ cột. Với các pool có tần suất kiểm tra khác nhau, tỷ lệ theo probe cũng có ý nghĩa khác tỷ lệ theo endpoint đang hoạt động tại một thời điểm.

Một chỉ số độ trễ trung bình chỉ tính các lần thành công có thể nhìn tốt hơn trong lúc nhiều yêu cầu timeout. Vì vậy, đặt nó cạnh số lần thử và tỷ lệ thất bại. Không thay timeout bằng một số mili giây tùy ý rồi gọi kết quả là thời gian phản hồi thực tế. Nếu cần thống kê phân vị, lưu các quan sát thích hợp và mô tả cách xử lý lần lỗi trước khi đưa biểu đồ vào báo cáo.

Người xem cũng cần biết bộ lọc đang áp dụng. Một màn hình chỉ hiển thị nhóm QA-VN không nên ghi tổng pool nếu thực tế đã loại nhóm khác. Khi thêm bộ lọc, hiển thị số bản ghi sau lọc cùng thời điểm lấy snapshot. Các thay đổi này giúp người trực hiểu phạm vi con số mà không phải nhớ mình đã bấm những lựa chọn nào từ lần mở màn hình trước.

Dashboard quản lý proxy pool và tiêu chí bàn giao

Một bản bàn giao cần có schema, vị trí snapshot, chu kỳ collector, ngưỡng stale, cách khởi động và cách xử lý khi API trả 503. Người nhận phải giải thích được healthy, failed và unknown bằng cùng một định nghĩa. Nếu hai người trực hiểu unknown theo hai nghĩa khác nhau, dashboard sẽ tạo tranh luận thay vì giúp xử lý sự cố. Chú giải ngắn trên màn hình và tài liệu vận hành cùng nguồn sẽ giảm sai lệch này.

Khi mô hình nhỏ đủ dùng và khi cần mở rộng

Flask cùng snapshot phù hợp cho prototype hoặc nhóm nhỏ cần quan sát kết quả gần nhất từ một collector. Khi có nhiều nguồn ghi, lịch sử dài, nhiều người xem hoặc yêu cầu cảnh báo, cần đánh giá kho lưu và hệ thống giám sát riêng. Chưa cần thay toàn bộ giao diện ngay khi thêm endpoint, nhưng cần nhận biết giới hạn một tệp và một tiến trình trước khi biến prototype thành hạ tầng phụ thuộc lâu dài.

Khi nghiệm thu, dùng cả snapshot tốt, lỗi và quá hạn. Xác nhận trình duyệt báo rõ khi API mất kết nối, không lộ bí mật trong JSON và không gọi probe từ lượt xem trang. Sau đó chạy một ca tích hợp với collector thật trên endpoint được phép. Kết quả của ca tích hợp phải ghi điều kiện và thời gian, tách khỏi dữ liệu giả đã dùng để phát triển giao diện trước đó.

Đường xử lý khi dashboard mất dữ liệu

Nếu mọi bản ghi chuyển unknown, kiểm tra lần collector ghi thành công gần nhất trước khi thay endpoint. Tiếp theo kiểm tra đồng hồ máy, quyền ghi và dung lượng lưu trữ. Nếu API trả503 nhưng collector vẫn ghi đều, kiểm tra schema và quyền đọc của tài khoản chạy WSGI. Một thay đổi kiểu dữ liệu từ số sang chuỗi có thể làm cả snapshot bị từ chối dù hệ thống mạng vẫn hoạt động.

Nếu API trả200 nhưng trình duyệt không cập nhật, xem yêu cầu fetch, phản hồi và lỗi JavaScript ở môi trường thử. Kiểm tra tệp thư viện có được phục vụ đúng đường dẫn và phiên bản hay không. Không tăng quyền server hoặc đưa mật khẩu collector xuống trình duyệt để sửa lỗi hiển thị. Tầng dữ liệu và tầng vẽ có trách nhiệm riêng, nên thao tác sửa cũng cần dừng đúng phạm vi đang có bằng chứng.

Sau khi khôi phục, lưu nguyên nhân, thời điểm và cách phát hiện vào nhật ký vận hành. Nếu lỗi đến từ schema, thêm fixture tương ứng vào bộ kiểm tra; nếu do file bị ghi dở, sửa quy trình xuất snapshot; nếu do thư viện frontend, chốt lại bản dựng. Mỗi sự cố nên tạo một cải tiến có thể kiểm tra, thay vì chỉ khởi động lại ứng dụng rồi để cùng lỗi xuất hiện vào lần sau.

Từ prototype tới vận hành

Dashboard quản lý proxy pool có giá trị khi số liệu mới, định nghĩa rõ và lỗi được hiển thị đúng phạm vi. Anh em có thể trao đổi về endpoint tại Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam, rồi dùng cùng hợp đồng đo để mở rộng dashboard quản lý proxy pool.