Hệ thống càng phức tạp thì càng có nhiều loại cảnh báo. Và cần phải phản ứng với những cảnh báo tương tự này, tổng hợp chúng và trực quan hóa chúng. Tôi nghĩ đây là tình huống quen thuộc với nhiều người đến mức lo lắng.
Giải pháp sẽ được thảo luận không phải là điều bất ngờ nhất, nhưng việc tìm kiếm không trả lại một bài viết đầy đủ về chủ đề này.
Vì vậy, tôi quyết định chia sẻ kinh nghiệm của FunCorp và nói về cách cấu trúc quy trình thực hiện nhiệm vụ, ai gọi điện, lý do và cách bạn có thể xem xét tất cả.
PagerDuty là gì?
Vì vậy, để giải quyết tất cả những vấn đề này, chúng tôi bắt đầu tìm kiếm một công cụ tiện lợi. Sau một hồi tìm kiếm, chúng tôi đã chọn PagerDuty. Đối với chúng tôi, PD dường như là một giải pháp khá đầy đủ và ngắn gọn với số lượng lớn các tích hợp và cài đặt. Tính cách cô ấy là gì?
Nói tóm lại, PagerDuty là một nền tảng xử lý sự cố có thể xử lý các sự cố đến thông qua nhiều tích hợp khác nhau, thiết lập lệnh nhiệm vụ và sau đó cảnh báo cho kỹ sư đang làm nhiệm vụ tùy thuộc vào mức độ của sự cố (ở mức cao - một cuộc gọi, ở mức thấp - một cú đẩy từ ứng dụng / SMS) .
Sĩ quan trực ban là ai?
Đây có lẽ là nơi đầu tiên bắt đầu thiết lập PD.
Tại FunCorp, giống như các công ty khác, có một vị trí danh dự là sĩ quan trực ban. Nó được truyền từ kỹ sư này sang kỹ sư khác mỗi ngày một lần. Có cái gọi là dòng phản hồi đầu tiên và thứ hai đối với cảnh báo từ PagerDuty. Giả sử có một cảnh báo có mức độ ưu tiên cao đến và nếu 10 phút sau khi cuộc gọi đến nhân viên trực từ tuyến đầu tiên không có phản hồi nào (tức là nó không được chuyển sang trạng thái xác nhận hoặc đã giải quyết), cuộc gọi sẽ chuyển sang trạng thái thứ hai. kỹ sư trực. Điều này được định cấu hình trong chính PagerDuty thông qua Chính sách nâng cấp.
Nếu nhân viên trực thứ hai không phản hồi, thông báo sẽ quay trở lại chủ yếu tới người trực ca.
Do đó, mọi cảnh báo có mức độ ưu tiên cao đến đều không thể chưa được xử lý.
Bây giờ hãy xem sự cố có thể đến từ đâu.
Chúng tôi sử dụng những tích hợp nào?
PD nhận được nhiều sự cố khác nhau từ các dịch vụ khác nhau. Chúng tôi hiện có khoảng 25 dịch vụ như vậy và để xử lý chúng, chúng tôi sử dụng một số tích hợp sẵn có.
- Prometheus
Hệ thống thu thập số liệu chính là Prometheus. Rất nhiều điều đã được viết về nó trên Habré, tôi chỉ nói rằng chúng tôi có một số trong số chúng dành cho các môi trường khác nhau: một thu thập số liệu từ máy ảo và đế, một số khác từ các dịch vụ của Amazon, thứ ba từ máy phần cứng. Telegraf chủ yếu được sử dụng như một công cụ xuất khẩu số liệu.
Ở đây cũng vậy, tôi nghĩ, mọi thứ đều rõ ràng ngay từ tiêu đề. Sự tích hợp này được sử dụng để gửi thông báo từ một số tập lệnh được thực thi bởi cron. PD cung cấp cho bạn một địa chỉ nhất định để bạn gửi thư. Khi tạo một dịch vụ có tích hợp như vậy, bạn có thể đặt mức độ ưu tiên, thứ tự xử lý các sự cố đến, cách tạo cảnh báo chính xác (đối với từng thư đến, đối với thư đến + một quy tắc nhất định, v.v.).
- Slack
Theo tôi, một sự tích hợp rất thú vị. Có những lúc chuyện gì đó xảy ra nhưng sự cố lại không che đậy được. Do đó, chúng tôi đã thêm tính năng tích hợp từ Slack để tạo ra sự cố. Tức là bạn có thể viết thư cho công ty Slack /callofduty mọi thứ đều chậm và sẽ sớm hỏng và PD sẽ xử lý và gửi sự việc cho kỹ sư trực.
Chúng tôi làm:
Chúng tôi thấy:
- API
Tích hợp HTTP. Trên thực tế, không có gì đặc biệt thú vị ở đây, chỉ là một yêu cầu POST có nội dung ở định dạng JSON. Ví dụ: có một điều thú vị: chúng tôi sử dụng nó để giám sát bên ngoài bằng cách sử dụng . Dịch vụ này kiểm tra khả năng truy cập các trang web của chúng tôi từ các nơi khác nhau trên thế giới. Trong trường hợp chúng tôi nhận được mã phản hồi không được chấp nhận (ví dụ: 502), một sự cố sẽ được tạo ra và sau đó mọi thứ diễn ra theo chuỗi được mô tả ở trên. Bản thân StatusCake có khả năng giám sát các URL nội bộ, chứng chỉ SSL hoặc hết hạn tên miền.
- LibreNMS
Đây là một hệ thống giám sát khác, bạn có thể đọc thêm về nó trên trang web của họ . Với sự trợ giúp của nó, chúng tôi giám sát giao diện mạng và iDRAC từ máy chủ.
Ngoài ra còn có các tích hợp như Datadog, CloudWatch. Bạn có thể xem thêm về những gì đã xảy ra với họ .
Hình dung
Hệ thống báo cáo sự cố chính là Slack. Tất cả các sự cố đến với PD đều được ghi vào một cuộc trò chuyện đặc biệt và nếu trạng thái của chúng thay đổi thì điều này cũng được hiển thị trong cuộc trò chuyện.
Khi có cơ hội hiển thị dữ liệu hữu ích trên màn hình của màn hình treo trên trần nhà, chúng tôi chợt nhận ra rằng chúng tôi (trong bộ phận phát triển) không có gì để hiển thị trên chúng. Có một Grafana tuyệt vời, nhưng nó không bao gồm mọi thứ và nhân viên phản ứng với các cảnh báo chứ không phải biểu đồ.
Sau khi tìm kiếm kỹ lưỡng nhưng không thành công trên GitHub để tìm một “bảng” ngắn gọn và đầy thông tin dành cho PD, chúng tôi quyết định viết bảng của riêng mình - chỉ với những gì chúng tôi cần. Mặc dù lúc đầu có ý tưởng hiển thị chính giao diện PD nhưng trông nó càng bất tiện hơn.
Để viết nó, tất cả những gì bạn cần làm là lấy khóa từ PD có quyền chỉ đọc.
Và đây là những gì chúng tôi có:
Màn hình hiển thị các sự cố đang mở hiện tại, tên của kỹ sư hiện tại đang làm nhiệm vụ theo lịch trình đã chọn và thời gian không có sự cố có mức độ ưu tiên cao (bảng có sự cố có mức độ ưu tiên cao sẽ được đánh dấu màu đỏ).
.
Kết quả là chúng tôi đã nhận được một bảng điều khiển thuận tiện để xem tất cả các sự cố của mình. Tôi sẽ rất vui nếu một số bạn thấy kinh nghiệm của chúng tôi hữu ích.
Nguồn: www.habr.com