Grafana Loki quản lý log proxy: label, LogQL và lab đối chứng
Grafana Loki quản lý log proxy là cách gom access log và error log của gateway proxy vào một chỗ để tìm lỗi theo thời gian và theo máy. ProxyVN viết bài này cho người chạy crawler hay hệ thống tự động đi qua proxy. Lab dùng 6.001 dòng log mẫu để chỉ ra label nào làm Loki phình to, và truy vấn nào tìm đúng lỗi 407 hay timeout.
Grafana Loki quản lý log proxy: tác vụ cụ thể và ranh giới với bài đã có
Bài toán đặt ra
Một hệ crawler cỡ vừa thường chạy vài chục worker, đi qua hai ba gateway proxy nội bộ rồi ra nhà cung cấp proxy. Khi tỷ lệ lỗi tăng, người trực cần biết ba điều trong vài phút. Lỗi nằm ở gateway nào, bắt đầu từ lúc nào, và thuộc nhóm xác thực, kết nối hay đích chậm.
Metric cho biết tỷ lệ lỗi tăng. Log cho biết dòng nào, request nào, đích nào. Hai thứ bổ sung cho nhau, nhưng công cụ lưu và cách truy vấn khác nhau. Loki giữ từng dòng log, còn Prometheus giữ chuỗi số theo thời gian.
Ranh giới với bài Prometheus và Grafana
Bài giám sát proxy bằng Prometheus và Grafana đã nói cách đo tỷ lệ thử đạt, cách đặt nhãn metric và cách cảnh báo. Bài đó cũng nhắc chi tiết từng lần lỗi thuộc về log đã loại bí mật. Bài này đi tiếp đúng phần đó: đưa log vào Loki, đặt label sao cho Loki không phình, và viết truy vấn LogQL cho ba câu hỏi trực ca.
Bài không lặp cấu hình Prometheus rồi đổi tên thành Loki. Cấu hình ở đây là Loki, Grafana Alloy và LogQL. Việc làm sạch log, xóa mật khẩu proxy trước khi gửi đi được dành cho một bài riêng về Vector, ở đây chỉ nhắc ranh giới.
Phạm vi kiểm thử
Máy lab là Windows 10, không có Docker hay WSL. ProxyVN tải gói loki-windows-amd64.exe.zip bản 3.7.9 phát hành ngày 20/10/2026 từ GitHub, kiểm SHA256 khớp tệp SHA256SUMS. Lệnh loki --version chạy được và in ra version 3.7.9, revision d3b4a2f7.
Lần chạy tiếp theo với các tệp tải ngoài bị chế độ tự động của môi trường làm việc chặn, nên Loki server không được khởi động. Mọi phần truy vấn trong bài được tính trước bằng script Python trên cùng tệp log mẫu. Kết quả trong bảng là kết quả của script, chưa phải kết quả Loki trả về. Cấu hình Loki và Alloy viết theo tài liệu chính thức đọc ngày 29/10/2026.
Đưa access log và error log vào Grafana Loki quản lý log proxy theo thời gian
Loki lưu log theo stream
Theo trang tổng quan của Loki, Loki chỉ đánh chỉ mục cho tập label của mỗi luồng log, không đánh chỉ mục nội dung dòng. Mỗi tổ hợp label khác nhau là một stream. Dòng log được nén thành các chunk và lưu vào kho đối tượng hoặc ổ đĩa.
Thiết kế này làm Loki rẻ khi lưu nhiều log, đổi lại truy vấn phải chọn stream bằng label trước rồi mới lọc nội dung. Hiểu điều này thì mới đặt label đúng. Label là thứ để chọn nhóm log, còn chi tiết từng request nằm trong dòng log.
Định dạng log gateway trong lab
Lab dùng một định dạng logfmt do người viết đặt ra cho gateway proxy nội bộ. Mỗi dòng có thời điểm, mức log, tên gateway, IP worker, đích CONNECT, mã trạng thái, thời gian xử lý, số byte, mã lỗi và mã request. Dạng logfmt được chọn vì LogQL có sẵn parser logfmt, không cần viết biểu thức.
ts=1761720000 level=info proxy=gw-02 client=10.20.0.21 method=CONNECT target=shop109.example:443 status=200 dur_ms=605 bytes=19066 err=- req_id=447b125a10eb
ts=1761721815 level=warn proxy=gw-02 client=10.20.0.33 method=CONNECT target=shop12.example:443 status=407 dur_ms=4 bytes=0 err=auth_required req_id=1c0e5b9d77a2
ts=1761722040 level=error proxy=gw-01 client=10.20.0.17 method=CONNECT target=shop78.example:443 status=504 dur_ms=30000 bytes=0 err=upstream_timeout req_id=9a41f0c2be03
Nếu gateway là Squid hay Nginx, log có định dạng riêng. LogQL có parser pattern cho log dạng cột, ví dụ trong tài liệu là một dòng access log Nginx. Phần truy vấn bên dưới vẫn dùng được, chỉ đổi bước parser.
Ba nguồn log cần tách

Ba nguồn log, một kho chung
Một hệ crawler qua proxy thường có ba nguồn log. Log của gateway proxy ghi từng CONNECT và mã trả về. Log của worker ghi URL, lỗi thư viện như ProxyError hay ReadTimeout. Log của ứng dụng đích không có trong tay mình.
Nên gửi hai nguồn đầu vào Loki với label job khác nhau, ví dụ job="proxy-gw" và job="crawler". Khi cần nối một lỗi của worker với dòng tương ứng ở gateway, dùng req_id nếu worker gửi kèm, hoặc dùng IP worker và thời điểm.
Chuẩn bị phiên bản, tài khoản và môi trường kiểm thử Grafana Loki quản lý log proxy
Ghi phiên bản trước khi thử
Loki đổi cấu hình qua từng bản lớn, nhất là phần schema, chỉ mục và giữ log. Khi viết hướng dẫn nội bộ, nên ghi rõ ba con số: bản Loki, bản Alloy và bản Grafana. Ngày 29/10/2026, Loki mới nhất là 3.7.9, Alloy mới nhất là 1.21.3 phát hành ngày 28/10/2026.
Promtail không còn là lựa chọn cho hệ mới. Trang tài liệu Promtail ghi công cụ này hết vòng đời từ ngày 2/3/2026, mọi phát triển chuyển sang Grafana Alloy. Hệ đang chạy Promtail nên lập kế hoạch chuyển, tài liệu Alloy có công cụ đổi cấu hình bằng một lệnh.
Thư mục và cổng của lab
Lab đặt Loki nghe cổng 3100 trên localhost, Alloy đọc tệp log gateway ở một thư mục cố định. Không mở cổng Loki ra mạng ngoài trong bước thử. Cấu hình mẫu của Loki tắt xác thực bằng auth_enabled: false, chỉ hợp cho máy thử nghiệm.
- Tệp log mẫu: lab/t261_fixture.log, 6.001 dòng, trải trong một giờ.
- Ba gateway: gw-01, gw-02, gw-03, 30 IP worker, 120 đích.
- Một sự cố giả: gw-02 trả 407 dày đặc trong 5 phút từ giây thứ 1.800.
- Một dòng hỏng: dấu ngoặc kép không đóng, để thử nhánh lỗi parser.
Tài khoản và bí mật trong log
Log gateway trong lab không chứa mật khẩu proxy. Đó là điều kiện trước khi gửi log đi đâu. Nếu log đang chứa chuỗi kiểu http://user:pass@host:port, header Proxy-Authorization hay API key trong URL, phải làm sạch ở tầng thu gom trước. Loki không tự che bí mật.
Một khi bí mật đã vào Loki, xóa lại không đơn giản. Loki có API xóa theo truy vấn, nhưng còn bản sao trong bộ nhớ đệm, bản sao lưu và màn hình người đã xem. Che bí mật trước khi gửi rẻ hơn nhiều so với dọn sau khi lộ.
Cấu hình tối thiểu cho Grafana Loki quản lý log proxy và phạm vi từng thiết lập
Tệp cấu hình Loki cho một máy
Đoạn dưới dựa trên tệp loki-local-config.yaml trong kho mã Loki, thêm phần compactor để bật giữ log 7 ngày. Theo trang retention, mặc định log sống mãi nếu không bật retention_enabled. Khi bật, delete_request_store là bắt buộc.
auth_enabled: false
server:
http_listen_port: 3100
grpc_listen_port: 9096
common:
instance_addr: 127.0.0.1
path_prefix: C:/lab/loki
storage:
filesystem:
chunks_directory: C:/lab/loki/chunks
rules_directory: C:/lab/loki/rules
replication_factor: 1
ring:
kvstore:
store: inmemory
schema_config:
configs:
- from: 2026-10-01
store: tsdb
object_store: filesystem
schema: v13
index:
prefix: index_
period: 24h
compactor:
working_directory: C:/lab/loki/compactor
retention_enabled: true
delete_request_store: filesystem
limits_config:
retention_period: 168h
analytics:
reporting_enabled: false
Dòng analytics tắt việc gửi thống kê sử dụng ẩn danh về Grafana Labs. Chú thích trong tệp mẫu nói rõ mặc định Loki gửi thống kê này. Trong mạng nội bộ không ra Internet, tắt đi cho đỡ log lỗi.
Phạm vi của từng khối
- auth_enabled: false: một tenant duy nhất, không cần header X-Scope-OrgID. Hệ nhiều đội nên bật và đặt tenant theo đội.
- schema_config: kiểu chỉ mục tsdb, schema v13 như tệp mẫu. Ngày from đặt trước ngày đầu tiên của log.
- compactor và retention_period: xóa chunk cũ hơn 168 giờ. Tài liệu ghi compactor chạy mặc định mỗi 10 phút, retention chạy lệch đi để không trùng.
- path_prefix: thư mục chứa dữ liệu. Ổ đầy là lỗi vận hành hay gặp nhất của Loki một máy.
Grafana Alloy đọc tệp log
Alloy đọc tệp, tách trường bằng logfmt, gắn label tĩnh rồi đẩy sang Loki. Theo tài liệu thành phần loki.source.file, khối file_match là cách được khuyến nghị để theo dõi nhiều tệp theo mẫu đường dẫn. Thành phần loki.process có các bước logfmt, labels, structured_metadata và timestamp.
loki.source.file "proxy_gw" {
targets = [
{__path__ = "C:/lab/logs/gw-*.log", job = "proxy-gw", env = "lab"},
]
forward_to = [loki.process.proxy_gw.receiver]
file_match {
enabled = true
sync_period = "10s"
}
}
loki.process "proxy_gw" {
stage.logfmt {
mapping = { "ts" = "", "proxy" = "", "req_id" = "" }
}
stage.timestamp {
source = "ts"
format = "Unix"
}
stage.labels {
values = { host = "proxy" }
}
stage.structured_metadata {
values = { req_id = "" }
}
forward_to = [loki.write.local.receiver]
}
loki.write "local" {
endpoint {
url = "http://localhost:3100/loki/api/v1/push"
}
}
Chỉ tên gateway được đưa lên làm label host. Mã request đi vào structured metadata, tức dữ liệu kèm theo từng dòng mà không tạo stream mới. Trang structured metadata của Loki nói đây là chỗ cho giá trị nhiều biến thể mà vẫn hay cần lọc.
Gửi thẳng qua HTTP khi chưa có Alloy
Khi chỉ muốn thử nhanh, có thể đẩy log bằng API push của Loki. Thân JSON gồm danh sách streams, mỗi stream có label và mảng giá trị gồm thời điểm tính bằng nano giây cùng dòng log. Tài liệu ghi Loki kiểm chặt JSON, trường lạ sẽ bị trả 400.
curl -s -X POST http://localhost:3100/loki/api/v1/push ^
-H "Content-Type: application/json" ^
--data-raw "{\"streams\":[{\"stream\":{\"job\":\"proxy-gw\",\"host\":\"gw-02\",\"env\":\"lab\"},\"values\":[[\"1761720000000000000\",\"ts=1761720000 level=info proxy=gw-02 status=200\"]]}]}"
Script lab dựng payload cho dòng đầu tiên, dài 274 byte. Lệnh curl trên chưa chạy vì Loki server không khởi động được trong môi trường này. Dấu ^ là ký tự nối dòng của cmd trên Windows, trên Linux đổi thành dấu gạch chéo ngược.
Thiết kế label khi dùng Grafana Loki quản lý log proxy

Label ít, stream gọn
Số stream đo trên log mẫu
Đây là phần quan trọng nhất của bài. Script đếm số stream sinh ra nếu đưa từng trường lên làm label, giữ cố định job và env. Bảng dưới là kết quả chạy thật trên 6.000 dòng log hợp lệ.
Cách đặt label |
Số stream |
Nhận xét |
|---|---|---|
job, host |
3 |
Một stream cho mỗi gateway |
thêm status |
12 |
Bốn mã trạng thái nhân ba gateway |
thêm level |
9 |
Ba mức log nhân ba gateway |
thêm client (IP worker) |
90 |
30 worker nhân ba gateway |
thêm target |
360 |
120 đích nhân ba gateway |
thêm client và target |
4.613 |
Gần mỗi tổ hợp một stream |
thêm req_id |
6.000 |
Mỗi dòng một stream |
Log chỉ có một giờ và 6.000 dòng mà req_id đã tạo 6.000 stream. Mỗi stream khi đó chỉ chứa một dòng, chunk gần như rỗng. Ngày thứ hai con số này lại cộng thêm, vì mã request không lặp lại.
Tài liệu Loki nói gì về label
Trang thực hành tốt về label khuyên dùng label tĩnh như vùng, cụm, máy, ứng dụng, môi trường. Label động nên ít giá trị, lý tưởng là vài chục. Trang này còn ví dụ label requestId có 24.653 giá trị trong 24.979 stream và gọi đó là trường hợp xấu.
Cùng trang đó nói ngay cả label level cũng đang được xem lại. Với ứng dụng lượng log vừa, truy vấn lọc chuỗi level=error nhanh không kém chọn label level. Lý do là label level chia log một ứng dụng thành nhiều stream, nhiều chunk nhỏ hơn.
Label là để chọn nhóm log. Thứ gì có thể là hàng nghìn giá trị khác nhau thì để trong dòng log hoặc structured metadata.
Quy tắc áp vào log proxy
- Nên làm label: job, env, host của gateway, vùng hoặc nhà cung cấp proxy nếu chỉ có vài giá trị.
- Không làm label: IP worker, IP ra của proxy, đích, URL, mã request, tên tài khoản proxy.
- Cân nhắc structured metadata: req_id, mã phiên, mã worker khi cần lọc nhanh theo giá trị cụ thể.
- Để trong dòng log: status, err, dur_ms, bytes. LogQL tách được lúc truy vấn bằng logfmt.
IP ra của proxy xoay là ví dụ dễ sai. Một pool xoay có thể đổi IP mỗi request, nên số giá trị không có giới hạn. Đưa nó lên label thì Loki phình giống trường hợp req_id.
Khi nào mới thêm label động
Tài liệu label của Loki đưa ra một mốc để cân nhắc. Với chunk_target_size đặt 1MB, Loki cắt chunk ở khoảng 1MB sau nén, tương đương chừng 5MB log chưa nén. Nếu một stream ghi được lượng đó nhanh hơn max_chunk_age, việc tách stream bằng một label động mới có lợi.
Log gateway proxy của một hệ crawler vừa và nhỏ hiếm khi đạt mức đó trên mỗi gateway. Nghĩa là phần lớn đội nên dừng ở label host. Khi lượng log tăng hẳn, đo lại bằng metric loki_ingester_chunks_flushed_total theo lý do flush, như tài liệu gợi ý, rồi mới quyết.
Kiểm stream sau khi chạy thật
Tài liệu label gợi ý lệnh logcli series kèm cờ --analyze-labels để xem label nào nhiều giá trị. Chạy lệnh này sau ngày đầu tiên đưa log vào Loki, so với bảng ước tính ở trên. Nếu số stream lệch xa, có label động lọt vào từ phía Alloy.
set LOKI_ADDR=http://localhost:3100
logcli series --analyze-labels "{job=\"proxy-gw\"}"
Truy vấn LogQL tìm lỗi xác thực và timeout trong Grafana Loki quản lý log proxy
Cấu trúc một truy vấn LogQL
Theo tài liệu truy vấn log, một truy vấn gồm bộ chọn stream trong ngoặc nhọn và một chuỗi bước xử lý. Bước lọc dòng dùng |= cho chuỗi con, |~ cho biểu thức chính quy, != và !~ cho phủ định. Bước parser như logfmt hay json tách trường thành label tạm thời. Bước lọc label so sánh giá trị đã tách.
Thứ tự nên là lọc chuỗi trước, parser sau. Lọc chuỗi rẻ hơn tách trường, nên bỏ được nhiều dòng sớm thì truy vấn nhanh hơn. Tài liệu metric query có ví dụ dạng rate của json rồi lọc duration lớn hơn 10 giây.
Ba truy vấn cho người trực ca

Tìm gateway đang lỗi 407
Câu hỏi thứ nhất là lỗi 407 tăng ở gateway nào. Truy vấn đếm dòng có status 407 trong cửa sổ 5 phút, gộp theo host:
sum by (host) (
count_over_time({job="proxy-gw"} |= "status=407" | logfmt | status="407" [5m])
)
Câu hỏi thứ hai là đích nào hay timeout. Truy vấn lọc chuỗi err=upstream_timeout, tách logfmt, đếm theo target rồi lấy ba đích nhiều nhất:
topk(3,
sum by (target) (
count_over_time({job="proxy-gw"} |= "err=upstream_timeout" | logfmt [1h])
)
)
Câu hỏi thứ ba là request thành công chậm cỡ nào. Truy vấn dùng unwrap để lấy dur_ms làm giá trị số, tính phân vị 95 theo gateway:
quantile_over_time(0.95,
{job="proxy-gw"} | logfmt | status="200" | unwrap dur_ms [1h]
) by (host)
Trường target chỉ là label tạm sinh ra lúc truy vấn, không làm tăng số stream lưu trữ. Đó là lý do để target trong dòng log mà vẫn gộp theo nó được.
Kết quả script tính trước
Truy vấn |
Kết quả script trên log mẫu |
|---|---|
407 theo gateway, cửa sổ sự cố |
gw-02: 41, gw-03: 7, gw-01: 5 |
407 theo gateway, cửa sổ bình thường |
gw-03: 15, gw-01: 6, gw-02: 6 |
Ba đích timeout nhiều nhất trong 1 giờ |
shop78: 5, shop93: 5, shop41: 4 |
p95 dur_ms của request 200 |
gw-01: 539,2; gw-02: 505,0; gw-03: 515,2 |
Dòng hỏng khi tách logfmt |
1 |
Ở cửa sổ sự cố, gw-02 nhảy từ 6 lên 41 lỗi 407 trong 5 phút, hai gateway còn lại giữ mức thường. Kết luận đúng là sự cố nằm ở cấu hình hoặc tài khoản của gw-02, không phải nhà cung cấp proxy chung. Một biểu đồ metric tổng tỷ lệ lỗi chỉ thấy đỉnh nhỏ, không chỉ ra gateway.
Xem dòng thô khi điều tra
Sau khi biết gw-02 là điểm nóng, bước tiếp theo là đọc vài dòng thô. Truy vấn log, không phải truy vấn metric, trả về dòng gốc. Bước line_format giúp in gọn các trường cần đọc, bỏ phần thừa.
{job="proxy-gw", host="gw-02"} |= "status=407" | logfmt
| line_format "{{.ts}} {{.client}} {{.target}} {{.err}} {{.req_id}}"
Nhìn danh sách IP worker trong kết quả sẽ biết lỗi đến từ mọi worker hay chỉ vài worker. Mọi worker cùng lỗi thì vấn đề nằm ở gateway. Chỉ vài worker lỗi thì kiểm cấu hình của chính các worker đó.
Dòng hỏng và nhãn __error__
Khi logfmt không tách được một dòng, LogQL không bỏ dòng đó mà gắn nhãn __error__. Tài liệu ghi chỉ phép so sánh chuỗi đọc được nhãn này, ví dụ | __error__="" để bỏ dòng lỗi, hoặc | __error__!="" để xem riêng. Nên có một panel đếm dòng lỗi parser, vì nó cho biết gateway vừa đổi định dạng log.
Chạy đối chứng, đọc kết quả và kiểm tra output Grafana Loki quản lý log proxy
Trình tự chạy khi có máy Linux hoặc Docker
Phần này là các bước ProxyVN đề nghị chạy khi có môi trường khởi động được Loki. Script Python ở trên cho con số đối chiếu. Nếu Loki trả khác, cần tìm nguyên nhân trước khi tin dashboard.
1. Khởi động Loki với tệp cấu hình ở trên, mở http://localhost:3100/ready và chờ chữ ready.
2. Khởi động Alloy với tệp cấu hình, xem trang giao diện của Alloy để chắc thành phần loki.source.file đã thấy tệp.
3. Chép t261_fixture.log vào thư mục logs với tên gw-lab.log, chờ Alloy đọc hết.
4. Chạy logcli series --analyze-labels, kỳ vọng ba stream với host gw-01, gw-02, gw-03.
5. Chạy ba truy vấn ở mục trên với khoảng thời gian bao trọn giờ log, so với bảng kết quả script.
6. Thêm label client vào Alloy ở một lần chạy riêng, đo lại số stream, kỳ vọng 90.
Đối chứng thời điểm
Log mẫu dùng thời điểm Unix của quá khứ. Loki có giới hạn chấp nhận log quá cũ, tài liệu stage.timestamp của Alloy cũng nhắc Loki có thể từ chối dòng nằm ngoài cửa sổ chấp nhận. Nếu Loki từ chối dòng vì quá cũ, có hai cách: đổi thời điểm trong log mẫu về giờ hiện tại, hoặc bỏ bước timestamp để Loki dùng giờ đọc.
Cách thứ hai làm toàn bộ 6.000 dòng dồn vào vài giây, các truy vấn cửa sổ 5 phút sẽ ra số khác. Muốn đối chiếu đúng bảng, nên giữ thời điểm gốc và dời cả tệp về khung giờ hiện tại.
Đọc kết quả như người trực ca
Một quy trình đọc đơn giản giúp không nhảy vào kết luận. Bước đầu xem tổng dòng theo host để chắc log từ cả ba gateway đều về. Bước hai xem lỗi theo nhóm err. Bước ba mới đi vào đích hay worker cụ thể.
- Chỉ một gateway tăng 407: kiểm tài khoản proxy, tệp cấu hình hoặc bản cập nhật gần nhất của gateway đó.
- Cả ba gateway cùng tăng 407: tài khoản ở nhà cung cấp hết hạn, đổi mật khẩu, hoặc IP gateway không còn trong danh sách cho phép.
- Timeout tập trung vào vài đích: đích chậm hoặc đang chặn, không phải proxy hỏng.
- Timeout rải đều mọi đích: đường từ gateway ra nhà cung cấp có vấn đề.
Bài sửa lỗi 407 Proxy Authentication Required có các bước xử lý khi đã khoanh vùng xong. Còn timeout từ phía gateway xem thêm bài 504 Gateway Timeout.
Lỗi hay gặp khi dùng Grafana Loki quản lý log proxy
Bảng tra nhanh
Hiện tượng |
Nguyên nhân hay gặp |
Cách kiểm |
|---|---|---|
Truy vấn chậm dù ít log |
Quá nhiều stream nhỏ |
logcli series --analyze-labels |
Loki báo too many outstanding requests |
Truy vấn khoảng thời gian dài, không lọc chuỗi |
Thêm bộ lọc dòng trước parser |
Không thấy log mới |
Alloy chưa đọc tệp hoặc sai đường dẫn |
Xem trang giao diện Alloy |
Dòng bị từ chối vì thời điểm |
Log quá cũ hoặc lệch giờ |
Kiểm đồng hồ máy và bước timestamp |
Đếm 407 ra 0 |
Sai tên trường hoặc định dạng khác |
Xem một dòng thô rồi sửa parser |
Ổ đĩa đầy |
Chưa bật retention |
Kiểm compactor.retention_enabled |
Đếm sai vì lọc chuỗi quá rộng
Bộ lọc |= "407" khớp cả dòng có dur_ms=407 hay bytes=14070. Trên log thật, con số đếm sẽ cao hơn thực tế. Cách an toàn là lọc chuỗi cụ thể |= "status=407" để loại nhanh, rồi lọc lại bằng label status="407" sau logfmt.
Trong truy vấn đầu tiên ở trên có cả hai bước vì lý do này. Bước đầu giảm số dòng phải tách, bước sau đảm bảo đúng nghĩa.
Gộp theo label tạm làm tăng series kết quả
Truy vấn metric gộp theo target sẽ trả về một series cho mỗi đích. Với 120 đích thì ổn, với 50.000 đích thì panel Grafana sẽ nặng. Nên dùng topk như truy vấn thứ hai, hoặc gộp theo tên miền gốc thay vì đích đầy đủ.
Nhầm log với metric
Đếm lỗi bằng count_over_time trên log là đếm dòng. Nếu gateway ghi hai dòng cho một request, con số sẽ gấp đôi. Với tỷ lệ lỗi dùng để cảnh báo, metric đo từ gateway vẫn là nguồn chính. Log dùng để giải thích vì sao metric đổi.
Gỡ cấu hình thử, quản lý bí mật và checklist Grafana Loki quản lý log proxy
Gỡ môi trường thử
Sau khi đối chiếu xong, dừng Alloy trước để không còn gì đẩy vào Loki, rồi dừng Loki. Xóa thư mục C:/lab/loki nếu không cần giữ dữ liệu thử. Xóa tệp log mẫu khỏi thư mục logs để lần chạy sau không đọc lại.
Nếu đã thêm nguồn dữ liệu Loki trong Grafana để thử, xóa nguồn đó hoặc đổi tên rõ là lab. Dashboard thử nên để trong thư mục riêng, tránh người trực ca nhầm với dashboard thật.
Bí mật và quyền truy cập
- Không để Loki nghe trên địa chỉ public khi auth_enabled đang false.
- Hệ nhiều đội: bật auth_enabled, đặt tenant theo đội, đặt Loki sau reverse proxy có xác thực.
- Log gửi đi không chứa mật khẩu proxy, token, cookie phiên. Kiểm bằng truy vấn tìm chuỗi :// có dấu @ phía sau.
- Retention theo chính sách dữ liệu của công ty, không để mặc định sống mãi.
Truy vấn tìm dấu hiệu lộ tài khoản proxy trong log có thể viết như sau. Kết quả nên là 0. Nếu khác 0, sửa ở tầng thu gom rồi xóa dữ liệu đã lộ theo quy trình của đội.
sum(count_over_time({env="lab"} |~ "[a-z0-9]+://[^/ ]+:[^/ ]+@" [24h]))
Checklist trước khi dùng thật
- Đã ghi bản Loki, Alloy, Grafana và ngày thử.
- Label chỉ gồm job, env, host và vài giá trị cố định khác.
- Đã chạy logcli series --analyze-labels, số stream khớp ước tính.
- Ba truy vấn 407, timeout, p95 ra số khớp script trên log mẫu.
- Có panel đếm dòng lỗi parser.
- Đã bật retention và kiểm dung lượng ổ.
- Truy vấn tìm tài khoản trong URL trả 0.
- Có ghi chú phân biệt log và metric cho người trực ca.
Nguồn proxy cho hệ crawler khi dùng Grafana Loki quản lý log proxy
Log tốt giúp tách lỗi của mình và lỗi của nguồn
Khi log đủ rõ, đội vận hành tách được ba loại lỗi: cấu hình phía mình, giới hạn của đích và sự cố của nhà cung cấp proxy. Chỉ loại thứ ba mới cần liên hệ nhà cung cấp, kèm khoảng thời gian, gateway và mã lỗi cụ thể. Có số liệu thì trao đổi nhanh hơn nhiều so với báo chung chung là proxy lỗi.
ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay, hỗ trợ HTTP và SOCKS5, cấp tài khoản user và mật khẩu. Anh em cần nguồn ổn định cho gateway có thể mua proxy tại trang chủ ProxyVN rồi gắn log như hướng dẫn ở trên.
Proxy không thay việc đọc log
Đổi proxy không sửa được lỗi 407 do mình cấu hình sai, cũng không làm đích hết chặn. Proxy chỉ là một chặng trong đường đi. Log ở gateway giúp biết chặng nào đang có vấn đề trước khi quyết định đổi gì.
Câu hỏi thường gặp về Grafana Loki quản lý log proxy
Có nên dùng Loki thay Elasticsearch cho log proxy không?
Loki rẻ hơn khi lưu nhiều log vì không đánh chỉ mục nội dung, nhưng tìm toàn văn tự do chậm hơn. Log proxy có cấu trúc cố định và truy vấn theo thời gian, nên hợp với Loki. Nếu đội cần tìm kiếm toàn văn phức tạp thì cân nhắc lại.
Alloy có chạy trên Windows không?
Alloy có bản cho Windows và có thành phần đọc Windows Event Log. Đường dẫn trong cấu hình dùng dấu gạch chéo xuôi như ví dụ trên. Bài chưa chạy Alloy thật.
Có cần Grafana để dùng Loki?
Không bắt buộc. logcli và API HTTP truy vấn được trực tiếp. Grafana giúp dựng dashboard và chuyển từ biểu đồ metric sang log cùng khoảng thời gian.
Log của worker Python nên gửi thế nào?
Ghi log ra tệp dạng logfmt hoặc JSON rồi để Alloy đọc, như log gateway. Tránh để thư viện ghi URL proxy có tài khoản vào thông báo lỗi. Bài requests.exceptions.ProxyError có ví dụ thông báo lỗi của requests.
Giới hạn của bài
Bài chưa chạy Loki server, Alloy và Grafana. Loki 3.7.9 chỉ được xác nhận bằng lệnh --version. Mọi con số truy vấn đến từ script Python trên log mẫu tự sinh. Chưa thử log Squid, Nginx thật, chưa thử nhiều tenant, chưa đo hiệu năng.
Kế hoạch mở rộng sau khi Grafana Loki quản lý log proxy chạy ổn

Checklist Loki cho log proxy
Cảnh báo từ log
Loki có ruler để chạy truy vấn LogQL định kỳ và gửi cảnh báo qua Alertmanager, như dòng alertmanager_url trong tệp cấu hình mẫu. Truy vấn 407 theo host ở trên dùng được làm luật cảnh báo, ví dụ vượt 20 dòng trong 5 phút. Nên giữ cảnh báo chính ở metric và chỉ dùng cảnh báo log cho trường hợp metric không đo được.
Nối log với trace
Khi worker có trace ID, đưa trace ID vào structured metadata như req_id. Grafana cho phép nhảy từ một dòng log sang trace tương ứng nếu cấu hình liên kết dữ liệu. Phần trace thuộc một bài riêng về OpenTelemetry.
Lưu log lâu hơn
Lưu log trên ổ đĩa một máy chỉ hợp cho lab và hệ nhỏ. Hệ lớn hơn dùng kho đối tượng như S3 hoặc MinIO trong khối storage của Loki. Thay đổi này không ảnh hưởng tới label hay truy vấn, nên làm đúng phần label ngay từ đầu là quan trọng nhất.
Grafana Loki quản lý log proxy và những điều cần nhớ
Grafana Loki quản lý log proxy chạy tốt khi label chỉ gồm vài giá trị cố định như job, env, host, còn IP, đích và mã request nằm trong dòng log hoặc structured metadata. Lọc chuỗi trước, tách logfmt sau, đối chiếu với script trước khi tin dashboard. Cần nguồn ổn định cho Grafana Loki quản lý log proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.