Dernière fois: Veuillez arrêter l'impression et importer la journalisation pour la sortie du journal
L'article ci-dessus est toujours étrangement populaire, mais je l'ai écrit pour la première fois en 2016, il y a environ quatre ans à partir de cet article.
Bien que le contour de l'avis n'ait pas beaucoup changé, il y a quelques changements. Je veux écrire un article un peu supplémentaire car j'ai des opinions différentes et j'ai eu des expériences différentes jusqu'à présent, je vais donc l'écrire.
Certes, je regardais le comportement autour du journal de certains logiciels externes, et c'était juste une phrase que j'ai écrite avec élan comme "Muki!". C'est pourquoi ce n'est pas quelque chose qui nécessite l'exactitude et l'équité comme un manuel. Je n'ai pas reçu de critiques comme lorsque j'ai contribué à un doujinshi d'un cercle.
Cependant, pour l'article émotionnel (plutôt «parce que»?), Cet article a été lu étrangement ...
D'une manière ou d'une autre, je peux comprendre les sentiments du lecteur. L'histoire des logs n'est pas étonnamment écrite dans des livres techniques, et je suis toujours dans un domaine où j'ai encore du mal à perfectionner mes compétences. Donc, je suis reconnaissant que l'article soit utile même s'il ne s'agit que d'un indice.
Non limité à cet article, quand il y a une notification de LGTM (anciennement "like") ou de stock, je relis et retravaille parfois le texte, donc la sensation de "mukey" peut être douce maintenant. .. Quant au contenu, même si j'y repense maintenant, je le laisse comme "Eh bien ... je n'écris pas une mauvaise histoire".
Au fait, c'est un peu décevant de ne pas avoir vu un contre-article solide disant "Non!". Je me demande s'il serait intéressant d'écrire diverses choses comme «moi et moi».
(Je suis content que vous ayez signalé le commentaire, même si je suis à l'origine un ami)
Non limité à Python, les journaux sont utilisés lors de l'exploitation du logiciel.
est. Je ne pense pas qu'il soit possible de ne pas prendre cela au sérieux comme un problème majeur dans le développement de logiciels.
Malgré son importance, je pense qu'il y a une considération inhabituellement faible pour les journaux par rapport aux tests. L'impression est que chacun tâtonne, ou le fait en regardant le domaine et l'expérience auxquels il appartient.
D'un autre côté, comme je l'expliquerai plus tard, je pense que les stratégies de journalisation ont souvent des points particuliers pour chaque champ (domaine) plutôt que des éléments communs. Même si vous les partagez, il est possible qu'il soit difficile de partager des connaissances simplement en écrivant quelques lignes comme meilleure pratique.
Comme mentionné ci-dessus, le journal fait face "à deux sens" entre les personnes et les choses, donc si le point de vue ou le sujet est légèrement flou, il deviendra instantanément "Que signifie ce journal ???". Il est trop facile de savoir à qui s'adresse l'information.
On peut dire qu'un bon journal est une exigence importante qui conduit à un bon logiciel pour les utilisateurs et les opérateurs (enfin, une interface utilisateur directe est beaucoup plus importante, mais dans ce cas).
Il est impossible pour les personnes non-développeurs (sensées) de revoir leur environnement d'exécution sans avoir à le signaler, et d'atterrir sur un tel journal, si la qualité de la gestion des erreurs ou la racine du logiciel n'est pas bonne en premier lieu. .. Vous pouvez facilement dire à l'opérateur le journal "Parce qu'il y a un tel soupçon, veuillez vérifier ici!" En d'autres termes, le logiciel qui produit le journal doit être le logiciel qui évalue fermement vos capacités et vos limites. Je pense.
WARNING: Found duplicate entries for the query "otemoyan". Choosing the first.
Le journal ci-dessus est un exemple, mais il permet de comprendre «ce qui se passe», «ce qui est considéré comme un problème», et «ce que le logiciel y a sélectionné». Cela implique également implicitement (je vais y aller) l'intention que "généralement, il ne devrait pas y avoir d'entrées doubles dans ce modèle, mais soyez prudent, mais pas comme une erreur". Si cela est important pour le lecteur de journal, «qui a lancé la requête» peut également être ajouté ici. À titre d'exemple virtuel, si la partie requête correspond à des informations personnelles, elle doit être floutée pendant la production.
Il y a probablement une prémisse que ce journal semble "bon", et cela dépend "toujours" du contexte.
Dans mon cas, il fut un temps où je faisais du développement de contrat pour BtoBtoB, comme "lire le journal soumis par le client avec à propos de ag / grep et identifier le problème de l'environnement client à partir de celui-ci". Il y a des exemples comme celui-ci, mais j'avais l'impression que ce genre de journal fonctionne dans un tel environnement. Je pense que la personne de soutien entre les deux a été en mesure de répondre en douceur au client après cela (je ne peux pas vous en dire grand chose, mais à moi. Je ne l'ai pas compris, et c'est bien.)
Cela fait longtemps que j'ai écrit l'article original, mais l'un des points que j'ai souligné était le plus grand reflet auquel je pensais honnêtement, "je vois".
"Les tactiques / stratégies de journalisation doivent être proches du domaine de l'entrée à la sortie."
Hmm, qu'est-ce que tu veux dire?
Les hypothèses suivantes devraient avoir un impact clair et solide sur votre stratégie d'exploitation:
Dans l'article original, c'était bâclé, même dans le cadre du langage Python. Quoi qu'il en soit, les utilisateurs de Python sont très variés ...
Pour le mettre en excuse, le sens de l'échelle que j'avais initialement envisagé était le développement de logiciels avec l'image de «grandir» à partir de «pour moi» et de «contrat à petite échelle». L'image est que le nombre d'utilisateurs, y compris le client qui l'a utilisé en premier, puis en interne ou qui a donné le travail, augmentera "peut-être", mais la charge initiale ne sera pas importante.
D'autre part, par exemple, la stratégie de journalisation pour les logiciels qui ont commencé le développement en supposant un «service global» dès le début de la conception sera très différente. Par exemple, lorsqu'il s'agit de réécrire un SaaS à grande échelle qui était à l'origine populaire, il y avait des milliers, des centaines de millions, voire des centaines de millions de QPS depuis le début.
Dans ce cas, en termes simples, l'échelle standard que rencontre le logiciel devrait être différente et, dès le début du développement, cela devrait être le premier point d'atterrissage pour les stratégies d'exploitation. La quantité de journaux et la vitesse à laquelle ils s'accumulent (et la complexité de l'infrastructure à travers laquelle le flux de journaux circule) sont également différentes.
Le point d'atterrissage que vous envisagez depuis le début changera naturellement si vous êtes conscient du grand système depuis le début. Dans mon sens (égoïste), plus l'échelle est grande, moins la subdivision au niveau du log qui me tient à cœur est grande, et plus je dois me concentrer sur la fréquence d'occurrence dans l'environnement utilisateur et l'impact réel. Je pense que ça viendra. Eh bien, c'est vraiment une supposition, mais ...
Il y avait une certaine affirmation selon laquelle le domaine du lecteur ne correspondait pas toujours à celui du mien, mais je pense que c'était clairement inapproprié en tant qu'écrivain (au fait, le côté de l'article original a osé le réparer). Je n'ai pas. C'est un tel article, alors profitez-en comme ça)
Si «le domaine est le même mais les opinions sont différentes», il est facile de discuter du désaccord et du processus de conciliation, mais il est souvent difficile de concilier des domaines différents. C'est une mauvaise situation à regarder en arrière quand je n'ai pas dit: "C'est le domaine auquel je pense. C'est la stratégie d'exploitation pour cela."
Au fait, ce n'est pas Python, mais j'ai écrit des applications dans l'industrie mobile, alors je pensais également aux stratégies de journalisation à ce moment-là. C'était environ 5 ans avant que j'écrive l'article original en 2016.
A ce moment, eh bien ... l'échelle supposée est certainement "l'échelle globale", mais elle ne s'est pas écoulée comme un flux de journal constant sur un serveur principal. La cible est chaque terminal individuel, qui génère des journaux similaires en morceaux. La stratégie de journalisation à ce stade est différente de la gestion des journaux à petite échelle côté serveur.
C'est un peu différent d'un gros serveur principal. Je pense que le style de sensibilisation des gens à la version du logiciel et à la version du matériel va changer. Il n'est pas rare que le dépannage dise: «Quelle version avez-vous modifié le libellé du message de journal lorsque cette erreur s'est produite?»
Dans tous les cas, si le logiciel est si omniprésent dans la société, la logique de son fonctionnement sera complètement différente et la façon de penser l'exploitation forestière qui le soutient sera complètement différente.
En gardant ce qui précède à l'esprit, je voudrais faire une note supplémentaire de ce que j'essaie de faire avec mon domaine.
Certains projets transmettent logger: Logger ou logger: Optional [Logger] à la fonction. Aucun argument par défaut n'est spécifié. Cependant, vous pouvez être autorisé à passer explicitement None (pensez à l'échelle logicielle supposée comme "assez petite").
J'ai également utilisé logger: Optional [Logger] = None pendant un certain temps, mais c'était une mauvaise décision. Le journal peut être compressé implicitement, ce qui me rend très triste, j'ai donc deux choix maintenant. Cependant, il n'est peut-être pas nécessaire d'avoir deux choix.
Cette méthode ne sera probablement utile que pour des développements à une échelle qui "prend le contrôle de tout le journal" et "s'occupe des composants en détail". Si l'échelle du service que vous gérez concerne le premier BtoC au Japon, cela dépend de la charge, mais vous n'adopterez probablement pas une telle stratégie.
Je ne pense donc pas que cette méthode soit très polyvalente, mais en faisant cela de manière cohérente dans la mesure où je la gère personnellement, les perspectives du journal pour ce projet se sont considérablement améliorées.
En premier lieu, je pense qu'il y a une partie "Kodawari" en plus de la petite échelle. Je pense qu'il est discutable si le journal est bon ou mauvais, mais c'est toujours mieux que ** print () **. Si un autre technicien est le chef et a une autre convention de journalisation comme convention de codage, il la suivra tranquillement.
Ce n'est pas très différent qu'avant, et le problème est que «Logger.info ()» et «Logger.debug ()» seuls sont trop granuleux. Logger.trace () (ci-dessous debug (). C'est bien pour les niveaux de début et de fin de la fonction) Je le veux (peut-être le terme Zabbix) Logger.average () (avertissement ci-dessus, d'une erreur) Il y a un moment où je veux (ci-dessous, ou entre info et avertissement) (encore une fois, cela peut ne pas avoir d'importance à mesure que l'échelle du logiciel augmente).
Si vous créez un wrapper pour Logger, vous pouvez probablement le faire. En Python, DEBUG, INFO, etc. sont des valeurs constantes, et il y a un écart suffisant entre ces valeurs constantes (https://docs.python.org/3/library/logging.html#logging-levels).
Cependant, il existe également une règle empirique selon laquelle cela fonctionne mieux à long terme si vous vous en tenez au «standard» du langage ou du cadre, et cela ne semble pas «étrangement sournois» intuitivement, mais il y a une histoire d'hésitation. J'envie juste le logback qui contient la trace depuis le début.
Cette fois, je n'avais pas d'émotions fortes et je l'ai juste écrit de manière appropriée, donc cela n'avait peut-être pas été intéressant, mais je l'ai écrit comme suivi.