Công cụ quản lý khủng hoảng cho Linux

 (brendangregg.com)
2 điểm bởi GN⁺ 2024-03-25 | 1 bình luận | Chia sẻ qua WhatsApp
  • Nếu chỉ bắt đầu cài công cụ chẩn đoán sau khi xảy ra sự cố hiệu năng, thời gian sẽ bị tiêu tốn vào khâu chuẩn bị thay vì khôi phục, vì vậy cần đưa sẵn công cụ quản lý khủng hoảng vào image máy chủ Linux
  • Danh sách khuyến nghị gồm procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool, v.v.; đây là các gói tối thiểu để có thể kiểm tra ngay CPU, đĩa, mạng và truy vết kernel
  • bcc và bpftrace có nhiều công cụ trùng nhau, nhưng bcc giàu tùy chọn CLI hơn, còn bpftrace dễ chỉnh sửa tại hiện trường; khi chạy, cả hai phát ra cùng bytecode BPF
  • Việc cài đặt trong lúc sự cố có thể dẫn đến mất vài chục phút do các biến số như SSH chậm, cấu hình apt hỏng, repository bị chặn, tường lửa, filesystem bất biến, lỗi quyền hạn
  • Chi phí chủ yếu là dung lượng đĩa và thời gian triển khai image, nhưng hầu hết các gói khuyến nghị đều nhỏ; nếu các bản phân phối Linux doanh nghiệp đưa chúng vào mặc định, việc ứng phó sự cố hiệu năng có thể bắt đầu nhanh hơn

Bộ công cụ tối thiểu cần có trước khi xảy ra sự cố

  • Khi xảy ra sự cố hiệu năng, chính thời gian cài đặt công cụ cần thiết để chẩn đoán nguyên nhân đã là một tổn thất, vì vậy an toàn hơn là cài sẵn công cụ quản lý khủng hoảng trên máy chủ Linux
  • Danh sách dựa trên bảng “Linux Crisis Tools” trong Systems Performance 2nd Edition
  • Các công cụ khuyến nghị theo gói Ubuntu như sau
    • procps: ps, vmstat, uptime, top
      • Kiểm tra thống kê cơ bản
    • util-linux: dmesg, lsblk, lscpu
      • Kiểm tra log hệ thống và thông tin thiết bị
    • sysstat: iostat, mpstat, pidstat, sar
      • Kiểm tra thống kê thiết bị và hệ thống
    • iproute2: ip, ss, nstat, tc
      • Công cụ mạng được ưu tiên
    • numactl: numastat
      • Kiểm tra thống kê NUMA
    • tcpdump: tcpdump
      • Sniffing mạng
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • Kiểm tra profiler và thống kê PMU
    • bpfcc-tools hoặc bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile, v.v.
      • Công cụ eBPF dựng sẵn
    • bpftrace: bpftrace, các phiên bản cơ bản của opensnoop, execsnoop, runqlat, biosnoop, v.v.
      • Scripting eBPF
    • trace-cmd: trace-cmd
      • Ftrace CLI
    • nicstat: nicstat
      • Thống kê thiết bị mạng
    • ethtool: ethtool
      • Thông tin thiết bị mạng
    • tiptop: tiptop
      • PMU/PMC top
    • cpuid: cpuid
      • Thông tin chi tiết CPU
    • msr-tools: rdmsr, wrmsr
      • Điều tra chi tiết CPU

Cách nhìn bcc và bpftrace cùng nhau

  • bcc và bpftrace có nhiều công cụ trùng nhau, nhưng điểm thuận tiện khi sử dụng lại khác nhau
  • Công cụ bcc có nhiều tính năng hơn như tùy chọn CLI, nên dễ dùng như một công cụ hoàn chỉnh
  • Công cụ bpftrace có thể chỉnh sửa ngay lập tức tại hiện trường, nên dễ kiểm tra tùy theo tình huống
  • Điều này không có nghĩa một trong hai nhanh hơn
    • Hai công cụ phát ra cùng bytecode BPF
    • Khi chạy, chúng nhanh như nhau
  • bcc đang tiến hóa theo hướng chuyển các công cụ nền Python sang libbpf C
    • Sử dụng CO-RE và BTF
    • Các gói vẫn chưa được làm lại
    • Trong tương lai, bpfcc-tools nên được thay bằng gói libbpf-tools nhỏ hơn, chỉ chứa binary của công cụ

Công cụ bổ sung tùy theo loại máy chủ

  • Danh sách trên chỉ là danh sách tối thiểu
  • Nếu máy chủ có accelerator, cũng cần đưa vào các công cụ để phân tích phần cứng đó
    • Máy chủ Intel GPU: intel-gpu-tools
    • Máy chủ NVIDIA: nvidia-smi
  • Các công cụ gỡ lỗi như gdb cũng có thể được cài sẵn nếu muốn dùng ngay trong tình huống khủng hoảng
  • Các công cụ phân tích thiết yếu không thay đổi thường xuyên, nên danh sách này có thể chỉ cần cập nhật vài năm một lần

Chi phí thực tế của việc cài mặc định

  • Nhược điểm dễ thấy nhất khi thêm gói là dung lượng đĩa sử dụng
  • Trên các instance đám mây, chỉ cần image máy chủ mặc định tăng thêm vài MB cũng có thể làm thời gian triển khai instance tăng thêm vài giây hoặc một phần giây
  • Hầu hết các gói khuyến nghị đều nhỏ và bcc dự kiến cũng sẽ nhỏ hơn, nên chi phí về dung lượng và thời gian không nên quá lớn
  • debuginfo có tổng dung lượng khoảng 1GB, nên thực sự từng có lo ngại về dung lượng khiến nó không được đưa vào mặc định

Luồng cài đặt bị kẹt trong lúc sự cố

  • Nếu cố cài công cụ sau khi sự cố xảy ra, thời gian có thể bị cuốn vào việc xử lý vấn đề cài đặt thay vì chẩn đoán
  • Một luồng ví dụ như sau
    • 4:00pm: Website của công ty bị sập hoặc quá chậm đến mức không sử dụng được
    • 4:01pm: Dashboard giám sát cho thấy nhóm máy chủ backend bất thường, nghi ngờ I/O đĩa cao
    • 4:02pm: Cố SSH vào máy chủ nhưng đăng nhập rất chậm
    • 4:03pm: Cố chạy iostat -xz 1 nhưng không có iostat, và xuất hiện hướng dẫn cài sysstat
    • 4:07pm: Cài gói thất bại vì không phân giải được repository, làm lộ ra vấn đề cấu hình /etc/apt
    • 4:10pm: Cần chạy apt-get update với cấu hình đã sửa, nhưng rất chậm
    • 4:13pm: Xảy ra timeout kết nối, bắt đầu nghi ngờ vấn đề kết nối tới repository hoặc vấn đề hiệu năng
    • 4:17pm: Xác nhận rằng đội bảo mật mạng đã chặn lưu lượng bất ngờ và các yêu cầu apt outbound qua HTTP/HTTPS/FTP
    • 4:20pm: Sau khi vô hiệu hóa tường lửa, apt-get update chạy được, nhưng cài đặt gặp lỗi quyền hạn
    • 4:24pm: Đội bảo mật nền tảng giải thích đây là hệ thống bất biến, trong đó việc ghi lên một số filesystem như khu vực binary thực thi bị chặn
    • 4:27pm: Đội SRE thông báo sự cố quy mô lớn, ban lãnh đạo yêu cầu cập nhật trạng thái và ETA khôi phục, nhưng chẩn đoán thực tế hầu như chưa tiến triển
    • 4:30pm: Thử dùng cat /proc/diskstats như một cách thay thế iostat thô sơ, nhưng phải đọc tài liệu Linux và chỉ xác nhận lại điều đã biết là đĩa đang bận
    • 4:55pm: Image máy chủ mới có filesystem ghi được được khởi động và có thể cài sysstat, nhưng website chỉ quay lại vì máy chủ được khởi động lại, còn nguyên nhân chưa được sửa
    • 12:50am: Ví dụ tiếp diễn với tình huống website bị hack do hậu quả của việc tắt tường lửa và bảo mật filesystem
  • Sự kiện 12:50am không phải trải nghiệm thực tế, nhưng phần còn lại là ví dụ dựa trên trải nghiệm thực tế
  • Ở công ty trước đây, vào khoảng mốc 15 phút, “đội lưu lượng” đôi khi bắt đầu failover vùng đám mây, và khi cài xong iostat thì hệ thống mục tiêu có thể đã ở trạng thái nhàn rỗi

Vì sao cần đưa vào image mặc định

  • Kịch bản trên cho thấy cách cài công cụ sau trong lúc sự cố production mong manh đến mức nào
  • Một số công ty đã có đội OS tạo và sử dụng image máy chủ tùy chỉnh chứa các công cụ cần thiết
  • Tuy vậy vẫn còn nhiều website vận hành nguyên bản phiên bản Linux mặc định, và trong trường hợp đó họ chỉ nhận ra nhu cầu sau khi trải qua sự cố
  • Nếu các bản phân phối Linux doanh nghiệp đưa những công cụ quản lý khủng hoảng này vào mặc định, cả công ty lớn lẫn nhỏ đều có thể bắt đầu chẩn đoán ngay khi xảy ra sự cố hiệu năng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-25
Ý kiến trên Hacker News

  • Danh sách này hữu ích. Trong những tình huống bản thân máy chủ bị rối, chẳng hạn như không phân giải được kho apt, đám mây thường rất phù hợp
    Thay vì bám vào để sửa, hãy hủy máy hoặc loại khỏi pool rồi dựng máy mới; máy mới và ứng dụng sẽ khởi động sạch sẽ và sự cố kết thúc. Máy có vấn đề có thể được điều tra riêng ngoài hot path

    • Sau khi “giải quyết” vấn đề, không ai còn thời gian hoặc không được phép đào sâu vào máy đó nữa, nên theo thời gian cách rebuild từ đầu khiến năng lực xử lý vấn đề thực sự và tri thức tích lũy bị mất đi
      Nó trở thành phiên bản phần mềm của kiểu “người chỉ biết thay linh kiện” trong thế giới vật lý
    • “4:10pm vấn đề hiệu năng tương tự vẫn tiếp diễn ngay cả trên máy mới”
    • Đó không hẳn là ưu điểm riêng của cloud, mà gần với ưu điểm của việc vận hành máy chủ ảo hóa có thể thay thế (cattle) hơn
    • Nếu hủy máy, cả bằng chứng cũng có thể biến mất. Có thể mọi log đều nằm bên ngoài, nhưng thường sẽ thiếu thứ gì đó

  • Không phải mọi máy chủ đều được container hóa, nhưng khá nhiều là container và việc đó cũng có khó khăn riêng
    Các công cụ debug trong image Docker thường bị trình quét bảo mật tự động đánh dấu là “công cụ không cần thiết giúp kẻ tấn công quan sát/sửa đổi hoạt động của hệ thống”. Với những thứ như gdb thì lo ngại đó hợp lý, nhưng nhiều thứ khác thì không
    Vì vậy một số công cụ được đặt trong volume riêng, nếu có thể thì dưới dạng binary tĩnh, hoặc được biên dịch/cài đặt với đường dẫn mount làm tiền tố cài đặt. Khi cần debug thì yêu cầu đội vận hành mount tạm thời ở chế độ chỉ đọc
    Ngoài ra, nếu công cụ debug nào đó yêu cầu bật một tính năng kernel cụ thể, thường sẽ phát sinh câu hỏi và lo ngại về tác động tới các container khác trên cùng host

    • Nếu kẻ tấn công có thể thực thi file trên filesystem, và điều còn thiếu để thực thi chỉ là file đó tồn tại, thì chẳng phải họ có thể tự ghi file vào sao?
      Tôi không thấy kịch bản nào mà chính sách này có ý nghĩa, ngoài việc “tổ chức đang dùng sai công cụ quét bảo mật”
    • Cách tốt hơn là tạo image thứ hai có công cụ debug và người dùng root, rồi chạy nó gắn vào PID namespace và network namespace của container production
      Để dùng debugger thường cần nhiều flag như quyền SYS_PTRACE, user 0, --privileged, nên khởi chạy container thứ hai thường tốt hơn
      Cách này cũng không cần restart container production, giảm khả năng mất bằng chứng để tái hiện
      Tuy nhiên trong lúc sự cố thì không dễ nhớ quy trình này, nên cần thử trước và ghi từng bước vào runbook

  • Liên quan đến việc này, từ FreeBSD 5.2, tức năm 2004, mọi hệ thống FreeBSD đều có /rescue/*
    Một binary liên kết tĩnh gom khoảng 150 công cụ cốt lõi lại với nhau được hardlink bằng các tên thông thường, kích thước khoảng 17MB
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • Trong 15 năm tôi chưa từng phải dùng đến nó. 4–5 năm gần đây tôi đã port những thứ có thể sang *BSD vì sức khỏe tinh thần

  • Khi còn ở Netflix, Brendan và đội của anh ấy đã giúp cài sẵn công cụ debug như bpftrace, bcc, perf hoạt động ổn định ở khắp nơi
    Chúng là những công cụ đã cứu mạng tôi nhiều lần

  • Tôi ngạc nhiên khi không thấy strace trong danh sách đó. Thường đây là một trong những công cụ tôi với lấy đầu tiên
    Đặc biệt khi chương trình trả về thông báo lỗi vô dụng hoặc sai, strace thực sự hữu ích

  • Trong phỏng vấn các vị trí kiểu SRE, chúng tôi luôn hỏi về những công cụ như thế này
    Trọng tâm không phải ứng viên thuộc bao nhiêu lệnh cụ thể; nếu họ giới thiệu được công cụ mới thì rất ấn tượng, nhưng chúng tôi xem họ biết những gì có thể làm được, có công cụ nào và dùng ra sao
    Điều quan trọng là cảm nhận rằng có thể capture/phân tích lưu lượng mạng, system call, execution profile, cũng như xem trạng thái hệ điều hành và phần cứng

  • Nếu trong tình huống khủng hoảng như thế này không thể cài công cụ, có thể chạy nhiều tiện ích bằng Docker
    Ví dụ build container bằng một dòng lệnh, gắn vào mạng host để chạy các công cụ kiểu netstat, hoặc mount /proc và dùng --privileged, --net host, --pid host để chạy các công cụ hệ thống như iostat, sar, vmstat, mpstat, pidstat
    Tất nhiên yum install vẫn tốt hơn, nhưng nếu dùng được Docker và xử lý được các mapping cần thiết thì đây là một lựa chọn thay thế. Với cấu hình rootless hoặc Podman thì có lẽ không ổn lắm

    • Có tình huống nào apt không tải và cài được package nhưng Docker lại kéo được container mới không?
      Có phải kiểu thư viện apt bị hỏng hay gì đó không?
    • Nếu ở tình huống cách ly mạng thì là ngoại lệ. Muốn kéo image “Ubuntu” thì chúc may mắn
    • Trong bối cảnh đó, tôi ước busybox có thêm nhiều công cụ kiểu này
      Có một file khoảng 1MB có thể upload lên server rồi chạy ngay sẽ rất hữu ích

  • Mọi người đều được cấp quyền root à? Tôi làm gì cũng phải mở ticket cho quản trị viên hệ thống

    • Giờ tôi là consultant nên cứ vài tháng lại sang một công ty mới. Luôn có những người cần giữ quan hệ tốt
      Nên nhớ tên người phụ trách bảo mật, những người mặc áo khoác hơi gượng gạo cho bạn vào tòa nhà, và chuẩn bị cả thẻ Starbucks
      Cư xử lịch sự với nhân viên vệ sinh và nhớ tên họ thì chỗ ngồi của bạn sẽ sạch sẽ. Thỉnh thoảng ở lại muộn để làm quen với những người này cũng đáng
      Cũng nên kết bạn với đội kế toán. Uống cà phê, ăn trưa, trò chuyện ngoài công việc và thể hiện sự quan tâm; đúng người sẽ báo cho bạn khi sắp có sa thải hoặc khi công ty bắt đầu mở hầu bao
      Cũng phải đối xử tốt với IT, tức những người phát laptop và quản lý email. Bạn sẽ thấy họ gỡ các công cụ bảo mật vớ vẩn khỏi máy bạn nhanh thế nào, và bạn được đẩy lên trước trong hàng nâng cấp ra sao
      Quan trọng nhất là quản trị viên hệ thống. Không chỉ vì root, mà vì quản trị viên hệ thống giỏi biết lập trình nhưng tuyệt đối không nói to chuyện đó. Người quản trị giỏi sẽ cho bạn biết xác chết nằm ở góc tối nào, đó chỉ là một cái tủ hay cả nghĩa địa. Nếu học cách build phù hợp với nền tảng của họ, bạn sẽ có nhiều quyền tự quyết hơn rất nhiều. Khi họ nhờ việc gì thì nên giúp
    • Trước đây tôi phụ trách vận hành IT, ở đây ý là hệ thống/SRE/bảo mật
      Bài này hướng tới những người vận hành ứng dụng trên hạ tầng do IT cung cấp. Nếu phải tương tác như ví dụ đó thì đây không phải vấn đề kỹ thuật mà là thất bại ở cấp tổ chức
      Chúng tôi có các kênh liên lạc rất rõ ràng và đáng tin cậy; mọi người không phối hợp qua chat mà qua điện thoại, ngày nay thì có thể là Teams, cùng với dev/ops/security/compliance
      Trên thực tế, mỗi đội đều có ít nhất một đầu mối liên hệ, và thường thì developer chạy ứng dụng trên tài nguyên do đội vận hành cung cấp. Compliance phê duyệt cấu hình, còn độ tin cậy dịch vụ là công việc của development. Làm DevOps theo nghĩa này thì nhiều vấn đề sẽ biến mất

  • Không thấy nmap, netstat, nc. Những công cụ này cũng đã cứu tôi nhiều lần

  • Nếu chỉ thêm một thứ thì là nmap
    Vấn đề kết nối mạng không phải lúc nào cũng hiển thị rõ trong mọi ứng dụng

    • Cũng cần screen, tmux, byobu, pv, rsync, và tất nhiên cả vim