VnStat giám sát băng thông proxy: đọc đúng số liệu

VnStat giám sát băng thông proxy bằng số liệu trên interface, giúp theo dõi dung lượng theo thời gian nhưng không tự phân loại từng tài khoản proxy. ProxyVN hướng dẫn anh em chọn đúng điểm đo, kiểm tra daemon, đọc lịch sử và đối chiếu đơn vị cùng kỳ thống kê để tránh nhầm số liệu mạng của VPS với hóa đơn dịch vụ.

VnStat giám sát băng thông proxy từ bộ đếm interface

vnStat ghi nhận thống kê lưu lượng của những interface được chọn trên máy đang chạy công cụ. Nó không nhìn thấy một tài khoản proxy thương mại từ bên ngoài chỉ vì người dùng có địa chỉ và mật khẩu. Nếu anh em chỉ thuê proxy mà không quản lý host của dịch vụ, công cụ trên laptop sẽ đo interface của laptop, không biến thành dashboard lưu lượng riêng của máy chủ nhà cung cấp.

Trang dự án vnStat cho biết công cụ dùng thống kê interface do kernel cung cấp thay vì bắt nội dung từng gói tin. Điểm này phù hợp với theo dõi dung lượng qua thời gian, nhưng cũng xác định giới hạn phân tích. Một tổng byte tăng chưa cho biết website nào, người dùng nào hoặc request nào tạo ra phần tăng đó. Cần nguồn bổ sung khi câu hỏi đi sâu hơn.

Xác định máy mình có quyền đo

Bài viết giả định anh em quản lý một Linux VPS chạy proxy thử và được phép xem thống kê mạng. Interface minh họa là ens3, phải thay theo máy thật. Không có kết quả dung lượng hoặc số đo hiệu năng của một gói ProxyVN trong bài. Các phép tính chỉ minh họa cách đọc dữ liệu và cần được áp dụng trên số liệu thực tế do người vận hành thu thập.

Nếu tác vụ chạy trong container, interface bên trong container và interface ngoài host có thể biểu diễn những chặng khác nhau. Một số lưu lượng đi qua bridge, veth hoặc tunnel trước khi tới interface vật lý. Anh em cần vẽ đường đi và chọn điểm đo phù hợp. Cộng mọi interface nhìn thấy dễ đếm cùng dữ liệu nhiều lần mà không nhận ra nguồn sai khác.

Chọn câu hỏi phù hợp với công cụ

vnStat phù hợp với câu hỏi hôm nay interface đã truyền bao nhiêu hoặc tháng này xu hướng dung lượng thay đổi ra sao. Nó không thay thế log proxy khi cần phân bổ theo tài khoản và không thay thế công cụ quan sát luồng khi cần điều tra kết nối đang chiếm đường truyền. Xác định câu hỏi trước sẽ giúp không xây một báo cáo đẹp nhưng không trả lời được nhu cầu.

Nếu cần thêm nguồn IP cho tác vụ đã có kế hoạch lưu lượng, anh em có thể tham khảo mua proxy và đối chiếu cách tính dung lượng của gói; số đo interface vẫn cần được giữ riêng với số liệu thanh toán của nhà cung cấp.

VnStat giám sát băng thông proxy với điểm đo rõ ràng

Một máy proxy chuyển tiếp dữ liệu thường có lưu lượng giữa client và proxy, đồng thời có lưu lượng giữa proxy và upstream hoặc website. Nếu cả hai chặng đi qua cùng interface, bộ đếm có thể phản ánh nhiều lần dữ liệu đi vào và đi ra. Vì vậy, không nên lấy RX cộng TX rồi gọi ngay là dung lượng nội dung khách hàng đã tải.

Đọc hướng RX và TX từ góc nhìn interface

RX là lưu lượng nhận vào interface đang đo, TX là lưu lượng gửi ra từ interface đó. Tên hướng không tự đồng nghĩa với tải xuống và tải lên của khách hàng ở mọi kiến trúc. Một phản hồi website nhận vào proxy có thể xuất hiện ở RX, rồi dữ liệu gửi từ proxy về client xuất hiện ở TX. Nếu đổi điểm quan sát, cách diễn giải cũng thay đổi theo vị trí.

Tài liệu thống kê interface của Linux kernel mô tả các nguồn bộ đếm và những trường thống kê mạng. Công cụ lấy dữ liệu từ những nguồn đó cần được đọc theo phạm vi tương ứng. Không nên dùng một bộ đếm ở tầng interface để kết luận nội dung ứng dụng có kích thước giống hệt, vì còn có framing, giao thức và những loại lưu lượng khác trên cùng đường.

Chọn một điểm đo chính

Tách lưu lượng proxy với tác vụ cùng máy

VPS có thể đồng thời cập nhật hệ thống, đẩy bản sao lưu, tải image container và phục vụ quản trị từ xa. Những lưu lượng này cùng góp vào thống kê interface. Nếu biểu đồ ngày tăng mạnh, cần đối chiếu lịch tác vụ trước khi quy toàn bộ phần tăng cho proxy. Một thay đổi đúng lúc chỉ là gợi ý điều tra, chưa chứng minh quan hệ nguyên nhân.

Với nhu cầu phân bổ chi phí theo dịch vụ, có thể thiết kế điểm đo hoặc log phù hợp từ trước. Chẳng hạn, tách interface mạng theo kiến trúc đã được quản lý hoặc dùng thống kê ở lớp proxy có định nghĩa rõ. Không nên hứa vnStat tự tách được tiến trình bằng tên cổng. Khả năng công cụ và thiết kế thu thập phải được mô tả riêng để báo cáo không vượt phạm vi dữ liệu.

Không cộng các lớp encapsulation tùy ý

Một gói tin đi qua tunnel có thể xuất hiện ở interface tunnel và interface ngoài với cấu trúc khác nhau. Cộng cả hai tổng không tạo thành số liệu chính xác hơn. Hãy chọn một điểm chính cho mỗi mục đích, rồi dùng điểm còn lại làm đối chiếu. Nếu cần phân tích phần overhead, phải có điều kiện đo và cách ghép phù hợp, không suy từ hai số tổng thu ở những khoảng thời gian khác nhau.

VnStat giám sát băng thông proxy sau khi kiểm tra daemon

Lệnh truy vấn và tiến trình thu thập có vai trò khác nhau. Có thể chạy lệnh xem báo cáo nhưng lịch sử không tăng nếu daemon không hoạt động hoặc interface chưa được theo dõi. Trước khi đọc biểu đồ, kiểm tra phiên bản, interface và dịch vụ. Manual vnstatd của dự án là nguồn đối chiếu vai trò daemon cùng cách chạy theo môi trường cài đặt.

Bắt đầu bằng các lệnh chỉ đọc

Các lệnh sau dành cho Linux đã có vnStat và hệ thống dùng systemd với tên dịch vụ phù hợp. Tên ens3 là ví dụ, không phải giá trị có trên mọi VPS. Chúng phục vụ kiểm kê và đọc trạng thái, không cài phần mềm hoặc tạo dữ liệu lịch sử đã mất. Nếu hệ thống dùng trình quản lý dịch vụ khác, kiểm tra theo hướng dẫn của bản phân phối.

vnstat --version
vnstat --iflist
ip -s link show dev ens3
systemctl status vnstat --no-pager
vnstat -i ens3

Đọc lỗi theo lớp: không có lệnh khác với không có interface, và không có lịch sử khác với không có traffic. Nếu interface tồn tại nhưng vnStat chưa có bản ghi tương ứng, cần chuẩn bị theo quy trình của bản cài. Đừng xóa database để thử lại khi chưa sao lưu và chưa hiểu lỗi. Thao tác đó có thể làm mất phần dữ liệu vẫn còn hữu ích cho điều tra.

Thêm interface chỉ khi đã xác định đúng

Trong các bản hỗ trợ --add, lệnh dưới tạo mục theo dõi cho interface đã chọn. Nó thay đổi database vnStat nên chỉ thực hiện trên host được quản lý và sau khi kiểm tra quyền. Manual vnStat hiện hành mô tả tùy chọn cùng điều kiện daemon nhận interface mới. Cần đối chiếu man trên bản đang cài nếu phiên bản khác nguồn tham khảo.

sudo vnstat --add -i ens3

Sau khi thêm, xác nhận daemon nhận cấu hình theo tài liệu và chờ đủ khoảng cập nhật trước khi xem lại. Một giao diện mới theo dõi không có lịch sử tháng trước. Không nên điền số 0 cho những ngày chưa được thu thập rồi dùng chúng làm đường cơ sở. Thiếu dữ liệu và lưu lượng bằng không là hai trạng thái phải được phân biệt trong báo cáo.

Daemon trước biểu đồ

Lưu trạng thái thu thập cùng báo cáo

Bên cạnh tổng byte, ghi thời điểm bắt đầu theo dõi, phiên bản và những khoảng daemon ngừng hoạt động nếu biết. Một báo cáo thiếu các mốc này dễ tạo cảm giác tháng thấp hơn thực tế. Khi chuyển VPS hoặc đổi interface, lưu lại ánh xạ trước sau. Nếu tên interface giống nhau trên một máy mới, điều đó không làm hai chuỗi dữ liệu tự trở thành cùng một nguồn đo.

VnStat giám sát băng thông proxy theo ngày và tháng

Sau khi chắc dữ liệu đang được thu thập, mới chọn cửa sổ thống kê. Ngày, tháng và tổng toàn bộ lịch sử trả lời những câu hỏi khác nhau. Một ngày đang chạy chưa đủ độ dài để so trực tiếp với một ngày đã kết thúc. Một tháng hiện tại mới qua vài ngày cũng không nên được đặt cạnh tháng đủ ngày rồi kết luận mức sử dụng giảm.

Truy vấn đúng khoảng thời gian

Các lệnh minh họa dùng tham số phổ biến của vnStat 2.x, nhưng vẫn cần xem --help ở bản cài. Giới hạn số dòng giúp người vận hành tập trung vào đợt cần đối chiếu. Kết quả là dữ liệu có trong database, không phải kết quả truy xuất lịch sử từ nhà cung cấp proxy. Nếu database chỉ mới theo dõi, các lệnh không thể tạo lại những khoảng chưa từng được ghi nhận.

vnstat -i ens3 --days 7
vnstat -i ens3 --months 3
vnstat -i ens3 --json d 7 > vnstat-ens3-days.json

Trong JSON, giữ thông tin phiên bản định dạng cùng bản xuất để bộ đọc có thể kiểm tra tương thích. Không nên xử lý đầu ra như một bảng cố định bất biến qua mọi phiên bản. Nếu hệ thống xuất hiện trường mới, điều đó chưa chắc gây lỗi; nhưng thay đổi cấu trúc hoặc đơn vị cần được nhận diện. Đội phát triển nên kiểm tra đầu vào trước khi đưa dữ liệu vào báo cáo tự động.

Phân biệt tốc độ với dung lượng

Byte truyền trong một khoảng là dung lượng. Bit mỗi giây hoặc byte mỗi giây là tốc độ. Không thể so một tổng tháng với tốc độ hiện tại rồi gọi chúng lệch nhau. Muốn chuyển từ dung lượng sang tốc độ trung bình, cần độ dài khoảng đo và quy đổi đơn vị rõ. Giá trị trung bình cũng không thể thay cho đỉnh ngắn hạn khi đánh giá nghẽn mạng.

Ghi múi giờ và mốc bắt đầu kỳ

Một ngày thống kê được chia theo thời gian cấu hình của hệ thống, trong khi dashboard nhà cung cấp có thể dùng mốc khác. Lưu cả múi giờ và thời điểm chốt báo cáo. Khi so một đợt chạy qua nửa đêm, khác mốc ngày có thể khiến hai bảng phân bổ khác nhau dù tổng khoảng dài tương đương. Không cần nghi lỗi đo trước khi kiểm tra yếu tố thời gian cơ bản này.

Tài liệu cấu hình vnStat mô tả những thiết lập liên quan đầu ra và lưu dữ liệu. Chỉ thay đổi cấu hình sau khi biết yêu cầu báo cáo, không chỉnh nhiều tùy chọn để làm số liệu khớp một hóa đơn có định nghĩa chưa rõ. Mục tiêu là thống nhất phạm vi đo, không ép hai hệ thống khác nhau đưa ra một con số giống nhau.

VnStat giám sát băng thông proxy qua JSON có kiểm tra

Ví dụ Python sau nhận cấu trúc xuất có interfaces và traffic.day như trong dữ liệu vnStat phù hợp. Hàm tìm đúng tên interface, kiểm tra ngày và bộ đếm không âm rồi trả các dòng theo ngày. Nó không gọi mạng, không đọc database trực tiếp và không giả định mọi phiên bản JSON đều giống nhau. Cần xác nhận định dạng bản xuất trước khi dùng trong quy trình thật.

from datetime import date
 
def daily_rows(payload, iface):
    matches = [x for x in payload["interfaces"] if x["name"] == iface]
    if len(matches) != 1:
        raise ValueError("interface_not_unique")
    rows = []
    for item in matches[0]["traffic"]["day"]:
        d = item["date"]
        stamp = date(d["year"], d["month"], d["day"]).isoformat()
        rx, tx = item["rx"], item["tx"]
        if any(type(v) is not int or v < 0 for v in (rx, tx)):
            raise ValueError("invalid_counter")
        rows.append({"date": stamp, "rx_bytes": rx,
                     "tx_bytes": tx, "sum_bytes": rx + tx})
    if len({x["date"] for x in rows}) != len(rows):
        raise ValueError("duplicate_day")
    return sorted(rows, key=lambda x: x["date"])

Tên sum_bytes cố ý chỉ gọi là tổng hai chiều của interface, không phải dung lượng được thanh toán. Khi chuyển sang GB thập phân, chia cho một tỷ; khi chuyển sang GiB, chia cho lũy thừa hai tương ứng. Gắn đơn vị trong tên cột đầu ra sẽ giảm nhầm lẫn. Không nên làm tròn từng dòng quá sớm rồi cộng để đối chiếu một tổng có độ chính xác khác.

Kiểm tra lỗi schema trước khi cộng

Một interface không có trong bản xuất phải được báo thiếu, không trả tổng bằng không. Ngày không hợp lệ và bộ đếm âm cần dừng xử lý để điều tra. Nếu có nhiều interface cùng tên trong dữ liệu ghép, xác định nguồn trước khi tiếp tục. Việc bỏ qua im lặng những bản ghi bất thường có thể khiến báo cáo tháng nhìn bình thường nhưng thực tế thiếu một phần lưu lượng.

Kiểm tra hàm bằng dữ liệu giả có thể xác nhận việc chọn interface, sắp ngày và cộng bộ đếm. Nó không chứng minh daemon trên Linux đã thu đủ dữ liệu hoặc nhà cung cấp tính phí theo cùng cách. Các tầng kiểm chứng này cần được ghi riêng. Nếu sau này chạy bản xuất thật, giữ tệp đầu vào đã phù hợp quyền dữ liệu và metadata nguồn để người khác có thể đối chiếu.

JSON giữ đúng đơn vị byte

Bảo quản lịch sử thay vì chỉ giữ ảnh biểu đồ

Một ảnh biểu đồ giúp nhìn xu hướng nhưng khó dùng để kiểm tra lại phép tính. Giữ bản xuất có timestamp, interface và phiên bản sẽ hữu ích hơn khi có tranh luận về kỳ thống kê. Đồng thời cần chính sách giữ dữ liệu phù hợp dung lượng. Không sao chép database đang ghi bằng một cách tùy tiện rồi coi bản sao là đủ nhất quán cho mọi mục đích phục hồi.

VnStat giám sát băng thông proxy khi đối chiếu hóa đơn

Sai khác giữa vnStat và dashboard không tự chứng minh bên nào sai. Hai nguồn có thể đo ở hai lớp khác nhau, chỉ tính một chiều hoặc dùng kỳ khác. Trước khi gửi hỗ trợ, viết định nghĩa từng con số. Nếu chưa biết nhà cung cấp tính theo payload, đường truyền hay một phương pháp khác, hãy hỏi chính sách thay vì suy từ tên băng thông trên giao diện.

Thống nhất đơn vị và phạm vi trước

Đầu tiên đối chiếu byte với bit và GB với GiB. Tiếp theo đối chiếu RX, TX hay tổng hai chiều. Sau đó kiểm tra thời gian, interface, loại lưu lượng và trạng thái đầy đủ của lịch sử. Chỉ sau những bước này mới có cơ sở điều tra chênh lệch còn lại. Một báo cáo nêu rõ định nghĩa sẽ dễ được hỗ trợ hơn ảnh chụp hai tổng không cùng đơn vị.

Nếu proxy nằm trên VPS của mình, tổng interface có thể bao gồm cả chặng client lẫn upstream và tác vụ quản trị. Nếu nhà cung cấp proxy chỉ tính một loại lưu lượng qua cổng dịch vụ, hai số không nhất thiết giống. Đừng tự áp dụng hệ số chia hai như một công thức cố định. Overhead, cache, số chặng và luồng phụ có thể làm quan hệ thay đổi theo kiến trúc.

Dùng một cửa sổ thử nhỏ để hiểu quan hệ

Trong lab, chọn một tác vụ hữu hạn có dữ liệu thử và ghi counter trước sau ở điểm đo. Giữ các tác vụ khác ổn định trong khả năng kiểm soát, rồi đối chiếu số liệu ứng dụng và interface. Kết quả giúp hiểu hướng biến động, nhưng chưa tạo công thức thanh toán chung. Không chạy một tải lớn chỉ để khiến sai khác dễ nhìn khi chưa có hạn mức và tiêu chí dừng.

Một lần thử có thể cho thấy tổng interface tăng cùng thời điểm tác vụ, nhưng vẫn cần biết phần tăng nào thuộc luồng khác. Nếu không cô lập được, báo giới hạn thay vì gọi phần chênh là dung lượng thất thoát. Những từ như mất dữ liệu hoặc tính sai phí cần bằng chứng phù hợp. Mục tiêu ban đầu là hiểu cách đo và chọn dữ liệu cần bổ sung cho bước tiếp theo.

Chuẩn bị gói bằng chứng ngắn

Gửi khoảng thời gian, múi giờ, tên gói hoặc phạm vi dịch vụ đã che thông tin riêng, cùng định nghĩa con số đang so. Thêm bản xuất hoặc vài dòng có liên quan thay vì toàn bộ lịch sử máy. Không cần gửi mật khẩu proxy, khóa SSH hoặc cấu hình hệ thống chứa bí mật. Đội hỗ trợ có thể yêu cầu thêm thông tin cụ thể sau khi hiểu câu hỏi về cách tính.

VnStat giám sát băng thông proxy khi có khoảng trống dữ liệu

Một chuỗi lịch sử có thể bị gián đoạn do daemon dừng, interface đổi tên hoặc máy được thay thế. Cần tìm thời điểm dữ liệu ngừng tăng trước khi đọc xu hướng. Khi có khoảng trống, không tự nối đường biểu đồ như thể đã quan sát liên tục. Bảng báo cáo nên phân biệt dữ liệu không có, kỳ chưa kết thúc và số đo đã xác nhận bằng không.

Kiểm tra sau khởi động lại và thay interface

Sau bảo trì, xác nhận daemon chạy, interface còn đúng và database có bản ghi mới. Một service active chưa đủ nếu nó đang theo dõi interface không còn mang lưu lượng chính. Đối chiếu bộ đếm kernel cùng một khoảng cập nhật để biết nguồn có hoạt động. Nếu vừa đổi tuyến hoặc gắn thêm tunnel, xem lại sơ đồ điểm đo thay vì giữ tên cũ theo thói quen.

Với môi trường container, một interface có thể được tạo lại cùng tên nhưng thuộc một vòng đời khác. Lịch sử cần có metadata để diễn giải thay đổi này. Nếu chuyển database sang máy mới, đọc quy trình hỗ trợ của phiên bản và giữ sao lưu. Không ghép số liệu của hai host chỉ vì cùng dùng ens3, bởi tên interface là nhãn cục bộ chứ không phải định danh toàn cục.

Phân biệt sự cố thu thập với bất thường lưu lượng

Một ngày đột nhiên bằng không có thể do không có tác vụ, nhưng cũng có thể do daemon không ghi dữ liệu. Một ngày tăng cao có thể là tác vụ hợp lệ hoặc thay cách đo. Xem lịch thay đổi hệ thống và nguồn độc lập trước khi cảnh báo người dùng. Cách xác minh này giúp giảm những kết luận sai khiến đội vận hành thay proxy trong lúc lỗi nằm ở giám sát.

Tổng byte của interface là một phép đo tại một vị trí; muốn đối chiếu chi phí hoặc phân bổ theo tài khoản, phải có định nghĩa tương ứng của từng nguồn.

VnStat giám sát băng thông proxy với quy trình định kỳ

Quy trình định kỳ nên kiểm tra sức khỏe thu thập trước khi tạo báo cáo dung lượng. Ghi nguồn dữ liệu, cửa sổ thời gian và những thay đổi cấu hình liên quan. Với nhu cầu cảnh báo hạn mức, dùng ngưỡng gắn với ngân sách thực tế và giữ phần chưa xác nhận riêng. Không lấy một dự báo tháng khi dữ liệu mới có vài giờ làm cam kết về chi phí cuối kỳ.

Đối chiếu theo định nghĩa

Đặt tiêu chí cho báo cáo có thể sử dụng

Một báo cáo đủ dùng phải trả lời đo ở đâu, trong khoảng nào, đơn vị gì và có khoảng trống hay không. Nếu cần phân bổ theo dịch vụ, phải nêu rõ cách phân loại bổ sung. Nếu chỉ có thống kê interface, giữ tên chỉ số theo đúng phạm vi đó. Đây là điều kiện giúp người đọc ra quyết định mà không cần tự đoán ý nghĩa của một cột total.

Các lệnh trong bài được đối chiếu tài liệu ngày 26/10/2026; chưa chạy daemon trên một VPS proxy thương mại để công bố số đo. Hàm Python chỉ xử lý cấu trúc đầu vào đã xác định. Khi triển khai, anh em cần kiểm tra phiên bản bản cài, quyền dữ liệu và trạng thái thu thập thật. Không dùng dữ liệu minh họa trong bộ kiểm tra logic làm biểu đồ sử dụng của khách hàng.

Kiểm tra dự báo khi kỳ chưa kết thúc

Một dự báo cuối tháng cần nói rõ cách ước tính và dữ liệu đầu vào. Nếu lấy tốc độ sử dụng của vài ngày rồi nhân cho cả tháng, kết quả giả định nhịp sử dụng không thay đổi. Tác vụ theo lịch, ngày nghỉ hoặc đợt tải lớn có thể phá giả định đó. Nên trình bày dự báo như một kịch bản phục vụ chuẩn bị ngân sách, tách riêng với dung lượng đã đo và phần kỳ chưa có dữ liệu.

Trước khi đặt cảnh báo, xác định hành động cần làm khi vượt ngưỡng: xem tác vụ, giảm nhịp chạy theo kế hoạch hay trao đổi hạn mức. Một cảnh báo chỉ có số lớn mà không nêu interface và kỳ đo sẽ khiến người trực khó xử lý. Nếu dữ liệu thu thập đang thiếu, cảnh báo chất lượng dữ liệu phải được ưu tiên hơn một dự báo đang dựa trên lịch sử không đầy đủ.

Ghi nhận lần reset hoặc thay đổi nguồn

Khi interface hoặc máy được tạo lại, bộ đếm tại hệ điều hành có thể có vòng đời mới. Công cụ thu thập cần xử lý theo khả năng phiên bản, còn biên bản vẫn cần mốc thay đổi để giải thích lịch sử. Không nối hai đoạn dữ liệu rồi suy rằng một giá trị giảm là lưu lượng đã được hoàn lại. Chỉ báo cáo những khoảng có nguồn và cách thu thập đủ rõ để người khác đối chiếu được.

Kết hợp đúng công cụ khi câu hỏi thay đổi

Khi cần biết kết nối nào đang chiếm đường truyền, chuyển sang công cụ quan sát luồng và đối chiếu tiến trình theo quyền được cấp. Khi cần biết lỗi request hoặc tài khoản sử dụng, xem log ở lớp proxy. vnStat vẫn giữ vai trò lịch sử dung lượng để nhìn xu hướng. Kết hợp các nguồn theo câu hỏi sẽ hữu ích hơn cố bắt một công cụ trả lời mọi lớp thông tin.

VnStat giám sát băng thông proxy có ích khi điểm đo, đơn vị và kỳ thống kê được xác định rõ. Anh em nên kiểm tra daemon, giữ dữ liệu thiếu riêng và đối chiếu chính sách tính phí trước khi kết luận chênh lệch. Trao đổi cùng Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam về nhu cầu lưu lượng khi dùng vnStat giám sát băng thông proxy.