Tại sao kiểm tra trạng thái Amazon EC2 thành công cho trường hợp không phản hồi?


5

NGUY HIỂM!

Không chạy lệnh này để 'kiểm tra' nó trừ khi bạn chuẩn bị cho sự cố và / hoặc buộc khởi động lại hệ thống của bạn.

Các bước tôi đã thực hiện:

  • Tôi đã tạo một phiên bản t1.micro trên EC2 chạy Ubuntu 14.01 LTS.
  • Tôi xác nhận rằng cả hai kiểm tra trạng thái thông qua.
  • Tôi SSH vào ví dụ.
  • Tôi đã chạy bom ngã ba được ghi lại trong lý do tại sao lệnh này làm cho hệ thống của tôi bị lag đến mức tôi phải khởi động lại? .
    • Phiên SSH của tôi được hiển thị dưới đây.
  • Như bạn có thể thấy, ví dụ (nhanh chóng) hết bộ nhớ và phiên của tôi kết thúc sau khi hết thời gian.

Tôi dự kiến Kiểm tra tình trạng sơ thẩm không thành công. Tuy nhiên, cả hai kiểm tra trạng thái tiếp tục vượt qua hơn 20 phút sau. Ví dụ không phản hồi với SSH và ping, mặc dù nmap báo cáo rằng cổng 22 đang mở.

Tôi đã hy vọng sử dụng kiểm tra trạng thái để xác định xem trường hợp đó có phản hồi hay không và nhóm tự động hóa của nó chấm dứt và thay thế nó, nhưng có vẻ như tôi sẽ không thể làm điều đó.

Tôi có hai câu hỏi:

  1. Tại sao cá thể vượt qua cả hai kiểm tra trạng thái?
  2. Có giải pháp nào khác (ngoài việc trả $ 18 / tháng cho bộ cân bằng tải không được sử dụng để cân bằng tải) để chấm dứt các trường hợp trở nên không phản hồi? Có điều gì tôi có thể làm với báo thức trên đám mây không?
    • Lý tưởng nhất là tôi muốn có thể báo cáo tình trạng sức khỏe theo định kỳ và nếu không thực hiện được trong một khoảng thời gian nhất định, hãy chấm dứt nó (và để nhóm tự động hóa của tôi lo phần còn lại).

Phiên SSH của tôi:

Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-57-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Jul  9 18:50:39 UTC 2015

  System load: 0.0               Memory usage: 7%   Processes:       47
  Usage of /:  16.8% of 7.75GB   Swap usage:   0%   Users logged in: 0

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud


Last login: [[redacted]]
ubuntu@ip-172-31-18-225:~$ :(){ :|: & };:
[1] 1218
ubuntu@ip-172-31-18-225:~$ -bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
Connection to 52.2.62.141 closed.

Chỉnh sửa: Vì vậy, mục tiêu thực sự của tôi là thu hẹp khoảng cách giữa những gì kiểm tra trạng thái kiểm tra và kiểm tra xem ứng dụng của tôi có đang chạy hay không. Nếu kiểm tra trạng thái thực sự kiểm tra xem kernel có chạy đúng không, thì dường như tôi có thể sử dụng bộ theo dõi phần mềm kernel (như mô-đun kernel softdog) để thu hẹp khoảng cách đó.

  • Kiểm tra trạng thái có thực sự kiểm tra xem kernel đang chạy như bình thường không?
  • Nếu kiểm tra trạng thái cho biết kernel đang chạy, điều đó có nhất thiết có nghĩa là tất cả các mô-đun kernel tôi đã tải đang chạy đúng không?

Câu trả lời:


4

Không phản hồi! = Không có nhịp tim. Nhân vẫn đang chạy. AWS không có cách nào để biết rằng bạn đã tiêu thụ hết bộ nhớ của mình.

Giám sát AWS Cloudwatch thực sự chỉ là mức tối thiểu bạn nên làm. Nếu bạn cần theo dõi chi tiết hơn, bạn sẽ cần tự cuộn.


Phải, vậy bạn sẽ đề nghị làm gì? Tôi thực sự không muốn theo dõi chi tiết. Tôi (hiệu quả) muốn định kỳ đá một cơ quan giám sát từ ứng dụng của tôi. Bạn có biết một cách để làm điều đó với các dịch vụ AWS không?
Collin

Chắc chắn, bạn có thể cuộn số liệu Cloudwatch của riêng mình và sau đó điều chỉnh ASG của bạn dựa trên đó.
EEAA

Bạn có đề nghị tôi sử dụng một số liệu và một báo động cho mỗi trường hợp không? Điều đó có vẻ hơi quá đáng, mặc dù tôi không biết cách nào tốt hơn vào lúc này.
Collin


Điều này rất hữu ích, nhưng cuối cùng tôi đã giải quyết vấn đề theo cách khác (xem câu trả lời của tôi).
Collin

2

Vì các kiểm tra trạng thái đã quan tâm đến việc đảm bảo kernel đã hoạt động, nên đủ để sử dụng mô-đun kernel softdog . Mặc dù đây là bộ đếm thời gian theo dõi phần mềm, nhưng thực tế nó là mô-đun hạt nhân có nghĩa là bất kỳ trường hợp nào mà bản thân bộ giám sát trở nên không phản hồi cũng sẽ được phát hiện bởi Kiểm tra trạng thái sơ thẩm do AWS thực hiện, do đó sẽ chấm dứt phiên bản EC2.

Đây là những gì tôi đã làm trong tập lệnh thiết lập của mình (đây là Ubuntu AMI):

cat >>/etc/modules <<EOF
softdog
EOF

apt-get install watchdog

cat >>/etc/watchdog.conf <<EOF
interval = 10
logtick = 60
max-load-1 = 24
max-load-5 = 18
max-load-15 = 12
min-memory = 65536
watchdog-device = /dev/watchdog0
ping = 8.8.8.8
interface = eth0
test-binary = /path/to/my/health/check/script.sh
test-timeout = 30
realtime = yes
priority = 1
EOF

...other setup stuff...

reboot

# If you don't want to reboot, you can instead do:
modprobe softdog
service watchdog restart
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.