Pemicu HTTP di Azure SRE Agent

Pemicu HTTP di Azure SRE Agent adalah titik akhir webhook yang digunakan sistem eksternal untuk memanggil agen Anda sesuai permintaan. Ketika alur CI/CD gagal, alat peringatan mendeteksi anomali, atau klien HTTP apa pun mengirim permintaan POST, agen menerima konteks peristiwa dan mulai bekerja segera.

Masalahnya: peringatan dan kegagalan jalur pemrosesan membutuhkan triase manual

Tim Anda sudah memiliki alat peringatan, pengamatan, dan alur kerja—Datadog, Dynatrace, Jira, Splunk, Grafana—dan pipeline CI/CD yang rusak. Ketika terjadi kesalahan, responsnya sama setiap kali:

Seorang insinyur mendapatkan notifikasi, membuka alat pemantauan, membaca peringatan, kemudian secara manual membuka log, metrik, dan riwayat penyebaran di beberapa dasbor untuk mengetahui apa yang terjadi.
Alur gagal, dan seseorang harus menghentikan apa yang mereka lakukan, memeriksa output build, berkorelasi dengan perubahan terbaru, dan memutuskan apakah akan menggulung balik atau memperbaiki ke depan.
Konteks tersebar—pemberitahuan Datadog mengatakan "Lonjakan CPU pada prod-api" tetapi untuk menemukan akar penyebabnya, diperlukan korelasi log dari tiga layanan, pengecekan penyebaran terbaru, dan peninjauan trace Dynatrace.

Cara kerja pemicu HTTP

Pemicu HTTP memungkinkan Anda menghubungkan alat apa pun yang mendukung webhook langsung ke Agen SRE Anda. Daripada insinyur melakukan triase manual, sistem yang mendeteksi masalah—baik itu pemberitahuan Datadog, anomali Dynatrace, transisi alur kerja Jira, atau kegagalan aliran—memberi tahu agen untuk menyelidiki, memberikan konteks secara otomatis.

Setiap pemicu adalah titik akhir webhook bernama di agen Anda dengan URL unik. Saat sistem eksternal memanggil URL tersebut melalui HTTP POST, agen menjalankan prompt pemicu yang dikonfigurasi—diperkaya dengan data JSON apa pun di isi permintaan.

Konsep utama:

Konsep	Cara kerjanya
Pemicu	Titik akhir bernama dengan perintah, agen yang ditetapkan (default atau subagen), dan tingkat otonomi (otonom atau tinjauan)
URL Pemicu	URL webhook unik yang dihasilkan saat Anda membuat pemicu—inilah yang disebut alat eksternal
Konteks JSON	Isi JSON opsional yang dikirim dengan permintaan POST—menjadi bagian dari perintah agen sehingga memiliki konteks penuh
Riwayat eksekusi	Setiap pemanggilan dicatat dengan penanda waktu, tautan utas, serta status keberhasilan atau kegagalan.
Aktifkan/nonaktifkan	Mengaktifkan atau menonaktifkan pemicu tanpa menghapus—pemicu yang dinonaktifkan mengembalikan 404

Memanggil pemicu

Panggil URL pemicu dengan permintaan HTTP POST:

curl -X POST \
  https://your-agent.sre.azure.com/api/v1/httptriggers/trigger/<TRIGGER_ID> \
  -H "Authorization: Bearer <ARM_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "datadog",
    "alert_title": "High error rate on checkout-api",
    "severity": "critical",
    "service": "checkout-api",
    "region": "eastus2",
    "metric": "error_rate",
    "value": "8.2%",
    "threshold": "5%"
  }'

Bagian	Apa fungsinya
URL	Titik akhir webhook unik pemicu—temukan pada tampilan detail pemicu di bawah URL Pemicu
Otorisasi	Token Pembawa Azure ARM—lihat Autentikasi untuk pemanggilan pemicu
Content-Type	Harus `application/json` jika Anda mengirim isi JSON
Bodi JSON (opsional)	Setiap data JSON yang ingin Anda lihat oleh agen. Ini menjadi bagian dari perintah agen—sertakan konteks apa pun yang membantu agen menyelidiki (nama pemberitahuan, tingkat keparahan, layanan yang terpengaruh, dan sebagainya)

Isi JSON bersifat opsional. Jika Anda memanggil pemicu tanpa isi, agen hanya berjalan dengan perintah pemicu yang dikonfigurasi. Dengan sebuah tubuh, agen melihat baik perintah yang diberikan maupun data yang Anda kirim.

Autentikasi untuk pemanggilan pemicu

Titik akhir pemicu memerlukan token Bearer Azure ARM pada header Authorization: Bearer <TOKEN>. Pemanggil memerlukan Microsoft.App/agents/threads/write izin pada sumber daya agen.

Cara untuk mendapatkan token:

Metode	Paling cocok untuk	Rincian
Prinsipal layanan	Alur CI/CD, sistem otomatis	Membuat pendaftaran aplikasi, menetapkan peran pada sumber daya agen, dan menggunakan alur kredensial klien untuk mendapatkan token
Identitas yang dikelola	Layanan yang dihosting Azure (Azure Functions, VM, Container Apps)	Tidak ada rahasia untuk dikelola—sumber daya Azure mengautentikasi secara otomatis
Azure CLI (antarmuka baris perintah Azure)	Pengujian dan pengembangan	Jalankan `az account get-access-token --resource https://management.azure.com --query accessToken -o tsv`

Menyambungkan alat eksternal yang tidak mendukung autentikasi Azure:

Alat seperti Datadog, Dynatrace, Jira, dan Splunk mengirim webhook dengan format autentikasi mereka sendiri—bukan token Azure ARM. Untuk menjembatani kesenjangan, gunakan salah satu perantara ini:

Perantara	Cara kerjanya
Azure Functions	Menerima webhook, memperoleh token ARM menggunakan identitas terkelolanya, dan meneruskan panggilan ke URL pemicu
Aplikasi Logika	Alur kerja tanpa kode yang menerima webhook dari sumber apa pun dan memanggil API Azure dengan autentikasi ARM bawaan
Azure API Management	Berada di depan URL pemicu dan menangani validasi dan transformasi token melalui kebijakan

Jawaban:

{
  "message": "HTTP trigger execution initiated",
  "executionTime": "2026-03-13T10:30:00Z",
  "threadId": "thread-abc123",
  "success": true
}

Pemicu segera mengembalikan HTTP 202 (Diterima). Agen memproses permintaan secara asinkron.

Apa yang membuat pendekatan ini berbeda

Pemicu HTTP menghubungkan alat peringatan dan CI/CD yang sudah ada langsung ke agen Anda tanpa keterlibatan insinyur. Sistem yang mendeteksi masalah memberi tahu agen untuk menyelidiki, menyampaikan konteks penuh secara otomatis. Tidak ada pemindahan halaman, tidak ada penggantian dasbor, dan tidak ada pencarian konteks secara manual.

Sebelum dan sesudah

Sebelum (triase manual)	Setelah (pemicu HTTP)
Peringatan Datadog terpicu, insinyur dipanggil, membuka 3 dasbor, memulai penyelidikan.	Panggilan webhook Datadog memicu, agen perangkat lunak menyelidiki dan mengunggah temuan secara otomatis.
Ketika pipeline rusak, insinyur memeriksa log build, meninjau PR, memutuskan langkah berikutnya	Penangan kegagalan pipeline memicu panggilan, agen menganalisis kegagalan dan memublikasikan akar penyebabnya
Dynatrace mendeteksi anomali, teknisi berkorelasi secara manual di seluruh layanan	Panggilan webhook Dynatrace dipicu oleh konteks anomali, agen mengaitkan log, metrik, dan penyebaran

Tugas terjadwal vs. pemicu HTTP

Tugas terjadwal	Pemicu HTTP
Berbasis waktu (jadwal cron)	Digerakkan oleh peristiwa (sesuai permintaan)
Berjalan terlepas dari apakah sesuatu terjadi atau tidak	Hanya berjalan saat dipanggil
Tidak ada input eksternal per eksekusi	Data payload yang disuntikkan ke dalam setiap pemanggilan
Terbaik untuk pemeriksaan berulang	Terbaik untuk reaksi berbasis peristiwa

Gunakan keduanya bersama-sama—tugas terjadwal untuk pemantauan proaktif, pemicu HTTP untuk penanganan peristiwa reaktif.

Skenario penggunaan

Integrasi alur CI/CD

Ketika alur penyebaran gagal, panggil agen untuk menganalisis kegagalan:

# In your pipeline's failure handler
curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"pipeline\": \"$PIPELINE_NAME\", \"run_id\": \"$RUN_ID\", \"error\": \"$ERROR_MESSAGE\"}"

Investigasi berbasis peringatan

Sambungkan sistem pemberitahuan Anda untuk memicu penyelidikan otomatis saat pemberitahuan penting diaktifkan:

{
  "alert_name": "Error rate > 5%",
  "severity": "P1",
  "service": "checkout-api",
  "region": "eastus2",
  "start_time": "2026-03-13T10:15:00Z"
}

Pemeriksaan kepatuhan penyebaran

Setelah penyebaran selesai, laksanakan tinjauan kepatuhan.

curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -d '{"deployment_id": "deploy-456", "environment": "production", "changes": ["config update", "image bump"]}'

Referensi API

Titik Akhir	Metode	Deskripsi
`/api/v1/httptriggers`	DAPATKAN	Mencantumkan semua pemicu
`/api/v1/httptriggers/create`	POST	Membuat pemicu baru
`/api/v1/httptriggers/{id}`	DAPATKAN	Dapatkan detail pemicu
`/api/v1/httptriggers/{id}`	TEMPATKAN	Memperbarui properti pemicu
`/api/v1/httptriggers/{id}`	MENGHAPUS	Menghapus pemicu
`/api/v1/httptriggers/{id}/enable`	POST	Mengaktifkan pemicu
`/api/v1/httptriggers/{id}/disable`	POST	Menonaktifkan pemicu
`/api/v1/httptriggers/{id}/execute`	POST	Jalankan pemicu secara manual
`/api/v1/httptriggers/{id}/executions`	DAPATKAN	Dapatkan riwayat eksekusi
`/api/v1/httptriggers/trigger/{id}`	POST	Titik akhir webhook eksternal

Troubleshooting

Pemicu mengembalikan 404

Verifikasi bahwa pemicu diaktifkan—pemicu yang dinonaktifkan mengembalikan 404.
Periksa ID pemicu di URL sudah benar.

401 Tidak Sah

Audiens token harus cocok dengan ID aplikasi Agen SRE, bukan https://management.azure.com.
Untuk mendapatkan token untuk pengujian: az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsv.

Pemicu dijalankan tetapi agen tidak bertindak

Periksa permintaan agen—perintah kosong mungkin tidak menghasilkan output yang berguna.
Verifikasi bahwa subagen yang dipilih memiliki alat yang diperlukan untuk tugas tersebut.
Periksa riwayat pelaksanaan untuk detail kesalahan.

Batasan

Sumber Daya	Limit
Pemicu untuk setiap agen	Tidak ada batas keras
Putaran maksimum per eksekusi	250 putaran
Authentication	Token pembawa diperlukan untuk setiap URL pemicu

Langkah selanjutnya

Membuat dan menguji pemicu HTTP

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-04-02