Linux संकट प्रबंधन टूल्स

 (brendangregg.com)
2 पॉइंट द्वारा GN⁺ 2024-03-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • परफॉर्मेंस समस्या होने के बाद अगर आप डायग्नोस्टिक टूल्स इंस्टॉल करना शुरू करते हैं, तो रिकवरी से पहले तैयारी में ही समय निकल जाता है, इसलिए Linux server image में crisis management tools पहले से शामिल होने चाहिए
  • सुझाई गई सूची में procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool आदि शामिल हैं, और यह CPU·disk·network·kernel tracing को तुरंत जांचने के लिए जरूरी न्यूनतम पैकेज हैं
  • bcc और bpftrace में कई टूल्स एक-दूसरे से मिलते-जुलते हैं, लेकिन bcc में CLI options ज्यादा समृद्ध हैं और bpftrace को मौके पर एडिट करना आसान है; रनटाइम पर दोनों एक ही BPF bytecode आउटपुट करते हैं
  • आउटेज के दौरान इंस्टॉलेशन, धीमे SSH, खराब apt configuration, repository block, firewall, immutable filesystem, permission errors जैसी वजहों से दर्जनों मिनट का नुकसान करा सकता है
  • लागत मुख्य रूप से disk capacity और image deployment time की होती है, लेकिन सुझाए गए ज्यादातर पैकेज छोटे हैं; इसलिए अगर इन्हें enterprise Linux distributions में डिफॉल्ट रूप से शामिल किया जाए, तो परफॉर्मेंस incidents पर प्रतिक्रिया जल्दी शुरू की जा सकती है

समस्या से पहले तैयार रखने वाले न्यूनतम टूल्स

  • परफॉर्मेंस समस्या होने पर root cause पता करने के लिए जरूरी टूल्स इंस्टॉल करने में लगने वाला समय खुद एक नुकसान है, इसलिए Linux servers पर crisis management tools को डिफॉल्ट रूप से इंस्टॉल करके रखना ज्यादा सुरक्षित है
  • यह सूची Systems Performance 2nd Edition की “Linux Crisis Tools” तालिका पर आधारित है
  • Ubuntu packages के आधार पर सुझाए गए टूल्स इस प्रकार हैं
    • procps: ps, vmstat, uptime, top
      • बेसिक statistics जांचना
    • util-linux: dmesg, lsblk, lscpu
      • system logs और device information जांचना
    • sysstat: iostat, mpstat, pidstat, sar
      • device और system statistics जांचना
    • iproute2: ip, ss, nstat, tc
      • पसंदीदा network tools
    • numactl: numastat
      • NUMA statistics जांचना
    • tcpdump: tcpdump
      • network sniffing
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • profiler और PMU statistics जांचना
    • bpfcc-tools या bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile आदि
      • पहले से बने eBPF tools
    • bpftrace: bpftrace, बेसिक version के opensnoop, execsnoop, runqlat, biosnoop आदि
      • eBPF scripting
    • trace-cmd: trace-cmd
      • Ftrace CLI
    • nicstat: nicstat
      • network device statistics
    • ethtool: ethtool
      • network device information
    • tiptop: tiptop
      • PMU/PMC top
    • cpuid: cpuid
      • CPU की विस्तृत जानकारी
    • msr-tools: rdmsr, wrmsr
      • CPU की गहराई से जांच

bcc और bpftrace को साथ में कैसे देखें

  • bcc और bpftrace में कई टूल्स ओवरलैप करते हैं, लेकिन दोनों की उपयोगिता अलग-अलग जगह पर है
  • bcc tools में CLI options जैसी सुविधाएं ज्यादा होती हैं, इसलिए वे तैयार टूल की तरह इस्तेमाल करने के लिए अच्छे हैं
  • bpftrace tools को मौके पर तुरंत एडिट किया जा सकता है, इसलिए स्थिति के अनुसार जांच करना आसान होता है
  • इसका मतलब यह नहीं है कि इनमें से कोई एक ज्यादा तेज है
    • दोनों टूल्स एक ही BPF bytecode आउटपुट करते हैं
    • रनटाइम के दौरान दोनों एक जैसी तेजी से चलते हैं
  • bcc, Python-आधारित tools को libbpf C में ले जाने की दिशा में विकसित हो रहा है
    • यह CO-RE और BTF का उपयोग करता है
    • पैकेज अभी तक दोबारा तैयार नहीं किए गए हैं
    • आगे चलकर bpfcc-tools की जगह सिर्फ tool binaries वाला छोटा libbpf-tools package आना चाहिए

server के प्रकार के अनुसार और जरूरी टूल्स

  • ऊपर की सूची सिर्फ न्यूनतम सूची है
  • अगर server में accelerators हैं, तो उस hardware का विश्लेषण करने वाले टूल्स भी साथ होने चाहिए
    • Intel GPU server: intel-gpu-tools
    • NVIDIA server: nvidia-smi
  • gdb जैसे debugging tools भी अगर crisis के समय तुरंत इस्तेमाल करने हैं, तो पहले से इंस्टॉल किए जा सकते हैं
  • जरूरी analysis tools अक्सर बदलते नहीं हैं, इसलिए इस सूची को शायद कुछ वर्षों में एक बार अपडेट करना ही काफी हो सकता है

डिफॉल्ट इंस्टॉलेशन की वास्तविक लागत

  • packages जोड़ने पर सबसे पहले दिखने वाला नुकसान disk usage है
  • cloud instances में base server image में कुछ MB भी बढ़ें, तो instance deployment time कुछ सेकंड या सेकंड के अंश तक बढ़ सकता है
  • सुझाए गए ज्यादातर packages छोटे हैं और bcc भी आगे और छोटा होने वाला है, इसलिए capacity और time cost बहुत बड़ी नहीं होनी चाहिए
  • debuginfo का कुल आकार लगभग 1GB तक पहुंचता है, इसलिए उसे डिफॉल्ट में शामिल न करने की storage concern वास्तव में मौजूद थी

समस्या के दौरान इंस्टॉलेशन कैसे अटकता है

  • अगर समस्या होने के बाद टूल्स इंस्टॉल करने की कोशिश की जाए, तो diagnosis से ज्यादा समय इंस्टॉलेशन की दिक्कतें सुलझाने में चला जा सकता है
  • उदाहरण के तौर पर यह flow हो सकता है
    • 4:00pm: कंपनी की साइट डाउन हो जाती है या इतनी धीमी हो जाती है कि इस्तेमाल नहीं की जा सकती
    • 4:01pm: monitoring dashboard में backend server group असामान्य दिखता है, और ऊंचे disk I/O का शक होता है
    • 4:02pm: server पर SSH से कनेक्ट करने की कोशिश होती है, लेकिन login बहुत धीमा है
    • 4:03pm: iostat -xz 1 चलाने की कोशिश होती है, लेकिन iostat मौजूद नहीं है और sysstat इंस्टॉल करने का संदेश आता है
    • 4:07pm: package install repository resolve न होने के कारण fail हो जाता है, और /etc/apt configuration की समस्या सामने आती है
    • 4:10pm: ठीक की गई configuration के साथ apt-get update चलाना पड़ता है, लेकिन यह बहुत धीमा है
    • 4:13pm: connection timeout होता है, और repository connectivity या performance समस्या का शक होता है
    • 4:17pm: यह पता चलता है कि network security team ने अनपेक्षित traffic और HTTP/HTTPS/FTP outbound apt requests को block कर दिया है
    • 4:20pm: firewall disable करने के बाद apt-get update चल जाता है, लेकिन install के दौरान permission error आती है
    • 4:24pm: platform security team बताती है कि यह एक immutable system है जिसमें executable binaries area समेत कुछ filesystems पर write block है
    • 4:27pm: SRE team बड़े outage की घोषणा करती है और management status update व recovery ETA मांगता है, लेकिन वास्तविक diagnosis लगभग शुरू ही नहीं हो पाया है
    • 4:30pm: cat /proc/diskstats से iostat का एक अस्थायी और अधूरा विकल्प आजमाया जाता है, लेकिन इसके लिए Linux documentation पढ़नी पड़ती है और सिर्फ यह पुष्टि होती है कि disk व्यस्त है
    • 4:55pm: writable filesystem वाली नई server image आ जाती है और sysstat इंस्टॉल किया जा सकता है, लेकिन server restart की वजह से साइट वापस आ जाती है; root cause अब भी ठीक नहीं हुआ होता
    • 12:50am: firewall और filesystem security बंद छोड़ देने के असर से उदाहरण आगे इस स्थिति तक पहुंचता है कि साइट हैक हो जाती है
  • 12:50am वाली घटना वास्तविक अनुभव नहीं है, लेकिन बाकी उदाहरण वास्तविक अनुभव पर आधारित है
  • एक पिछली नौकरी में लगभग 15 मिनट के आसपास “traffic team” cloud region failover शुरू कर देती थी, और जब तक iostat इंस्टॉल होता, target system पहले ही idle हो चुका होता

इन्हें base image में शामिल करना क्यों जरूरी है

  • ऊपर का scenario दिखाता है कि production outage के दौरान बाद में tools इंस्टॉल करने का तरीका कितना कमजोर है
  • कुछ कंपनियां पहले से OS team द्वारा बनाए गए जरूरी tools वाले custom server images इस्तेमाल करती हैं
  • अब भी कई sites plain default Linux version पर चलती हैं, और ऐसे मामलों में अक्सर समस्या झेलने के बाद ही इसकी जरूरत समझ आती है
  • अगर enterprise Linux distributions ऐसे crisis management tools को डिफॉल्ट रूप से शामिल करें, तो छोटी-बड़ी कंपनियां परफॉर्मेंस समस्या होने पर तुरंत diagnosis शुरू कर सकती हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-25
Hacker News की राय

  • यह सूची उपयोगी है। apt repository resolution fail होने जैसी स्थिति, जहाँ server खुद ही गड़बड़ा गया हो, वहाँ cloud अक्सर सही बैठता है।
    उसे ठीक करने में लगे रहने के बजाय machine को kill कर दें या pool से निकाल दें और नई machine चालू कर दें; नई machine और app साफ़-सुथरे ढंग से ऊपर आ जाते हैं और outage खत्म हो जाता है। problematic machine को hot path से बाहर अलग से investigate किया जा सकता है।

    • समस्या “हल” करने के बाद किसी के पास उस machine को investigate करने का समय नहीं होता या अनुमति नहीं मिलती, इसलिए समय के साथ शुरू से rebuild करने का तरीका असली problem-solving क्षमता और जमा हुई knowledge को खत्म कर देता है।
      यह physical world के “सिर्फ़ parts बदलने वाले व्यक्ति” का software version बन जाता है।
    • “4:10pm नई machine पर भी वही performance issue जारी है”
    • यह केवल cloud का फायदा नहीं, बल्कि virtualized replaceable servers (cattle) चलाने का फायदा ज्यादा है।
    • machine kill करने से evidence भी गायब हो सकता है। हो सकता है सारे logs बाहर मौजूद हों, लेकिन आमतौर पर कुछ न कुछ छूट जाता है।

  • सभी servers containerized नहीं हैं, लेकिन काफी सारे containers हैं और उनकी अपनी मुश्किलें हैं।
    Docker image के अंदर debugging tools को automated security scanners अक्सर “ऐसे unnecessary tools जो attacker को system behaviour observe/modify करने में मदद करते हैं” के रूप में flag कर देते हैं। gdb जैसे tools के लिए यह चिंता वाजिब है, लेकिन कई मामलों में नहीं।
    इसलिए कुछ tools को अलग volume पर, संभव हो तो static binaries के रूप में रखते हैं, या mount path को install prefix बनाकर compile/install करते हैं। debugging की जरूरत पड़े तो operations team से उसे read-only mode में temporary mount करने को कहते हैं।
    साथ ही, अगर कोई debug tool किसी खास kernel feature को enable करने की मांग करता है, तो अक्सर यह सवाल और चिंता उठती है कि उसी host के दूसरे containers पर उसका क्या असर पड़ेगा।

    • अगर attacker filesystem पर file execute कर सकता है, और execution में बस उस file का मौजूद होना ही missing piece है, तो वह सीधे file लिख क्यों नहीं देगा?
      मुझे इस policy का कोई meaningful scenario नहीं दिखता, सिवाय इसके कि “organization security scanner का गलत इस्तेमाल कर रही है।”
    • बेहतर तरीका यह है कि debug tools और root user वाली दूसरी image बनाई जाए और उसे production container के PID namespace और network namespace से जोड़कर चलाया जाए।
      debugger इस्तेमाल करने के लिए SYS_PTRACE permission, user 0, --privileged जैसे कई flags चाहिए होते हैं, इसलिए दूसरी container चलाना आमतौर पर बेहतर होता है।
      इस तरीके में production container restart नहीं करना पड़ता, इसलिए reproduction evidence खोने की संभावना भी कम होती है।
      हालांकि outage के दौरान यह procedure याद रखना आसान नहीं है, इसलिए इसे पहले से try करके runbook में step-by-step लिख देना चाहिए।

  • इसी से जुड़ा हुआ: FreeBSD 5.2, यानी 2004 से, हर FreeBSD system में /rescue/* मौजूद है।
    करीब 150 core tools को एक साथ bundling करने वाली एक statically linked binary होती है, जो आम नामों से hardlink की गई होती है, और उसका size करीब 17MB है।
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • 15 साल में मुझे इसका इस्तेमाल करने की जरूरत नहीं पड़ी। पिछले 4–5 साल से अपनी mental health के लिए जो भी संभव हो, उसे *BSD पर port करता आ रहा हूँ।

  • जब मैं Netflix में था, Brendan और उनकी team ने bpftrace, bcc, ठीक से काम करने वाला perf जैसे debugging tools जगह-जगह install करवा दिए थे।
    ये tools कई बार जान बचाने वाले साबित हुए।

  • हैरानी हुई कि उस सूची में strace नहीं है। आमतौर पर यह सबसे पहले उठाए जाने वाले tools में से एक है।
    खासकर जब कोई program बेकार या गलत error message लौटाता है, तब strace बहुत उपयोगी होता है।

  • SRE-type roles के interviews में हम हमेशा ऐसे tools पर बात करते हैं।
    मुद्दा यह नहीं होता कि candidate को कौन-सी specific command कितनी याद है; नया tool बताना impressive हो सकता है, लेकिन हम देखते हैं कि उसे क्या-क्या संभव है, कौन-से tools मौजूद हैं और उन्हें कैसे इस्तेमाल करना है, इसका अंदाजा है या नहीं।
    network traffic, system calls, execution profile को capture/analyze कर सकने और operating system व hardware state को देख सकने की समझ अहम है।

  • ऐसी crisis situation में अगर tools install करना संभव न हो, तो Docker से कई utilities चलाई जा सकती हैं।
    उदाहरण के लिए container को one-liner में build करना, host network से जोड़कर netstat-type tools चलाना, या /proc mount करके --privileged, --net host, --pid host के साथ iostat, sar, vmstat, mpstat, pidstat जैसे system tools चलाना।
    बेशक yum install बेहतर है, लेकिन अगर Docker इस्तेमाल कर सकते हैं और जरूरी mappings संभाल सकते हैं, तो यह एक alternative है। rootless या Podman setup में शायद यह ठीक से काम न करे।

    • क्या ऐसी स्थिति होती है जहाँ apt package download और install न कर पाए, लेकिन Docker नया container pull कर सके?
      शायद apt libraries टूट गई हों या ऐसा कुछ?
    • network isolation वाली स्थिति exception है। “Ubuntu” image pull करनी हो तो किस्मत अच्छी होनी चाहिए।
    • इसी context में अच्छा होगा अगर busybox में ऐसे और tools शामिल हों।
      server पर upload करके तुरंत चला सकने वाली करीब 1MB की file हो तो बहुत मदद मिलेगी।

  • क्या सबको root access मिल जाता है? मुझे तो कुछ भी करना हो, system administrator ticket raise करना पड़ता है।

    • मैं अभी consultant हूँ, इसलिए हर कुछ महीनों में नई company में जाता हूँ। हमेशा कुछ लोग होते हैं जिनसे अच्छे संबंध रखना जरूरी होता है।
      security वाले, building access दिलाने वाले awkward jacket पहने लोगों के नाम याद रखें और Starbucks cards भी साथ रखें तो अच्छा है।
      cleaning staff से भी विनम्र रहें और उनके नाम याद रखें, तो आपकी desk साफ रहती है। कभी-कभी देर तक रुककर इन लोगों को जानना भी valuable है।
      accounting team में भी दोस्त बनाना अच्छा है। coffee पिएँ, lunch करें, काम के अलावा बातें करें और interest दिखाएँ—सही लोग आपको layoffs आने पर या company का पैसा खुलने पर बता देते हैं।
      IT, यानी जो laptop बाँटते हैं और email manage करते हैं, उनसे भी अच्छे संबंध रखें। फिर देखेंगे कि वे आपके computer से बकवास security tools कितनी जल्दी हटाते हैं और upgrade queue में आपको कितना आगे कर देते हैं।
      सबसे अहम हैं system administrators। सिर्फ root की वजह से नहीं, बल्कि इसलिए कि अच्छे system administrators code लिखना जानते हैं, लेकिन कभी जोर से नहीं कहते। अच्छे admins बताते हैं कि कौन-से अंधेरे कोने में लाशें पड़ी हैं, और वह सिर्फ एक closet है या पूरा graveyard। अगर आप उनके platform के हिसाब से build करना सीख लें, तो आपको कहीं ज्यादा discretion मिलता है। जब वे कोई favor माँगें, तो करना चाहिए।
    • पहले मैं IT operations संभालता था, और यहाँ इसका मतलब systems, SRE और security से है।
      यह लेख उन लोगों के लिए है जो IT द्वारा provide किए गए infrastructure पर apps चलाते हैं। अगर example की तरह interaction करनी पड़े, तो वह technical problem नहीं, बल्कि organizational failure है।
      हमारे पास बहुत clear और reliable communication lines थीं, और लोग chat नहीं बल्कि phone पर—आज के समय में शायद Teams जैसी जगह पर—development, operations, security और compliance के साथ मिलकर काम करते थे।
      असल में हर team में कम से कम एक contact person था, और आमतौर पर developers operations team द्वारा दिए गए resources पर app चलाते थे। compliance configuration approve करता था, और service reliability development work था। इस अर्थ में DevOps करने से बहुत-सी problems गायब हो जाती हैं।

  • nmap, netstat, nc नहीं दिख रहे। इन tools ने भी कई बार बचाया है।

  • अगर सिर्फ एक चीज जोड़नी हो तो वह nmap है।
    network connection problems हर app में हमेशा साफ-साफ सामने नहीं आतीं।

    • screen, tmux, byobu, pv, rsync, और निश्चित रूप से vim भी चाहिए।