คอนโซลอนุกรม

บันทึกเมื่อ 2026-07-28 จาก CE หนึ่งโหนดของการปรับใช้นี้ sitecli/capture-manifest.json บันทึกว่าเป็นโหนดใด และ scripts/capture-sitecli.sh --check จะตรวจสอบชุดคำสั่ง ซ้ำกับ CE ที่ทำงานอยู่จริง

Azure Serial Console เชื่อมต่อกับพอร์ตอนุกรมจำลองของโหนดผ่านแพลตฟอร์ม Azure โดยไม่ผ่าน control plane ของ F5 Distributed Cloud, data plane ของโหนด หรือเส้นทาง เครือข่ายใด ๆ ที่โหนดควบคุมอยู่ — ซึ่งนั่นคือเหตุผลที่มันใช้งานได้ เมื่อทุกอย่างอื่นใช้ไม่ได้

ใช้วิธีนี้เมื่อ CE ไม่เคยขึ้นมาเลย: การลงทะเบียนล้มเหลว, ไซต์ไม่ปรากฏ ในเทนแนนต์, หรือโหนดทำงานอยู่แต่ไม่มีเส้นทางออก ในทุกกรณีเหล่านั้น debug API ไม่มีอุโมงค์ให้ส่งต่อผ่าน SSH ยังใช้ได้เมื่อ การลงทะเบียนล้มเหลว แต่ต้องมีการเขียนคีย์ไว้แล้วตอนบูตครั้งแรกและคุณต้อง เข้าถึงที่อยู่ภายในของโหนดได้จากภายใน VNet — ซึ่งทั้งสองข้อไม่เป็นจริงสำหรับ โหนดที่คุณเพิ่งพบเป็นครั้งแรก

ลอง Site Console ก่อนวิธีนี้ หากโหนดยังมีเส้นทางเครือข่ายที่ใช้งานได้ แม้เพียงเล็กน้อย: มันก็ยังใช้ได้เมื่อการลงทะเบียนล้มเหลว ไม่ต้องใช้คีย์ และไม่ไล่คนที่ กำลังดูโหนดอยู่ออกไป คอนโซลอนุกรมคือสิ่งที่เหลืออยู่เมื่อเส้นทางเครือข่ายเป็นสิ่งที่ เสียหาย

ข้อกำหนดเบื้องต้น: boot diagnostics

Azure กำหนดให้เปิด boot diagnostics บน VM ก่อนจึงจะเชื่อมต่อคอนโซลอนุกรมได้ ซึ่งเปิดใช้งานโดย terraform/modules/ce-node:

boot_diagnostics {}

บล็อกว่างเปล่าจะเลือกใช้พื้นที่จัดเก็บที่ Azure จัดการให้ ดังนั้นจึงไม่มีบัญชี พื้นที่จัดเก็บ diagnostics, นโยบายวงจรชีวิต หรือคีย์การเข้าถึงที่ต้องดูแล ตรวจสอบบนโหนด:

az vm show -g <resource-group> -n <vm-name> --query diagnosticsProfile

{ "bootDiagnostics": { "enabled": true } }

Boot diagnostics จะเก็บบันทึกอนุกรม ขณะบูต การเปิดใช้งานสำหรับ VM ที่ กำลังทำงานอยู่แล้วจะไม่สร้างบันทึกของการบูตที่เกิดขึ้นไปแล้ว ดังนั้น az vm boot-diagnostics get-boot-log จะตอบว่า:

<Error><Code>BlobNotFound</Code><Message>The specified blob does not exist.

นั่นเป็นเรื่องปกติ ไม่ใช่ข้อผิดพลาด บันทึกการบูตจะมีอยู่หลังจากโหนดรีบูตครั้งถัดไป แต่การเชื่อมต่อคอนโซลแบบสดใช้งานได้ทันที — ไม่ได้ขึ้นอยู่กับบันทึกนั้น

การตรวจสอบความพร้อมใช้งานโดยไม่ใช้เทอร์มินัล

การเชื่อมต่อจำเป็นต้องมีเซสชันแบบโต้ตอบ แต่การตรวจว่ามัน จะ เชื่อมต่อได้หรือไม่นั้น ใช้เพียงสองการเรียก API ทั้งสองมีประโยชน์ในการตรวจสอบสุขภาพระบบ

บริการนี้ต้องถูกเปิดใช้งานสำหรับ subscription — ผู้ดูแลระบบสามารถปิดใช้งาน ทั้งเทนแนนต์ได้:

az rest --method get --url \
  "https://management.azure.com/subscriptions/<sub>/providers/Microsoft.SerialConsole/consoleServices/default?api-version=2018-05-01"

{ "properties": { "disabled": false } }

จากนั้นขอการเชื่อมต่อไปยังพอร์ตอนุกรมของโหนดที่ต้องการ:

az rest --method post \
  --headers "Content-Type=application/json" --body '{}' --url \
  "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>/providers/Microsoft.SerialConsole/serialPorts/0/connect?api-version=2018-05-01"

connectionString ที่เริ่มต้นด้วย wss:// — ในการปรับใช้นี้คือ eastus.gateway.serialconsole.azure.com — หมายความว่าคอนโซลสามารถเชื่อมต่อได้ ในตอนนี้ ก่อนที่จะเปิด boot diagnostics การเรียกนี้ไม่มีอะไรให้เชื่อมต่อเลย

การเชื่อมต่อ

ติดตั้งส่วนขยายหนึ่งครั้ง:
Terminal window
```
az extension add --name serial-console
```

เชื่อมต่อ:

az serial-console connect -g <resource-group> -n <vm-name>

คุณจะมาถึงหน้าจอ login prompt ของโหนดเอง ไม่ใช่เชลล์ ซึ่งอยู่หลังแบนเนอร์การตรวจสอบ ของอุปกรณ์ คอนโซลอนุกรมพิสูจน์ว่า ช่องทาง ใช้งานได้ แต่ไม่ได้ข้ามการยืนยันตัวตน

ยังไม่มีใครล็อกอินผ่านคอนโซลอนุกรมสำเร็จบนการปรับใช้นี้ ดังนั้นหน้านี้จึงไม่ได้ ระบุว่าต้องพิมพ์อะไร admin เป็นบัญชีของอุปกรณ์ที่มีเชลล์เป็น Site CLI และ บัญชีเดียวกันนี้ยืนยันตัวตนผ่าน Site Console ด้วยรหัสผ่าน — แต่ยังไม่ได้แสดงว่ารหัสผ่านนั้นใช้ได้กับ การล็อกอินผ่านคอนโซลอนุกรม และ sshd ใช้เฉพาะคีย์สำหรับ admin ดังนั้นทั้งสอง จึงเห็นได้ชัดว่าไม่ใช่เส้นทางข้อมูลรับรองเดียวกัน

บันทึกจาก f5-xc-ce-vm-01 โดยตัดส่วนกลางที่ผลลัพธ์ของ systemd unit ไม่ได้เพิ่มข้อมูลอะไรออกไป:

+-----------------------------------------------+
Connected to the serial port of the VM.
If no login prompt is displayed, press ENTER.
+-----------------------------------------------+


Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
init_cea_offsets KASLR using RDRAND RDTSC...
Poking KASLR using RDRAND RDTSC...

Welcome to Red Hat Enterprise Linux 9.2024.6.3 (Plow) dracut-057-44.git20230822.el9 (Initramfs)!

[  OK  ] Started Dispatch Password …ts to Console Directory Watch.

... [320 lines of systemd unit output elided]

[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started OpenSSH server daemon.
[  OK  ] Started Container Runtime Interface for OCI (CRI-O).
[   19.960784] cloud-init[1311]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:config' at Sun, 26 Jul 2026 13:13:54 +0000. Up 19.84 seconds.
[  OK  ] Finished Apply the settings specified in cloud-config.
         Starting Execute cloud user/final scripts...
[  OK  ] Started Docker Application Container Engine.
         Starting Argo Watch service...
         Starting VP Manager image load...
[  OK  ] Started Argo Watch service.
[   21.544663] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:final' at Sun, 26 Jul 2026 13:13:56 +0000. Up 21.41 seconds.
[   22.751629] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 finished at Sun, 26 Jul 2026 13:13:57 +0000. Datasource DataSourceAzure [seed=/var/lib/waagent].  Up 22.37 seconds
[  OK  ] Finished Execute cloud user/final scripts.
[  OK  ] Started libcontainer conta…f4b59f3b96c31ee10cd95f6eb371c.


UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED
All actions performed on this device are audited
f5-xc-ce-vm-01 login: [  123.107074] Warning: Deprecated Driver is detected: iptables will not be maintained in a future major release and may be disabled
[  123.144641] Warning: Deprecated Driver is detected: ip6tables will not be maintained in a future major release and may be disabled

มีสี่สิ่งในบันทึกนั้นที่ควรสังเกต เพราะมันตอบคำถามที่ debug API ไม่สามารถตอบได้:

cloud-init เสร็จสมบูรณ์ — Datasource DataSourceAzure เสร็จที่ 22.37 วินาที โหนดที่ไม่เคยลงทะเบียนสำเร็จมักล้มเหลวที่จุดนี้ และนี่คือที่ที่คุณจะเห็นมัน
container runtime ทั้งสองตัวเริ่มทำงาน Container Runtime Interface for OCI (CRI-O) และ Docker Application Container Engine ต่างก็เป็น [ OK ] ซึ่งเป็น หลักฐานตอนบูตของพฤติกรรม dual-runtime ที่ทำให้ผู้คนแปลกใจใน crictl และ docker
VP Manager image load และ Argo Watch service — vpm และ Argo กำลังเริ่มทำงาน
พรอมต์เป็นของโหนดเอง อยู่หลังแบนเนอร์การตรวจสอบของมัน คอนโซลอนุกรมนำคุณไปสู่ หน้าจอล็อกอิน ไม่ใช่เซสชัน

az serial-console connect จะตั้งเทอร์มินัลเป็นโหมด raw ดังนั้นจึงไม่สามารถทำงานจาก ไปป์ไลน์หรือบริบทใด ๆ ที่ไม่มี TTY มันจะล้มเหลวที่ฝั่งไคลเอนต์ ก่อนติดต่อ Azure:

ERROR: (19, 'Operation not supported by device')
  File ".../azext_serialconsole/custom.py", line 633, in connect_serialconsole
    GV.serial_console_instance.launch_console()

traceback นั้นเป็นเรื่องการจัดการเทอร์มินัล ไม่ใช่เหตุขัดข้องของคอนโซลอนุกรม

อย่างไรก็ตาม การเชื่อมต่อเองนั้น สามารถ ทำอัตโนมัติได้ — ให้ควบคุม websocket โดยตรงแทน การใช้ CLI บันทึกด้านบนถูกเก็บมาด้วยวิธีนั้น โดยไม่มี TTY ดู scripts/serial_console_capture.py ซึ่งเป็นวิธีที่คุณจะใช้เก็บหลักฐานการบูตจาก โหนดที่ลงทะเบียนไม่สำเร็จโดยไม่ต้องมีคนนั่งอยู่หน้าเทอร์มินัล

เฟรมแรกของเกตเวย์เป็นการท้าทาย (challenge) ไม่ใช่ผลลัพธ์ และไคลเอนต์ตอบด้วย bearer token แม้ทำถูกต้องแล้ว ซ็อกเก็ตก็มักปิดตัวลงทันที:

[close] code=1011 reason=Connection not trusted

พฤติกรรมที่สังเกตได้: มันสำเร็จเป็นช่วง ๆ และเมื่อใช้งานต่อเนื่อง ทุกโหนดใน resource group จะปฏิเสธ — รวมถึงโหนดที่ใช้งานได้เมื่อไม่กี่นาทีก่อน scripts/serial_console_capture.py จะลองใหม่ตามค่าเริ่มต้นเพราะการลองใหม่มักได้ผล

สาเหตุยังไม่ได้รับการยืนยัน สิ่งที่ถูกตัดออกไปแล้ว เพราะแต่ละข้อเป็น การเดาที่ฟังดูมีเหตุผลแต่เสียเวลา:

ไม่ใช่ข้อนี้	วิธียืนยัน
การจำกัดอัตราของ ARM/compute	กรณีนั้นจะคืนค่า HTTP `429` ในการเรียก ARM แต่นี่คือการปิด websocket บนช่องข้อมูลแยกต่างหาก
การดักจับ TLS โดยพร็อกซี	`openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 \| openssl x509 -noout -issuer` หากผู้ออกใบรับรองเป็น `O=Microsoft Corporation` จริง ก็ตัดข้อนี้ออกได้ หากผู้ออกเป็นผู้ให้บริการพร็อกซี ก็ยืนยันได้ และวิธีแก้คือเพิ่ม `*.serialconsole.azure.com` ในรายการอนุญาต
boot diagnostics ถูกปิดใช้งาน	`az vm show -g <rg> -n <vm> --query diagnosticsProfile` รายงานว่า `enabled: true`
โทเค็นไม่ตรงกันระหว่าง grant และ challenge	การใช้โทเค็นเดียวกันทั้งสองที่เป็นแนวปฏิบัติที่ถูกต้อง แต่ไม่ได้ป้องกันการปิดการเชื่อมต่อ

สิ่งที่ เป็น พฤติกรรมของ Azure ที่มีเอกสารระบุไว้: หนึ่งเซสชันคอนโซลอนุกรมต่อหนึ่ง VM และคำขอที่ สำเร็จรายที่สองจะไล่รายแรกออก ผู้ที่ถูกไล่ออกจะถูกตัดการเชื่อมต่อแต่ไม่ได้ถูก ล็อกเอาต์ ดังนั้นเซสชันเชลล์ยังคงอยู่ สองคนที่ดีบักโหนดเดียวกันจะไล่กันเอง ไปมาซ้ำ ๆ

สำหรับงานจำนวนมาก ให้เลือกใช้ debug API หรือ SSH ซึ่งทั้งสองไม่มี ข้อจำกัดเหล่านี้ โดยเฉพาะ SSH ที่ไม่มีขีดจำกัดการวางข้อความและไม่มีข้อจำกัดเซสชันเดียว ดังนั้นจึงเป็นตัวเลือกที่ดีกว่าเมื่อใดก็ตามที่เข้าถึงโหนดได้จากภายใน VNet

Azure จำกัดความยาวการวางข้อความในคอนโซลอนุกรมไว้ที่ 2,048 อักขระ เพื่อหลีกเลี่ยงการทำให้ พอร์ตอนุกรมทำงานหนักเกินไป การส่งคำสั่งยาว ๆ — หรือชุดคำสั่งหลายคำสั่งในการเขียนครั้งเดียว — จะล้มเหลวใน ลักษณะที่ดูเหมือนการค้างหรือการจำกัดอัตรา แทนที่จะดูเหมือนข้อจำกัดด้านความยาว

ให้ส่งคำสั่งทีละคำสั่ง นี่เป็นข้อจำกัดจริงของการเก็บข้อมูลจำนวนมากผ่านคอนโซล อนุกรม และเป็นอีกเหตุผลที่ควรเลือกใช้ debug API สำหรับงานนั้น

สิ่งที่คุณเห็นได้ที่นี่แต่ API ไม่สามารถแสดงให้คุณเห็น

cloud-init ที่กำลังทำงาน, ล้มเหลว หรือไม่เคยเริ่มเลย — สาเหตุปกติของโหนด ที่ไม่เคยลงทะเบียนสำเร็จ
ความพยายามลงทะเบียน กับ register.ves.volterra.io รวมถึง ข้อผิดพลาดในการกำหนดค่าหรือโทเค็นที่เทนแนนต์ปฏิเสธ
ข้อความจากเคอร์เนลและการบูต จากช่วงก่อนที่เอเจนต์ใด ๆ จะทำงาน
โหนดในขณะที่มัน ไม่มีเส้นทางเครือข่ายที่ใช้งานได้ ซึ่งทำให้เส้นทางอื่นทั้งหมดใช้ไม่ได้

สำหรับโหนดที่ อยู่ในสถานะ ONLINE ให้เลือกใช้ debug API: มันเขียนสคริปต์ได้ สร้าง หลักฐานที่คุณสามารถรันซ้ำได้ และไม่ครองพอร์ตอนุกรมที่มีเพียงพอร์ตเดียว