Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Azure Database pour PostgreSQL vous permet de configurer et d’accéder aux journaux standard de Postgres. Les journaux d’activité peuvent servir à identifier, résoudre et réparer les erreurs de configuration et les problèmes de performances. Les informations de journalisation que vous pouvez configurer et auxquelles vous pouvez accéder incluent les erreurs, les informations de requête, les enregistrements de nettoyage automatique, les connexions et les points de contrôle. (L’accès aux journaux des transactions n’est pas disponible).
L’enregistrement d’audit est mis à disposition par le biais d’une extension Postgres, pgaudit. Pour plus d’informations, consultez l’article Concepts d’audit.
Configuration de la journalisation
Vous pouvez configurer la journalisation standard Postgres sur votre serveur avec les paramètres de journalisation. Pour en savoir plus sur les paramètres de journal Postgres, consultez les sections Quand journaliser et Que journaliser de la documentation Postgres. La plupart, mais pas tous, les paramètres de journalisation Postgres sont disponibles pour la configuration dans Azure Database pour PostgreSQL.
Pour savoir comment configurer des paramètres dans Azure Database pour PostgreSQL, consultez la documentation du portail ou la documentation CLI.
Remarque
Lors de la configuration d’un grand volume de journaux, cela peut entraîner une surcharge significative du traitement des performances. Par exemple, la journalisation des instructions peut avoir un impact sur les performances.
Accéder aux journaux d’activité
Azure Database pour PostgreSQL est intégré aux paramètres de diagnostic d'Azure Monitor. Les paramètres de diagnostic vous permettent d’envoyer des journaux PostgreSQL au format JSON aux journaux Azure Monitor pour l’analytique et les alertes. Vous pouvez également les diffuser en continu vers Event Hubs ou les archiver dans Stockage Azure.
Contrôle d’accès pour les fichiers journaux
L’accès aux journaux du serveur est contrôlé via Azure Role-Based Access Control (RBAC). Tout rôle qui fournit un accès en lecture au serveur autorise également le téléchargement des journaux. Cela inclut des rôles intégrés tels que :
- Lecteur
- Lecteur d’analyse
- Lecteur Log Analytics
- Ou des rôles personnalisés équivalents
Avertissement
Les journaux peuvent contenir des informations sensibles, telles que des informations d’identification, en fonction de votre configuration de journalisation.
Stratégie de conservation des données et tarification
Pour les journaux envoyés à Event Hubs ou à un compte de stockage, vous pouvez configurer une stratégie de rétention pour supprimer automatiquement les données après une certaine période. Les coûts log Analytics dépendent de deux facteurs :
- Ingestion des données : les frais sont basés sur le volume de données ingérées dans l’espace de travail.
- Conservation des données : les journaux stockés dans votre espace de travail Log Analytics sont conservés gratuitement pendant les 31 premiers jours. Au-delà de cette période de rétention gratuite, il existe des frais pour le stockage des données, calculés au prorata quotidien, en fonction de la quantité de données (en Go) conservées chaque mois.
Pour obtenir une répartition des coûts associés à l’ingestion et à la rétention des données, consultez la page de tarification d’Azure Monitor.
Format de journal
Le tableau suivant décrit les champs du type PostgreSQLLogs. Selon le point de terminaison de sortie que vous choisissez, les champs inclus et l’ordre dans lequel ils apparaissent peuvent varier.
| Champ | Description |
|---|---|
| TenantId | Votre ID d’abonné |
| SourceSystem | Azure |
| HeureGénérée [UTC] | Horodatage du moment où le journal a été enregistré en UTC |
| Type | Type de journal. Toujours AzureDiagnostics |
| SubscriptionId | GUID de l’abonnement auquel appartient le serveur |
| ResourceGroup | Nom du groupe de ressources auquel le serveur appartient |
| ResourceProvider | Nom du fournisseur de ressources. Toujours MICROSOFT.DBFORPOSTGRESQL |
| ResourceType | FlexibleServers |
| ResourceId | URI de ressource |
| Ressource | Nom du serveur |
| Category | PostgreSQLLogs |
| NomOpération | LogEvent |
| errorLevel_s | Niveau de journalisation, par exemple : LOG, ERROR, NOTICE |
| processId_d | ID de processus du back-end PostgreSQL |
| sqlerrcode_s | Code d’erreur PostgreSQL qui suit les conventions de la norme SQL pour les codes SQLSTATE |
| Message | Message de journal principal |
| Detail | Message du journal secondaire (le cas échéant) |
| ColumnName | Nom de la colonne (le cas échéant) |
| SchemaName | Nom du schéma (le cas échéant) |
| DatatypeName | Nom du type de données (le cas échéant) |
| _ResourceId | URI de ressource |
Limitations connues
- Taille de l’événement de journal : les plans de requête ou les messages journaux supérieurs à 65 Ko ne sont pas capturés dans les journaux Azure Monitor. Il s’agit d’une limite Azure Monitor à l’échelle de la plateforme. Par conséquent, les requêtes complexes (par exemple, celles impliquant des vues imbriquées) peuvent générer une sortie incomplète ou manquante du plan de requête dans les journaux du serveur.
- Autres contraintes : d’autres limites à l’échelle de la plateforme s’appliquent aux journaux Azure Monitor, tels que les quotas de règles d’alerte et la taille des résultats de requête. Pour obtenir plus d’informations sur la liste complète, reportez-vous à la documentation relative aux limites du service Azure Monitor.