Linux Kriz Yönetimi Araçları

 (brendangregg.com)
2 puan yazan GN⁺ 2024-03-25 | 1 yorum | WhatsApp'ta paylaş
  • Performans arızası yaşandıktan sonra tanılama araçlarını kurmaya başlarsanız, hazırlık çalışmaları kurtarmadan daha fazla zaman alabilir; bu yüzden Linux sunucu imajlarına kriz yönetimi araçları önceden eklenmelidir
  • Önerilen liste procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool vb. araçlardan oluşur ve CPU·disk·ağ·çekirdek izleme durumunu hemen kontrol etmek için gereken asgari paketlerdir
  • bcc ile bpftrace’in birçok aracı örtüşür; ancak bcc CLI seçenekleri açısından zengindir, bpftrace ise sahada düzenlemesi kolaydır ve çalıştırma sırasında aynı BPF bytecode’unu üretir
  • Arıza sırasında kurulum yapmak; yavaş SSH, bozuk apt ayarları, depo engellemeleri, güvenlik duvarı, değiştirilemez dosya sistemi, izin hataları gibi değişkenler nedeniyle onlarca dakikalık kayba yol açabilir
  • Maliyet çoğunlukla disk alanı ve imaj dağıtım süresidir; ancak önerilen paketlerin çoğu küçüktür, bu nedenle kurumsal Linux dağıtımlarına varsayılan olarak eklenirse performans arızalarına müdahale daha hızlı başlatılabilir

Arıza Öncesinde Hazır Bulundurulması Gereken Asgari Araçlar

  • Bir performans arızası oluştuğunda, nedeni tanılamak için gereken araçları kurmaya harcanan süre başlı başına bir kayıp olur; bu yüzden Linux sunucularda kriz yönetimi araçlarını varsayılan olarak kurulu tutmak daha güvenlidir
  • Liste, Systems Performance 2nd Edition kitabındaki “Linux Crisis Tools” tablosunu temel alır
  • Ubuntu paketleri bazında önerilen araçlar şunlardır
    • procps: ps, vmstat, uptime, top
      • Temel istatistikleri kontrol etme
    • util-linux: dmesg, lsblk, lscpu
      • Sistem günlüklerini ve cihaz bilgilerini kontrol etme
    • sysstat: iostat, mpstat, pidstat, sar
      • Cihaz ve sistem istatistiklerini kontrol etme
    • iproute2: ip, ss, nstat, tc
      • Tercih edilen ağ araçları
    • numactl: numastat
      • NUMA istatistiklerini kontrol etme
    • tcpdump: tcpdump
      • Ağ dinleme/sniffing
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • Profiler ve PMU istatistiklerini kontrol etme
    • bpfcc-tools veya bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile vb.
      • Önceden hazırlanmış eBPF araçları
    • bpftrace: bpftrace, temel sürüm opensnoop, execsnoop, runqlat, biosnoop vb.
      • eBPF betikleme
    • trace-cmd: trace-cmd
      • Ftrace CLI
    • nicstat: nicstat
      • Ağ cihazı istatistikleri
    • ethtool: ethtool
      • Ağ cihazı bilgileri
    • tiptop: tiptop
      • PMU/PMC top
    • cpuid: cpuid
      • CPU ayrıntıları
    • msr-tools: rdmsr, wrmsr
      • CPU ayrıntılı inceleme

bcc ve bpftrace Birlikte Nasıl Değerlendirilmeli

  • bcc ve bpftrace’in birçok aracı örtüşür, ancak kullanışlı oldukları noktalar farklıdır
  • bcc araçları, CLI seçenekleri gibi daha fazla işleve sahip olduğu için tamamlanmış araçlar gibi kullanmaya elverişlidir
  • bpftrace araçları sahada anında düzenlenebilir, bu da duruma göre kontrol yapmayı kolaylaştırır
  • Bu, ikisinden birinin daha hızlı olduğu anlamına gelmez
    • İki araç da aynı BPF bytecode’unu üretir
    • Çalışma sırasında aynı derecede hızlıdırlar
  • bcc, Python tabanlı araçları libbpf C’ye taşıma yönünde evriliyor
    • CO-RE ve BTF kullanır
    • Paketler henüz yeniden işlenmiş değildir
    • Gelecekte bpfcc-tools, yalnızca araç ikililerini içeren daha küçük bir libbpf-tools paketiyle değiştirilmelidir

Sunucu Türüne Göre Gerekli Olabilecek Ek Araçlar

  • Yukarıdaki liste yalnızca asgari listedir
  • Hızlandırıcı bulunan bir sunucuysa, ilgili donanımı analiz edecek araçlar da birlikte eklenmelidir
    • Intel GPU sunucusu: intel-gpu-tools
    • NVIDIA sunucusu: nvidia-smi
  • gdb gibi hata ayıklama araçları da kriz anında hemen kullanılacaksa önceden kurulabilir
  • Temel analiz araçları sık değişmediği için bu listenin birkaç yılda bir güncellenmesi yeterli olabilir

Varsayılan Kurulumun Gerçek Maliyeti

  • Paket eklerken ilk göze çarpan dezavantaj disk kullanımıdır
  • Bulut instance’larında, temel sunucu imajına yalnızca birkaç MB eklenmesi bile instance dağıtım süresini birkaç saniye veya saniyenin küçük bir bölümü kadar artırabilir
  • Önerilen paketlerin çoğu küçüktür ve bcc’nin de daha küçülmesi planlandığından, kapasite ve zaman maliyetinin büyük olmaması gerekir
  • debuginfo’nun toplam boyutu yaklaşık 1GB’a ulaştığı için, varsayılan olarak eklenmesini engelleyen gerçek kapasite endişeleri vardı

Arıza Sırasında Kurulumun Tıkandığı Akış

  • Arıza yaşandıktan sonra araçları kurmaya çalışırsanız, zaman tanılamadan çok kurulum sorunlarını çözmeye akabilir
  • Örnek akış şöyledir
    • 4:00pm: Şirket sitesi çöker veya kullanılamayacak kadar yavaşlar
    • 4:01pm: İzleme panosunda backend sunucu grubunun anormal olduğu görülür ve yüksek disk I/O’dan şüphelenilir
    • 4:02pm: Sunucuya SSH ile bağlanmaya çalışılır, ancak oturum açma çok yavaştır
    • 4:03pm: iostat -xz 1 çalıştırılmak istenir, fakat iostat yoktur ve sysstat kurulum yönlendirmesi çıkar
    • 4:07pm: Paket kurulumu depoyu çözemediği için başarısız olur ve /etc/apt yapılandırma sorunu ortaya çıkar
    • 4:10pm: Düzeltilmiş ayarlarla apt-get update çalıştırılması gerekir, ancak çok yavaştır
    • 4:13pm: Bağlantı zaman aşımı oluşur ve depo bağlantısı ya da performans sorunu olduğundan şüphelenilir
    • 4:17pm: Ağ güvenliği ekibinin beklenmeyen trafiği ve HTTP/HTTPS/FTP outbound apt isteklerini engellediği anlaşılır
    • 4:20pm: Güvenlik duvarı devre dışı bırakıldıktan sonra apt-get update çalışır, ancak kurulumda izin hatası oluşur
    • 4:24pm: Platform güvenliği ekibi, çalıştırılabilir ikili alanları gibi bazı dosya sistemi yazmalarının engellendiği değiştirilemez bir sistem olduğunu açıklar
    • 4:27pm: SRE ekibi büyük ölçekli arızayı duyurur ve yönetim durum güncellemeleri ile kurtarma ETA’sı ister; ancak gerçek tanılama neredeyse hiç ilerlememiştir
    • 4:30pm: cat /proc/diskstats ile kaba bir iostat alternatifi denenir; ancak Linux belgelerini okumak gerekir ve yalnızca diskin meşgul olduğu zaten bilinen gerçek doğrulanır
    • 4:55pm: Yazılabilir dosya sistemine sahip yeni sunucu imajı ayağa kalkar ve sysstat kurulumu mümkün olur; ancak site yalnızca sunucu yeniden başlatıldığı için geri gelmiştir, asıl neden düzeltilmemiştir
    • 12:50am: Güvenlik duvarı ve dosya sistemi güvenliği kapalı bırakıldığı için sitenin hacklenmesiyle örnek devam eder
  • 12:50am olayı gerçek bir deneyim değildir; ancak geri kalanı gerçek deneyime dayalı bir örnektir
  • Önceki iş yerinde yaklaşık 15. dakikada “traffic team”in bulut bölgesi failover’ını başlattığı durumlar olurdu ve iostat kurulumu bittiğinde hedef sistem çoktan boşta kalmış olabilirdi

Varsayılan İmaja Eklenmesi Gereken Neden

  • Yukarıdaki senaryo, prodüksiyon arızası sırasında araçları sonradan kurma yönteminin ne kadar kırılgan olduğunu gösterir
  • Bazı şirketlerde OS ekibi gerekli araçları içeren özel sunucu imajları hazırlayıp zaten kullanıyor
  • Yine de varsayılan Linux sürümünü olduğu gibi işleten birçok site var ve bu durumda ihtiyaç ancak arıza yaşandıktan sonra fark ediliyor
  • Kurumsal Linux dağıtımları bu kriz yönetimi araçlarını varsayılan olarak içerirse, büyük ve küçük şirketler performans arızası yaşandığında tanılamaya hemen başlayabilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-25
Hacker News yorumları

  • Bu liste faydalı. apt deposunu çözümleyememe gibi sunucunun kendisinin karıştığı durumlarda bulut çoğu zaman iyi oturuyor
    Düzeltmeye uğraşmak yerine makineyi öldürür ya da havuzdan çıkarıp yeni bir makine ayağa kaldırırsanız, yeni makine ve uygulama temiz biçimde açılır ve kesinti biter. Sorunlu makineyi hot path dışında ayrıca inceleyebilirsiniz

    • Sorunu “çözdükten” sonra kimsenin o makineyi inceleyecek zamanı olmuyor ya da buna izin verilmiyor; zamanla baştan yeniden build etme yaklaşımı gerçek sorun çözme becerisini ve birikmiş bilgiyi kaybettiriyor
      Fiziksel dünyadaki “sadece parça değiştiren kişi”nin yazılım sürümü haline geliyor
    • “16:10 Yeni makinede de aynı performans sorunu devam ediyor”
    • Bu mutlaka yalnızca bulutun avantajı değil; daha çok sanallaştırılmış, değiştirilebilir sunucu (cattle) işletmenin avantajı
    • Makineyi öldürürseniz kanıtlar da kaybolabilir. Tüm loglar dışarıda tutuluyor olabilir ama genelde bir şeyler eksik kalır

  • Tüm sunucular konteynerleştirilmiş değil, ama önemli bir kısmı konteyner ve bunun kendine özgü zorlukları var
    Docker imajı içindeki hata ayıklama araçları, otomatik güvenlik tarayıcılarında çoğu zaman “saldırganın sistem davranışını gözlemlemesine/değiştirmesine yardımcı olan gereksiz araçlar” diye işaretleniyor. gdb gibi haklı kaygılar var, ama hepsi öyle değil
    Bu yüzden bazı araçları ayrı bir volume’da, mümkünse statik binary olarak tutuyor ya da mount yolunu kurulum prefix’i olarak derleyip kuruyoruz. Hata ayıklama gerektiğinde operasyon ekibinden bunu geçici olarak salt okunur mount etmelerini istiyoruz
    Ayrıca bir debug aracı belirli kernel özelliklerinin etkinleştirilmesini gerektiriyorsa, aynı host’taki diğer konteynerleri nasıl etkileyeceğine dair sık sık soru ve kaygılar doğuyor

    • Saldırgan dosya sisteminde bir dosyayı çalıştırabiliyorsa ve çalıştırmak için eksik olan tek şey o dosyanın varlığıysa, dosyayı doğrudan yazıp koyamaz mı diye düşünüyorum
      Bu politikanın anlamlı olduğu senaryo olarak “organizasyon güvenlik tarayıcısını yanlış kullanıyor” dışında pek bir şey göremiyorum
    • Daha iyi yöntem, debug araçlarını ve root kullanıcısını içeren ikinci bir imaj oluşturup bunu production konteynerinin PID namespace’i ve network namespace’ine bağlayarak çalıştırmak
      Debugger kullanmak için SYS_PTRACE yetkisi, kullanıcı 0, --privileged gibi çok sayıda flag gerektiğinden, ikinci bir konteyner ayağa kaldırmak genelde daha iyidir
      Bu yöntemle production konteynerini yeniden başlatmanız gerekmez; böylece yeniden üretim kanıtını kaybetme olasılığı da azalır
      Ancak bir arıza sırasında bu prosedürü hatırlamak kolay değildir; bu yüzden önceden deneyip adım adım runbook’a yazmak gerekir

  • Bununla bağlantılı olarak FreeBSD 5.2’den, yani 2004’ten beri tüm FreeBSD sistemlerinde /rescue/* var
    Yaklaşık 150 temel aracı tek bir statik linklenmiş binary içinde toplayan dosya, normal adlarla hardlink edilmiş durumda ve boyutu yaklaşık 17 MB
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • 15 yıl boyunca onu kullanmam gerekmedi. Son 4-5 yıldır akıl sağlığım için mümkün olan şeyleri *BSD’ye port ediyorum

  • Netflix’teyken Brendan ve ekibi, bpftrace, bcc, düzgün çalışan perf gibi hata ayıklama araçlarının her yere kurulmasını sağlamıştı
    Bunlar birkaç kez hayat kurtaran araçlardı

  • O listede strace olmamasına şaşırdım. Genelde ilk elime aldığım araçlardan biridir
    Özellikle bir program işe yaramaz ya da yanlış hata mesajı döndürdüğünde strace gerçekten faydalı

  • SRE türü pozisyonların mülakatlarında bu araçlar her zaman ele alınır
    Adayın belirli komutları ne kadar ezbere bildiği asıl mesele değildir; yeni bir araç gösterirse etkileyici olur ama bakılan şey nelerin mümkün olduğu, hangi araçların bulunduğu ve bunların nasıl kullanıldığıdır
    Ağ trafiğini, sistem çağrılarını, çalışma profillerini yakalayıp analiz edebilme; işletim sistemi ve donanım durumunu inceleyebilme sezgisi önemlidir

  • Böyle kriz anlarında araç kurmak mümkün değilse, Docker ile çeşitli yardımcı araçlar çalıştırılabilir
    Örneğin tek satırda konteyner build etmek, host ağına bağlanıp netstat türü araçlar çalıştırmak ya da /proc’u mount edip --privileged, --net host, --pid host ile iostat, sar, vmstat, mpstat, pidstat gibi sistem araçlarını çalıştırmak mümkün
    Elbette yum install daha iyi, ama Docker kullanabiliyor ve gerekli eşlemeleri göze alabiliyorsanız bu bir alternatif olur. Rootless ya da Podman kurulumlarında muhtemelen pek iyi çalışmayacaktır

    • apt paketleri indirip kuramıyorken Docker’ın yeni bir konteyner çekebildiği bir durum var mı?
      apt kütüphanesinin bozulması gibi bir şey mi?
    • Ağ ayrımı varsa istisna. “Ubuntu” imajını çekmek için şans dilemek gerekir
    • Bu bağlamda busybox içinde bu araçlardan daha fazlası olsa iyi olurdu
      Sunucuya yükleyip hemen çalıştırabileceğiniz 1 MB civarında bir dosya çok yardımcı olurdu

  • Herkes root erişimi mi alıyor? Ben ne yaparsam yapayım sistem yöneticisi ticket’ı açmak zorundayım

    • Şu anda danışmanım, birkaç ayda bir yeni bir şirkete gidiyorum. Her zaman iyi geçinmeniz gereken insanlar var
      Güvenlik sorumlularının, binaya girişinizi sağlayan o garip ceketli insanların adlarını ezberlemek ve Starbucks kartı bulundurmak iyi olur
      Temizlik görevlilerine de nazik davranıp adlarını hatırlarsanız masanız temiz kalır. Bazen geç saatlere kalıp bu insanları tanımak değerlidir
      Muhasebe ekibinde de arkadaş edinmek iyi olur. Kahve içip öğle yemeği yiyerek, iş dışı konularda da konuşup ilgi gösterirseniz, doğru kişiler işten çıkarmalar yaklaştığında ya da şirketin parası açıldığında size haber verir
      IT’ye, yani dizüstü bilgisayarları dağıtan ve e-postayı yöneten insanlara da iyi davranmalısınız. Bilgisayarınızdaki saçma güvenlik araçlarını ne kadar hızlı kaldırdıklarını, yükseltme sırasında sizi sırada ne kadar öne aldıklarını görürsünüz
      En önemlisi sistem yöneticisidir. Sadece root yüzünden değil; iyi bir sistem yöneticisi kod yazabilir ama bunu asla yüksek sesle söylemez. İyi bir yönetici, hangi karanlık köşede cesetler olduğunu, bunun tek bir dolap mı yoksa mezarlık mı olduğunu söyler. Onların platformuna uygun build etmeyi öğrenirseniz çok daha fazla hareket alanı kazanırsınız. Onlar bir şey rica ederse yapmalısınız
    • Eskiden IT operasyonundan sorumluydum; burada sistem, SRE ve güvenliği kastediyorum
      Bu yazı, IT’nin sağladığı altyapı üzerinde uygulama işleten kişilere yönelik. Örnekteki gibi etkileşim gerekiyorsa bu teknik bir sorun değil, organizasyonel bir başarısızlıktır
      Bizde çok net ve güvenilir iletişim hatları vardı; insanlar sohbetten ziyade telefonla, günümüzde olsa Teams gibi bir yerde geliştirme, operasyon, güvenlik ve uyumluluk ekipleriyle birlikte hareket ederdi
      Gerçekte her ekipte en azından bir irtibat kişisi vardı ve genellikle geliştiriciler operasyon ekibinin sağladığı kaynaklar üzerinde uygulama çalıştırırdı. Uyumluluk yapılandırmayı onaylar, servis güvenilirliği ise geliştirme işinin parçasıydı. DevOps’u bu anlamda yaptığınızda birçok sorun ortadan kalkar

  • nmap, netstat, nc görünmüyor. Bu araçlar da beni birkaç kez kurtardı

  • Bir tane ekleyecek olsam nmap olurdu
    Ağ bağlantısı sorunları bazı uygulamalarda her zaman açıkça ortaya çıkmaz

    • screen, tmux, byobu, pv, rsync ve tabii ki vim de gerekir