أوامر Linux الأساسية التي يجب أن يعرفها كل مهندس DEVOPS - الجزء الثاني
تم التحديث: ٢٧ مارس ٢٠٢٦
ملخص
تشخيص الشبكات باستخدام ss (بديل لـ netstat)، و ip (بديل لـ ifconfig)، و curl، و dig؛ وبالمثل انتقلت جدران الحماية من iptables إلى nftables في RHEL 8+ و Debian 11+؛ وتصحيح أخطاء الحاويات (containers) عبر Docker exec، و kubectl exec، و kubectl debug، و crictl؛ والمراقبة في الوقت الفعلي باستخدام htop و btop؛ والتقاط الحزم (packet capture) باستخدام tcpdump (classic BPF) وتتبع النواة (kernel tracing) بشكل أعمق باستخدام أدوات eBPF مثل bpftrace و bcc.
بناءً على أوامر الملفات والأذونات في الجزء الأول، يتعمق الجزء الثاني في الأوامر التي يستخدمها مهندسو DevOps يومياً لاستكشاف الأخطاء وإصلاحها، والمراقبة، وعمليات الحاويات. في عام 2026، ومع هيمنة أعباء العمل المعتمدة على الحاويات على البنية التحتية، أصبح فهم كل من أوامر الشبكة التقليدية وأدوات تصحيح أخطاء الحاويات الحديثة أمراً ضرورياً. يغطي هذا القسم مجموعة أدوات الشبكات، وأوامر مراقبة النظام، والعمليات الخاصة بالحاويات التي تميز مهندسي DevOps ذوي الخبرة عن المبتدئين.
تشخيص الشبكات: مجموعة الأدوات الحديثة
تم إيقاف ifconfig و netstat (من حزمة net-tools) منذ سنوات ولم تعد تُثبت افتراضياً في معظم التوزيعات الحديثة — حيث تشحن RHEL/Rocky و Fedora وإصدارات Debian/Ubuntu الحديثة حزمة iproute2 (التي تشمل ip و ss) بدلاً منها. الأدوات الأحدث أسرع، وأكثر ميزات، وتقرأ مباشرة من واجهة netlink الخاصة بالنواة (kernel).
إعدادات IP (بديل ifconfig):
# Legacy (often not installed by default):
ifconfig # Display all interfaces
# Modern (iproute2):
ip addr show # Show all IP addresses (alias: ip a)
ip addr show eth0 # Show specific interface
ip link set eth0 up # Bring interface up
ip link set eth0 down # Bring interface down
ip route show # Show routing table (alias: ip r)
sudo ip route add 192.168.0.0/24 via 10.0.0.1 # Add static route (needs root)
ip -s link show eth0 # Per-interface counters (rx/tx packets, errors, drops)
أمر ip (من حزمة iproute2) أسرع وأقوى، وهو الأداة القياسية عبر جميع توزيعات Linux الحديثة. استخدمه لجميع مهام تكوين الواجهات. ملاحظة: بالنسبة لجدران الحماية، التحول المماثل هو من iptables إلى nftables — حيث تعتمد RHEL/Rocky 8+ و Debian 11+ افتراضياً على محرك nftables، مع توفير iptables-nft كغلاف توافق للسكربتات القديمة. يجب كتابة القواعد الجديدة لـ nft مباشرة.
اتصالات الشبكة (بديل netstat):
# Legacy (often not installed; slow on hosts with many sockets):
netstat -tlnp # Show listening TCP ports + program
# Modern replacement: ss (socket statistics)
ss -tlnp # Show listening ports (TCP, listening, numeric, program)
ss -tlnpu # Include UDP sockets
ss -atnepo # Show all connections with extended info
ss -tan state established # Show established TCP connections (filter syntax)
ss -tan | grep ESTAB # Same idea via grep (ss prints ESTAB, not ESTABLISHED)
sudo ss -K dst 192.168.1.100 # Kill matching sockets — capital -K, requires CONFIG_INET_DIAG_DESTROY in kernel
يتواصل أمر ss مباشرة مع النواة عبر واجهة netlink/sock_diag، مما يجعله أسرع بكثير من netstat — وهو أمر بالغ الأهمية عند تصحيح مشكلات الاتصال على الأنظمة التي تحتوي على آلاف المقابس (sockets) المفتوحة.
فهم أعلام (flags) ss:
-t: مقابس TCP-u: مقابس UDP-l: المقابس المستمعة (Listening) فقط-a: جميع المقابس-n: إظهار العناوين الرقمية (عدم حل أسماء المضيفين)-p: إظهار اسم العملية/PID-e: معلومات موسعة-o: معلومات المؤقت (Timer)
حل أسماء النطاقات DNS (dig):
dig example.com # Full DNS query
dig example.com +short # Short answer only
dig example.com MX # Mail server records
dig @8.8.8.8 example.com # Query specific nameserver
dig example.com +trace # Trace entire DNS path
nslookup example.com # Alternative (older but still useful)
عندما يفشل اكتشاف الخدمة في Kubernetes أو يتعطل حل DNS، يوفر dig معلومات تصحيح مفصلة تعرض استجابات DNS الدقيقة.
اختبار اتصال HTTP:
curl https://example.com # Simple GET request
curl -I https://example.com # Headers only (useful for status codes)
curl -X POST -d '{"key":"value"}' https://example.com # POST with JSON
curl -H "Authorization: Bearer TOKEN" https://example.com # Custom headers
curl --resolve example.com:443:192.168.1.100 https://example.com # Override DNS
curl -w "%{http_code}\n" -o /dev/null https://example.com # Check status code only
لتصحيح أخطاء API واختبارات الاتصال السريعة، لا غنى عن curl في عمل DevOps.
أوامر تصحيح أخطاء الحاويات
تصحيح أخطاء Docker
Docker ps # List running containers
Docker ps -a # List all containers (including stopped)
Docker logs <container_id> # View container output
Docker logs -f <container_id> # Follow logs in real-time
Docker exec -it <container_id> /bin/bash # Open shell in running container
Docker exec <container_id> cat /etc/hosts # Run command without interactive shell
Docker inspect <container_id> # View detailed container configuration
Docker top <container_id> # View running processes inside container
Docker stats # Real-time resource usage (memory, CPU)
Docker network ls # List networks
Docker network inspect <network> # Inspect specific network
مزيج Docker exec -it ضروري لتصحيح مشكلات التطبيق دون إعادة بناء الحاويات. يحافظ علم -i على بقاء stdin مفتوحاً، ويقوم -t بتخصيص طرفية وهمية (pseudo-terminal).
تصحيح أخطاء Kubernetes
kubectl exec -it <pod> -- /bin/sh # Open shell in pod (sh works on minimal/distroless-ish images)
kubectl exec -it <pod> -- /bin/bash # Use bash if the image actually ships it
kubectl exec <pod> -- cat /var/log/app # Run a one-shot command in the pod
kubectl logs <pod> # View pod logs
kubectl logs -f <pod> # Follow pod logs
kubectl logs <pod> -c <container> # Logs from a specific container
kubectl logs <pod> --tail=50 # Last 50 lines
kubectl logs <pod> --previous # Logs from the previous (crashed) container instance
kubectl describe pod <pod> # Detailed pod information (events, conditions, last state)
kubectl get events -n <namespace> --sort-by=.lastTimestamp # Recent events
kubectl top pod <pod> # Resource usage (requires metrics-server)
kubectl port-forward <pod> 8080:8080 # Forward local port to pod
kubectl cp <pod>:/path/to/file ./local # Copy file from pod
kubectl debug -it <pod> --image=busybox --target=<container> # Ephemeral debug container (no shell needed in image)
عندما يتعطل pod أو يسيء التصرف، فإن kubectl logs --previous و kubectl describe هما محطتك الأولى — فهما يعرضان سبب الحالة الأخيرة والأحداث الأخيرة. بالنسبة للصور التي لا تشحن غلافاً (shell) على الإطلاق (مثل distroless أو scratch)، استخدم kubectl debug لإرفاق حاوية تصحيح أخطاء مؤقتة بدلاً من محاولة عمل exec في الفراغ.
بيئة تشغيل الحاويات (crictl)
بالنسبة للأنظمة التي تستخدم بيئات تشغيل حاويات مثل containerd (شائع في Kubernetes)، استخدم crictl:
crictl ps # List running containers
crictl logs <container_id> # View container logs
crictl exec -it <container_id> /bin/bash # Shell into container
crictl inspect <container_id> # Container details
crictl images # List pulled images
أداة crictl ضرورية على عقد (nodes) Kubernetes حيث قد لا يكون Docker مثبتاً ولكن containerd موجود.
مراقبة النظام والأداء
htop (مراقب العمليات التفاعلي)
htop # Interactive process list
htop -p <pid> # Monitor specific process
htop -u <username> # Monitor specific user's processes
# Within htop: press F6 to sort by different columns (CPU, memory, etc.)
أداة htop تتفوق بمراحل على top، حيث توفر مخرجات ملونة، وفرزاً أفضل، وواجهة تفاعلية.
btop (مراقب الموارد الحديث)
btop # Full system resource overview
# Shows: CPU, memory, disks, network, processes
# Interactive: sort by column, search processes, kill processes
أداة btop هي إعادة تنفيذ حديثة لـ top و htop مع واجهة طرفية رسومية تعرض المعالج والذاكرة والقرص والشبكة في عرض واحد.
مراقبة إدخال/إخراج القرص (Disk I/O)
sudo iotop # Real-time disk I/O by process (needs root)
sudo iotop -o # Only show processes currently doing I/O
sudo iotop -b -n 5 # Batch mode, 5 iterations (good for logging)
iostat -x 1 # Extended I/O statistics, refresh every 1 second
dstat -cdn # CPU, disk, and network in one view
# Note: dstat is unmaintained on some distros; Fedora/RHEL replaced it with `dool` (a fork)
عند مواجهة اختناقات في إدخال/إخراج القرص، تعرض iotop فوراً العمليات التي تستهلك القرص بكثافة.
مراقبة حركة مرور الشبكة
nethogs # Bandwidth usage by process
nethogs -r # Reverse sorting (highest bandwidth first)
iftop # Live network bandwidth by host
iftop -P # Show ports
nload # Simple bandwidth graph
تعرض nethogs أي تطبيق يستهلك النطاق الترددي — وهو أمر بالغ الأهمية لتحديد "الجيران المزعجين" في البنية التحتية المشتركة.
تحليل الذاكرة
free -h # Human-readable memory usage
free -h -s 2 # Refresh every 2 seconds
ps aux --sort=-%mem | head -10 # Top 10 memory-consuming processes
pmap -x <pid> # Memory map of specific process
smem -k -s swap -r # Per-process memory sorted by swap, descending (apt/dnf install smem)
التقاط الحزم وقابلية الملاحظة عبر eBPF
التقاط الحزم باستخدام tcpdump
أداة tcpdump هي الأداة الكلاسيكية لالتقاط الحزم. تستخدم BPF الأصلي (classic Berkeley Packet Filter) عبر libpcap لتصفية الحزم في النواة — لاحظ أن هذا ليس نفس eBPF، على الرغم من النسب المشترك.
sudo tcpdump -i eth0 # Capture all traffic on eth0
sudo tcpdump -i eth0 port 80 # Capture HTTP traffic
sudo tcpdump -i eth0 src 192.168.1.100 # Capture traffic from specific IP
sudo tcpdump -i eth0 -w capture.pcap # Save to file for analysis
sudo tcpdump -i eth0 -A # Print packet contents (ASCII)
قابلية الملاحظة القائمة على eBPF
تسمح eBPF (extended BPF) بتشغيل برامج معزولة (sandboxed) في النواة دون الحاجة لإعادة تجميعها أو تحميل وحدات مخصصة. تعتمد عليها عدة أدوات ناضجة:
- bpftrace — لغة تتبع عالية المستوى لـ kprobes و uprobes و tracepoints وأحداث USDT.
- bcc (BPF Compiler Collection) — مجموعة أدوات Python/C مع مرافق مثل
execsnoop، وtcplife، وbiolatency، وopensnoop. - falco — مراقبة أمن وقت التشغيل؛ تشحن مسبار eBPF CO-RE حديثاً إلى جانب محرك وحدة النواة القديم الخاص بها.
- Cilium / Hubble — الشبكات وقابلية الملاحظة لـ Kubernetes المبنية على eBPF.
مثال باستخدام bpftrace — سرد كل ملف يتم فتحه على مستوى النظام بالكامل:
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'
إدارة العمليات
ps aux # List all running processes
ps aux | grep nginx # Find specific process
ps -ef --forest # Process tree (hierarchical view)
pgrep -a python # Find python processes; -a prints command line (replaces older `-l`)
pgrep -f "manage.py runserver" # Match against full command line, not just process name
pkill -f "old_process" # Send SIGTERM to processes matching command line
pkill -TERM -f "old_process" # Same as above, signal made explicit
kill <pid> # Send SIGTERM (graceful shutdown)
kill -9 <pid> # Send SIGKILL (force kill, last resort)
killall nginx # Kill all processes named exactly "nginx" (dangerous on shared hosts!)
fg # Bring background job to foreground
bg # Resume stopped job in background
jobs # List background jobs
wait <pid> # Wait for process to complete
تُفضل أدوات pgrep و pkill عادةً على killall لأنها تطابق سطر الأوامر بالكامل باستخدام -f (لذا يمكنك استهداف سكربت Python محدد، وليس كل عملية تسمى python)، ويمكنك معاينة المطابقات باستخدام pgrep قبل إرسال الإشارات إليها.
معلومات النظام
uname -a # Kernel version and system info
lsb_release -a # Linux distribution version
cat /proc/cpuinfo # CPU information
cat /proc/meminfo # Memory information
lscpu # CPU architecture summary
lsblk # Block devices and partitions
lspci # PCI devices (GPUs, NICs)
lsusb # USB devices
عند استكشاف مشكلات التوافق أو مشاكل الأداء، يعد التحقق السريع من إصدار النواة ومواصفات الأجهزة أمراً ضرورياً.
ورقة مرجعية سريعة
| المهمة | الأمر | حالة الاستخدام |
|---|---|---|
| البحث عن المنافذ (ports) المفتوحة | ss -tlnp | حل تعارضات المنافذ |
| مراقبة العمليات (processes) | btop أو htop | التحقق من استهلاك المعالج والذاكرة |
| عرض سجلات الحاويات (container logs) | Docker logs -f <id> | تصحيح أخطاء الحاويات |
| تصحيح أخطاء شبكة الـ pod | kubectl exec -it <pod> -- sh | استكشاف أخطاء الشبكة وإصلاحها (استخدم bash إذا كانت الصورة تدعمه) |
| مراقبة مدخلات ومخرجات القرص (disk I/O) | iotop -o | البحث عن اختناقات الـ I/O |
| التحقق من دقة الـ DNS | dig example.com | استكشاف أخطاء الـ DNS وإصلاحها |
| مراقبة عرض النطاق الترددي (bandwidth) | nethogs -r | البحث عن العمليات المستهلكة للشبكة |
| عرض شجرة العمليات | ps -ef --forest | فهم التسلسل الهرمي للعمليات |
الخلاصة
الجزء الثاني يزودك بأدوات الشبكات والمراقبة وتصحيح أخطاء الحاويات الضرورية لعمل الـ DevOps في بيئات الإنتاج. إن إتقان ss و ip و curl للشبكات؛ و Docker exec و kubectl exec لتصحيح أخطاء الحاويات؛ و btop و iotop و nethogs للمراقبة الفورية يجعلك فعالاً في تشخيص مشاكل البنية التحتية بسرعة. ومع استمرار تبني تقنيات الحاويات و Kubernetes في عام 2026، تظل هذه الأوامر أساسية في حقيبة أدوات أي مهندس DevOps.