Audit log cho bot trading: hồ sơ để trả lời mọi câu hỏi về một lệnh sai

Sẽ có một ngày bạn nhìn vào lịch sử giao dịch và thấy một lệnh bạn không giải thích được. Khối lượng gấp ba lần bình thường. Vào lúc 2 giờ 47 phút sáng, thời điểm bạn không hề thiết kế để giao dịch. Và kết quả là một khoản lỗ lớn hơn mọi lệnh khác trong tháng.

Câu hỏi đầu tiên của bạn là: "tại sao?"

Và câu trả lời sẽ phụ thuộc vào một thứ duy nhất: bạn có ghi lại đủ dữ liệu để trả lời hay không. Không phải dữ liệu về bot nói chung — dữ liệu cụ thể về lệnh đó, tại thời điểm đó, với bộ tham số đó, ở phiên bản code đó.

Đây là chủ đề của bài này. Không phải "log để gỡ lỗi" — bài đó đã có. Đây là audit log: hồ sơ đủ để trả lời mọi câu hỏi về quá khứ, kể cả những câu hỏi bạn chưa biết là mình sẽ hỏi.

Phần đầu là bốn câu hỏi bắt buộc phải trả lời được và sáu loại bằng chứng cần giữ. Phần giữa là cấu trúc cụ thể của một dòng nhật ký lệnh, ba mức audit để bạn chọn theo quy mô, và nhật ký thay đổi tham số — loại hồ sơ hay bị thiếu nhất. Phần sau là vòng đời lưu trữ, cách xử lý khi log của bạn khác statement của sàn, và quy trình điều tra một lệnh sai.

1. Vì sao bạn cần hồ sơ, không chỉ cần log

Cần phân biệt hai thứ rất khác nhau:

Log là dữ liệu chi tiết, sinh ra liên tục, có vòng đời ngắn, dùng để chẩn đoán sự cố đang diễn ra. Log của MT5 bị xoay vòng theo ngày; log của EA nếu không dọn sẽ làm đầy ổ đĩa.

Hồ sơ (audit trail) là dữ liệu tổng hợp, sinh ra theo sự kiện, giữ lâu dài, dùng để giải thích quá khứ. Statement của sàn, danh sách nhật ký lệnh, nhật ký thay đổi tham số, hash của từng phiên bản EA.

Hai thứ này phục vụ hai mục đích khác nhau, và bạn cần cả hai. Sai lầm phổ biến là chỉ có log: khi sự cố xảy ra trong ngày, bạn chẩn đoán được; nhưng ba tháng sau, khi bạn muốn hiểu vì sao kết quả của một chiến lược xấu đi, log đã bị xoá và bạn chỉ còn con số trong statement — không có gì để giải thích.

Có một điểm cần thẳng thắn: bạn sẽ không xây audit log cho đến khi nó cứu bạn một lần. Hầu hết trader đều bắt đầu xây sau khi gặp một lệnh không giải thích được. Nhưng lúc đó, dữ liệu của sự việc vừa xảy ra đã mất — bạn xây để đối phó với những lần sau. Nếu bạn đọc được bài này trước lần đó, hãy coi đây là một khoản đầu tư có tỉ lệ hoàn vốn rất cao trong tương lai.

2. Bốn câu hỏi bắt buộc phải trả lời được

Câu 1 — Vì sao bot vào lệnh này? Câu trả lời cần là: tín hiệu nào kích hoạt, các giá trị đầu vào lúc đó là bao nhiêu, điều kiện nào đúng và điều kiện nào không. Không trả lời được bằng suy luận — chỉ trả lời được nếu EA đã ghi lại các giá trị đó ngay khi quyết định. Đây là lý do dòng log SIGNAL phải có số đo, không chỉ có chữ "buy".

Câu 2 — Vì sao khối lượng đó? Đây là câu hỏi bị bỏ qua nhiều nhất, và lại là câu hỏi tốn tiền nhất khi không trả lời được. Cần biết: công thức tính khối lượng, vốn dùng để tính, hệ số rủi ro được đặt là bao nhiêu, và khối lượng đã được chuẩn hoá theo VOLUME_STEP / VOLUME_MIN / VOLUME_MAX của symbol chưa. Rất nhiều lệnh sai khối lượng có nguyên nhân là tính toán dùng công thức của symbol này nhưng gửi lệnh cho symbol khác.

Câu 3 — Vì sao đúng lúc đó? Cần: thời điểm gửi, giá yêu cầu, giá khớp, độ trễ tính bằng mili giây, và tick cuối cùng trước khi gửi. Con số này phân biệt được "bot vào lệnh muộn 3 giây vì mạng chậm" với "bot vào lệnh muộn 20 phút vì EA bị treo rồi mới xử lý".

Câu 4 — Ai đã đổi cái gì, khi nào? Đây là câu khó trả lời nhất vì nó không liên quan tới giao dịch mà liên quan tới quá trình vận hành. Cần: phiên bản EA đang chạy (kèm hash của file), bộ tham số đang dùng, và người thay đổi. Nếu bạn sửa một tham số lúc 21 giờ tối và kết quả xấu đi từ 22 giờ, bạn cần ghép được hai sự kiện đó lại.

Điểm chung của cả bốn câu: câu trả lời phải là dữ liệu đã được ghi TRƯỚC, không phải suy luận SAU. Đây là nguyên tắc định nghĩa toàn bộ bài này. Mọi thứ bạn ghi sau khi sự việc xảy ra đều bị ảnh hưởng bởi kết quả bạn đã biết — và đó là loại bằng chứng vô giá trị nhất trong việc tìm ra lỗi thật.

3. Sáu loại bằng chứng cần giữ

Loại 1 — Log EA, ghi vào file riêng. Trả lời câu hỏi "bot đang nghĩ gì". Đây là thứ đã bàn ở bài về log; điểm cần nhấn ở đây là nó phải nằm trong file riêng theo ngày, để bạn tìm được chính xác khoảng thời gian cần tra.

Loại 2 — Log Trade của MT5. Trả lời "lệnh đã gửi, khớp, hay bị từ chối". Đây là nguồn đáng tin hơn log EA cho câu hỏi về giao dịch, vì nó do terminal ghi, không do EA của bạn ghi.

Loại 3 — Statement của sàn. Trả lời "kết quả thực tế cuối cùng là gì". Đây là nguồn sự thật duy nhất về mặt tài chính. Hãy tải định kỳ (hằng tuần hoặc hằng tháng) và lưu ở nơi khác ngoài VPS — vì đây là loại hồ sơ bạn cần giữ vĩnh viễn.

Loại 4 — Ảnh chụp cấu hình. File .set của EA, file profile của MT5, và cấu hình Scheduled Task. Trả lời "tham số lúc đó là gì". Một bộ .set được lưu ở mỗi lần thay đổi đáng kể là đủ; bạn không cần lưu mỗi ngày.

Loại 5 — File EA (`.ex5`) kèm hash. Trả lời "đang chạy đúng code nào". Đây là loại bằng chứng bị bỏ qua nhiều nhất. Cách làm: sau mỗi lần biên dịch, tính hash của file .ex5 (SHA-256) và ghi vào file nhịp hoặc nhật ký thay đổi. Khi cần, bạn đối chiếu hash để chắc chắn máy đang chạy đúng phiên bản.

Loại 6 — Nhật ký thay đổi (changelog). Trả lời "ai đổi gì, khi nào, vì sao". Đây là một file văn bản đơn giản, nhưng là loại hồ sơ duy nhất mà không thể tái tạo từ dữ liệu khác — vì lý do thay đổi nằm trong đầu bạn, không nằm trong máy.

Quy tắc vàng của cả sáu loại: bằng chứng chỉ có giá trị nếu nằm NGOÀI máy đã sinh ra nó. Log trên VPS chết cùng VPS. Statement tải về máy bạn thì tồn tại lâu dài. Đây là lý do việc sao lưu không phải là việc phụ — nó là một phần của định nghĩa "có hồ sơ".

4. Cấu trúc một dòng nhật ký lệnh

Đây là phần cụ thể nhất của bài. Một dòng nhật ký lệnh đầy đủ nên có cấu trúc sau, lưu dạng JSON Lines (mỗi dòng một JSON) hoặc CSV:

{
  "ticket": 3847291056,
  "gio_gui": 1757694538.412,
  "gio_khop": 1757694538.516,
  "do_tre_ms": 104,
  "tai_khoan": "1234567",
  "may": "VPS-A",
  "ea": "BotXAU",
  "ea_phien_ban": "3.1.2",
  "ea_hash": "b41f9c2e",
  "symbol": "XAUUSD",
  "loai_lenh": "buy",
  "khoi_luong": 0.10,
  "gia_yeu_cau": 2345.20,
  "gia_khop": 2345.28,
  "sl": 2338.00,
  "tp": 2360.00,
  "spread_luc_gui": 22,
  "tick_cuoi": 1757694537,
  "tin_hieu": {
    "ten": "ema_cross_h1",
    "ema_nhanh": 2344.91,
    "ema_cham": 2344.55,
    "atr": 3.42,
    "gia_dong_cua": 2345.10
  },
  "tinh_khoi_luong": {
    "cong_thuc": "risk_pct * equity / (sl_pips * pip_value)",
    "equity": 10240.55,
    "risk_pct": 0.5,
    "sl_pips": 72,
    "ket_qua_tho": 0.1038,
    "sau_chuan_hoa": 0.10
  },
  "ket_qua": "khop",
  "retcode": 10009,
  "lenh_dang_mo_sau_khi_vao": 1
}

Mười trường quan trọng nhất và lý do:

Ba trường trong bảng này đáng nói riêng:

`ea_hash`. Một chuỗi ngắn như b41f9c2e (8 ký tự đầu của SHA-256). Bạn tính hash sau mỗi lần biên dịch và cho EA đọc hash đó từ file cấu hình, hoặc ghi hash vào file nhịp. Không có trường này, câu hỏi "máy A có chạy đúng bản không" không có câu trả lời chắc chắn.

`tinh_khoi_luong`. Đây là trường làm cho việc điều tra lỗi khối lượng trở nên khả thi. Bạn ghi lại cả công thức dạng chuỗi và các giá trị trung gian. Khi có sự cố, thay vì tự tính lại (và có thể tính sai theo cùng một cách sai), bạn nhìn thấy chính xác bot đã tính gì.

`spread_luc_gui` và `tick_cuoi`. Hai trường này trả lời câu hỏi "bối cảnh thị trường lúc đó như thế nào" — thứ mà bạn không thể tái tạo lại ba tháng sau, vì dữ liệu tick chi tiết không còn.

Ghi đủ mười trường này không tốn nhiều: khoảng 600 byte một lệnh. Với bot vào 10 lệnh một ngày, một năm là khoảng 2 MB. Chi phí lưu trữ của hồ sơ đầy đủ gần như bằng không; chi phí của việc thiếu hồ sơ thì không.

5. Ba mức audit: chọn theo quy mô

Không phải ai cũng cần hồ sơ đầy đủ ngay từ đầu. Ba mức dưới đây để bạn chọn điểm bắt đầu.

Mức tối thiểu — "trả lời được câu hỏi về lệnh". Ghi theo thứ tự: ticket, gio_gui, symbol, loai_lenh, khoi_luong, gia_khop, sl, tp, retcode. Đây là những gì MT5 đã ghi trong tab Trade — bạn chỉ cần tải về và lưu ở nơi khác ngoài VPS. Mức này mất gần như không công và đã đủ để trả lời câu hỏi "lệnh này là gì".

Mức đủ dùng — "trả lời được vì sao". Thêm tin_hieu (các số đo của chỉ báo) và tinh_khoi_luong. Mức này đòi hỏi sửa EA để ghi thêm dữ liệu, nhưng đó là loại thay đổi nhỏ và an toàn: thêm PrintFormat hoặc ghi thêm file, không đổi logic giao dịch.

Mức đầy đủ — "tái hiện được quyết định". Thêm do_tre_ms, spread_luc_gui, tick_cuoi, ea_hash, ea_phien_ban, và lưu ảnh chụp .set mỗi lần thay đổi. Mức này cần bạn kỷ luật hơn trong việc ghi hash và lưu cấu hình, nhưng nó là mức duy nhất trả lời được câu 4 ("ai đã đổi cái gì").

Một lưu ý quan trọng về thứ tự triển khai: đừng bắt đầu ở mức đầy đủ. Hãy bắt đầu ở mức tối thiểu trong hôm nay (tải statement và bật ghi nhật ký lệnh cơ bản), rồi nâng lên mức đủ dùng trong tuần này. Mức đầy đủ có thể chờ tới khi bạn thật sự cần — vì nó đòi hỏi thay đổi quy trình, và quy trình là thứ khó duy trì nhất.

6. Nhật ký thay đổi tham số — thứ hay thiếu nhất

Trong sáu loại bằng chứng, đây là loại hay bị thiếu nhất và cũng là loại duy nhất không thể tái tạo từ dữ liệu khác. Bạn có thể tính lại hash của một file EA. Bạn có thể tải lại statement. Nhưng bạn không thể biết vì sao ba tuần trước bạn đổi ngưỡng spread từ 30 xuống 22.

Một nhật ký thay đổi đủ dùng chỉ cần bốn cột:

Cột cuối — "vì sao" — là cột quan trọng nhất và cũng là cột bạn sẽ muốn bỏ qua khi đang vội. Đừng bỏ. Không có nó, ba tháng sau bạn sẽ thấy một thay đổi và không biết đó là ý định hay là lỗi — và bạn sẽ không dám hoàn tác vì không biết hoàn tác có đúng hay không.

Hai thực hành cụ thể để duy trì nhật ký này:

Thứ nhất, ghi ngay, trong cùng ngày. Một thay đổi được ghi sau ba ngày thường mất lý do — vì lý do là thứ dễ phai nhất trong trí nhớ. Nếu bạn không ghi được lý do ngay, hãy ghi "chưa rõ lý do" chứ đừng bỏ trống.

Thứ hai, đặt nhật ký cùng chỗ với mã nguồn. Nếu bạn dùng Git cho mã EA (nên dùng), hãy để nhật ký thay đổi tham số là một file trong cùng repo. Bằng cách đó, mỗi lần bạn commit, thay đổi về code và thay đổi về tham số nằm cạnh nhau, cùng một mốc thời gian, dễ đối chiếu. Còn những thay đổi không nằm trong repo (ngưỡng cảnh báo, số chart) thì ghi vào file nhật ký riêng.

7. Vòng đời bằng chứng: lưu ở đâu, giữ bao lâu

Có một điểm dễ nhầm: log và hồ sơ có vòng đời khác nhau, và bạn phải đối xử với chúng khác nhau.

Ngay khi chạy. Log ghi liên tục, chi tiết tới từng tick. Giữ tại chỗ, chưa cần sao lưu. Đây là giai đoạn bạn muốn nhiều dữ liệu nhất để chẩn đoán.

Sau 7 ngày. MT5 bắt đầu xoay vòng log cũ. Bạn nên: giữ 30 ngày log gần nhất, và bắt đầu sao lưu ra ngoài VPS những sự kiện bất thường (lệnh bị từ chối, lỗi kết nối, khởi động lại) chứ không phải toàn bộ log.

Sau 30 ngày. Đây là mốc chuyển tiếp. Bạn nên: giữ bản tổng hợp theo ngày (số lệnh, lỗi, sự cố) và xoá log chi tiết từng tick. Lý do: log chi tiết của một tháng có thể lên hàng GB, nhưng tổng hợp theo ngày chỉ vài chục KB — và tổng hợp theo ngày mới là thứ bạn dùng để phát hiện xu hướng.

Sau 90 ngày. Giữ nhật ký lệnh (đã bỏ các trường chi tiết) và statement. Xoá log EA chi tiết. Đây là mốc hợp lý vì hầu hết việc điều tra xảy ra trong vòng ba tháng.

Vĩnh viễn. Giữ statement, nhật ký thay đổi, danh sách hash của các phiên bản EA, và nhật ký lệnh đã tổng hợp. Đây là hồ sơ, không phải log — và đây là phần bạn sẽ cần khi nhìn lại hiệu suất của một chiến lược sau nhiều năm.

Cách phân biệt đơn giản: log để chẩn đoán, hồ sơ để giải thích. Log trả lời "chuyện gì đã xảy ra tối qua". Hồ sơ trả lời "vì sao kết quả của tôi xấu đi từ tháng Sáu".

8. Khi log của bạn và statement của sàn khác nhau

Đây là tình huống bạn chắc chắn sẽ gặp, và nó là lý do quan trọng nhất để có nhiều nguồn bằng chứng.

Bốn nguyên nhân phổ biến của sự khác biệt, xếp theo mức độ thường gặp:

Nguyên nhân 1 — Lệnh đã tới sàn nhưng EA không nhận được phản hồi. Kết nối bị đứt sau khi lệnh đã gửi. Trong log của bạn, lệnh có thể hiện là thất bại (timeout); trên statement của sàn, lệnh đã khớp. Đây là trường hợp phổ biến nhất và cũng nguy hiểm nhất: bạn có thể gửi lại và tạo ra hai lệnh. Cách xử lý: trước khi gửi lại, luôn kiểm tra PositionsTotal và lịch sử lệnh gần nhất.

Nguyên nhân 2 — Chênh lệch múi giờ. Log của MT5 ghi theo giờ server (thường GMT+2 hoặc GMT+3), statement của sàn có thể ghi theo giờ khác, và giờ máy VPS của bạn có thể khác nữa. Ba đồng hồ khác nhau cho cùng một sự kiện. Cách xử lý: ghi rõ múi giờ trong mọi dòng nhật ký, và ghi cả hai mốc (TimeLocal và TimeCurrent) như đã bàn ở các bài trước.

Nguyên nhân 3 — Lệnh bị sàn sửa (partial fill, requote). Khối lượng khớp có thể nhỏ hơn khối lượng yêu cầu, hoặc giá khớp khác giá yêu cầu. Nếu bạn chỉ ghi "đã gửi 0.10", hồ sơ của bạn sẽ khác statement. Cách xử lý: luôn ghi cả khối lượng yêu cầu và khối lượng khớp thực tế từ kết quả trả về.

Nguyên nhân 4 — Lệnh bị đóng bởi công cụ khác. Sàn có thể đóng lệnh do margin (stop out), hoặc bạn đóng bằng tay trên điện thoại, hoặc một EA khác đóng. Log của EA bạn sẽ không biết. Cách xử lý: định kỳ đối chiếu số lệnh đang mở với kỳ vọng, và ghi lại mọi thay đổi bất thường.

Quy trình đối chiếu hằng tuần (10 phút): tải statement của sàn, so với nhật ký lệnh của bạn theo ticket. Ba kết quả có thể xảy ra: khớp hoàn toàn (bình thường), có trong statement mà không có trong nhật ký của bạn (nguyên nhân 1 hoặc 4), có trong nhật ký mà không có trong statement (lệnh chưa tới sàn — thường là lỗi kết nối). Đối chiếu mỗi tuần thì mỗi lần chỉ 10 phút; đối chiếu sau ba tháng thì mất cả buổi và thường không tìm ra.

9. Quy trình điều tra một lệnh sai

Bước 1 — Lấy mã lệnh (ticket). Từ MT5 hoặc từ statement của sàn. Luôn bắt đầu từ con số này, không bắt đầu từ khoảng thời gian.

Bước 2 — Tìm dòng nhật ký tương ứng. Tìm theo mã lệnh, không theo giờ. Lý do: một lệnh có thể bị gửi lại nhiều lần trong cùng một phút và bị từ chối vài lần trước khi khớp. Nếu bạn tìm theo khoảng thời gian, bạn sẽ chọn nhầm dòng — và kết luận sai từ bước này.

Bước 3 — Đối chiếu thời điểm và giá. So gio_gui, gia_yeu_cau, gia_khop với dữ liệu thị trường lúc đó. Bước này cho biết lệnh có bị trượt giá hay không, và trượt bao nhiêu.

Bước 4 — Kiểm tra phiên bản EA và bộ tham số. Dùng ea_hash và ea_phien_ban từ nhật ký, đối chiếu với nhật ký thay đổi. Bước này loại trừ khả năng "máy này đang chạy bản cũ".

Bước 5 — Kết luận vào một trong bốn nhóm. Đây là bước bạn phải kết luận, không được dừng ở "không rõ nguyên nhân":

• Lỗi code — logic EA làm sai điều nó được thiết kế để làm.
• Lỗi cấu hình — code đúng, nhưng tham số hoặc môi trường không đúng kỳ vọng (symbol sai hậu tố, ngưỡng sai, giờ server sai).
• Điều kiện thị trường — không có lỗi; thị trường diễn biến ngoài giả định (spread giãn, gap, thanh khoản thấp).
• Lỗi hạ tầng — mạng, VPS, hoặc sàn gây ra (chậm, mất dữ liệu, từ chối lệnh).

Việc phân loại này quan trọng vì bốn nhóm cần bốn cách xử lý khác nhau, và ba nhóm đầu không liên quan gì tới nhau. Nếu bạn kết luận "lỗi code" khi thật ra là "điều kiện thị trường", bạn sẽ sửa một thứ đang đúng — và có thể làm nó tệ đi.

Một lưu ý cuối về quy trình này: hãy ghi lại kết luận ngay khi điều tra xong. Sau một tuần, bạn sẽ nhớ mình đã điều tra, nhưng không nhớ chi tiết nào là quan trọng. Một dòng ngắn như "ticket 3847291: lỗi cấu hình — symbol EURUSD.pro nhưng .set dùng EURUSD" có giá trị hơn nhiều so với một phân tích dài mà bạn không ghi lại.

10. Riêng tư và an toàn: đừng để bằng chứng thành lỗ hổng

Hồ sơ audit chứa những thứ nhạy cảm, và bạn cần xử lý chúng như vậy:

Số tài khoản và số dư. Không cần thiết phải đưa vào log. Nếu cần để đối chiếu, hãy dùng mã nội bộ (ví dụ TK-01) thay cho số tài khoản thật. Cách này đủ để phân biệt các tài khoản trong log mà không lộ thông tin.

Không bao giờ ghi mật khẩu, khoá API, token. Nghe hiển nhiên, nhưng có một biến thể tinh vi: ghi cả chuỗi kết nối hoặc URL có tham số vào log. Nếu bạn ghi một URL có chứa token, token đó đã nằm trong file log — và file log đó có thể bị sao chép đi khắp nơi.

Vị trí lưu trữ. Nếu bạn sao lưu log lên dịch vụ cloud, hãy kiểm tra quyền truy cập. Một thư mục chia sẻ công khai chứa log giao dịch là một lỗ hổng thật, không phải rủi ro lý thuyết.

Thời hạn xoá. Có một lý do thực dụng để xoá log cũ ngoài chuyện dung lượng: log cũ là dữ liệu bạn không cần và không kiểm soát được rủi ro của nó. Vòng đời ở mục 7 đã trả lời câu này — log chi tiết 30–90 ngày, hồ sơ tổng hợp vĩnh viễn.

Mã hoá ổ đĩa nếu có thể. Với VPS, điều này tùy nhà cung cấp. Nếu không làm được, hãy giảm thiểu dữ liệu nhạy cảm trong log — đó là biện pháp hiệu quả nhất và bạn luôn làm được.

11. Checklist và tóm lại

Checklist 12 điểm cho audit log:

1. Trả lời được bốn câu hỏi: vì sao vào lệnh, vì sao khối lượng đó, vì sao đúng lúc đó, ai đổi gì
2. Nhật ký lệnh ghi theo mã lệnh, không chỉ theo thời gian
3. Có gio_gui và gio_khop (và độ trễ tính bằng ms)
4. Có khoi_luong và các giá trị trung gian của phép tính khối lượng
5. Có các số đo của tín hiệu, không chỉ có chữ "buy"/"sell"
6. Có spread_luc_gui và tick_cuoi
7. Có ea_phien_ban và hash của file EA
8. Statement của sàn được tải định kỳ và lưu ngoài VPS
9. Có nhật ký thay đổi tham số, luôn ghi cột "vì sao"
10. Có quy trình đối chiếu hằng tuần giữa nhật ký và statement
11. Phân loại kết luận điều tra vào một trong bốn nhóm, không để "không rõ"
12. Log không chứa số tài khoản thật, mật khẩu, hay token

Bốn ý cần nhớ:

1. Log trả lời "chuyện gì đã xảy ra"; hồ sơ trả lời "vì sao kết quả xấu đi". Bạn cần cả hai, và chúng có vòng đời khác nhau.
2. Câu trả lời phải là dữ liệu ghi trước, không phải suy luận sau. Mọi thứ ghi lại sau khi biết kết quả đều bị ảnh hưởng bởi kết quả đó.
3. Hash của file EA và nhật ký thay đổi là hai thứ không thể tái tạo. Hai thứ này thiếu là bạn mất khả năng trả lời câu hỏi khó nhất.
4. Bằng chứng chỉ có giá trị khi nằm ngoài máy sinh ra nó. Log trên VPS chết cùng VPS; statement trên máy bạn thì tồn tại.

Nếu bạn muốn đi tiếp: Đọc log MT5 để tìm nguyên nhân là phần chẩn đoán (bài này là phần hồ sơ), MT5 treo nhưng vẫn "đang chạy" giải thích cách đo hoạt động của bot, và Đo uptime bot cho đúng là phần số liệu vận hành.

Một lệnh bạn không giải thích được là một bài học miễn phí. Cùng lệnh đó ba tháng sau, khi log đã bị xoá, là một bài học bạn phải trả tiền hai lần.