Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Configuration et utilisation de la journalisation dans le AWS SDK pour Rust AWS SDK pour Rust Utilise le cadre de [suivi](http://tracing.rs/) pour la journalisation. Pour activer la journalisation, ajoutez la `tracing-subscriber` caisse et initialisez-la dans votre application Rust. Les journaux incluent les horodatages, les niveaux de journalisation et les chemins des modules, ce qui permet de déboguer les requêtes d'API et le comportement du SDK. Utilisez la variable d'`RUST_LOG`environnement pour contrôler la verbosité du journal, en filtrant par module si nécessaire. ## Comment activer la connexion dans le AWS SDK pour Rust 1. Dans une invite de commande pour le répertoire de votre projet, ajoutez la caisse [tracing-subscriber](https://crates.io/crates/tracing-subscriber) en tant que dépendance : ``` $ cargo add tracing-subscriber --features tracing-subscriber/env-filter ``` Cela ajoute la caisse à la `[dependencies]` section de votre `Cargo.toml` fichier. 1. Initialisez l'abonné. Cela se fait généralement au début de la `main` fonction avant d'appeler un SDK pour une opération Rust : ``` use aws_config::BehaviorVersion; type BoxError = Box; #[tokio::main] async fn main() -> Result<(), BoxError> { tracing_subscriber::fmt::init(); // Initialize the subscriber. let config = aws_config::defaults(BehaviorVersion::latest()) .load() .await; let s3 = aws_sdk_s3::Client::new(&config); let _resp = s3.list_buckets() .send() .await?; Ok(()) } ``` 1. Activez la journalisation à l'aide d'une variable d'`RUST_LOG`environnement. Pour activer l'affichage des informations de journalisation, dans une invite de commande, définissez la variable d'`RUST_LOG`environnement au niveau auquel vous souhaitez vous connecter. L'exemple suivant définit la journalisation au `debug` niveau suivant : ------ #### [ Linux/macOS ] ``` $ RUST_LOG={{debug}} ``` ------ #### [ Windows ] Si vous utilisez VSCode, la fenêtre du terminal est souvent définie par défaut sur PowerShell. Vérifiez le type d'invite que vous utilisez. ``` C:\> set RUST_LOG={{debug}} ``` ------ #### [ PowerShell ] ``` PS C:\> $ENV:RUST_LOG="debug" ``` ------ 1. Exécutez le programme : ``` $ cargo run ``` Vous devriez voir une sortie supplémentaire dans la console ou dans la fenêtre du terminal. Pour plus d'informations, consultez la section [Filtrage des événements à l'aide de variables d'environnement](https://docs.rs/tracing-subscriber/0.3.18/tracing_subscriber/fmt/index.html#filtering-events-with-environment-variables) dans la `tracing-subscriber` documentation. ## Interpréter la sortie du journal Une fois que vous avez activé la journalisation en suivant les étapes de la section précédente, les informations de journal supplémentaires seront imprimées en standard par défaut. Si vous utilisez le format de sortie de journal par défaut (appelé « complet » par le module de suivi), les informations que vous voyez dans la sortie du journal ressemblent à ceci : ``` 2024-06-25T16:10:12.367482Z DEBUG invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt:lazy_load_identity: aws_smithy_runtime::client::identity::cache::lazy: identity cache miss occurred; added new identity (took 480.892ms) new_expiration=2024-06-25T23:07:59Z valid_for=25066.632521s partition=IdentityCachePartition(7) 2024-06-25T16:10:12.367602Z DEBUG invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt: aws_smithy_runtime::client::identity::cache::lazy: loaded identity 2024-06-25T16:10:12.367643Z TRACE invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt: aws_smithy_runtime::client::orchestrator::auth: resolved identity identity=Identity { data: Credentials {... }, expiration: Some(SystemTime { tv_sec: 1719356879, tv_nsec: 0 }) } 2024-06-25T16:10:12.367695Z TRACE invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt: aws_smithy_runtime::client::orchestrator::auth: signing request ``` Chaque entrée inclut les éléments suivants : + Horodatage de l'entrée du journal. + Le niveau de journalisation de l'entrée. Il s'agit d'un mot tel que `INFO``DEBUG`, ou`TRACE`. + Ensemble imbriqué de plages à partir [duquel](https://docs.rs/tracing/latest/tracing/span/index.html) l'entrée du journal a été générée, séparées par des deux-points (« : »). Cela vous permet d'identifier la source de l'entrée du journal. + Le chemin du module Rust contenant le code qui a généré l'entrée du journal. + Texte du message du journal. Les formats de sortie standard du module de traçage utilisent des codes d'échappement ANSI pour coloriser la sortie. Gardez ces séquences d'échappement à l'esprit lorsque vous filtrez ou recherchez la sortie. **Note** Dans `sdk_invocation_id` l'ensemble imbriqué de plages apparaît un identifiant unique généré côté client par le SDK pour aider à corréler les messages du journal. Il n'est pas lié à l'ID de demande trouvé dans la réponse d'un Service AWS. ## Ajustez vos niveaux de journalisation Si vous utilisez une caisse qui prend en charge un filtrage d'environnement, par exemple`tracing_subscriber`, vous pouvez contrôler la verbosité des journaux par module. Vous pouvez activer le même niveau de journalisation pour chaque module. Ce qui suit définit le niveau de journalisation `trace` pour chaque module : ``` $ RUST_LOG={{trace}} cargo run ``` Vous pouvez activer la journalisation au niveau du traçage pour un module spécifique. Dans l'exemple suivant, seuls les journaux provenant de `aws_smithy_runtime` seront entrés au `trace` niveau. ``` $ RUST_LOG={{aws_smithy_runtime}}={{trace}} ``` Vous pouvez spécifier un niveau de journalisation différent pour plusieurs modules en les séparant par des virgules. L'exemple suivant définit le `aws_config` module sur la journalisation de `trace` niveau et le `aws_smithy_runtime` module sur la journalisation de `debug` niveau. ``` $ RUST_LOG={{aws_config}}={{trace}},{{aws_smithy_runtime}}={{debug}} cargo run ``` Le tableau suivant décrit certains des modules que vous pouvez utiliser pour filtrer les messages du journal : | Préfixe | Description | | --- | --- | | `aws_smithy_runtime` | Enregistrement des câbles relatifs aux demandes et aux réponses | | `aws_config` | Chargement des identifiants | | `aws_sigv4` | Signature de demandes et demandes canoniques | Pour déterminer quels modules vous devez inclure dans la sortie de votre journal, vous pouvez d'abord tout enregistrer, puis trouver le nom de la caisse dans le résultat du journal contenant les informations dont vous avez besoin. Vous pouvez ensuite définir la variable d'environnement en conséquence et exécuter à nouveau votre programme.