https://livekit.io logo
Join Slack
Powered by
nous testons la solution cekura mais nous avons un...
# ask-ai
b
nous testons la solution cekura mais nous avons un ptobleme : Ce qui fonctionne : - Cekura v2 dispatche notre agent correctement - L'injection de matchId via room metadata fonctionne - Le chargement du contexte training via le fallback metadata fonctionne - Le mode debrief ne se déclenche plus par erreur Ce qui bloque : - L'agent Gemini ne produit AUCUNE audio malgré generate_reply() — testé avec 4 approches différentes (direct, on_enter, avec délai, différentes instructions) - L'unique test qui a fonctionné (run 2698505, 3:26 de conversation) était un accident dû au stale metadata Pourquoi on est bloqué : - Pas d'accès aux logs agent : lk agent logs requiert un TTY interactif - Pas de token Sentry pour le projet agent - On debug "à l'aveugle" — impossible de voir ce qui se passe côté Gemini Realtime
t
Thanks for reaching out, Akim. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Merci — je comprends que vous êtes bloqués parce que l’agent Gemini n’émet aucun audio et que vous ne voyez pas de logs (TTY requis pour 
lk agent logs
, pas de token Sentry), ce qui vous empêche de debugger. Voici une démarche claire et pragmatique pour sortir de l’aveugle et identifier la source du problème. Résumé rapide de ce que je réponds : comment accéder aux logs sans TTY, activer le suivi externe (Sentry) et lancer l’agent en local pour obtenir des logs temps réel — plus quelques vérifications rapides spécifiques à l’audio/Gemini. 1) Accéder aux logs depuis la console LiveKit (pas besoin de TTY) • Activez Agent Observability dans le projet : Settings > Data and Privacy > toggle Agent Observability. • Dans le Cloud dashboard : allez dans Sessions, sélectionnez la session concernée (ex. run 2698505), puis ouvrez l’onglet Agent insights → Logs. • Vous pouvez télécharger les logs JSON depuis là pour analyse. Cela donne traces, logs et transcripts synchronisés sans passer par la CLI. 2) Forwarder les logs vers Sentry (ou autre) pour visualisation continue • Ajoutez le DSN Sentry comme secret d’environnement pour l’agent (clé 
SENTRY_DSN
) via le dashboard ou la CLI. • Exemple de principe (à adapter à votre workflow) : ◦ Définir 
SENTRY_DSN=your_dsn_here
dans vos secrets pour l’agent. • Une fois DSN présent, les logs peuvent être remontés automatiquement (fonctionne pour agents hébergés en LiveKit Cloud). 3) Lancer l’agent en local pour voir les logs en temps réel (recommandé) • Utilisez le mode dev pour reproduire le run tout en affichant les logs : ◦ 
lk agent dev --agent-id=<votre-agent-id>
◦ Ou lancez votre agent localement (par ex. 
python agent.py dev
) selon votre projet. • Activez le niveau DEBUG si besoin : 
--log-level=DEBUG
. • En local, vous pourrez voir les appels à 
generate_reply()
, erreurs d’API vers Gemini Realtime, et étapes de génération audio. 4) Vérifications rapides et points à contrôler (spécifiques à l’absence d’audio) • Confirmez que la génération de texte renvoie bien un contenu avant la conversion audio (logs 
generate_reply()
devraient montrer le texte produit). • Vérifiez que la pipeline Text → TTS / Realtime audio est appelée : cherchez dans les logs des événements de création de flux audio ou d’envoi RTP. • Si vous utilisez un modèle Realtime (Gemini Realtime), assurez-vous que 
preemptive_generation=True
est configuré dans 
AgentSession
si votre logique s’appuie dessus. • Vérifiez que l’agent a bien les droits/paramètres pour publier des pistes audio dans la room et que le participant attend l’audio. • Contrôlez si STT/transcription détecte de l’audio entrant (pour confirmer que la chaîne audio fonctionne dans les deux sens). 5) Si un test a « fonctionné par accident » (run 2698505) • Téléchargez les logs de cette session depuis Agent insights — comparez les différences de metadata, ordre d’événements et timeouts par rapport à un run qui échoue. Les logs téléchargés faciliteront l’analyse des variations (ex. stale metadata ayant permis une séquence différente). 6) Prochaines étapes que je peux faire pour vous aider • Si vous me fournissez : ◦ l’ID de session (ex. run 2698505) ou l’agent-id, ◦ un extrait de logs JSON (ou upload des logs téléchargés), ◦ et la configuration de l’agent (snippet montrant 
generate_reply()
/ config TTS / 
preemptive_generation
), alors je peux : • examiner les logs pour pointer l’endroit exact où l’audio n’est pas généré/envoyé, • repérer erreurs d’auth/API vers Gemini Realtime, • recommander des modifications précises de config ou code à tester en local. Si vous préférez, commencez par activer Agent Observability et télécharger les logs du run 2698505, puis partagez-les ici — je regarderai immédiatement ce qu’ils révèlent et vous dirai la marche à suivre la plus rapide pour rétablir l’audio. Je reste disponible pour analyser les logs ou vous guider pas à pas pour le test local. Sources: Streamline troubleshooting with Agent Observability | Where to find your Agent Logs | LiveKit | SIP Lifecycle Management Agent | LiveKit Documentation | Server-side | livekit/livekit_composite | DeepWiki | Server startup modes | LiveKit Documentation
b
comment supprimer des workers self hosted ?
t
Merci — je comprends que vous voulez supprimer des workers self‑hosted. La marche à suivre dépend de l’environnement où ces workers tournent (Kubernetes, Docker, VM, etc.). Voici les options générales et les actions concrètes selon l’environnement ; si vous me dites lequel vous utilisez, je vous donnerai les commandes exactes à exécuter. Résumé rapide : LiveKit ne supprime pas directement vos instances self‑hosted — vous devez arrêter/supprimer le processus ou conteneur sur votre infra. Options selon l’environnement • Kubernetes ◦ Supprimer un Deployment : i. Identifiez le nom du Deployment lié à votre agent/worker. ii. Exécutez : ◦ 
kubectl delete deployment <nom-du-deployment>
◦ Supprimer un Pod directement : ▪︎ 
kubectl delete pod <nom-du-pod>
◦ Bonnes pratiques : ▪︎ Définissez un grace period pour laisser les jobs en cours se terminer. ▪︎ Vérifiez les ReplicaSets/HorizontalPodAutoscaler pour éviter que le déploiement ne recrée automatiquement les pods. • Docker (conteneurs individuels) ◦ Arrêter et supprimer le conteneur : i. 
docker stop <nom-ou-id-du-conteneur>
ii. 
docker rm <nom-ou-id-du-conteneur>
◦ Si vous utilisez Docker Compose : ▪︎ 
docker-compose down
(ou 
docker-compose rm <service>
pour un service précis). ◦ Bonnes pratiques : ▪︎ Inspectez les volumes ou réseaux associés et nettoyez si nécessaire (
docker volume rm
, 
docker network rm
). • Machine virtuelle / process systemd / service ◦ Arrêter le service/processus : ▪︎ 
systemctl stop <nom-du-service>
puis, si nécessaire, 
systemctl disable <nom-du-service>
▪︎ Ou kill le process et supprimer les scripts d’auto‑démarrage. ◦ Supprimer l’instance VM via votre provider (AWS EC2, GCP, Azure) si le worker est dédié. ◦ Bonnes pratiques : ▪︎ Assurez-vous qu’aucune tâche en cours ne sera interrompue de façon critique. • Autres orchestrateurs (Nomad, ECS, etc.) ◦ Utilisez la commande de l’orchestrateur pour arrêter/supprimer le job/service. ◦ Exemples : 
nomad job stop <job>
ou supprimer la Task Definition / Service dans ECS. Points à vérifier avant suppression • Assurez-vous qu’aucune session critique n’est en cours sur ce worker. • Vérifiez si d’autres workers/replicas peuvent prendre la charge (pour éviter perte de disponibilité). • Sauvegardez les logs ou metrics si besoin pour post‑mortem. Ce que je peux faire pour vous maintenant • Dites‑moi quel environnement vous utilisez (Kubernetes, Docker, VM, autre) et le nom/id du worker si disponible. • Je vous fournirai les commandes exactes et les vérifications à faire avant/après suppression. • Si vous voulez, je peux aussi vous expliquer comment éviter que le worker soit recréé automatiquement (ex. scale down, supprimer le Deployment, ou retirer la configuration d’autoscaling). Dites‑moi votre environnement et je vous guide pas à pas. Sources: Self-hosted deployments | LiveKit Documentation | Agent deployment overview | LiveKit Documentation
2 Views
Open in Slack
PreviousNext
Powered by