Chuyển đến nội dung chính
Mọi vấn đề của Resolve đều nằm ở một giai đoạn trên đường đi từ cảnh báo đến bản sửa. Tìm giai đoạn từ triệu chứng bên dưới, rồi lần lượt xem nguyên nhân, cách kiểm tra và cách sửa.

​
Tìm giai đoạn

Hai kiểm tra nhanh loại trừ hầu hết vấn đề trước khi bạn đi sâu:
  • Resolve → Integrations hiển thị huy hiệu sẵn sàng cho từng nền tảng. Bất kỳ giá trị nào khác Ready đều chỉ ra vấn đề truyền tải. Xem huy hiệu sẵn sàng.
  • Phần đầu trang Resolve → Investigation hiển thị On duty hoặc Paused. Paused nghĩa là Pulse vẫn nhóm cảnh báo và vẫn ghi sự cố với trạng thái Open, nhưng CloudThinker không tự phân loại hay điều tra chúng. Xem Điều gì khởi động một cuộc điều tra.

​
Cảnh báo không đến

Kết nối hiển thị khỏe mạnh chưa chứng tỏ cảnh báo đến được Resolve. Nền tảng chỉ thật sự là nguồn hoạt động khi có ít nhất một đường tín hiệu truyền tải thành công.
Nguyên nhân: công cụ giám sát chưa bao giờ gửi, hoặc gửi sai URL. Kiểm tra: log truyền tải trong công cụ giám sát, và hàng nguồn của nền tảng trên Resolve → Integrations. Nếu log của công cụ hiển thị 401 hoặc 403, secret hoặc URL bị sai. Cách sửa: sao chép lại webhook URL từ phần Signals to Resolve của nền tảng, dán vào công cụ và gửi một cảnh báo thử. Nếu bạn không còn secret, chọn Regenerate credentials từ menu … của webhook và cập nhật công cụ với URL và secret mới. Sau đó mở Resolve → Pulse và chọn lane All. Lane là các bộ lọc chọn cluster nào bạn thấy, xem Pulse.
Nguyên nhân: nền tảng cần kết nối một tài khoản trước, chưa có đường tín hiệu nào, hoặc một kết quả được bật trong What Resolve can do chưa có đích. Các nền tảng chỉ dùng webhook, chẳng hạn Amazon Web Services cho CloudWatch alarm, không bao giờ hiển thị Needs connection. Slack, Teams và Google Chat hiển thị Needs setup ngay sau khi bạn kết nối, vì Post incident updates mặc định bật mà chưa có kênh. Cách sửa: kết nối tài khoản trong phần Connection của nền tảng, nhấn Add signal, hoặc chọn đích cho kết quả được đánh dấu Needs setup (hoặc tắt kết quả đó). Đọc trạng thái sẵn sàng liệt kê mọi huy hiệu và cách xử lý.
Nguyên nhân: một kết nối không khỏe mạnh, hoặc một đường tín hiệu thất bại trong khi các đường khác hoạt động. Kiểm tra: mở nền tảng và đọc gợi ý trên từng hàng nguồn. Cách sửa: làm theo gợi ý. Với polling AWS, kiểm tra kết nối AWS và quyền của kết nối. Xem Đọc trạng thái sẵn sàng để biết ý nghĩa của từng huy hiệu.
Nguyên nhân: phản hồi HTTP thành công chỉ chứng minh sự kiện đã được truyền tới. Pulse vẫn có thể loại bỏ sự kiện vì coi là nhiễu: một bản lặp chính xác (cùng tiêu đề, mức độ nghiêm trọng và tài nguyên, với dấu thời gian sự kiện cùng phút với một sự kiện đã thấy trong giờ qua), một sự kiện vượt giới hạn nhiễu của Pulse là 100 sự kiện mỗi phút từ một nguồn, hoặc khớp với một snooze. Giới hạn nhiễu luôn cho sự kiện Critical và High đi qua. Kiểm tra: lane All, và mọi snooze trên nguồn hoặc tài nguyên đó. Cách sửa: gửi một cảnh báo thử với tiêu đề khác, hoặc nhấn Unsnooze. Xem lọc nhiễu.
Nguyên nhân: giới hạn tần suất theo giờ của webhook. Mỗi webhook mặc định nhận 1.000 request mỗi giờ. Sự kiện vượt quá giới hạn vẫn nhận phản hồi thành công, rồi bị loại bỏ trước khi đến Pulse, bất kể mức độ nghiêm trọng. Giới hạn này tách biệt với giới hạn nhiễu của Pulse. Kiểm tra: sự kiện bị loại bỏ mà không có thông báo nào, nên hãy so sánh số lượng. Đặt cửa sổ thời gian của Resolve → Pulse thành Last 1 hour và đọc số raw events ở phần đầu trang. Nếu số này thấp hơn số bên gửi báo đã gửi trong giờ đó, sự kiện đã bị loại bỏ. Cách sửa: mở menu … của webhook trong Resolve → Integrations, chọn Edit và nâng Rate limit (requests per hour), tối đa 10.000, hoặc 0 để không giới hạn.
Nguyên nhân: một trong ba điều. Nguồn đã gửi vượt quá 10 lần giới hạn tần suất theo giờ, có 10 lần xác thực thất bại trong vòng 15 phút (thường gặp ngay sau khi xoay vòng secret), hoặc CloudThinker tạm thời bận. Kiểm tra: xem có phản hồi 401 hoặc 403 trước 429 trong log truyền tải của công cụ hay không. Cách sửa: nếu bị khóa do xác thực thất bại, đặt secret và URL hiện tại vào công cụ, rồi chờ cửa sổ 15 phút trôi qua. Với giới hạn tần suất, nâng Rate limit (requests per hour). Nếu không, thử lại sau khoảng thời gian trong header Retry-After. Xem bảng Responses của nguồn tùy chỉnh.
Nguyên nhân: kênh không nằm trong danh sách theo dõi. Cách sửa: trên nền tảng Slack hoặc Teams trong Resolve → Integrations, thêm kênh vào Listen for incidents.

​
Cluster không hình thành

Cluster là một nhóm tín hiệu liên quan mà Pulse coi là một vấn đề. Mọi tín hiệu còn lại sau bước lọc nhiễu đều vào một cluster, kể cả cluster chỉ có một tín hiệu. Tín hiệu mới gia nhập một cluster đang mở gần đây khi có chung resource ID hoặc tiêu đề với một tín hiệu trong đó, hoặc nếu không, có cùng Service. Cách tín hiệu gia nhập cluster có quy tắc đầy đủ.
Nguyên nhân: cảnh báo không mang resource ID, hoặc mỗi lần một ID khác, nên Pulse không thể biết chúng là cùng một lỗi. Tiêu đề chung không gộp hai cảnh báo có resource ID khác nhau, và cảnh báo không có Service (hoặc unknown) không thể gộp theo service. Kiểm tra: trong Resolve → Pulse, mở từng tín hiệu trong cluster và mở rộng Raw payload để so sánh resource ID. Cách sửa: với một nguồn tùy chỉnh, mở menu … của nguồn, chọn Edit và đặt Resource ID Path thành một ID ổn định trong payload, như alert.resource.id. Trường Resource trong thiết lập chỉ là tên hiển thị và không ảnh hưởng đến cách nhóm. Để gộp các cảnh báo khác nhau về một service, hãy ánh xạ thêm Service Path đến một tên service duy nhất.
Nguyên nhân: webhook đang bật Send directly to CloudThinker, tùy chọn này bỏ qua bước lọc và nhóm của Pulse. Kiểm tra: mở webhook trong Resolve → Integrations. Cách sửa: tắt tùy chọn này trừ khi nguồn có lưu lượng thấp và mọi sự kiện đều quan trọng.
Nguyên nhân: ánh xạ Incident title của nguồn tùy chỉnh trỏ đến sai trường. Cách sửa: sửa webhook, gửi một payload mới và chọn lại trường tiêu đề.
Nguyên nhân: cluster đã được định tuyến, nghĩa là một sự cố đang mở đã chứa cluster này. Tín hiệu khớp sẽ gia nhập cluster đó và cập nhật sự cố thay vì khởi động cuộc điều tra thứ hai. Kiểm tra: tìm cluster trong lane Routed. Cách sửa: xử lý từ sự cố. Xem vòng đời cluster.

​
Cuộc điều tra không khởi động

Nguyên nhân: On duty đang tạm dừng. Pulse vẫn phát hiện và nhóm cảnh báo và vẫn ghi sự cố với trạng thái Open, nhưng CloudThinker không tự phân loại hay điều tra chúng. Kiểm tra: phần đầu trang Resolve → Investigation. Cách sửa: bật lại On duty, thao tác này thay đổi cách xử lý cảnh báo mới — sự cố được ghi trong lúc tạm dừng không được khởi động hồi tố. Để khởi động một cuộc điều tra ngay, nhấn Investigate trên sự cố, hoặc nhấn Escalate và Send to triage trên một cluster trong Resolve → Pulse.
Nguyên nhân: sự cố chưa có cuộc điều tra nào. Cách sửa: chọn sự cố trong Resolve → Investigation và nhấn Investigate (chỉ Admin).
Nguyên nhân: webhook đó có Auto-investigate tắt, hoặc Only from a minimum severity được đặt cao hơn mức độ nghiêm trọng của cảnh báo. Cảnh báo có mức độ thấp hơn vẫn được nhóm thành cluster nhưng không tự khởi động phân loại. Cách sửa: mở webhook trong Resolve → Integrations và điều chỉnh một trong hai tùy chọn. Quy tắc đầy đủ có trong Điều gì khởi động một cuộc điều tra.
Nguyên nhân: bước phân lớp chạy sau khi tín hiệu gia nhập cluster. Bước này đánh giá các tín hiệu là Not actionable, nên cluster không bao giờ được gửi sang phân loại. Tín hiệu không bị lọc bỏ: cluster vẫn nằm trong lane All. Xem lọc nhiễu. Cách sửa: nếu bạn cần xử lý, mở cluster trên Resolve → Pulse và nhấn Escalate trên thanh hành động của bảng chi tiết, rồi Send to triage. Hoặc dùng Attach to incident… để liên kết với một sự cố bạn chọn.
Lần lượt kiểm tra từng nguyên nhân:

​
Cuộc điều tra bị kẹt

Nhấn Watch live trên sự cố để xem từng kiểm tra mà CloudThinker chạy theo thời gian thực. Nếu dòng thời gian đang di chuyển, cuộc điều tra không bị kẹt.
Nguyên nhân: CloudThinker muốn chạy một lệnh cần quyết định của con người, nên lượt chạy dừng lại cho đến khi có người trả lời. Kiểm tra: banner Action requires approval trên sự cố, hoặc bộ lọc Awaiting my approval trên Resolve → Investigation. Cách sửa: nhấn Go to conversation và nhấn Approve hoặc Decline tại đó. Hành động bị từ chối hiển thị là Rejected trong Execution history.
Nguyên nhân: CloudThinker đang chờ thông tin, quyền truy cập hoặc một quyết định. Sự cố nằm trong nhóm Needs your decision trên Resolve → Investigation cho đến khi có người cung cấp. Huy hiệu trạng thái của sự cố có thể hiển thị On Hold. Cách sửa: mở More actions → Open AI Conversation và trả lời điều CloudThinker yêu cầu.
Nguyên nhân: phiên gặp lỗi, hoặc ngừng phản hồi và bị đánh dấu thất bại. Sự cố hiển thị Analysis Failed kèm thông báo lỗi. Cách sửa: khắc phục điều mà thông báo nêu, chẳng hạn một kết nối không khỏe mạnh, rồi nhấn Retry Analysis. Nếu thông báo mơ hồ hoặc lần thử lại thất bại theo cùng cách, xem Nhận trợ giúp.
Nguyên nhân: CloudThinker không đọc được đủ hệ thống của bạn để chứng minh một nguyên nhân gốc. Cách sửa: thêm kết nối còn thiếu, bổ sung ngữ cảnh trong cuộc hội thoại và điều tra lại. Xem nhãn bằng chứng.

​
Runbook không chạy

Runbook là một quy trình sửa lỗi từng bước mà Resolve đọc từ Confluence, GitHub, GitLab hoặc tệp tải lên thủ công. Mỗi lệnh thay đổi hệ thống mang một tác động (Allow, Require Approval hoặc Deny). Lệnh từ Confluence, GitHub và GitLab luôn là Require Approval. Chỉ tệp tải lên mới mang được các tác động khác, xem Kiểm soát tác động của lệnh. Mở Resolve → Runbooks → Execution history để xem điều gì đã xảy ra với từng lượt chạy.
Nguyên nhân: Resolve chưa tìm kiếm runbook của bạn trong một cuộc điều tra nào, hoặc chưa có nguồn nào được kết nối. Kiểm tra: tab Runbook sources. Cách sửa: thêm một nguồn. Với Confluence, GitHub hoặc GitLab, đảm bảo kết nối phía sau đọc được space hoặc repository.
Nguyên nhân: Require Approval là mặc định. Mọi lệnh thay đổi hệ thống từ Confluence, GitHub hoặc GitLab đều chờ người duyệt, và mọi lệnh trong tệp tải lên mà chưa ai thay đổi tác động cũng vậy. Cách sửa: phê duyệt trong cuộc hội thoại. Với tệp tải lên, bạn có thể thay đổi tác động của lệnh ở nơi workspace hiển thị Policies trên Resolve → Settings. Xem Kiểm soát tác động của lệnh.
Nguyên nhân: tác động của lệnh là Deny, nên Resolve không thể thực thi. Chỉ runbook tải lên mới mang được Deny: lệnh từ Confluence, GitHub và GitLab luôn là Require Approval. Kiểm tra: cột Policy trong Execution history hiển thị Denied. Cách sửa: ở nơi workspace hiển thị Policies trên Resolve → Settings, đổi tác động của lệnh thành Require Approval hoặc Allow trong chính sách của tệp tải lên. Nếu không, hãy liên hệ bộ phận hỗ trợ. Xem Kiểm soát tác động của lệnh.

​
Không có cập nhật trong Slack hoặc Teams

Nguyên nhân: Live progress updates đang tắt, hoặc sự cố không có phản ứng đang hoạt động (không gắn war room Slack, Incident Room, kênh sự cố Teams hay không gian sự cố Google Chat). Kiểm tra: công tắc trong Resolve → Settings → Behaviour, và sự cố có war room hoặc Incident Room hay không. Cách sửa: bật công tắc, hoặc gắn một phản ứng, xem On-call. Cập nhật luôn có trên Investigation timeline của sự cố. Xem Chọn nơi hiển thị tiến độ.

​
Nhận trợ giúp

Vẫn bị kẹt? Gửi email đến support@cloudthinker.io kèm tên workspace, ID sự cố (giá trị id= trong URL của sự cố trên Resolve → Investigation), tên nguồn, thời điểm cảnh báo gần đúng theo UTC, giai đoạn từ Tìm giai đoạn và mọi thông báo lỗi hiển thị trên sự cố.

​
Liên quan

Kết nối nguồn Pulse

Thiết lập đường tín hiệu và đọc huy hiệu sẵn sàng.

Cluster tín hiệu

Hiểu cách nhóm, lọc nhiễu và các hành động trên cluster.

Điều tra và RCA

Đọc kết luận, kết quả và nhãn bằng chứng.

Runbook

Thêm nguồn và kiểm soát tác động của lệnh.