การใช้ K8s ในการ Monitor Airflow

[brabigz]

สวัสดีครับ

อยากรู้ว่าเราจะใช้ K8s มาช่วยในการ Monitor พวก Airflow ยังไงเหรอครับ
สิ่งที่กำลังทำตอนนี้คือ
ใช้ Airflow ผ่าน Composer บน GCP
Monitor piepline ผ่าน PowerBI โดยการดึงข้อมูล log มาจาก Airflow หรือ
เข้าไปดูหน้า UI ของ Airflow ว่ามัน Pass รึเปล่า แต่ก็ไปอ่านเจอว่าหลายๆ ที่เขาใช้ K8s ในการ Monitor เลยอยากจะฟัง use cases เพิ่ม เผื่อจะสามารถนำมาปรับใช้กับงานปัจจุบันได้ครับ

[kahnwong]

Cloud Composer จริง มันก็คือ Airflow บน K8s น่ะแหละ แต่ GCP จัดการหลังบ้านให้

ทีนี้ ปกติ services ของ GCP มันจะพ่น metrics ทุกสิ่งอย่างไปซักที่ ซึ่ง Cloud Monitoring (GCP) จะมองเห็น และใช้ดู metrics ต่างๆ ได้

ท่าปกติของ k8s คือ วางของไว้ แล้วใส่ grafana stack ให้มันเก็บ logs + metrics แล้วเอา dashboard มาครอบ

Cloud Monitoring ของ GCP ก็คือ grafana น่ะแหละ

สรุปสั้นๆ ก็คือ ไม่ต้องทำอะไรถ้าใช้ GCP อยู่แล้ว ไปขูดของออกมาจาก airflow logs ไม่ก็ cloud monitoring เอา หรือจะเข้าไปดู cloud monitoring ตรงๆ เลยก็ได้

[brabigz]

ขอบคุณครับเห็นภาพมากขึ้นแล้วครับ

แปลว่าคนที่ใช้ท่าปกติเนี่ยจะใช้ framework หรือ opensource ที่ไม่ได้อยู่ใน cloud service มาต่อกับ k8s เพื่อใช้ในการ monitoring ประมาณนี้ไหมครับ เพราะ k8s ท่าปกติเลยสะดวกกว่าเพราะมัน flexible ได้

[kahnwong]

ต้องแยกกัน ระหว่าง:

• ท่า Self-managed: ลง airflow บน k8s เอง (ก็คือ เข้าไปใน cluster แล้วเอาของไปวางได้) แล้วก็เอา monitoring stack ไปลงในนี้ จะได้ดูสัญญาณชีพได้
• ท่า PaaS: ใช้ Cloud Composer / managed Airflow ที่ทาง platform จัดการทุกอย่างให้แล้ว ไม่ต้องทำอะไรเพิ่ม เข้าไปดู metrics & logs ได้เลย

เพราะฉะนั่น ท่าปกติที่ว่า ขึ้นอยู่กับว่า ใช้ PaaS หรือ Self-managed

[zkan]

ของผมไม่ได้ใช้ Airflow ที่เป็น managed service ครับ จะใช้ตามที่เค้าใช้กันทั่วไปเลยแบบนี้ ซึ่งแบบนี้ก็จะต้องลง Prometheus เพิ่ม เพื่อเอามาเก็บ metrics แล้วใช้ Grafana เป็น dashboard ดู metrics

Ref: Logging and Monitoring architecture — Airflow 3.1.3 Documentation

ถ้าใช้ Cloud Composer ก็ไม่ต้องทำอะไรเพิ่มครับ ตามคอมเม้นต์ด้านบนได้เลย เข้าไปดูใน Cloud Monitoring

[atb]

เสริมเรื่องการ monitor Airflow ครับ

การ monitor Airflow จริง ๆ มีหลายท่าเลย จุดประสงค์เราคือต้องการมั่นใจว่า Airflow และ pipelines ต่าง ๆ ยังทำงานได้ปกติตามที่เราคาดหวัง

• Web UI (built-in monitoring) อันนี้ดูง่าย ใช้ได้เลย
• Email (SMTP) ส่งเมลตาม events ที่เราสนใจได้ เช่น ส่งตอน DAG Run พัง
  • ถ้าสะดวก channels อื่น ก็ได้เช่นเดียวกัน เช่น slack
• SLA/Deadline Alerts กำหนดเวลาการทำงานให้ DAG Run, Task ถ้าเลยเวลาก็พัง พังแล้วก็ส่งเมล
• Metrics อันนี้เราจะเก็บเอา metrics ต่าง ๆ มาใช้งานต่อ เช่น ทำหน้าจอ dashboard ทำ alerts

  • ตัวอย่าง metrics เช่น จำนวน task พัง หรือ จำนวน pool slot ที่เหลือ

  • ไม่ว่าจะเป็น Airflow ที่ run ในเครื่องตัวเอง หรือ run บน Kubernetes จะต้อง set up การเก็บ metrics ก่อนถึงจะใช้งานต่อได้ (Cloud Composer ทำให้อัตโนมัติ)

  • มี metrics แล้วคำถามคือจะเอาไปใช้ยังไง ด้วยเครื่องมืออะไร เช่น เอาไปทำ dashboard และ alerts ด้วย Grafana ก็ต้องดูต่อว่าจะส่ง metrics ไปหา Grafana ยังไงต่อ เช่น ท่ามาตรฐานก็จะส่งเข้าไปเก็บใน Prometheus ก่อนแล้วให้ Grafana มาจิ้มอีกที

  • ตัวอย่างหน้าจอ dashboard ที่ใช้ Grafana

    

สรุปก็คือการ monitor มีหลายวิธีครับ ไม่ว่า Airflow จะ run ที่ไหนเราก็ monitor ได้ เลือกวิธีที่สะดวก หลาย ๆ ที่อาจจะ run Airflow บน Kubernetes แต่หลักการการ monitor ก็ไม่ต่างจาก run ที่อื่น อาจจะสะดวกในเรื่องของการ deploy ร่วมกับ monitoring tools ต่าง ๆ ใน cluster เดียวกัน