คำสั่ง Linux และทักษะเชลล์
curl: เว็บไคลเอ็นต์บรรทัดคำสั่งที่รันเว็บ
curl เป็นไคลเอนต์ HTTP พกพาของทุกกล่องเครื่องมือการดำเนินงาน: การวินิจฉัย เป็นมิตรกับไปป์ไลน์ และซื่อสัตย์เกี่ยวกับสิ่งที่กลับมา พื้นผิวธงดูใหญ่โตและส่วนใหญ่ไม่ได้ใช้งานอยู่: ธงประมาณโหลครอบคลุมการใช้งานในแต่ละวัน และการรู้ว่าสิ่งเหล่านี้คือความแตกต่างระหว่างการตรวจสุขภาพตามสคริปต์กับธงนำโชค กฎที่บันทึกเพจได้มากที่สุดนั้นไม่สำคัญ: set --max-time ทุกครั้ง เพราะความอดทนของ curl นั้นไม่มีที่สิ้นสุด และความอดทนของคุณไม่มี
ประเด็นสำคัญ
- ดูก่อนที่คุณจะดาวน์โหลด: curl -sSI https://host ส่งคืนเมธอด ส่วนหัว และสถานะที่ไม่มีเนื้อหา เพิ่ม -v เมื่อการแฮนด์เชค TLS, พร็อกซี หรือส่วนหัวของโฮสต์ทำงานผิดปกติ
- วินัยการหมดเวลาไม่สามารถต่อรองได้: --connect-timeout 5 ฆ่าการเชื่อมต่อที่ตายแล้ว --max-time 15 ฆ่าการเชื่อมต่อที่ช้า; การตรวจสุขภาพโดยไม่มีทั้งสองอย่างสามารถอยู่ได้นานกว่าการหยุดทำงานที่ควรตรวจพบ
- รหัสออกคือสัญญาในสคริปต์: 7 ถูกปฏิเสธการเชื่อมต่อ, 28 หมดเวลา, 22 คือข้อผิดพลาด HTTP ที่แสดงโดย --fail; อ่านโค้ด ไม่ใช่แค่เอาต์พุต หรือการมอนิเตอร์ของคุณไม่ได้เรียนรู้อะไรเลย
- การมองเห็นคู่กับการบังคับใช้: -w '%{http_code} %{time_total}\n' รายงานสิ่งที่เกิดขึ้น ในขณะที่ --fail-with-body แสดงเนื้อหาข้อผิดพลาด หากไม่มีสิ่งใดสิ่งหนึ่งเหล่านี้ ความล้มเหลวก็ดูเหมือนความสำเร็จทุกประการ
- ทดสอบสิ่งที่ผู้ใช้เข้าชมจริง: --resolve example.com:443:10.1.2.3 ตรวจสอบแบ็กเอนด์ที่มีชื่อโดยไม่มีเกม DNS และ -H 'Host: vhost.example.com' ครอบคลุมด้าน vhost ของคำขอเดียวกัน
- การถ่ายโอนจะได้รับแฟล็กโดยเจตนา: -o ตั้งชื่อเอาต์พุต, -L ติดตามการเปลี่ยนเส้นทางที่คุณได้ตรวจสอบแล้ว, --retry 3 --retry-delay 2 จะทำให้อัปสตรีมที่ไม่สม่ำเสมออ่อนลง และ -F จัดการการอัปโหลดแบบหลายส่วนโดยที่ไม่เคยสนใจ
- ส่วนหัวและซ็อกเก็ตถือเป็นโลกที่ไม่ใช่เบราว์เซอร์: -H 'Authorization: Bearer ...' สำหรับ API และ --unix-socket /run/app/app.sock เพื่อตรวจสอบบริการในพื้นที่ที่ไม่เคยสัมผัส TCP เลย
- รู้จักกับดักแบบคลาสสิกสองประการ: ตัวแปรสภาพแวดล้อมพร็อกซีที่แย่งชิงคำขอที่ -v เปิดเผยภายในไม่กี่วินาที และการเปลี่ยนเส้นทางที่เปลี่ยน POST ให้เป็น GET โดยไม่โต้ตอบ เว้นแต่คุณจะตั้งใจ
บันทึกจากหน้างาน
การตรวจสุขภาพที่หยุดไว้สิบห้านาทีนั้นถูกม้วนงอโดยไม่มี --max-time ภายในลูป cron และใช้เวลานานกว่าการหยุดทำงานที่ควรตรวจพบ ตามหลักการแล้ว การหมดเวลาจะอยู่ก่อน URL
คำถามที่พบบ่อย
เหตุใด curl exit 0 เมื่อไซต์ส่งคืน 500
ความสำเร็จของ curl หมายถึงการขนส่งได้ผล ข้อผิดพลาดระดับ HTTP จะไม่สามารถมองเห็นได้หากไม่มี --fail (ทางออก 22) หรืออ่าน %{http_code} จาก -w สคริปต์การตรวจสอบยืนยันหนึ่งในสองสคริปต์
curl หรือ wget สำหรับสคริปต์?
curl สำหรับ API, ส่วนหัว, ส่วนเนื้อหา POST และการควบคุมที่แม่นยำ wget สำหรับการมิเรอร์และการเรียกซ้ำ สำหรับ one-shot GET ก็ใช้งานได้ และไปป์ไลน์ที่ผสมทั้งสองอย่างมักเป็นสัญญาณบ่งบอกว่าไม่มีใครตัดสินใจว่าใครเป็นเจ้าของงาน
การข้ามการตรวจสอบ TLS เป็นสิ่งที่สมเหตุสมผลหรือไม่
สำหรับการวินิจฉัยเชิงโต้ตอบหนึ่งครั้งกับใบรับรองห้องปฏิบัติการที่ลงนามด้วยตนเองในบางครั้ง ในสิ่งที่เป็นสคริปต์หรือขับเคลื่อนด้วย cron ไม่ใช่ -k ปิดใช้งานการตรวจสอบเดียวที่หยุดบุคคลที่อยู่ตรงกลางจากการเป็นเจ้าของการถ่ายโอนของคุณ
ฉันจะทราบได้อย่างไรว่าคำขอที่ช้านั้นหยุดทำงานจริง ๆ ได้อย่างไร
ตัวแปรกำหนดเวลา: -w 'dns:%{time_namelookup} เชื่อมต่อ:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} รวม:%{time_total}\n' ทำงานสองสามครั้งแยกความไม่แน่นอนของ DNS ออกจากความเจ็บปวดจากการจับมือจากแผงแบ็กเอนด์
Kinetikatech ช่วยเรื่อง คำสั่ง linux และทักษะเชลล์ ได้อย่างไร
พูดตรง ๆ ว่าทีมส่วนใหญ่มาหาเราหลังลองทำเองมาแล้ว: คำสั่งและพฤติกรรมการเขียนสคริปต์ที่ตัดสินใจว่าผู้ดูแลระบบจะใช้งานเซิร์ฟเวอร์หรือต่อสู้กับเซิร์ฟเวอร์: ค้นหา แปลง ถ่ายโอน และดูแลข้อความและกระบวนการด้วยเครื่องมือที่อยู่ในทุกการติดตั้งฐาน บริการ ความปลอดภัยเซิร์ฟเวอร์ Linuxและการจัดการเซิร์ฟเวอร์ ของเรามีอยู่เพื่อไม่ให้คุณต้องเรียนรู้ คำสั่ง linux และทักษะเชลล์ แบบเจ็บปวด เราดูแลทั้งการตั้งค่า การเฝ้าดู และเรื่องกะทันหันตอนตีสาม