Men-debug agen yang dihosting

Mendiagnosis dan memperbaiki masalah umum saat Anda membangun, menjalankan, dan menyebarkan agen dengan azd ai agent untuk Microsoft Foundry. Mulai dengan perintah diagnostik. Kemudian gunakan bagian berbasis gejala untuk memecahkan masalah autentikasi, pengembangan lokal, penyebaran, perintah langsung, log, dan rutinitas.

Prasyarat

Mengumpulkan konteks diagnostik

Sebelum menyelami kesalahan tertentu, gunakan perintah ini untuk mengumpulkan konteks:

# Check extension version
azd ai agent version

# Verify Azure authentication
azd auth login

# Show current environment configuration
azd env get-values

# View agent details
azd ai agent show

# Show the resolved Foundry project endpoint and where it came from
azd ai project show

# Stream production logs
azd ai agent monitor --follow

Untuk laporan kesehatan terstruktur, jalankan azd ai agent doctor. Untuk informasi selengkapnya, lihat Mendiagnosis proyek dengan dokter agen.

Mendiagnosis latensi pemanggilan

Gunakan header debug latensi untuk menentukan apakah permintaan agen yang dihosting lambat menghabiskan waktu di platform, menyediakan infrastruktur, menunggu kontainer, atau memproses permintaan di agen Anda. Header ini adalah sinyal diagnostik, bukan metrik SLA atau penagihan.

Aktifkan diagnostik pada setiap permintaan dengan mengatur x-ms-debug-latency-enabled: true. Jika permintaan tidak menyertakan header ini, respons tidak akan menyertakan x-ms-debug-latency-* header.

  1. Tambahkan header latensi ke permintaan protokol Responses atau Invocations untuk agen yang dihosting. Contoh ini menggunakan protokol Respons:

    ENDPOINT="https://{account}.services.ai.azure.com/api/projects/{project}"
    API_VERSION="v1"
    TOKEN=$(az account get-access-token \
      --resource https://ai.azure.com \
      --query accessToken -o tsv)
    AGENT="my-code-agent"
    
    curl --http2 -i -X POST \
      "$ENDPOINT/agents/$AGENT/endpoint/protocols/openai/responses?api-version=$API_VERSION" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -H "x-ms-debug-latency-enabled: true" \
      -d '{"model":"gpt-5.4-mini","input":"Hello, agent!","stream":false}'
    
  2. Periksa header respons. Semua nilai latensi adalah milidetik bilangan bulat:

    Header Meaning
    x-ms-debug-latency-session-start-type Jenis awal sesi yang dipicu oleh permintaan: mulai dingin (cold), mulai hangat (warm), atau lanjutkan dari kondisi idle (resume).
    x-ms-debug-latency-platform-preprocessing-ms Waktu platform untuk proses penerimaan, autentikasi, pencarian sesi, dan orkestrasi. Ini tidak mencakup penyediaan micro-VM atau penundaan kesiapan kontainer. Tersedia untuk sesi dingin, hangat, dan dilanjutkan dimulai.
    x-ms-debug-latency-infra-setup-ms Saatnya menyediakan mikro-VM. Dihilangkan untuk permintaan hangat.
    x-ms-debug-latency-container-readiness-ms Waktu dari pembuatan mikro-VM hingga kontainer dilaporkan siap. Dihilangkan untuk permintaan hangat.
    x-ms-debug-latency-container-response-ms Waktu sejak proxy meneruskan hingga header respons dikirim. Termasuk transfer permintaan, penyiapan koneksi, penanganan agen, percobaan ulang, dan penyanggaan kebijakan output.
    x-ms-debug-latency-response-begin-ms Waktu total sejak permintaan diterima oleh layanan hingga header respons dikirim. Nilai ini bukan waktu yang diperlukan untuk mencapai byte pertama badan respons atau peristiwa pertama yang dikirim oleh server.

    Keempat komponen waktu tersebut berjumlah x-ms-debug-latency-response-begin-ms. Pada permintaan cold start atau permintaan yang dilanjutkan, jika platform tidak dapat mencatat setiap batas provisioning, platform akan menghilangkan header infrastruktur dan kesiapan serta menghitung waktu tersebut sebagai bagian dari prapemrosesan platform.

  3. Gunakan jenis mulai sesi dan komponen waktu terbesar untuk mengidentifikasi kemungkinan sumber penundaan:

    Result Penafsiran Apa yang harus dilakukan
    x-ms-debug-latency-session-start-type adalah cold atau resume, dan x-ms-debug-latency-infra-setup-ms bernilai tinggi Platform ini menghabiskan waktu untuk menyediakan mikro-VM. Bandingkan beberapa permintaan awal atau permintaan yang dilanjutkan. Jika keterlambatan berlanjut, catat ID respons, tanda waktu, dan header latensi untuk permintaan dukungan.
    x-ms-debug-latency-session-start-type adalah cold atau resume, dan x-ms-debug-latency-container-readiness-ms tinggi Container membutuhkan waktu lama untuk memulai dan melaporkan status siap. Ukur langkah-langkah inisialisasi dalam log startup Anda, kurangi pekerjaan sebelum titik akhir kesiapan tersedia, dan kode aplikasi prakompilasi jika memungkinkan.
    x-ms-debug-latency-platform-preprocessing-ms tinggi untuk setiap jenis awal sesi Penundaan terjadi pada platform sebelum penyediaan micro-VM atau kesiapan kontainer. Buat permintaan dukungan. Sertakan ID respons, stempel waktu, jenis awal sesi, dan header latensi.
    x-ms-debug-latency-container-response-ms, x-ms-debug-latency-first-byte-ms, atau trailer first_byte_ms tinggi Penundaan terjadi setelah penerusan proksi dimulai. Tambahkan instrumentasi pada penangan permintaan dan periksa log agen, pemanggilan model, pemanggilan alat, percobaan ulang, dan penyanggaan output.

Mengurangi waktu kesiapan kontainer

Nilai kesiapan kontainer mencakup waktu yang diperlukan untuk memulai proses Anda, memuat aplikasi, dan mengembalikan HTTP 200 dari /readiness. Tambahkan tanda waktu ke log startup untuk mengidentifikasi impor lambat, pemuatan dependensi, panggilan jaringan, dan pekerjaan inisialisasi lainnya.

Terapkan pengoptimalan ini ke langkah lambat yang Anda identifikasi:

  • Instal dependensi dan kompilasi kode saat Anda membuat gambar. Jangan jalankan penginstalan, pemulihan, atau kompilasi paket di startup kontainer.
  • Gunakan build multistage dan jangan sertakan alat build, cache paket, file uji, dan file pengembangan lainnya dalam image runtime.
  • Hindari panggilan model, migrasi, deteksi alat, dan unduhan aset sebelum sistem siap. Jalankan secara paralel inisialisasi independen yang harus selesai terlebih dahulu.
  • Tetap /readiness fokus pada apakah agen dapat menerima permintaan. Jika Anda menunda inisialisasi, ukur permintaan pertama untuk memastikan bahwa Anda tidak memindahkan penundaan waktu mulai ke penanganan permintaan.

Instal dependensi di lingkungan virtual yang disalin ke dalam image runtime. Kompilasi dependensi sebisa mungkin agar file yang tidak dapat diuraikan dalam paket pihak ketiga tidak menyebabkan build gagal. Kompilasi aplikasi secara ketat agar proses build gagal jika ada kesalahan sintaks.

FROM python:3.13-slim AS build

WORKDIR /app
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q /opt/venv \
      || true; \
    PYTHONDONTWRITEBYTECODE= python -m compileall -q /app

FROM python:3.13-slim AS final

ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app

COPY --from=build /opt/venv /opt/venv
COPY --from=build /app /app

# Precompile the standard library in the runtime image.
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q \
    "$(python -c "import sysconfig; print(sysconfig.get_path('stdlib'))")" \
    || true

CMD ["python", "main.py"]

Mengosongkan PYTHONDONTWRITEBYTECODE untuk langkah build ini memungkinkan Python menulis bytecode ke dalam image. Variabel lingkungan memblokir penulisan bytecode, bukan bacaan, sehingga kontainer yang sedang berjalan masih dapat menggunakan file yang dikompilasi.

Referensi: compileall - Mengompilasi byte pustaka Python

Buat salah satu gambar untuk arsitektur x86-64 yang diperlukan oleh agen yang dihosting:

docker build --platform linux/amd64 -t my-agent:latest .

Di sini, linux/amd64 adalah platform Docker, bukan pengidentifikasi runtime .NET.

Referensi: Persyaratan kontainer agen terhosting

Menyelidiki latensi agen dan model

Jika kesiapan kontainer cepat tetapi respons kontainer atau waktu byte pertama tinggi, fokuskan penyelidikan Anda pada jalur permintaan setelah penerusan dimulai. Jalankan azd ai agent monitor --follow saat mereproduksi permintaan, dan tambahkan pelacakan pada panggilan model, pemanggilan alat, layanan eksternal, percobaan ulang, dan serialisasi respons. Untuk informasi selengkapnya, lihat Memantau log agen terhosting.

Untuk agen yang memanggil model bahasa besar, ukur latensi model secara terpisah sebelum mengubah penyebaran. Bandingkan waktu dengan token pertama, waktu antar token, jumlah token yang dihasilkan, ukuran prompt, pemanfaatan penyebaran, dan pembatasan. Kemudian evaluasi pilihan model, batas token output, streaming, dan pemisahan beban kerja. Lihat Meningkatkan performa OpenAI Azure.

Jika pengukuran menunjukkan tekanan kapasitas yang terus-menerus untuk beban kerja yang dapat diprediksi, evaluasi deployment terprovisi dan tentukan kapasitasnya berdasarkan token input, token output, dan laju permintaan yang teramati. Lihat Throughput yang disediakan.

Memeriksa waktu penyelesaian

Pada HTTP/2 atau versi yang lebih baru, layanan dapat mengembalikan trailer respons x-ms-debug-latency-final sebisa mungkin. Ini mengulangi nilai header respons dan dapat menambahkan bidang ini:

Ladang Meaning
first_byte_ms Waktu sejak permintaan diterima oleh layanan hingga byte pertama dari isi respons atau event yang dikirim server.
total_last_byte_ms Waktu dari penerimaan layanan hingga penerusan respons selesai.

Trailer menggunakan format berversi yang dipisahkan oleh titik koma:

x-ms-debug-latency-final: v=1;start=cold;platform_pre_ms=...;
  infra_ms=...;ready_ms=...;container_response_ms=...;
  response_begin_ms=...;first_byte_ms=...;total_last_byte_ms=...

Respons HTTP/1.1 tidak menyertakan trailer ini. Trailer juga dapat tidak ada setelah pembatalan, pemutusan klien, kesalahan midstream, atau ketika gateway atau SDK tidak mempertahankan trailer. Perlakukan header respons sebagai kontrak diagnostik yang dijamin.

Mengambil hasil latensi tersimpan

Layanan menyimpan data waktu yang dicatat bersama respons atau pemanggilan. Permintaan GET berikutnya untuk respons atau ID pemanggilan yang sama mengembalikan informasi waktu permintaan asli sebagai header respons. Permintaan GET tidak memerlukan header latensi dan tidak mengukur permintaan GET itu sendiri.

Permintaan GET juga dapat mengembalikan nilai penyelesaian ini sebagai header biasa:

Header Meaning
x-ms-debug-latency-first-byte-ms Waktu hingga byte pertama dari bodi respons.
x-ms-debug-latency-total-last-byte-ms Waktu hingga penerusan respons selesai.

Penyimpanan akhirnya konsisten, sehingga permintaan GET segera setelah permintaan asli mungkin belum menyertakan header. Untuk respons atau pemanggilan asinkron, hanya nilai overhead platform yang tersedia: jenis awal sesi, prapemrosesan platform, penyiapan infrastruktur, dan kesiapan kontainer. Header latensi tidak dikirimkan untuk respons proksi yang gagal atau permintaan WebSocket (invocations_ws).

Memperbaiki kesalahan autentikasi

Perbaiki AuthenticationError

Gejala: Agen gagal memulai secara lokal atau mengembalikan 401/403 saat memanggil model AI.

Penyebab dan perbaikan:

  • Kredensial kedaluwarsa -- Jalankan azd auth login untuk menyegarkan sesi Azure Anda.
  • Langganan yang salah -- Verifikasi dengan azd env get-values | grep AZURE_SUBSCRIPTION_ID dan bandingkan dengan langganan proyek Foundry.
  • Peran RBAC yang hilang -- Identitas Anda memerlukan Pengguna Foundry atau akses yang setara pada proyek Foundry.

Important

Peran Foundry RBAC baru-baru ini diubah namanya. Pengguna Foundry, Pemilik Foundry, Pemilik Akun Foundry, dan Manajer Proyek Foundry sebelumnya bernama Pengguna Azure AI, Pemilik Azure AI, Pemilik Akun Azure AI, dan Manajer Proyek Azure AI. Anda mungkin masih melihat nama sebelumnya di beberapa tempat saat penggantian nama diluncurkan. ID peran dan izin inti tidak berubah oleh penggantian nama.

Identitas Anda juga memerlukan Pengguna OpenAI Cognitive Services untuk menggunakan penyebaran model.

Perbaiki AuthorizationFailed selama provisioning

Gejala:azd up atau azd provision gagal dengan kesalahan izin.

Memperbaiki: Minta peran Kontributor pada langganan Azure Anda. Untuk CI/CD, perwakilan layanan juga memerlukan Pemilik Foundry.

Perbaiki SubscriptionNotRegistered

Gejala: Provisi gagal karena penyedia sumber daya yang diperlukan tidak terdaftar.

Perbaikan pada :

az provider register --namespace Microsoft.CognitiveServices
az provider register --namespace Microsoft.ContainerRegistry

Memperbaiki masalah pengembangan lokal

Memperbaiki koneksi yang ditolak pada port 8088

Gejala:azd ai agent invoke --local gagal tersambung.

Penyebab dan perbaikan:

  • Agen tidak berjalan -- Mulai dengan azd ai agent run di terminal terpisah.

  • Konflik port -- Proses lain menggunakan port 8088. Hentikan atau gunakan port kustom:

    azd ai agent run --port 9090
    azd ai agent invoke --local --port 9090 "Hello!"
    
  • Aplikasi gagal saat memulai -- Periksa terminal tempat azd ai agent run berjalan untuk melihat keluaran kesalahan. Penyebab umum meliputi dependensi yang tidak ada, kesalahan impor, atau penggunaan startupCommand yang salah dalam azure.yaml.

Atasi kegagalan instalasi dependensi

Gejala:azd ai agent run gagal saat penginstalan dependensi.

Penyebab dan perbaikan:

  • Versi runtime yang salah -- Pastikan Python 3.10+ atau .NET 8+ diinstal.
  • Hilang requirements.txt atau .csproj -- CLI secara otomatis mendeteksi jenis proyek dari file-file ini. Verifikasi bahwa mereka ada di direktori agen Anda.
  • Masalah jaringan -- Registri paket dapat diblokir oleh proksi perusahaan Anda. Periksa konfigurasi pip atau dotnet Anda.

Perbaiki ResourceNotFound atau DeploymentNotFound

Gejala: Agen berhasil dimulai, tetapi gagal saat mencoba memanggil model.

Penyebab dan perbaikan:

  • Ketidakcocokan titik akhir -- Jalankan azd env get-values dan pastikan bahwa FOUNDRY_PROJECT_ENDPOINT cocok dengan titik akhir yang ditampilkan di portal Foundry.
  • Nama penyebaran model tidak cocok -- Nama penyebaran model yang dikonfigurasi azure.yaml harus cocok dengan nama penyebaran di proyek Foundry Anda. Periksa di portal pada Penyebaran.
  • Sumber daya tidak disediakan -- Jika Anda belum menjalankan azd up , sumber daya cloud tidak akan ada. Jalankan azd up terlebih dahulu, lalu uji secara lokal. Agen lokal tetap mengakses model yang dihosting di cloud.

Memperbaiki masalah penyebaran

Memperbaiki kegagalan build kontainer

Gejala:azd up gagal selama fase build Docker.

Penyebab dan perbaikan:

  • Dockerfile hilang -- Pastikan direktori agen Anda memiliki Dockerfile. Jika Anda menginisialisasi dari templat, ini dibuat secara otomatis.
  • Kesalahan konteks build -- Dockerfile Harus berada di direktori yang ditentukan oleh jalur layanan project di azure.yaml.
  • Penginstalan dependensi di Docker -- Jika pemulihan pip/dotnet gagal di dalam kontainer, periksa apakah Anda requirements.txt atau .csproj memiliki semua dependensi yang disematkan dengan benar.

Perbaiki azd up macet atau habis waktu

Gejala: Provisi atau penyebaran membutuhkan waktu yang sangat lama.

Penyebab dan perbaikan:

  • Penyebaran pertamaazd up -- Pertama menyediakan semua sumber daya Azure, termasuk proyek Foundry, ACR, identitas terkelola, dan penyebaran model, dan dapat memakan waktu 5-10 menit. Penyebaran berikutnya lebih cepat.
  • Build jarak jauh -- Secara default, gambar kontainer dibangun dari jarak jauh di ACR. Ini bisa lebih lambat tetapi tidak memerlukan Docker secara lokal. Untuk membangun secara lokal, atur docker.remoteBuild: false di konfigurasi layanan Anda azure.yaml .
  • Kapasitas wilayah -- Beberapa wilayah mungkin memiliki kapasitas terbatas untuk SKU model tertentu. Coba wilayah lain jika proses penyediaan terus gagal.

Perbaiki agen yang di-deploy tetapi tidak merespons

Gejala:azd ai agent invoke mengalami batas waktu atau menampilkan kesalahan setelah penerapan berhasil.

Penyebab dan perbaikan:

  • Pemeriksaan kesehatan gagal -- Kontainer Anda harus merespons GET /readiness pada port 8088 dengan status 200. Periksa log dengan azd ai agent monitor --follow.
  • Ketidakcocokan protokol -- Pastikan protokol yang ditentukan dalam layanan azure.ai.agent di azure.yaml sesuai dengan yang diimplementasikan oleh kode Anda. Jika azure.yaml mengatakan responses tetapi kode Anda hanya menangani invocations, atau sebaliknya, permintaan gagal.
  • Kontainer mengalami crash -- Periksa log sistem untuk memulai ulang peristiwa: azd ai agent monitor --type system. Penyebab umum meliputi pengecualian yang tidak tertangani dan masalah kehabisan memori. Tingkatkan sumber daya kontainer di azure.yaml jika diperlukan.

Memperbaiki kegagalan perintah langsung

Kesalahan ini berasal dari perintah langsung azd ai, seperti azd ai connection, azd ai toolbox, dan azd ai routine, ketika dijalankan pada proyek Foundry.

Memperbaiki titik akhir proyek Foundry yang tidak diselesaikan

Gejala: Perintah langsung keluar dengan No Foundry project endpoint resolved. Run azd ai project set to set one, or pass --project-endpoint.

Menyebabkan: CLI tidak dapat menemukan titik akhir proyek Foundry di salah satu sumber yang didukung: --project-endpoint bendera, lingkungan aktif azd , konfigurasi global, atau FOUNDRY_PROJECT_ENDPOINT variabel lingkungan.

Perbaikan:

  • Jalankan azd ai project set <endpoint> untuk menyimpan titik akhir di konfigurasi global azd Anda (~/.azd/config.json).
  • Sertakan --project-endpoint (-p) pada setiap perintah: azd ai connection list -p https://my-proj.services.ai.azure.com/api/projects/my-project.
  • Atur FOUNDRY_PROJECT_ENDPOINT di lingkungan shell Anda.

Untuk urutan resolusi lengkap dan ketika setiap sumber menang, lihat Memahami konteks proyek azd.

Memperbaiki kegagalan pembuatan untuk sumber daya yang ada

Gejala:azd ai connection create, azd ai toolbox create, azd ai routine create, atau azd ai skill create gagal dengan kesalahan "sudah ada".

Penyebab: Sesuai desain, create tidak mendukung upsert. Mode kegagalan default mencegah satu pengembang menimpa status orang lain secara diam-diam pada proyek Foundry bersama.

Perbaikan:

  • Pilih nama yang berbeda dan jalankan ulang.
  • Berikan --force, jika didukung oleh perintah create, untuk mengganti sumber daya yang ada melalui ARM PUT. Penggantian bersifat destruktif: tindakan ini menimpa sumber daya yang sudah ada secara langsung, dan setiap perubahan akibat pengeditan manual di portal, metadata, atau kredensial akan hilang. Perintah azd ai toolbox create tidak mendukung --force. Hapus kotak alat yang ada atau gunakan nama baru sebagai gantinya.

Perbaiki keluaran kredensial connection show

Gejala:azd ai connection show <name> mengembalikan nama, jenis, target, dan jenis autentikasi koneksi, tetapi tidak ada kunci API atau nilai kredensial.

Penyebab: Secara desain, nilai kredensial tidak pernah dikembalikan secara default. Mereka memerlukan bendera eksplisit --show-credentials .

Perbaikan pada :

azd ai connection show tavily-conn --show-credentials

Ini memanggil API bidang data dan memerlukan izin bidang data pada proyek Foundry, seperti Pengguna Foundry atau yang setara. Jika Anda hanya memiliki akses management-plane Reader atau Contributor, panggilan akan gagal dengan kode 403. Minta peran data-plane kepada pemilik proyek Anda.

Membaca log agen

Gunakan azd ai agent monitor untuk memeriksa perilaku agen:

# Stream all recent logs
azd ai agent monitor --follow

# View system-level events (container starts, crashes, restarts)
azd ai agent monitor --type system

# Filter to a specific session
azd ai agent monitor --session-id <session-id>

Pola log umum meliputi:

Pesan log Meaning
Listening on 0.0.0.0:8088 Agen berhasil dimulai.
AuthenticationError Masalah kredensial atau RBAC. Periksa identitas terkelola.
ModelNotFound Nama deployment model tidak cocok dengan azure.yaml.
Mulai ulang kontainer dalam peristiwa sistem Perulangan crash. Periksa kesalahan kode atau tingkatkan batas sumber daya.

Mendiagnosis kegagalan rutin

Rutinitas gagal secara berbeda dari panggilan interaktif agent invoke karena tidak ada penelepon yang hadir untuk menampilkan kesalahan. Rutin adalah proses berjalan agen yang dipicu oleh timer, berulang, dipicu oleh issue GitHub, atau dipicu oleh peristiwa kustom. Gunakan azd ai routine run list untuk memeriksa apa yang terjadi.

Periksa eksekusi sebelumnya

# Recent runs of a routine: trigger time, agent input/output, status, trace link
azd ai routine run list daily-digest

Filter ke yang gagal

# Failed runs only, with an OData filter
azd ai routine run list daily-digest --filter "status eq 'failed'"

Gabungkan dengan --top untuk memperlebar atau mempersempit jendela.

Telusuri ke dalam satu eksekusi

# Full detail for the most recent runs as JSON, then look up the run you care about
azd ai routine run list daily-digest --top 5 --output json

Output JSON mencakup payload masukan, respons agen, dan tautan langsung ke jejak terdistribusi, yaitu jejak yang sama seperti yang Anda lihat pada pemanggilan interaktif.

Memicu ulang rutinitas secara manual

Jika Anda perlu mereproduksi kegagalan atau menguji perbaikan, aktifkan rutinitas sesuai permintaan dengan dispatch:

azd ai routine dispatch daily-digest
azd ai routine dispatch triage-issues --input '{"issue":{"number":42}}'

dispatch berjalan secara asinkron dan mencetak ID pengiriman. Periksa hasilnya dengan azd ai routine run list <name>.

Memperbaiki eksekusi rutin yang gagal

azd ai routine run list menampilkan eksekusi dengan status: failed. Ikuti tautan jejak untuk melihat kesalahan agen yang mendasar, seperti kesalahan model, kegagalan alat, atau batas waktu. Perbaikan di sisi agen sama seperti perbaikan untuk kegagalan interaktif. Lihat Memperbaiki kesalahan autentikasi dan Membaca log agen.

Memperbaiki rutinitas yang tidak pernah menembak

Jika azd ai routine run list sama sekali tidak menghasilkan eksekusi, pemicunya sendiri tidak berjalan:

  1. Periksa apakah rutinitas diaktifkan: azd ai routine show <name>. Cari enabled: true.
  2. Untuk pemicu timer, pastikan --at berada di masa mendatang dan belum pernah dipicu.
  3. Untuk pemicu recurring, verifikasi bahwa ekspresi --cron valid dan bahwa --time-zone adalah yang Anda harapkan.
  4. Untuk pemicu github-issue, verifikasi bahwa --connection-id mengarah ke koneksi yang sehat serta bahwa repositori GitHub dan --issue-event sesuai dengan peristiwa yang dipancarkan oleh repositori tersebut.
  5. Untuk trigger custom, pastikan cakupan --provider, --event-name, dan --parameters sesuai dengan event yang dipublikasikan oleh penyedia.

Dapatkan bantuan lainnya

  • Mode debug -- Tambahkan --debug ke perintah azd apa pun untuk keluaran terperinci.
  • portal Azure -- Periksa proyek Foundry di portal Azure untuk kesehatan dan diagnostik sumber daya.
  • Ajukan bug -- Laporkan masalah di github.com/Azure/azure-dev/issues.