# Luồng hoạt động của MikroTik Alert

Tài liệu này mô tả đúng logic hiện tại để kiểm tra trước khi triển khai. Mọi ngưỡng có thể đổi trong script cấu hình nhưng thay đổi phải được thử trên router thật.

## 1. Thứ tự cài đặt

```mermaid
flowchart TD
    A[Cấu hình Identity, PPPoE và Telegram Bot] --> B[Cài scripts/pppoe-monitor-install.rsc]
    B --> C[pppoe-monitor-config]
    B --> D[pppoe-monitor]
    B --> E[pppoe-monitor-reset]
    B --> F[Scheduler mỗi 3 phút]
    D --> G{PPPoE Monitor chạy ổn?}
    G -- Không --> H[Xem log PPPoE-MON và sửa cấu hình]
    G -- Có --> I[Cài scripts/network-alerts-install.rsc]
    I --> J[Ba nhóm mở rộng, mặc định Disabled]
    J --> K[Bật từng nhóm sau khi chạy thử]
```

`network-alerts-install.rsc` phụ thuộc `pppoe-monitor-config`. Nếu chưa có script này, installer dừng và không thay bản alert đang chạy.

## 2. PPPoE Monitor cơ bản

Scheduler `pppoe-monitor-every-3m` chạy mỗi 3 phút. Mỗi đường PPPoE có state riêng.

```mermaid
flowchart TD
    A[Scheduler mỗi 3 phút] --> B[Đọc pppoe-monitor-config]
    B --> C[Ping 3 gói qua đúng PPPoE]
    C --> D{Có ít nhất 1 reply?}
    D -- Không --> E[Tăng fail count và lưu giờ bắt đầu]
    E --> F{Đủ 3 lần lỗi?}
    F -- Không --> Z[Kết thúc đường truyền]
    F -- Có --> G[Đánh dấu sự cố đang hoạt động]
    G --> H[Thử gửi DOWN nếu chưa báo hôm nay]
    D -- Có --> I{Có sự cố đang hoạt động?}
    I -- Không --> J[Reset fail count]
    I -- Có --> K{DOWN đã gửi thành công?}
    K -- Có --> L[Gửi thông báo UP]
    K -- Không --> M[Gửi báo bù sau khi có mạng]
    L --> N{Telegram thành công?}
    M --> N
    N -- Không --> O[Giữ sự cố để lần sau gửi lại]
    N -- Có --> P[Đóng sự cố và nghỉ cảnh báo WAN 5 phút]
```

Logic chính:

- Một lần chạy gửi 3 ping, cách nhau 500ms. Chỉ cần một reply thì đường truyền được coi là UP.
- Cần 3 lần Scheduler liên tiếp không có reply. Với chu kỳ 3 phút, cảnh báo xuất hiện khoảng 6–9 phút sau khi mất mạng.
- Mỗi đường chỉ gửi tối đa một cảnh báo DOWN mỗi ngày.
- Khi chỉ có một WAN, DOWN thường không gửi được vì chính Internet đang mất. Script vẫn lưu sự cố; khi có mạng lại sẽ gửi một báo bù gồm giờ bắt đầu và thời gian gián đoạn.
- Nếu DOWN đã gửi được qua WAN dự phòng, lúc phục hồi script gửi thông báo UP bình thường.
- Chỉ đóng sự cố sau khi thông báo phục hồi/báo bù gửi thành công. Nếu Telegram lỗi, lần Scheduler sau thử lại.
- Sau khi gửi phục hồi thành công, cảnh báo WAN liên quan đường đó tiếp tục nghỉ 5 phút để kết nối ổn định.
- `pppoe-monitor-reset` xóa fail count, ngày cảnh báo, sự cố và thời gian nghỉ để thử lại.

Điểm cần xác nhận: sau khi DOWN rồi UP, nếu đường truyền DOWN lần nữa trong cùng ngày, script không gửi DOWN lần hai vì đã đạt giới hạn một cảnh báo DOWN/ngày. Đây là chống spam hiện tại, không phải giới hạn kỹ thuật.

## 3. Nhóm Router

Scheduler `network-alert-router-every-1m` chạy mỗi phút.

```mermaid
flowchart LR
    A[Mỗi phút] --> B[CPU]
    A --> C{Trong 10 phút đầu sau boot?}
    C -- Có và chưa gửi --> D[Gửi reboot]
    A --> E[Bộ đếm 5 lần]
    E -->|Đủ 5| F[RAM và storage]
```

- CPU: cảnh báo khi `cpu-load > 90%` trong 5 lần liên tiếp; phục hồi khi `<=80%`.
- Reboot: thử gửi mỗi phút trong 10 phút đầu sau boot cho tới khi thành công. Lúc cài installer, state được đánh dấu sẵn để không báo reboot giả. Nội dung gồm IP WAN của các PPPoE đang kết nối, không lấy log reboot. Scheduler và script cần quyền `read,write,policy,test` để giữ cờ đã gửi giữa các lần chạy.
- RAM/storage: kiểm tra mỗi 5 lần chạy; cảnh báo khi phần trống `<=10%` trong 3 mẫu, tương đương khoảng 15 phút; phục hồi khi `>=15%`.

## 4. Nhóm WAN

Scheduler `network-alert-wan-every-1m` chạy mỗi phút nhưng chia nhịp nội bộ:

| Nhánh | Chu kỳ | Logic |
|---|---:|---|
| PPPoE rớt nhiều lần | 1 phút | 3 lần chạy liên tiếp không reply mới tính một lần rớt; lần thứ 4 trong ngày mới cảnh báo |
| Packet loss/latency | 5 phút | 10 ICMP; 3 mẫu xấu mới cảnh báo, 2 mẫu tốt mới phục hồi |
| Link flap/counter lỗi | 5 phút | Đọc `link-downs` và mức tăng counter Ethernet |
| CGNAT/private WAN | 60 phút | Phân loại IPv4 và chỉ báo khi state thay đổi |

```mermaid
flowchart TD
    A[Mỗi phút] --> B[Kiểm tra PPPoE rớt]
    A --> C[Tăng bộ đếm 5 phút]
    A --> D[Tăng bộ đếm 60 phút]
    C -->|Đủ 5| E[Quality + Ethernet]
    D -->|Đủ 60| F[CGNAT/private IPv4]
```

Chi tiết quan trọng:

- Mỗi nhánh WAN kiểm tra state của đúng đường PPPoE. Khi interface không chạy, sự cố đã được xác nhận, thông báo phục hồi còn đang chờ gửi, hoặc đang trong 5 phút ổn định sau phục hồi, nhánh đó không gửi alert.
- Router và LAN Security không phụ thuộc PPPoE nên vẫn chạy khi Internet mất; Telegram có thể gửi lại khi kết nối khả dụng.
- Nhánh rớt mạng vẫn dùng ping riêng để đếm từng sự cố, nhưng chỉ được gửi cảnh báo tổng số lần rớt sau khi đường truyền đã phục hồi và hết thời gian nghỉ.
- Một sự cố chỉ được tính sau khoảng 3 phút mất reply liên tục. Sự cố ngắn hơn có thể không được đếm.
- Quality cảnh báo khi loss `>=30%` hoặc RTT trung bình `>=200ms` trong khoảng 15 phút.
- Khi tạm dừng, Quality xóa mẫu xấu cũ; Link lấy counter hiện tại làm baseline mới. Vì vậy không phát sinh cảnh báo phục hồi hoặc counter dồn ngay sau khi Internet lên lại.
- Khi không có reply nào, Quality không gửi cảnh báo riêng; PPPoE Monitor xử lý trạng thái mất mạng.
- Nếu `flood-ping` bị device-mode chặn, script dùng `/ping` để tính loss nhưng không có RTT trung bình.
- CGNAT gồm `100.64.0.0/10`; private WAN gồm `10/8`, `172.16/12`, `192.168/16`.
- Link flap cảnh báo từ lần link down thứ 4 trong ngày.
- Counter lỗi cảnh báo khi tổng FCS/alignment/overflow/collision tăng ít nhất 100 trong một kỳ 5 phút.
- Script tự tìm cổng vật lý qua một lớp VLAN. Topology sâu hơn phải khai báo `netAlertWanPort1/2` thủ công.

## 5. Nhóm LAN Security

```mermaid
flowchart TD
    A[Scheduler mỗi phút] --> B[Đọc Loop Protect status]
    A --> C[Tìm log probably loop hoặc loop-protect]
    B --> D{Có cổng bị Loop Protect disable?}
    D -- Có state mới --> E[Gửi cảnh báo loop]
    D -- Không --> F{Có log mới sau baseline?}
    F -- Có --> E
    G[DHCP Alert native] --> H{DHCP reply từ MAC không hợp lệ?}
    H -- Có --> I[network-alert-lan-dhcp gửi Telegram]
```

- Lần chạy đầu chỉ lưu log loop mới nhất làm baseline; không gửi lại log cũ.
- Khi Loop Protect đã disable cổng, state cổng được ưu tiên hơn log.
- DHCP Alert là detector native, được installer tạo ở trạng thái Disabled trên interface có DHCP Server đang bật.
- Interface có DHCP Client bị bỏ qua để tránh detector ảnh hưởng DHCP Client.
- Muốn bật đầy đủ nhóm LAN phải bật cả Scheduler và DHCP Alert.

## 6. Gửi Telegram và state

- Telegram dùng `tool fetch` với POST `application/x-www-form-urlencoded`.
- Bot Token/Chat ID lấy từ `pppoe-monitor-config`; không nằm trong installer public.
- State chỉ đổi sau khi gửi Telegram thành công ở các nhánh cần chống lặp.
- State là biến global trong RAM và mất sau reboot. Các script tự khởi tạo lại khi gặp `nil` hoặc `nothing`.
- Khi Internet mất hoàn toàn, Telegram không thể gửi ngay. PPPoE Monitor giữ state để báo bù sau khi có mạng; các alert WAN của đường đó tạm dừng để tránh spam.

## 7. Tải dự kiến

- PPPoE Monitor cơ bản: 3 ICMP mỗi 3 phút trên mỗi WAN.
- Nhóm WAN: 3 ICMP mỗi phút cộng 10 ICMP mỗi 5 phút trên mỗi WAN.
- Nhóm Router: đọc thuộc tính mỗi phút; RAM/storage chỉ mỗi 5 phút.
- Nhóm LAN: quét log trong RAM mỗi phút; DHCP Alert gửi một DHCP Discover mỗi phút trên mỗi interface được bật.
- Telegram chỉ gọi HTTPS khi phát sinh cảnh báo hoặc phục hồi.

Tải dự kiến thấp với router gia đình thông thường. Router rất yếu vẫn nên theo dõi 24 giờ bằng:

```routeros
/system resource print
/system script job print
/log print where message~"PPPoE-MON|NET-ALERT"
```

## 8. Checklist xác nhận flow

- [ ] Chấp nhận PPPoE Monitor mất khoảng 6–9 phút mới báo DOWN.
- [ ] Chấp nhận tối đa một cảnh báo DOWN/ngày cho mỗi WAN.
- [ ] Chấp nhận trường hợp một WAN chỉ nhận báo bù sau khi Internet phục hồi.
- [ ] Chấp nhận alert WAN nghỉ thêm 5 phút sau khi gửi thông báo phục hồi.
- [ ] Chấp nhận một lần rớt mở rộng phải kéo dài khoảng 3 phút mới được đếm.
- [ ] Quality xấu phải kéo dài khoảng 15 phút mới báo.
- [ ] RAM/storage thấp phải kéo dài khoảng 15 phút mới báo.
- [ ] Đã khai báo đúng cổng WAN nếu PPPoE đi qua topology VLAN phức tạp.
- [ ] Đã thêm mọi DHCP Server hợp lệ vào `Valid Servers`.
- [ ] Đã thử trên đúng model và phiên bản RouterOS trước khi dùng chính thức.