Alat Manajemen Krisis Linux

 (brendangregg.com)
2 poin oleh GN⁺ 2024-03-25 | 1 komentar | Bagikan ke WhatsApp
  • Jika Anda baru mulai memasang alat diagnosis setelah gangguan performa terjadi, waktu akan habis untuk persiapan alih-alih pemulihan, jadi alat manajemen krisis perlu dimasukkan terlebih dahulu ke image server Linux
  • Daftar yang disarankan mencakup procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool, dan lainnya; ini adalah paket minimum untuk segera memeriksa CPU, disk, jaringan, dan penelusuran kernel
  • bcc dan bpftrace memiliki banyak alat yang tumpang tindih, tetapi bcc kaya opsi CLI sementara bpftrace mudah diedit di lapangan; saat dijalankan, keduanya mengeluarkan bytecode BPF yang sama
  • Instalasi saat gangguan dapat menyebabkan kehilangan puluhan menit karena variabel seperti SSH yang lambat, konfigurasi apt yang rusak, repositori yang diblokir, firewall, filesystem immutable, dan error izin
  • Biayanya terutama berupa kapasitas disk dan waktu distribusi image, tetapi sebagian besar paket yang disarankan berukuran kecil; jika disertakan secara default dalam distro Linux enterprise, respons terhadap gangguan performa dapat dimulai lebih cepat

Alat minimum yang perlu disiapkan sebelum gangguan

  • Ketika gangguan performa terjadi, waktu untuk memasang alat yang dibutuhkan guna mendiagnosis penyebabnya sendiri menjadi kerugian, jadi lebih aman memasang alat manajemen krisis secara default di server Linux
  • Daftar ini didasarkan pada tabel “Linux Crisis Tools” dari Systems Performance 2nd Edition
  • Alat yang direkomendasikan berdasarkan paket Ubuntu adalah sebagai berikut
    • procps: ps, vmstat, uptime, top
      • Memeriksa statistik dasar
    • util-linux: dmesg, lsblk, lscpu
      • Memeriksa log sistem dan informasi perangkat
    • sysstat: iostat, mpstat, pidstat, sar
      • Memeriksa statistik perangkat dan sistem
    • iproute2: ip, ss, nstat, tc
      • Alat jaringan yang disukai
    • numactl: numastat
      • Memeriksa statistik NUMA
    • tcpdump: tcpdump
      • Sniffing jaringan
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • Memeriksa profiler dan statistik PMU
    • bpfcc-tools atau bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile, dan lainnya
      • Alat eBPF yang sudah dibuat sebelumnya
    • bpftrace: bpftrace, versi dasar dari opensnoop, execsnoop, runqlat, biosnoop, dan lainnya
      • Scripting eBPF
    • trace-cmd: trace-cmd
      • CLI Ftrace
    • nicstat: nicstat
      • Statistik perangkat jaringan
    • ethtool: ethtool
      • Informasi perangkat jaringan
    • tiptop: tiptop
      • PMU/PMC top
    • cpuid: cpuid
      • Detail CPU
    • msr-tools: rdmsr, wrmsr
      • Pemeriksaan detail CPU

Cara melihat bcc dan bpftrace bersama-sama

  • bcc dan bpftrace memiliki banyak alat yang tumpang tindih, tetapi titik penggunaannya yang nyaman berbeda
  • Alat bcc memiliki lebih banyak fitur seperti opsi CLI, sehingga nyaman digunakan seperti alat yang sudah jadi
  • Alat bpftrace dapat langsung diedit di lapangan, sehingga mudah disesuaikan dengan situasi
  • Ini tidak berarti salah satunya lebih cepat
    • Kedua alat mengeluarkan bytecode BPF yang sama
    • Saat berjalan, keduanya sama cepatnya
  • bcc sedang berevolusi ke arah memindahkan alat berbasis Python ke libbpf C
    • Menggunakan CO-RE dan BTF
    • Paketnya belum dikerjakan ulang
    • Ke depannya, bpfcc-tools seharusnya digantikan oleh paket libbpf-tools yang lebih kecil dan hanya berisi binary alat

Alat tambahan yang dibutuhkan tergantung jenis server

  • Daftar di atas hanyalah daftar minimum
  • Jika server memiliki akselerator, alat untuk menganalisis perangkat tersebut juga harus disertakan
    • Server Intel GPU: intel-gpu-tools
    • Server NVIDIA: nvidia-smi
  • Alat debugging seperti gdb juga dapat dipasang terlebih dahulu jika ingin langsung menggunakannya saat krisis
  • Alat analisis penting tidak sering berubah, jadi daftar ini mungkin cukup diperbarui beberapa tahun sekali

Biaya nyata dari instalasi default

  • Kekurangan yang paling pertama terlihat saat menambahkan paket adalah penggunaan disk
  • Pada instance cloud, penambahan beberapa MB saja pada image server default dapat menambah waktu deployment instance beberapa detik atau sepersekian detik
  • Sebagian besar paket yang direkomendasikan berukuran kecil, dan bcc juga direncanakan menjadi lebih kecil, sehingga biaya kapasitas dan waktu seharusnya tidak besar
  • debuginfo totalnya mencapai sekitar 1GB, sehingga memang pernah ada kekhawatiran kapasitas yang menghalangi penyertaannya secara default

Alur saat instalasi terhambat di tengah gangguan

  • Jika Anda mencoba memasang alat setelah gangguan terjadi, waktu bisa tersedot untuk menyelesaikan masalah instalasi alih-alih diagnosis
  • Contoh alurnya sebagai berikut
    • 4:00pm: Situs perusahaan down atau terlalu lambat untuk digunakan
    • 4:01pm: Dashboard monitoring menunjukkan grup server backend tidak normal, dan I/O disk yang tinggi dicurigai
    • 4:02pm: Mencoba mengakses server melalui SSH, tetapi login sangat lambat
    • 4:03pm: Mencoba menjalankan iostat -xz 1, tetapi iostat tidak ada, dan muncul panduan untuk memasang sysstat
    • 4:07pm: Instalasi paket gagal karena tidak dapat me-resolve repositori, dan masalah konfigurasi /etc/apt terungkap
    • 4:10pm: Harus menjalankan apt-get update dengan konfigurasi yang sudah diperbaiki, tetapi prosesnya sangat lambat
    • 4:13pm: Terjadi timeout koneksi, sehingga koneksi repositori atau masalah performa dicurigai
    • 4:17pm: Tim keamanan jaringan mengonfirmasi adanya trafik tak terduga dan bahwa permintaan apt outbound HTTP/HTTPS/FTP telah diblokir
    • 4:20pm: Setelah firewall dinonaktifkan, apt-get update berhasil, tetapi saat instalasi muncul error izin
    • 4:24pm: Tim keamanan platform menjelaskan bahwa itu adalah sistem immutable yang memblokir penulisan ke sebagian filesystem, termasuk area binary executable
    • 4:27pm: Tim SRE mengumumkan gangguan besar dan manajemen meminta pembaruan status serta ETA pemulihan, tetapi diagnosis sebenarnya hampir belum berjalan
    • 4:30pm: Mencoba pengganti iostat yang kasar dengan cat /proc/diskstats, tetapi harus membaca dokumentasi Linux dan hanya mengonfirmasi fakta yang sudah diketahui bahwa disk sedang sibuk
    • 4:55pm: Image server baru dengan filesystem yang dapat ditulis sudah naik dan sysstat dapat dipasang, tetapi situs kembali berjalan hanya karena server direstart; penyebabnya belum diperbaiki
    • 12:50am: Contoh berlanjut dengan situasi situs diretas akibat firewall dan keamanan filesystem dibiarkan mati
  • Kejadian 12:50am bukan pengalaman nyata, tetapi sisanya adalah contoh berdasarkan pengalaman nyata
  • Di tempat kerja sebelumnya, sekitar menit ke-15, ada kasus “traffic team” mulai melakukan failover region cloud, dan saat instalasi iostat selesai, sistem target bisa saja sudah berada dalam keadaan idle

Alasan memasukkannya ke image default

  • Skenario di atas menunjukkan betapa rapuhnya pendekatan memasang alat belakangan saat gangguan produksi sedang berlangsung
  • Beberapa perusahaan sudah menggunakan image server kustom yang dibuat tim OS dengan menyertakan alat yang diperlukan
  • Namun masih banyak situs yang menjalankan versi Linux default apa adanya, dan dalam kasus seperti ini kebutuhan tersebut baru disadari setelah mengalami gangguan
  • Jika distro Linux enterprise menyertakan alat manajemen krisis ini secara default, perusahaan besar maupun kecil dapat langsung memulai diagnosis saat gangguan performa terjadi

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-25
Pendapat Hacker News

  • Daftar ini berguna. Dalam situasi ketika server itu sendiri sudah kacau, seperti kegagalan interpretasi repositori apt, cloud sering kali cocok
    Daripada terus berkutat mencoba memperbaikinya, jika mesin dimatikan atau dikeluarkan dari pool lalu mesin baru dinyalakan, mesin dan aplikasi baru akan naik dengan bersih dan insiden selesai. Mesin bermasalah bisa diselidiki terpisah di luar hot path

    • Setelah masalah “diselesaikan”, biasanya tidak ada yang punya waktu atau izin untuk menyelidiki mesin itu, sehingga seiring waktu pendekatan rebuild dari awal membuat kemampuan pemecahan masalah nyata dan pengetahuan yang terkumpul hilang
      Ini menjadi versi perangkat lunak dari “orang yang hanya mengganti komponen” di dunia fisik
    • “4:10pm masalah performa yang sama terus terjadi juga di mesin baru”
    • Itu bukan semata-mata keunggulan cloud, melainkan lebih dekat dengan keunggulan menjalankan server tervirtualisasi yang dapat diganti (cattle)
    • Jika mesin dimatikan, bukti juga bisa ikut hilang. Mungkin semua log tersimpan di luar, tetapi biasanya ada sesuatu yang kurang

  • Tidak semua server dikontainerisasi, tetapi cukup banyak yang berupa kontainer, dan itu punya kesulitannya sendiri
    Alat debugging di dalam image Docker sering ditandai oleh pemindai keamanan otomatis sebagai “alat tidak perlu yang membantu penyerang mengamati dan mengubah perilaku sistem”. Ada kekhawatiran yang valid seperti gdb, tetapi banyak juga yang tidak
    Karena itu, sebagian alat diletakkan di volume terpisah, sebisa mungkin sebagai binary statis, atau dikompilasi dan diinstal dengan path mount sebagai prefix instalasi. Jika perlu debugging, kami meminta tim operasi untuk melakukan mount sementara secara read-only
    Selain itu, jika suatu alat debug mengharuskan fitur kernel tertentu diaktifkan, sering muncul pertanyaan dan kekhawatiran tentang dampaknya terhadap kontainer lain di host yang sama

    • Kalau penyerang bisa mengeksekusi file di filesystem, dan satu-satunya hal yang kurang untuk menjalankannya adalah keberadaan file itu, bukankah mereka bisa langsung menulis file itu sendiri?
      Saya tidak begitu tahu skenario di mana kebijakan ini masuk akal selain “organisasi menggunakan pemindai keamanan dengan keliru”
    • Cara yang lebih baik adalah membuat image kedua yang berisi alat debug dan pengguna root, lalu menjalankannya dengan menempel ke PID namespace dan network namespace milik kontainer produksi
      Untuk memakai debugger, biasanya diperlukan banyak hal seperti izin SYS_PTRACE, pengguna 0, dan flag seperti --privileged, jadi biasanya lebih baik menjalankan kontainer kedua
      Dengan cara ini, kontainer produksi tidak perlu direstart, sehingga kemungkinan kehilangan bukti untuk reproduksi juga berkurang
      Namun, tidak mudah mengingat prosedur ini dalam situasi insiden, jadi harus dicoba sebelumnya dan ditulis langkah demi langkah di runbook

  • Terkait hal itu, sejak FreeBSD 5.2, yaitu tahun 2004, semua sistem FreeBSD memiliki /rescue/*
    Satu binary ber-link statis yang menggabungkan sekitar 150 alat inti di-hardlink dengan nama-nama biasa, dan ukurannya sekitar 17MB
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • Selama 15 tahun saya tidak pernah perlu menggunakannya. Dalam 4–5 tahun terakhir, demi kesehatan mental, saya mem-porting hal-hal yang memungkinkan ke *BSD

  • Saat berada di Netflix, Brendan dan timnya memungkinkan pemasangan alat debugging seperti bpftrace, bcc, dan perf yang berfungsi normal di berbagai tempat
    Alat-alat itu menyelamatkan nyawa saya berkali-kali

  • Saya terkejut strace tidak ada di daftar itu. Biasanya itu salah satu alat pertama yang saya ambil
    Terutama ketika program mengembalikan pesan error yang tidak berguna atau keliru, strace benar-benar berguna

  • Dalam wawancara untuk peran semacam SRE, alat-alat seperti ini selalu dibahas
    Intinya bukan seberapa banyak kandidat menghafal perintah tertentu; kalau mereka memperkenalkan alat baru memang mengesankan, tetapi yang dilihat adalah apa yang mungkin dilakukan, alat apa saja yang ada, dan bagaimana menggunakannya
    Yang penting adalah punya intuisi bahwa kita bisa menangkap dan menganalisis traffic jaringan, system call, profil eksekusi, serta memeriksa kondisi sistem operasi dan hardware

  • Jika dalam situasi krisis seperti ini pemasangan alat tidak memungkinkan, berbagai utilitas bisa dijalankan dengan Docker
    Misalnya membangun kontainer dalam satu baris, menempelkannya ke jaringan host untuk menjalankan alat sejenis netstat, atau me-mount /proc dan menjalankan alat sistem seperti iostat, sar, vmstat, mpstat, pidstat dengan --privileged, --net host, --pid host
    Tentu yum install lebih baik, tetapi jika Docker bisa dipakai dan pemetaan yang diperlukan bisa ditangani, ini bisa menjadi alternatif. Pada konfigurasi rootless atau Podman, kemungkinan besar tidak akan berjalan baik

    • Apakah ada situasi ketika apt tidak bisa mengunduh dan memasang paket, tetapi Docker bisa menarik kontainer baru?
      Apakah mungkin kasusnya library apt rusak atau semacamnya?
    • Jika situasinya jaringan terpisah, itu pengecualian. Semoga beruntung kalau mau menarik image “Ubuntu”
    • Dalam konteks seperti itu, akan bagus jika busybox memuat lebih banyak alat seperti ini
      File berukuran sekitar 1MB yang bisa diunggah ke server dan langsung dijalankan akan sangat membantu

  • Apakah semua orang mendapat akses root? Saya harus membuat tiket administrator sistem untuk melakukan apa pun

    • Sekarang saya konsultan, jadi setiap beberapa bulan pindah ke perusahaan baru. Selalu ada orang-orang yang harus dijaga hubungannya
      Ada baiknya menghafal nama petugas keamanan, orang-orang berjaket kaku yang memberi akses masuk gedung, dan menyiapkan kartu Starbucks
      Bersikap sopan kepada petugas kebersihan dan menghafal nama mereka juga membuat meja saya bersih. Kadang-kadang tinggal sampai larut untuk mengenal orang-orang ini juga ada nilainya
      Ada baiknya juga berteman dengan tim akuntansi. Jika minum kopi, makan siang, berbicara tentang hal selain pekerjaan, dan menunjukkan minat, orang-orang yang tepat akan memberi tahu ketika PHK datang atau dana perusahaan mulai cair
      Bersikap baik juga kepada IT, yaitu orang-orang yang membagikan laptop dan mengelola email. Anda akan melihat seberapa cepat mereka mencabut alat keamanan omong kosong dari komputer Anda, dan seberapa jauh Anda maju dalam antrean upgrade
      Yang paling penting adalah administrator sistem. Bukan hanya karena root, tetapi karena administrator sistem yang baik bisa coding namun tidak pernah mengatakannya keras-keras. Admin yang baik akan memberi tahu di sudut gelap mana ada mayat, dan apakah itu satu lemari atau kuburan massal. Jika Anda belajar membangun sesuai platform mereka, Anda akan mendapat jauh lebih banyak keleluasaan. Jika mereka meminta bantuan, turutilah
    • Dulu saya menangani operasi IT, dan di sini maksudnya sistem, SRE, dan keamanan
      Tulisan ini ditujukan kepada orang-orang yang menjalankan aplikasi di atas infrastruktur yang disediakan IT. Jika harus berinteraksi seperti contoh itu, itu bukan masalah teknis, melainkan kegagalan organisasi
      Kami punya jalur komunikasi yang sangat jelas dan dapat dipercaya, dan orang bergerak bersama pengembangan, operasi, keamanan, serta compliance lewat telepon, bukan chat—atau sekarang mungkin di tempat seperti Teams
      Dalam praktiknya, setiap tim setidaknya punya kontak penghubung, dan biasanya developer menjalankan aplikasi di atas resource yang disediakan tim operasi. Compliance menyetujui konfigurasi, dan keandalan layanan adalah pekerjaan pengembangan. Jika DevOps dilakukan dalam arti seperti ini, banyak masalah hilang

  • Saya tidak melihat nmap, netstat, nc. Alat-alat ini juga menyelamatkan saya berkali-kali

  • Kalau menambahkan satu saja, itu adalah nmap
    Masalah koneksi jaringan tidak selalu tampak jelas di beberapa aplikasi

    • screen, tmux, byobu, pv, rsync, dan tentu saja vim juga diperlukan