> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/fr/developpement/logging.md).
# Journalisation
## À propos
PowerShell Universal utilise un cadre de journalisation structuré appelé Serilog. Serilog permet de définir plusieurs cibles de journalisation (sinks), des propriétés d'événements de journal et le stockage des données d'événements de journal. Par défaut, PowerShell Universal consigne deux fichiers journaux distincts. Le premier est le journal système. Il contient des détails de journalisation concernant le serveur PowerShell Universal et est configuré en mode verbose par défaut. Le second est le journal utilisateur. Le journal utilisateur capture des informations sur tous les scripts exécutés dans PowerShell Universal et créés par l'utilisateur.
Les deux fichiers journaux se trouvent dans `%ProgramData%\PowerShellUniversal`.
## Journalisation système
La journalisation système est configurée via les paramètres de l'application (appsettings.json) ou les variables d'environnement. Les journaux système contiennent généralement des informations internes utiles pour déterminer ce qui se passe au sein du serveur PowerShell Universal, et non nécessairement dans vos scripts.
Les paramètres du journal système se trouvent à la racine du fichier appsettings.json.
```json
{
"SystemLogPath": "%ProgramData%\\PowerShellUniversal",
"SystemLogLevel": "Information"
}
```
Le chemin du journal système peut contenir des variables d'environnement. Les niveaux de journalisation valides sont :
* Verbose
* Debug
* Information
* Warning
* Error
Nous recommandons d'utiliser le niveau Information ou supérieur dans les environnements de production, et de descendre en dessous de ces niveaux uniquement lors du débogage de problèmes.
## Configuration
La configuration de la journalisation peut être modifiée dans la page Settings \ Logging.
### Cibles
PowerShell Universal propose cinq cibles de journalisation intégrées.
* File
* Database
* TCP
* HTTP
* PowerShell
Chaque cible possède son propre ensemble de propriétés. Par exemple, les fichiers disposent d'une propriété de chemin de fichier.
#### Portée
Chaque cible peut être configurée pour capturer un ensemble spécifique d'événements de journal en fonction de leur source. Ceux-ci comprennent :
* Scope — Messages du journal système ou utilisateur
* Feature — La fonctionnalité générant le message de journal (p. ex. API)
* Resource — Une ressource spécifique générant le journal (p. ex. Script1.ps1)
Si la fonctionnalité ou la ressource ne sont pas spécifiées, la cible de journalisation recevra tous les messages pour la portée définie. Par exemple, si vous définissez une cible avec une portée User et une fonctionnalité API, elle consignera toutes les requêtes API.
#### Niveau
Les niveaux de journalisation définissent quels messages consigner en fonction du niveau des messages de journal. Par exemple, une cible de journalisation configurée au niveau Information recevra les messages de journal allant de Information jusqu'à Error, mais ne consignera pas les messages de débogage ou verbose.
### Cible PowerShell
La cible de journalisation PowerShell peut être utilisée pour créer un enregistreur personnalisé avec un bloc de script PowerShell afin de recevoir les messages. Le bloc de script doit avoir deux paramètres. Le premier est l'objet d'événement de journal produit par Serilog, et le second est la chaîne de message rendu.
```powershell
New-PSULoggingTarget -Type 'PowerShell' -Level 'Information' -Scope User -Feature API -ScriptBlock {
param($LogEvent, $Message)
$Message | Out-File C:\logs\log.txt
}
```
Tenez compte des performances lors de l'utilisation de la cible PowerShell, car PowerShell sera exécuté pour chaque message de journal. Un pool de runspaces de journalisation est utilisé pour fournir une journalisation multithread pour les cibles PowerShell.
N'effectuez pas de journalisation dans votre cible PowerShell en utilisant Write-PSULog.
## Write-PSULog
Vous pouvez utiliser la cmdlet `Write-PSULog` pour écrire dans les journaux depuis vos scripts. La cmdlet définit automatiquement la portée User et vous pouvez choisir de fournir une fonctionnalité, une ressource et un message.
```powershell
Write-PSULog -Feature 'MyFeature' -Message 'MyMessage'
```
### Console
Vous pouvez autoriser `Write-PSULog` à envoyer des sorties vers les flux de la session PowerShell courante en utilisant le paramètre de commutateur `-Console`. Selon le niveau sélectionné, les messages de journal apparaîtront sur ces flux.
{% code overflow="wrap" %}
```powershell
# Information Stream
Write-PSULog -Console -Message "MyInfoMessage" -Level Information
# Error Stream
Write-PSULog -Console -Message "MyErrorMessage" -Level Error
# Warning Stream
Write-PSULog -Console -Message "MyWarningMessage" -Level Warning
```
{% endcode %}
### Runspaces imbriqués
Si votre solution crée ses propres runspaces, directement ou via des tâches, vous pouvez continuer à utiliser `Write-PSULog`, mais vous devrez fournir la variable globale `$UniversalClient` au runspace.
{% code overflow="wrap" %}
```powershell
$iss= [InitialSessionState]::CreateDefault()
$var1 = [SessionStateVariableEntry]::new("UniversalClient",
$UniversalClient,
"The PSU Client")
$iss.Variables.Add($var1)
$runspace = [runspacefactory]::CreateRunspace($iss)
$runspace.Open()
$script = { Write-PSULog -Message 'Hello from a runspace!' }
$pipeline = $runspace.CreatePipeline()
$pipeline.Commands.AddScript($script)
$pipeline.Invoke()
$runspace.Close()
```
{% endcode %}
## Affichage des journaux
Vous pouvez afficher les journaux en accédant à Platform \ Logging. La visionneuse de journaux affiche tous les messages de journal par défaut. Vous pouvez utiliser les options de tri et de filtrage pour sélectionner des niveaux, des fonctionnalités et des ressources particuliers afin d'afficher les journaux correspondants.
La barre de recherche permet de rechercher les messages de journal contenant la chaîne de recherche.
Visionneuse de journaux
## Exemple : pile ELK
Vous pouvez utiliser la cible de journalisation TCP pour stocker et analyser les messages de journal dans la pile ELK. Pour les besoins de cet exemple, nous utiliserons le [dépôt docker-elk](https://github.com/deviantony/docker-elk).
Clonez le dépôt docker-elk et exécutez les commandes suivantes dans le dépôt.
```
docker-compose up setup
docker-compose up
```
Une fois exécutés, vous disposerez d'une pile ELK en fonctionnement. Vous pouvez accéder à la console Web en naviguant vers `http://localhost:5601`.
Le nom d'utilisateur par défaut est elastic et le mot de passe est changeme.
Dans PowerShell Universal, vous devrez créer une cible de journalisation et envoyer les événements TCP vers `tcp://localhost:50000`.
```powershell
New-PSULoggingTarget -Type "TCP" -Level "Verbose" -Properties @{
hostName = 'tcp://localhost'
port = '50000'
} -Scope "User"
```
La configuration ci-dessus enverra tous les messages de journal de portée User vers Logstack via la connexion TCP. Dans la section Observability de la console, naviguez vers la page Logs \ Stream.
Depuis cet emplacement, vous pourrez rechercher et afficher les messages de journal provenant de Universal.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.devolutions.net/powershell-universal/fr/developpement/logging.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.