OpenTelemetry truy vết request qua proxy: span, retry và log

OpenTelemetry truy vết request qua proxy là cách gắn mỗi tác vụ crawl với một mã trace, để mọi lần thử HTTP, mọi lần chờ và mọi dòng log của tác vụ đó gom về một chỗ. Khi crawler báo một URL thất bại, anh em mở trace ra là thấy nó đã thử mấy lần, mỗi lần mất bao lâu và lỗi gì. ProxyVN chạy lab OpenTelemetry SDK 1.45.1 với thư viện requests qua một proxy có xác thực. Lab tạo bốn tác vụ có chủ đích thành công, chập chờn, chậm và chết, rồi soi từng span để xem cái gì được ghi và cái gì bị lộ.

OpenTelemetry truy vết request qua proxy: tác vụ cụ thể và ranh giới với bài đã có

Bài này giải một việc: biến log rời rạc của crawler thành chuỗi có cấu trúc cho mỗi tác vụ. Một tác vụ crawl thường gồm nhiều request, có khi qua nhiều proxy, có thử lại. Log dòng theo thời gian trộn lẫn các tác vụ chạy song song, rất khó lần lại.

Trace, span và thuộc tính

Trace là một chuỗi việc có chung một mã định danh 32 ký tự hex. Span là một bước trong chuỗi, có thời điểm bắt đầu, kết thúc, trạng thái và thuộc tính. Span có thể lồng nhau: span cha cho tác vụ, span con cho từng request HTTP.

Thuộc tính là cặp khóa và giá trị gắn vào span, như mã tác vụ, URL hay mã trạng thái HTTP. Event là mốc thời gian bên trong span, như một lần thử hay một ngoại lệ. Toàn bộ dữ liệu này được xuất ra một nơi lưu trữ để xem lại.

Vì sao crawler qua proxy cần trace

Crawler qua proxy có nhiều lớp có thể chậm hoặc lỗi: kết nối tới proxy, proxy xác thực, proxy mở kết nối ra trang đích, trang đích xử lý. Log thường chỉ ghi lỗi cuối. Trace ghi từng lần thử với thời gian riêng, nên thấy được lần nào chậm và chậm bao nhiêu.

Khi chạy trên nhiều proxy, trace còn cho phép lọc theo proxy: tất cả tác vụ đi qua proxy A có tỷ lệ lỗi bao nhiêu, thời gian trung bình bao nhiêu. Đây là cách tìm proxy kém mà không cần dựng bảng điều khiển riêng.

Trace giúp trả lời những câu hỏi nào

Câu hỏi thứ nhất: vì sao tác vụ này mất 30 giây trong khi trung bình chỉ 2 giây. Trace cho thấy ngay tác vụ đó có năm lần thử, bốn lần đầu hết thời gian chờ. Không cần đoán.

Câu hỏi thứ hai: lỗi tập trung ở proxy nào. Lọc trace theo nhãn proxy và trạng thái lỗi, đếm số trace của mỗi proxy. Proxy có tỷ lệ trace lỗi cao hơn hẳn các proxy còn lại là ứng viên cần thay. Bài proxy success rate có cách tính tỷ lệ thành công theo proxy.

Câu hỏi thứ ba: thử lại có đáng không. Đếm số tác vụ thành công ở lần thử thứ hai, thứ ba, thứ tư. Nếu gần như không có tác vụ nào thành công sau lần thử thứ ba, giảm số lần thử để tiết kiệm thời gian và băng thông proxy.

Ranh giới với bài giám sát bằng Prometheus

Bài giám sát proxy bằng Prometheus và Grafana nói về metric: số request mỗi phút, tỷ lệ lỗi, độ trễ trung bình, cảnh báo khi vượt ngưỡng. Metric cho biết hệ thống đang khỏe hay không.

Trace trả lời câu hỏi khác: tác vụ cụ thể này đã đi qua những bước nào. Khi metric báo tỷ lệ lỗi tăng, trace giúp mở từng tác vụ lỗi ra xem. Bài này không dựng bảng điều khiển metric, chỉ đi vào trace, span, retry và nối log.

Metric cho biết có bao nhiêu tác vụ lỗi, trace cho biết từng tác vụ lỗi như thế nào.

Dùng trace để nối một tác vụ crawl với các request HTTP và các lần thử lại khi OpenTelemetry truy vết request qua proxy

Thiết kế trace quyết định trace có hữu ích hay không. Phần này đi qua cách chia span, nhãn nào gắn ở đâu và nhãn nào không bao giờ được gắn.

Một tác vụ là một trace

Mỗi tác vụ crawl mở một span gốc, đặt tên cố định như crawl.job. Mọi request HTTP bên trong tác vụ thành span con tự động nhờ thư viện instrumentation cho requests. Các lần thử lại là các span con nối tiếp dưới cùng span gốc.

Cách này cho mỗi tác vụ một trace riêng. Mở trace là thấy ngay số lần thử, thời gian từng lần và kết quả cuối. Nếu thiết kế ngược lại, mỗi request một trace, sẽ mất liên kết giữa các lần thử của cùng một URL.

Nhãn nên gắn ở span gốc

Span gốc và span con

Span gốc mang những thứ mô tả tác vụ: mã tác vụ, nhóm trang đích, mã proxy đã dùng, kết quả cuối. Mã proxy là một chuỗi ngắn do anh em đặt, như vn-dc-01 hay lab-a, không phải URL proxy.

Thư viện instrumentation cho requests không biết request đi qua proxy. Trong lab, span HTTP chỉ ghi URL trang đích, phương thức, user agent và mã trạng thái. Không có trường nào nói proxy nào được dùng. Muốn lọc theo proxy, anh em phải tự gắn nhãn proxy ở span gốc.

Thứ không bao giờ gắn vào span

URL proxy dạng http://user:pass@host:port chứa mật khẩu. Nếu gắn nguyên chuỗi này làm thuộc tính, mật khẩu sẽ nằm trong mọi trace và trong nơi lưu trữ trace, thường được nhiều người trong nhóm xem. Header Proxy-Authorization cũng vậy.

Trong lab, ProxyVN tìm chuỗi tên đăng nhập và mật khẩu proxy trong toàn bộ 16 span và 12 dòng log, không thấy lần nào. Lý do là mã lab chỉ gắn mã proxy, và thư viện instrumentation không ghi cấu hình proxy.

Đặt tên span ổn định

Tên span nên là loại việc, không phải dữ liệu cụ thể. crawl.job là tên tốt. crawl https://example.com/san-pham/123 là tên tồi, vì mỗi URL thành một tên span khác nhau và công cụ xem trace không gom nhóm được.

URL cụ thể, mã sản phẩm hay trang số mấy đặt vào thuộc tính. Thư viện instrumentation cho requests cũng theo nguyên tắc này: tên span HTTP chỉ là phương thức GET, URL nằm trong thuộc tính.

Retry thể hiện thế nào

Mỗi lần thử là một span HTTP riêng. Span gốc thêm một event attempt mang số thứ tự trước mỗi lần thử. Khi request ném ngoại lệ, span gốc ghi event exception kèm loại lỗi. Cuối cùng span gốc đặt trạng thái lỗi nếu hết lần thử.

Khoảng chờ giữa các lần thử hiện ra tự nhiên: là khoảng trống giữa span con trước và span con sau trên trục thời gian. Không cần ghi riêng.

Chuẩn bị phiên bản, thông tin proxy và môi trường thử để OpenTelemetry truy vết request qua proxy

Lab chạy ngày 29/10/2026 trên Windows 10, Python 3.12.10, môi trường ảo riêng với opentelemetry-api và opentelemetry-sdk 1.45.1, opentelemetry-instrumentation-requests 0.66b1, requests 2.34.2.

Không dùng collector

Hệ thống thật thường gửi span tới OpenTelemetry Collector qua giao thức OTLP, rồi collector chuyển tới nơi lưu như Jaeger, Tempo hay dịch vụ đám mây. Máy lab không chạy collector. Thay vào đó, lab dùng một exporter tự viết ghi mỗi span thành một dòng JSON vào tệp spans.jsonl.

Cách này đủ để kiểm nội dung span, quan hệ cha con và thuộc tính. Nó không kiểm việc gửi qua mạng, nén, lấy mẫu hay hàng đợi của collector. Khi chuyển sang thật, chỉ thay exporter, phần còn lại giữ nguyên.

Ba thành phần lab

Trang đích lab ở 127.0.0.1 cổng 9563 có ba loại đường dẫn: /ok trả 200 ngay, /flaky trả 503 cho hai lần đầu rồi 200, /slow ngủ 3 giây trước khi trả. Proxy HTTP lab ở cổng 9564 yêu cầu Basic auth với mật khẩu có ký tự @ và #.

Tác vụ thứ tư gọi tới cổng 9565, nơi không có gì lắng nghe, để mô phỏng trang đích chết phía sau proxy. Proxy lab là bản tối giản, khi không mở được kết nối ra ngoài nó không trả 502 mà để client chờ.

Vì sao chọn bốn tác vụ này

Bốn tác vụ phủ bốn kết quả hay gặp khi crawl qua proxy. Thành công ngay là ca chuẩn để đối chiếu. Chập chờn là ca trang đích bận tạm thời, thử lại thì được. Chậm là ca trang đích phản hồi lâu hơn timeout của client. Chết là ca không có gì phía sau proxy.

Hai ca cuối được chọn có chủ ý để xem trace có tách được chúng hay không. Đây là câu hỏi thực tế: khi crawler báo timeout hàng loạt, lỗi ở trang đích hay ở proxy.

Timeout của client

Mọi request đặt timeout dạng cặp: 2 giây cho kết nối, 1,5 giây cho đọc. Tác vụ /slow vì vậy sẽ hết thời gian đọc ở mọi lần thử, vì trang đích cần 3 giây. Mỗi tác vụ thử tối đa 4 lần.

Thông tin proxy nằm ở đâu

URL proxy có mật khẩu chỉ nằm trong biến của mã, truyền vào tham số proxies của requests. Không có dòng log hay thuộc tính span nào nhận chuỗi này. Với hệ thống thật, đọc từ biến môi trường hoặc kho bí mật.

Cấu hình tối thiểu và phạm vi từng thiết lập khi OpenTelemetry truy vết request qua proxy

Toàn bộ cấu hình nằm ở đầu script. Phần dưới bỏ phần dựng trang đích cho gọn.

Khởi tạo provider, exporter và instrumentation

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor, SpanExporter, SpanExportResult
from opentelemetry.instrumentation.requests import RequestsInstrumentor
 
class FileExp(SpanExporter):
    def export(self, spans):
        with open("spans.jsonl", "a", encoding="utf-8") as f:
            for s in spans:
                f.write(s.to_json(indent=None) + "\n")
        return SpanExportResult.SUCCESS
 
prov = TracerProvider(resource=Resource.create({"service.name": "crawler-lab"}))
prov.add_span_processor(SimpleSpanProcessor(FileExp()))
trace.set_tracer_provider(prov)
RequestsInstrumentor().instrument()
tr = trace.get_tracer("crawl")

Bảng: Khởi tạo provider, exporter và instrumentation

Thành phần	Vai trò	Khi lên thật
Resource service.name	Tên dịch vụ gắn vào mọi span	Đặt tên crawler cụ thể
TracerProvider	Nơi tạo span	Giữ nguyên
SimpleSpanProcessor	Xuất span ngay khi kết thúc	Đổi sang BatchSpanProcessor
FileExp	Ghi span ra tệp	Đổi sang OTLP exporter
RequestsInstrumentor	Tự tạo span cho mỗi request	Giữ nguyên, cân nhắc excluded_urls

SimpleSpanProcessor xuất từng span đồng bộ, làm chậm ứng dụng khi nhiều span. Tài liệu instrumentation Python của OpenTelemetry dùng BatchSpanProcessor cho môi trường thật, gom span theo lô và xuất ở luồng nền.

Nối log với trace

class Ctx(logging.Filter):
    def filter(self, r):
        c = trace.get_current_span().get_span_context()
        r.trace_id = format(c.trace_id, "032x") if c.is_valid else "-"
        return True
 
h = logging.FileHandler("app.log", "w", encoding="utf-8")
h.addFilter(Ctx())
h.setFormatter(logging.Formatter("%(asctime)s trace=%(trace_id)s %(message)s"))

Bộ lọc này đọc span hiện tại và chèn trace_id vào mỗi dòng log. Dòng log nào ghi trong lúc tác vụ đang chạy sẽ mang mã trace của tác vụ đó. Tìm mã trace trong tệp log là ra mọi dòng liên quan.

Hàm tác vụ

def crawl(job, url, proxy_id):
    with tr.start_as_current_span("crawl.job") as sp:
        sp.set_attribute("crawl.job_id", job)
        sp.set_attribute("proxy.id", proxy_id)
        for n in range(4):
            sp.add_event("attempt", {"n": n})
            try:
                r = requests.get(url, proxies=P, timeout=(2, 1.5))
                log.info("job=%s try=%d status=%d", job, n, r.status_code)
                if r.status_code == 503:
                    time.sleep(0.2 * 2 ** n); continue
                sp.set_attribute("crawl.result", "ok"); return
            except requests.RequestException as e:
                log.info("job=%s try=%d loi=%s", job, n, type(e).__name__)
                sp.record_exception(e)
        sp.set_status(trace.StatusCode.ERROR, "het lan thu")
        sp.set_attribute("crawl.result", "fail")

Thuộc tính proxy.id là nhãn do lab đặt, không phải quy ước chuẩn của OpenTelemetry. Anh em có thể đặt tên khác, miễn thống nhất trong toàn hệ thống để lọc được.

Chạy đối chứng, đọc log và kiểm output khi OpenTelemetry truy vết request qua proxy

Script chạy bốn tác vụ nối tiếp, mỗi tác vụ một kiểu kết quả. Tổng cộng tệp spans.jsonl có 16 span và tệp app.log có 12 dòng.

Bảng kết quả theo tác vụ

Bảng: Bảng kết quả theo tác vụ

Tác vụ	Đường dẫn	Số span HTTP	Kết quả từng lần	Trạng thái span gốc	Thời gian span gốc
j1	/ok/1	1	200	UNSET, kết quả ok	0,006 giây
j2	/flaky/2	3	503, 503, 200	UNSET, kết quả ok	0,645 giây
j3	/slow/3	4	ReadTimeout cả 4 lần	ERROR, kết quả fail	6,091 giây
j4	cổng 9565 chết	4	ReadTimeout cả 4 lần	ERROR, kết quả fail	6,131 giây

Mỗi span HTTP đều có span cha là span gốc của tác vụ, cùng mã trace. Bốn tác vụ cho bốn mã trace khác nhau. Không có span HTTP nào mồ côi.

Hai span 503 của j2 mang trạng thái ERROR. Thư viện instrumentation đặt trạng thái lỗi cho span client khi mã trả về từ 500 trở lên. Span gốc của j2 vẫn UNSET vì cuối cùng tác vụ thành công.

Thuộc tính của span HTTP

Span HTTP có bốn thuộc tính: http.method, http.url, user_agent.original và http.status_code khi có phản hồi. Đây là bộ tên theo quy ước cũ. Thư viện ở phiên bản này mặc định dùng tên cũ, muốn dùng tên mới như url.full phải bật biến môi trường OTEL_SEMCONV_STABILITY_OPT_IN.

Không có thuộc tính nào nói tới proxy. Span HTTP của j1 qua proxy trông giống hệt span HTTP đi thẳng. Nhãn proxy.id trên span gốc là cách duy nhất để biết tác vụ đi qua proxy nào.

Đọc một span trong tệp JSON

Mỗi dòng trong spans.jsonl là một span đầy đủ: tên, mã trace, mã span, mã span cha, thời điểm bắt đầu và kết thúc, trạng thái, thuộc tính, danh sách event và resource. Span gốc có mã span cha rỗng. Span HTTP có mã span cha trùng mã span của span gốc.

Để kiểm quan hệ cha con, chỉ cần nhóm span theo mã trace rồi xem mỗi nhóm có đúng một span không có cha. Script đọc lab làm đúng việc này và in ra mỗi span một dòng gồm tên, sáu ký tự cuối của mã trace, mã span, mã cha, trạng thái, thuộc tính và thời gian. Bảng kết quả ở trên dựng từ đầu ra đó.

Event exception trong span chứa loại ngoại lệ, thông báo và stack trace. Với lỗi kết nối qua proxy, thông báo ngoại lệ của requests đôi khi chứa địa chỉ proxy. Trong lab, thông báo ReadTimeout có địa chỉ trang đích và timeout, không có mật khẩu proxy, nhưng nên kiểm lại với từng loại lỗi khi lên thật.

Hai lỗi giống nhau ở client, khác nhau ở bản chất

Hai timeout trông giống nhau

Tác vụ j3 và j4 có trace gần như giống hệt: bốn span HTTP lỗi, mỗi span khoảng 1,5 giây, ngoại lệ ReadTimeout. Nhưng nguyên nhân khác hẳn. j3 là trang đích chậm, trả lời sau 3 giây. j4 là trang đích không tồn tại, proxy lab không trả lỗi mà để client chờ.

Trace phía client không tách được lỗi của trang đích với lỗi của proxy khi cả hai biểu hiện thành timeout. Muốn tách, cần log hoặc trace từ phía proxy, hoặc proxy phải trả mã lỗi rõ như 502 và 504. Bài 504 Gateway Timeout giải thích proxy nên trả mã nào trong ca này.

Nối log theo trace_id

Mười hai dòng log chia thành bốn nhóm theo mã trace. Nhóm j2 có ba dòng: try=0 status=503, try=1 status=503, try=2 status=200, cùng mã trace kết thúc bằng f1829d. Mở trace với mã đó trong công cụ xem trace là thấy đúng ba span HTTP tương ứng.

Thời điểm trong log và thời điểm span khớp nhau trong vài mili giây. Khoảng cách giữa try=0 và try=1 của j2 là 0,2 giây, đúng khoảng chờ lab đặt. Khoảng giữa try=1 và try=2 là 0,44 giây, gồm 0,4 giây chờ cộng thời gian request.

Thứ được gửi tới trang đích

Traceparent lọt tới trang đích

Phép thử phụ trong lab cho một kết quả quan trọng: thư viện instrumentation tự chèn header traceparent vào mọi request đi ra. Định dạng header theo chuẩn W3C Trace Context. Request qua proxy tới trang đích vẫn mang header này. Trang đích nhận được dòng dạng 00, mã trace, mã span, cờ.

Với crawler, điều này có nghĩa trang đích có thể thấy request đến từ hệ thống có truy vết, và có thể nối các request cùng một trace với nhau. Header traceparent còn là một dấu hiệu nhận diện crawler, khác với trình duyệt thông thường.

Theo tài liệu gói instrumentation requests, khi bật lại instrumentation với excluded_urls chứa đường dẫn trang đích, request tới đường dẫn đó không còn header traceparent và cũng không có span. Đây là cách tắt truy vết cho từng nhóm URL.

URL có thông tin đăng nhập

Phép thử phụ thứ hai gửi request tới URL trang đích có dạng apiuser:secret123@host. Thuộc tính http.url ghi lại thành REDACTED:[email protected]:9568/b, tức thư viện đã che phần đăng nhập. Nhưng header Authorization kiểu Basic vẫn được gửi tới trang đích như bình thường, không liên quan tới trace.

Việc che này chỉ áp cho URL trang đích. Cấu hình proxy không đi qua thuộc tính nào nên không cần che. Nếu anh em tự gắn URL proxy làm thuộc tính, thư viện sẽ không che giúp.

Gỡ cấu hình thử, quản lý bí mật và checklist khi OpenTelemetry truy vết request qua proxy

Checklist OpenTelemetry

Sau khi lab cho kết quả, phần còn lại là chuyển cấu hình thử sang thật mà không mang theo rủi ro.

Thay exporter và processor

Đổi FileExp sang OTLP exporter gửi tới collector, đổi SimpleSpanProcessor sang BatchSpanProcessor. Đặt endpoint collector qua biến môi trường OTEL_EXPORTER_OTLP_ENDPOINT thay vì ghi trong mã.

Nếu crawler chạy sau proxy công ty để ra Internet, chú ý: exporter gửi span tới collector cũng là một request HTTP hoặc gRPC. Nếu biến HTTP_PROXY được đặt toàn cục, exporter có thể gửi span qua proxy crawl. Thêm địa chỉ collector vào NO_PROXY để span đi thẳng. Bài no_proxy là gì có cách đặt.

Chặn traceparent tới trang đích

Có ba cách. Cách thứ nhất là excluded_urls như lab, hợp khi biết trước nhóm trang đích. Cách thứ hai là xóa header traceparent trong hook request_hook của instrumentation trước khi gửi. Cách thứ ba là không dùng instrumentation tự động, tự tạo span bằng tay quanh lời gọi requests.

Cách thứ ba cho kiểm soát cao nhất, đổi lại phải tự ghi mã trạng thái và thời gian. Với crawler gọi trang bên ngoài, ProxyVN nghiêng về cách thứ hai hoặc thứ ba, vì không có lý do gì để trang đích nhận mã trace nội bộ.

Truyền ngữ cảnh qua hàng đợi

Nếu tác vụ crawl được gửi qua hàng đợi như Celery hay RabbitMQ, trace có thể bắt đầu từ lúc gửi tác vụ chứ không phải lúc worker nhận. Thư viện instrumentation cho Celery chèn ngữ cảnh trace vào message và worker đọc ra, nên span của worker nối với span của bên gửi.

Cách này cho thấy cả thời gian tác vụ nằm chờ trong hàng đợi, thứ mà trace chỉ ở phía worker không thấy. Khi crawler chậm, phần chờ trong hàng thường lớn hơn phần gọi HTTP. Bài viết riêng về Celery của ProxyVN đi vào phần hàng đợi tác vụ crawl.

Lấy mẫu

Crawler chạy hàng triệu request mỗi ngày sẽ sinh hàng triệu span. Lưu hết tốn kém. Bộ lấy mẫu theo tỷ lệ giữ một phần trace, ví dụ 5%. Nhưng trace lỗi là thứ cần xem nhất, nên cân nhắc lấy mẫu ở collector theo trạng thái, giữ mọi trace lỗi và một phần trace thành công.

Khi nào span nên ghi nội dung phản hồi

Không nên ghi thân phản hồi HTML vào span. Span có giới hạn kích thước thuộc tính, và thân trang có thể chứa dữ liệu cá nhân. Nếu cần bằng chứng trang trả gì, lưu một bản băm của thân hoặc độ dài thân làm thuộc tính, còn nội dung để ở kho lưu trữ riêng.

Ngoại lệ là các phản hồi lỗi ngắn từ proxy, như dòng đầu của trang 407 hay 502. Vài chục ký tự đầu giúp phân biệt lỗi proxy với lỗi trang đích. Cắt ngắn và kiểm không có thông tin nhạy cảm trước khi ghi.

Thuộc tính độ dài thân trang còn giúp phát hiện trang bị chặn mềm: trang đích trả 200 nhưng thân chỉ vài trăm byte là trang thử thách hoặc trang báo lỗi. Lọc trace theo độ dài bất thường là cách tìm nhanh những tác vụ "thành công" nhưng không có dữ liệu.

Quản lý nhãn proxy

Đặt bảng ánh xạ từ mã proxy sang thông tin proxy ở một nơi riêng, chỉ worker đọc được. Trace và log chỉ mang mã. Khi cần biết mã proxy vn-dc-01 là máy nào, tra bảng đó.

Nếu dùng proxy xoay mà IP thoát đổi theo request, có thể gắn thêm nhãn phiên hoặc nhóm quốc gia. Không gắn IP thoát thật làm thuộc tính nếu chính sách nội bộ coi đó là thông tin cần bảo vệ.

Xem trace ở đâu

Jaeger và Grafana Tempo là hai công cụ mã nguồn mở hay dùng để lưu và xem trace. Cả hai nhận dữ liệu qua OTLP từ collector. Giao diện cho phép tìm trace theo thuộc tính, ví dụ proxy.id bằng vn-dc-01 và trạng thái lỗi, rồi mở từng trace thành biểu đồ thanh theo thời gian.

Với nhóm nhỏ, có thể bắt đầu bằng cách đơn giản như lab: ghi span ra tệp JSON và đọc bằng script. Khi số tác vụ lớn và nhiều người cần xem, chuyển sang công cụ chuyên dụng. Mã crawler không phải đổi, chỉ đổi exporter.

Giới hạn suy luận của bài

Lab không chạy collector, không gửi span qua mạng và không dùng công cụ xem trace. Span được đọc trực tiếp từ tệp JSON. Hành vi lấy mẫu, gửi theo lô và gRPC chưa được thử. Tên thuộc tính theo quy ước cũ là mặc định của phiên bản 0.66b1 ngày 29/10/2026 và có thể đổi ở phiên bản sau.

Proxy lab không trả 502 khi trang đích chết, nên trace j4 không phản ánh hành vi của proxy thương mại thường trả mã lỗi rõ ràng.

Checklist OpenTelemetry truy vết request qua proxy

• Một tác vụ crawl là một span gốc, request HTTP là span con.
• Gắn mã tác vụ, mã proxy và kết quả cuối ở span gốc.
• Không gắn URL proxy hay header xác thực vào span hoặc log.
• Ghi event cho mỗi lần thử, ghi ngoại lệ bằng record_exception.
• Chèn trace_id vào mọi dòng log.
• Chặn traceparent tới trang đích bên ngoài.
• Thêm địa chỉ collector vào NO_PROXY.
• Dùng BatchSpanProcessor và lấy mẫu giữ trace lỗi.

Khi đã có trace theo mã proxy, anh em sẽ thấy rõ proxy nào làm tác vụ chậm hoặc lỗi. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5; anh em có thể mua proxy tại trang chủ ProxyVN, gắn mỗi proxy một mã riêng rồi so trace theo từng mã.

Câu hỏi thường gặp về OpenTelemetry truy vết request qua proxy

Thư viện instrumentation có ghi địa chỉ proxy không?

Trong lab với phiên bản 0.66b1, không. Span HTTP chỉ ghi URL trang đích. Muốn biết proxy, tự gắn nhãn ở span gốc.

Có truy vết được bên trong proxy thương mại không?

Không, trừ khi nhà cung cấp hỗ trợ. Trace chỉ đi tới chỗ có mã instrumentation. Proxy thương mại là hộp đen, anh em chỉ đo được thời gian từ phía client.

aiohttp và httpx có instrumentation tương tự không?

Có gói instrumentation riêng cho từng thư viện. Cách gắn nhãn proxy ở span gốc và nối log giữ nguyên.

Trace có thay được log không?

Không nên thay hẳn. Log vẫn hữu ích cho thông tin chi tiết không hợp làm thuộc tính. Trace giúp gom log theo tác vụ qua trace_id.

Có nên gửi traceparent tới API nội bộ không?

Nên, nếu API nội bộ cũng dùng OpenTelemetry. Khi đó trace nối liền từ crawler tới API. Chỉ chặn với trang bên ngoài.

OpenTelemetry truy vết request qua proxy và những điều cần nhớ

OpenTelemetry truy vết request qua proxy gom mọi lần thử của một tác vụ crawl về một trace. Lab cho 16 span, 12 dòng log nối đúng theo trace_id, không lộ mật khẩu proxy, nhưng traceparent đi tới trang đích nếu không chặn. Gắn nhãn proxy ở span gốc, nối log, chặn header ra ngoài. Cần proxy ổn định để so sánh trace khi dùng OpenTelemetry truy vết request qua proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.