Les journaux d'application révèlent des informations sur les événements externes et internes que l'application voit pendant l'exécution. Lorsqu'un bug, un piratage ou une anomalie se produit pendant le déploiement, les journaux sont la preuve la plus utile et la plus fiable pour analyser les causes de l'incident.
Voyons comment Ă©crire des messages utiles dans le journal que tout le monde aimera.
1. Quoi enregistrer
Messages entrants et sortants
Si les composants interagissent les uns avec les autres à l'aide de messages, vous devez enregistrer les messages entrants et sortants indiquant les URL des points de terminaison de l'API, les paramètres de demande, les demandes IP initiales et intermédiaires, les en-têtes de demande, les informations sur l'auteur, les corps de demande et de réponse, le contexte commercial , horodatages et étapes de traitement internes.
Il est très important que chaque message se voit attribuer un identifiant unique (généralement généré au niveau du gestionnaire d'API ou du service). Cela est nécessaire pour suivre l'échange de messages entre les services du système.
Appeler des services et des fonctions
Lors de l'appel d'un service ou d'une fonction, il est souhaitable de consigner leur contexte plus en détail, principalement pour le débogage (utilisez TRACE ou DEBUG). Ces journaux vous aideront à résoudre les problèmes de logique métier, en particulier si vous ne disposez pas du privilège d'attacher un débogueur à une application (par exemple, lors du déploiement dans un environnement de test, de préparation ou de pré-production).
Actions des utilisateurs et statistiques commerciales
Chaque application possède des scénarios d'entreprise et des parcours utilisateurs uniques qui fournissent de nombreuses informations aux professionnels spécialisés. Par exemple, si une certaine transaction a pris trop de temps ou si les utilisateurs sont bloqués sur certaines fonctionnalités - tout cela est des données très importantes du point de vue de l'expérience utilisateur. D'autres informations relatives à l'entreprise - le nombre de transactions et d'utilisateurs actifs, ainsi que leurs étapes - sont importantes pour trouver des relations causales et peuvent même être utilisées dans l'analyse commerciale.
Opérations de données (piste d'audit)
Pour des raisons de sécurité et de conformité, la plupart des applications d'entreprise nécessitent des journaux de transactions séparés avec toutes les informations importantes telles que les ID d'accès (utilisateurs et systèmes), les instances de service exactes et les privilèges de rôle utilisés, les horodatages, les demandes de données, les instantanés et le nouvel état des données modifiées (diff). La piste d'audit doit enregistrer toutes les opérations avec des données (accès, importation, exportation, etc.), ainsi que les opérations CRUD (création, lecture, mise à jour, suppression) effectuées par les utilisateurs, d'autres systèmes et services.
Evénements système
Celles-ci incluent des informations sur le comportement (démarrages, arrêts, redémarrages et événements liés à la sécurité), les modes transitoires (froid, échauffement, chaud), la communication inter-service (établissement de liaison, états d'établissement de la connexion - connecté, déconnecté, reconnecté, réessais), identifiants Instances de service, service actif d'API, écoute active des plages d'adresses IP et de ports, configurations chargées (bootstrap et mises à jour dynamiques), état général du service et tout ce qui peut vous aider à comprendre le comportement du système.
Statistiques de performance
La diligence est une grande caractéristique des appareils informatiques, mais ils peuvent ne pas fonctionner parfaitement. À tout moment, il peut y avoir des problèmes de performances ou des dégradations soudaines et inattendues du service (principalement en raison d'erreurs non gérées et de données corrompues). Pour les déterminer, il est toujours recommandé de publier des statistiques sur l'état général et les performances du système. Il peut contenir des informations telles que les compteurs d'appels API (réussis et échoués), la latence du réseau, la durée moyenne d'aller-retour, la consommation de mémoire et d'autres informations spécifiques à l'application (généralement déterminées par le contexte commercial).
Menaces et vulnérabilités
La divulgation des menaces et des vulnérabilités avec les applications d'exécution et les journaux est un art que tout développeur de logiciel d'entreprise doit maîtriser. Les piratages et les problèmes ne surviennent généralement pas soudainement. Le plus souvent, il y a des signes que personne ne remarque au début. Par conséquent, vous devez toujours consigner les activités humaines suspectes (par exemple, les tentatives erronées d'authentification et de vérification avec l'application de toutes les informations de bas niveau telles que les réseaux utilisés, les sources de demandes, les rôles et privilèges des utilisateurs), ainsi que le comportement du système (par exemple, une augmentation des pics dans les modèles de consommation de ressources, une charge élevée sur serveurs Web, pannes de service occasionnelles). Lorsque vous remarquez un événement suspect, assurez-vous que les journaux contiennent toutes les informations qui y sont liées. À la perfection,afin qu'il s'agisse d'une trace de pile complète avec des valeurs de paramètres et des informations supplémentaires obtenues à partir du contexte d'application.
2. Ce dont vous n'avez pas besoin pour vous connecter
Informations personnelles
Presque toutes les lois sur la confidentialité (par exemple, GDPR, CCPA) recommandent explicitement aux développeurs de ne pas enregistrer les informations personnelles identifiables. Cela comprend le nom, les surnoms, le sexe, la date de naissance, l'adresse postale, l'adresse e-mail, les numéros de téléphone, le numéro de sécurité sociale et les numéros de carte de crédit.
Noms de société et coordonnées
Assurez-vous de ne pas noter les noms de société, les employés, les clients, les informations sur les fournisseurs ou les coordonnées de l'entreprise et des personnes. Le journal ne doit jamais divulguer les relations d'affaires et les transactions avec des tiers. Pour suivre des transactions spécifiques, utilisez des ID d'événement générés par le système au lieu de noms réels et transmettez-les à d'autres services.
Données financières (comptes bancaires, coordonnées de carte bancaire, montants virés, etc.)
Selon la loi, toutes les données financières doivent être complètement supprimées ou masquées. La divulgation de ces informations dans les magazines peut facilement conduire à des poursuites judiciaires graves (pouvant aller jusqu'à et y compris la responsabilité pénale). Évitez cela par tous les moyens.
Mots de passe, clés et secrets de sécurité, jetons d'authentification
Les informations d'identification et les jetons d'authentification sont considérés comme des informations confidentielles, de sorte que leur présence dans les journaux aidera les attaquants à trouver facilement des failles dans le système. Par conséquent, ne laissez pas ces données dans les journaux.
Remarque: Vous pouvez facilement déterminer les informations à masquer dans les journaux si vous ajoutez un attribut à chaque champ qui détermine le niveau de visibilité (par exemple, afficher, masquer, masquer, crypter). Si vous disposez d'un tel mécanisme, vous pouvez modifier la visibilité des champs en mettant simplement à jour les propriétés dans la configuration. C'est une bonne solution dans les cas où vous avez besoin de consigner certaines informations utilisateur dans des environnements non liés au combat, en particulier pour les tests et le débogage. Ou, vous pouvez écrire des analyseurs qui filtrent les journaux et traitent les champs sensibles selon des instructions pré-écrites pour cet environnement.
3. Meilleures pratiques
Savoir quand utiliser un niveau particulier de journalisation
Le niveau de journalisation est utilisé pour indiquer la gravité de chaque élément du système. La plupart des frameworks de journalisation ont ces niveaux:
- FATAL : erreurs très graves qui entraîneront probablement l'arrêt de l'application. Cela se termine généralement par de graves échecs.
- ERREUR : erreurs avec lesquelles l'application peut continuer à fonctionner, mais avec la détérioration de certaines capacités.
- AVERTISSEMENT : événements moins dangereux que les erreurs. Ils ne dégradent généralement pas ou ne plantent pas complètement l'application. Mais ce sont encore des événements importants qui doivent être étudiés.
- INFO : bannières d'événements importants et messages d'information sur le comportement des applications.
- DEBUG: , . .
- TRACE: , , . .
Linux Syslog a également des niveaux plus sérieux tels que Urgence, Alerte, Critique, Erreur, Avertissement, Avis, Information et Débogage.
Indépendamment de la complexité et de la profondeur de chaque niveau de journalisation, nous devons les configurer correctement dans notre code pour fournir la quantité optimale d'informations dans chaque scénario. Par exemple, toutes les données utilisées par les développeurs pour le débogage et l'analyse technique doivent aller au niveau DEBUG ou TRACE, et les bannières avec des données système doivent aller sous INFO.
Utiliser l'anglais
Certains outils et consoles ne prennent pas en charge la sortie et le stockage des journaux contenant certains caractères Unicode. Par conséquent, la localisation et d'autres améliorations peuvent être difficiles. Tenez-vous-en à l'anglais et utilisez toujours un jeu de caractères largement pris en charge pour écrire des messages.
2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all
Ajoutez des messages conviviaux pour les développeurs (concis et significatifs)
S'il y a trop peu de journalisation, nous ne pourrons pas obtenir les informations dont nous avons besoin pour recréer le contexte de chaque événement important. Et si vous vous connectez trop, cela dégradera les performances: l'écriture d'un fichier journal volumineux augmentera la consommation des ressources d'E / S et de stockage sur disque. Si le système de fichiers ne le prend pas en charge, cela réduira les performances globales du système.
Pour optimiser les messages, vous devez avoir une compréhension claire des attentes fonctionnelles et non fonctionnelles du système et planifier la qualité et la quantité de messages souhaitées. Chaque journal doit être significatif et adapté au contexte: écrivez toujours brièvement et précisément.
2020-11-11 13:52:27 DEBUG Users:18 - Successfully created new user (RecordID: 5f5a0d594d17e22b848ee570)2020-11-11 13:52:27 ERROR Users:34 - Failed to update DB (E: inactive user, RecordID: 5f5a0d594d17e22b848ee570)
Créez des identifiants de référence, des alias et des modèles simplifiés pour les messages longs et fréquemment utilisés
Au lieu d'écrire une description complète à chaque fois, essayez de créer des identificateurs de référence ou des modèles simplifiés pour représenter de longues descriptions répétitives dans le journal. Cela réduit le nombre total et la longueur des messages, et augmente également la flexibilité de masquer certaines informations. Par exemple, au lieu de décrire une vulnérabilité dans un journal texte, il est préférable d'utiliser un alias ou un identifiant afin que seuls des experts spécialisés puissent comprendre le scénario actuel.
2020-11-11 13:52:27 ERROR DB:22 - Failed to write (E:ORA-01017)// ORA-01017 denotes "invalid username/password; logon denied" error message
Utiliser des horodatages corrects
Les horodatages fournissent un aperçu de la séquence des événements et sont essentiels pour le débogage et l'analyse. Lors de la fixation de l'heure, il est recommandé d'utiliser les valeurs les plus détaillées (par exemple, au niveau des millisecondes ou des microsecondes) pour faciliter l'identification des événements adjacents. Assurez-vous également que les horodatages sont au début du message au format aaaa-mm-jj HH: mm: ss. Spécifiez toujours votre fuseau horaire, sauf si vous utilisez l'heure par défaut du serveur (UTC).
// with default server time (UTC)2020-11-11 13:52:12 INFO XYZ Integration API Manager v2.0.0// with timezone (e.g. PST - Pacific Standard Time)2020-11-11 13:52:12PST INFO XYZ Integration API Manager v2.0.0
Fournir la source ou l'origine des données du journal (pour DEBUG, TRACE, ERROR)
Ceci est très utile pour identifier clairement l'emplacement qui a conduit au message correspondant. Certains cadres de journalisation vous permettent de spécifier les sources au niveau le plus détaillé (jusqu'au nom des fichiers avec les numéros de ligne), mais le plus souvent, il suffit de mentionner le nom de la classe, de la fonction ou du fichier.
2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG) 2020-11-11 13:52:12 DEBUG App:22 - Initializing Swagger UI.. 2020-11-11 13:52:14 DEBUG App:28 - Generating schemata.. 2020-11-11 13:52:14 DEBUG App:30 - Initializing REST services.. 2020-11-11 13:52:15 DEBUG App:32 - Generating documentation.. 2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all 2020-11-11 13:52:31 INFO app - Started listening...
Chaque journal doit être unique dans le système
La plupart des débutants font la même erreur: ils copient et collent un exemple de message dans différents fichiers, collectant le journal final à partir des mêmes lignes provenant de différentes parties du système. Dans ce cas, il est difficile de localiser l'emplacement spécifique qui a déclenché l'événement. Si l'ensemble de mots ne peut pas être modifié, mentionnez au moins la source dans le message afin que les lignes du fichier final diffèrent les unes des autres. De plus, si la journalisation est gérée par la classe parent, envoyez un identifiant lors de l'initialisation et utilisez-le pour enregistrer des messages sur le comportement des classes enfants.
2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all
Ajouter un identifiant suivi ou un jeton de message au message
Lorsqu'un événement ou un message entre dans le système, un identifiant unique lui est généralement attribué. Il peut être transmis à d'autres étapes de traitement pour suivre le mouvement d'un événement dans le système, ce qui est utile pour le débogage, le traitement simultané et les opérations basées sur les données. Idéalement, le système devrait avoir un identifiant d'événement unique dans tous les modules et services.
[87d4s-a98d7-9a8742jsd] Request Body: { "request_id": "87d4s-a98d7-9a8742jsd", "app_id": "TX001", "option_val": "IBM", "req_type_id": "0013", "data": {...........} [87d4s-a98d7-9a8742jsd] Sending request to RefData: href="http://10.244.2.168:8280/v1
Faire correspondre les identifiants aux points de transition
Dans certains cas, notamment lors de la transmission d'un événement d'un système à un autre, les identifiants changent conformément à la convention adoptée dans l'autre système. À ces points de transition, il est nécessaire d'indiquer explicitement la correspondance de l'ancien et du nouvel identifiant dans un message séparé, avec l'ajout du contexte nécessaire.
[1000508] ***** Incoming request from 10.244.2.168:3000 ***** [1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508 [1000508] Transaction successfully added to Rabbit Queue
Spécifiez des identifiants pour toutes les instances de service
La plupart des systèmes d'entreprise sont des plates-formes informatiques distribuées dans lesquelles il existe de nombreuses instances des mêmes services avec diverses configurations d'application, ressources, versions et propriétés de réseau. Il est recommandé d'attribuer des identificateurs aux instances et de les utiliser pour la communication interservices.
2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG)
Configurer un niveau de journalisation actif
Le niveau de journalisation actif doit être modifié en fonction de l'environnement de déploiement. Pour la production, il est recommandé de sortir les journaux jusqu'au niveau INFO. Dans d'autres environnements, les journaux sont émis jusqu'au niveau DEBUG ou TRACE, en fonction du niveau de détail requis par les équipes de développement et d'exploitation.
// Active Log Level = DEBUG2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG) 2020-11-11 13:52:12 DEBUG App:22 - Initializing Swagger UI.. 2020-11-11 13:52:14 DEBUG App:28 - Generating schemata.. 2020-11-11 13:52:14 DEBUG App:30 - Initializing REST services.. 2020-11-11 13:52:15 DEBUG App:32 - Generating documentation.. 2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all 2020-11-11 13:52:31 INFO app - Started listening...// Active Log Level = INFO2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID API_V2_I02 2020-11-11 13:52:18 INFO app — *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 04 (INFO) 2020-11-11 13:52:31 INFO app - Started listening...
Fournir un contexte suffisant pour les erreurs et les plantages
Les erreurs et les échecs nécessitent une enquête plus approfondie. Pour ce faire, l'application doit fournir aux experts en la matière les informations dont ils ont besoin, ainsi que le contexte technologique et commercial. Par exemple, si une demande ou un message n'a pas pu être traité, il est très utile de consigner le corps de la demande ayant échoué en plus de l'erreur.
[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Failed to validate msg body (E: Uncaught ReferenceError: missing params - option_val)[1000508] Failed Message: { "request_id": "87d4s-a98d7-9a8742jsd", "app_id": "TX001", "req_type_id": "0013", "data": {...........} }
Sauvegardez les transactions de données avec des preuves (ne présumez pas!)
Pour chaque opération de données, ne prenez pas pour acquis qu'elle a réussi. Vérifiez toujours la condition finale avec des preuves. Par exemple, lorsque vous créez, mettez à jour ou supprimez un enregistrement dans la base de données, il renvoie un compteur des enregistrements modifiés et de l'enregistrement mis à jour lui-même. Vérifiez toujours le compteur ou le résultat attendu. Autre exemple: lorsque vous insérez un enregistrement dans une structure de données (par exemple, dans une file d'attente), vérifiez si sa taille a augmenté. Supposons que votre système utilise des opérations simultanées, mais que la file d'attente ne les prend pas en charge. Ensuite, vous risquez de perdre certains enregistrements et la seule façon de détecter ces erreurs cachées dans le code est de vérifier la longueur.
DEBUG BatchWriter:28 - Successfully connected to DB. Trying to insert 24 accounts...DEBUG BatchWriter:35 - Successfully inserted 24 accounts. Total DB rows affected: 24
Crypter ou masquer les données sensibles
Habituellement, la loi exige que les informations confidentielles des utilisateurs et des systèmes internes soient masquées et / ou cryptées. Les exigences réglementaires peuvent varier en fonction de votre secteur d'activité et de votre lieu de travail. Découvrez toutes les nuances et implémentez les procédures correctes dans l'application. Dans certains cas, vous devrez peut-être soumettre votre stratégie de journalisation au service de sécurité et obtenir son approbation ou sa certification avant l'opérationnalisation.
[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Request Body: { ”user_id”:”XXXXXXXXXX”, ”personal_details”:{ ”firstName”:”XXXXXXXXXX”, ”lastName”:”XXXXXXXXXX”, ”DOB”:”XXXXXXXXXX”, ”gender”:”Male”, ”proffessional”:”Software Architect”, ”industry”:”IT”, ”SSN”:”XXXXXXXXXX” }, ”address_history”:[ {”streetAdress”:”Street No 1″,”zipcode”:”XXXXX”,”state”:”CA”}, {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”NY”}, {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”AL”} ], ”card_info”:[ {”type”:”amex″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”}, {”type”:”visa″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”} ] }
Configurer la dénomination des fichiers journaux, les politiques de rotation, les tailles de stockage et les procédures de sauvegarde
Si vous écrivez des journaux dans des fichiers, assurez-vous qu'ils sont stockés sur un disque distinct qui n'affecte en aucune manière l'application en cours d'exécution (par exemple, vous pouvez allouer un volume sur un serveur distant et le joindre au serveur d'applications). Découvrez également la fréquence de journalisation et la croissance des fichiers. Assurez-vous d'avoir une politique de rotation des journaux avec des conventions de dénomination correctes (par exemple, l'ajout d'un horodatage au nom lors de la création) pour conserver la taille et le nombre de fichiers idéaux. Vous devez également disposer d'un mécanisme pour sauvegarder les anciens journaux dans un endroit sûr et d'un mécanisme pour nettoyer régulièrement le stockage. Selon votre secteur d'activité, vous pouvez configurer une sauvegarde minutée (généralement tous les quelques mois ou quelques années), avec tous les fichiers précédents détruits à la fin de la période.
[ec2-user@ip-XXX-XX-X-XXX logs]$ ls .. APIM_V2_I02-2020-11-20_04:38:43.log APIM_V2_I02-2020-11-23_02:05:35.log APIM_V2_I02-2020-11-24_04:38:17.log APIM_V2_I02-2020-11-27_03:28:37.log APIM_V2_I02-2020-11-27_12:06:45.log ...
4.
Une pratique très courante chez les développeurs d'applications d'entreprise consiste à créer un serveur ou un emplacement centralement accessible pour collecter les journaux. En règle générale, ces agrégateurs suivent les journaux non seulement des applications, mais également des périphériques et des systèmes d'exploitation (par exemple, Linux Syslog), des réseaux, des pare-feu, des bases de données, etc. En outre, ils séparent les fichiers journaux des serveurs d'applications et vous permettent de stocker les journaux dans plus des formats protégés, ordonnés et efficaces pendant plus longtemps. Dans certains secteurs (comme la banque et la finance), il est nécessaire de stocker les journaux dans le stockage local et central afin que les attaquants ne puissent pas accéder aux deux endroits et supprimer les preuves de leurs activités en même temps. Ainsi, la redondance des données et l'inadéquation des données entre les deux magasins peuvent aider à repérer les intrusions.
Écrire des analyseurs et suivre prudemment les journaux
La capacité d'écrire des analyseurs et des filtres est intégrée à la plupart des outils de surveillance des journaux - ce que l'on appelle l'intégration de la gestion des événements et des informations de sécurité (SIEM) . Les analyseurs aident à conserver les journaux dans des formats plus rationalisés et les requêtes de données deviennent beaucoup plus faciles et plus rapides. En outre, des données correctement organisées peuvent être transférées vers des systèmes de surveillance et de recherche d'anomalies pour une surveillance proactive et la prévision d'événements futurs. Ces outils sont très puissants pour représenter graphiquement des données basées sur des séries chronologiques et en temps réel.
Configurer des alertes et des notifications push pour les incidents critiques
Presque tous les outils de surveillance des journaux vous permettent de définir des seuils spécifiques pour certains niveaux. Lorsque le système atteint ces valeurs, l'outil les détecte à l'avance, aide à consigner les données et avertit les administrateurs système via des alertes, des API de notification push (telles que l' API Slack Audit Logs ), des e-mails, etc. Ils peuvent également être préconfigurés pour lancer des processus automatisés. comme la mise à l'échelle dynamique, les sauvegardes système, l'élingage de charge, etc. Mais si vous investissez dans un logiciel commercial de surveillance des journaux, jetez-y un œil car ces outils peuvent être exagérés pour les systèmes logiciels de petite à moyenne taille.
5. Outils recommandés
Cadres de journalisation
JavaScript / TypeScript: Log4js / pino
Java: Log4j
Golang: Logrus
Serverless-functions: aws-lambda-powertools-python / Auto-Ă©crit
Exploration, agrégation et surveillance des journaux
Outils CLI: less, vim
Cloud Tools: Fluentd, AWS CloudWatch
Outils SIEM: SolarWinds, Splunk, McAfee ESM, DataDog, IBM QRadar
Autres: ELK Stack (ElasticSearch, Logstash, Kibana, Beats), Loggly