Letztes Mal: Bitte beenden Sie das Drucken und importieren Sie die Protokollierung für die Protokollausgabe
Der obige Artikel ist immer noch seltsam beliebt, aber ich habe ihn zum ersten Mal im Jahr 2016 geschrieben, also vor ungefähr vier Jahren aus diesem Artikel.
Obwohl sich der Umriss der Stellungnahme nicht wesentlich geändert hat, gibt es einige Änderungen. Ich möchte einen leicht ergänzenden Artikel schreiben, weil ich verschiedene Meinungen habe und bisher unterschiedliche Erfahrungen gemacht habe, also werde ich ihn schreiben.
Sicherlich habe ich mir das Verhalten im Protokoll einer externen Software angesehen, und es war nur ein Satz, den ich mit Schwung als "Muki!" Schrieb. Deshalb erfordert es nicht Genauigkeit und Fairness wie ein Lehrbuch. Ich habe keine Bewertungen erhalten, wie wenn ich zu einem Doujinshi eines Kreises beigetragen hätte.
Für den emotionalen Artikel (eher "weil"?) Wurde dieser Artikel jedoch seltsam gelesen ...
Irgendwie kann ich die Gefühle des Lesers verstehen. Die Geschichte der Protokolle ist nicht überraschend in technischen Büchern geschrieben, und ich bin immer noch in einem Bereich, in dem ich immer noch Schwierigkeiten habe, meine Fähigkeiten zu verbessern. Daher bin ich dankbar, dass der Artikel nützlich ist, auch wenn es sich nur um eine Hinweisstufe handelt.
Nicht auf diesen Artikel beschränkt, wenn es eine Benachrichtigung über LGTM (früher "wie") oder Lager gibt, lese ich den Text manchmal erneut und überarbeite ihn, so dass das Gefühl von "mukey" jetzt mild sein kann. .. Was den Inhalt betrifft, so belasse ich ihn, selbst wenn ich jetzt zurückblicke, als "Nun ... ich schreibe keine schlechte Geschichte."
Es ist übrigens ein wenig enttäuschend, dass ich keinen soliden Gegenartikel mit der Aufschrift "Nein!" Gesehen habe. Ich frage mich, ob es interessant wäre, verschiedene Dinge wie "Ich und Ich" zu schreiben.
(Ich bin froh, dass Sie auf den Kommentar hingewiesen haben, obwohl ich ursprünglich ein Freund bin)
Nicht nur auf Python beschränkt, Protokolle werden beim Betrieb von Software verwendet.
ist. Ich denke nicht, dass es möglich ist, dies als Hauptproblem in der Softwareentwicklung nicht ernst zu nehmen.
Trotz seiner Bedeutung denke ich, dass Protokolle im Vergleich zum Testen ungewöhnlich wenig berücksichtigt werden. Der Eindruck ist, dass jeder tastet oder es schafft, während er das Feld und die Erfahrung betrachtet, zu denen er gehört.
Andererseits denke ich, wie ich später erläutern werde, dass Protokollierungsstrategien häufig für jedes Feld (jede Domäne) besondere Punkte haben und keine gemeinsamen Elemente. Selbst wenn Sie es teilen, besteht die Möglichkeit, dass es schwierig ist, Wissen zu teilen, indem Sie nur ein paar Zeilen als Best Practice schreiben.
Wie oben erwähnt, ist das Protokoll "wechselseitig" zwischen Personen und Dingen ausgerichtet. Wenn also der Blickwinkel oder das Motiv leicht verschwommen ist, wird es sofort zu "Was bedeutet dieses Protokoll ???". Es ist zu einfach zu wissen, für wen die Informationen bestimmt sind.
Man kann sagen, dass ein gutes Protokoll eine wichtige Voraussetzung ist, die zu einer guten Software für Benutzer und Bediener führt (eine direkte Benutzeroberfläche ist jedoch viel wichtiger, aber in diesem Fall).
Es ist für Nicht-Entwickler (vernünftige) Personen unmöglich, ihre Ausführungsumgebung ohne Berichterstattung zu überprüfen und in einem solchen Protokoll zu landen, wenn die Qualität der Fehlerbehandlung oder die Wurzel der Software überhaupt nicht gut ist. .. Sie können dem Bediener das Protokoll leicht mitteilen: "Da ein solcher Verdacht besteht, überprüfen Sie dies bitte hier!" Mit anderen Worten, die Software, die das Protokoll ausgibt, muss die Software sein, die Ihre Fähigkeiten und Grenzen genau bewertet. Ich denke.
WARNING: Found duplicate entries for the query "otemoyan". Choosing the first.
Das obige Protokoll ist ein Beispiel, aber es ermöglicht es zu verstehen, "was passiert", "was als Problem angesehen wird" und "was die Software dort ausgewählt hat". Dies impliziert implizit auch die Absicht (ich werde es tun), dass "normalerweise keine doppelten Einträge in diesem Muster vorhanden sein sollten, aber seien Sie vorsichtig, wenn auch nicht als Fehler". Wenn dies für den Protokollleser von Bedeutung ist, kann hier auch "Wer hat die Abfrage geworfen" hinzugefügt werden. Wenn der Abfrageteil als virtuelles Beispiel persönlichen Informationen entspricht, muss er während der Produktion unscharf werden.
Es gibt wahrscheinlich die Voraussetzung, dass dieses Protokoll "gut" erscheint und "immer" vom Kontext abhängt.
In meinem Fall gab es eine Zeit, in der ich die Vertragsentwicklung für BtoBtoB durchführte, z. B. "Lesen des vom Kunden eingereichten Protokolls mit etwa ag / grep und Identifizieren des Problems der Kundenumgebung daraus". Es gibt Beispiele wie dieses, aber ich hatte den Eindruck, dass diese Art von Protokoll in einer solchen Umgebung funktioniert. Ich habe das Gefühl, dass die dazwischen liegende Support-Person danach reibungslos auf den Kunden reagieren konnte (ich kann Ihnen nicht viel darüber erzählen, aber mir. Ich habe es nicht verstanden und es ist gut.)
Es ist lange her, dass ich den Originalartikel geschrieben habe, aber einer der Punkte, auf die ich hingewiesen habe, war die größte Reflexion, die ich ehrlich dachte: "Ich verstehe."
"Protokollierungstaktiken / -strategien müssen vom Eingang bis zum Ausgang in der Nähe der Domäne sein."
Hmm, was meinst du?
Die folgenden Annahmen sollten einen klaren und soliden Einfluss auf Ihre Protokollierungsstrategie haben:
Im ursprünglichen Artikel war dies selbst im Rahmen der Python-Sprache schlampig. Wie auch immer, Python-Benutzer sind breit gefächert ...
Um es in eine Entschuldigung zu bringen, der Sinn für Skalierbarkeit, den ich mir ursprünglich vorgestellt hatte, war Softwareentwicklung mit dem Bild des "Aufwachsens" ausgehend von "für mich selbst" und "Kleinvertrag". Das Bild ist, dass die Anzahl der Benutzer, einschließlich des Bestellers, der es zuerst verwendet hat, dann intern oder der den Auftrag gegeben hat, "vielleicht" zunimmt, aber die anfängliche Last wird nicht groß sein.
Auf der anderen Seite wird beispielsweise die Protokollierungsstrategie für Software, die mit der Entwicklung begonnen hat und von Beginn des Entwurfs an einen "globalen Service" angenommen hat, sehr unterschiedlich sein. Wenn es beispielsweise darum ging, ein ursprünglich beliebtes SaaS in großem Maßstab neu zu schreiben, gab es von Anfang an Tausende, Hunderte von Millionen oder sogar Hunderte von Millionen von QPS.
In diesem Fall sollte die Standardskala, auf die Software stößt, einfach ausgedrückt sein, und von Beginn der Entwicklung an sollte dies der erste Landepunkt für Protokollierungsstrategien sein. Die Anzahl der Protokolle und die Geschwindigkeit, mit der sie sich ansammeln (und die Komplexität der Infrastruktur, durch die der Protokolldatenstrom fließt), sind ebenfalls unterschiedlich.
Der Landepunkt, den Sie sich von Anfang an vorstellen, ändert sich natürlich, wenn Sie das große System von Anfang an kennen. In meinem (egoistischen) Sinne gilt: Je größer der Maßstab, desto weniger aussagekräftig ist die Unterteilung auf Log-Ebene, die mir wichtig ist, und desto mehr muss ich mich auf die Häufigkeit des Auftretens in der Benutzerumgebung und die tatsächlichen Auswirkungen konzentrieren. Ich denke es wird kommen. Nun, es ist wirklich eine Vermutung, aber ...
Es gab eine gewisse Behauptung, dass die Domain des Lesers nicht immer mit meiner eigenen übereinstimmte, aber ich denke, dass dies als Autor eindeutig unangemessen war (die ursprüngliche Artikelseite wagte es übrigens, dies zu beheben). Ich nicht. Es ist so ein Artikel, also bitte genieße es so)
Wenn "die Domäne dieselbe ist, aber die Meinungen unterschiedlich sind", ist es leicht, mit der Meinungsverschiedenheit und dem Prozess ihrer Abstimmung zu diskutieren, aber es ist oft schwierig, sich mit verschiedenen Domänen zu versöhnen. Es ist eine schlechte Situation, auf die ich zurückblicken kann, wenn ich nicht gesagt habe: "Dies ist der Bereich, über den ich nachdenke. Dies ist die Protokollierungsstrategie dafür."
Übrigens ist es nicht Python, aber ich habe Apps in der Mobilbranche geschrieben, also habe ich damals auch über Protokollierungsstrategien nachgedacht. Es dauerte ungefähr 5 Jahre, bis ich 2016 den Originalartikel schrieb.
Zu diesem Zeitpunkt ist die angenommene Skalierung sicherlich "globale Skalierung", aber sie floss nicht als konstanter Protokolldatenstrom auf einem Server-Backend. Das Ziel ist jedes einzelne Terminal, das ähnliche Protokolle in Stücken erzeugt. Die Protokollierungsstrategie unterscheidet sich derzeit von der kleinen Protokollverwaltung auf der Serverseite.
Es unterscheidet sich ein wenig von einem großen Server-Backend. Ich denke, der Stil, die Leute auf die Software- und Hardwareversion aufmerksam zu machen, wird sich ändern. Es ist nicht ungewöhnlich, dass bei der Fehlerbehebung angegeben wird: "In welcher Version haben Sie den Wortlaut der Protokollnachricht geändert, als dieser Fehler auftrat?"
In jedem Fall, wenn Software in der Gesellschaft so allgegenwärtig ist, wird die Logik hinter ihrer Funktionsweise völlig anders sein, und die Art und Weise, über die Protokollierung nachzudenken, die sie unterstützt, wird völlig anders sein.
Vor diesem Hintergrund möchte ich eine zusätzliche Notiz darüber machen, was ich mit meiner Domain zu tun versuche.
Einige Projekte übergeben "logger: Logger" oder "logger: Optional [Logger]" an die Funktion. Es ist kein Standardargument angegeben. Möglicherweise dürfen Sie jedoch explizit None übergeben (stellen Sie sich die angenommene Software-Skala als "ziemlich klein" vor).
Optional bedeutet" Wenn Sie den Logger nicht übergeben möchten, übergeben Sie None ". Die aufgerufene Funktion verwendet das Objekt, wenn es übergeben wird, andernfalls verwendet sie den Standardlogger der Domäne, zu der die Funktion gehört.Ich habe auch eine Weile "logger: Optional [Logger] = None" verwendet, aber das war ein schlechter Schachzug. Das Protokoll kann implizit zusammengedrückt werden, was mich sehr traurig macht, sodass ich jetzt zwei Möglichkeiten habe. Es ist jedoch möglicherweise nicht erforderlich, zwei Möglichkeiten zu haben.
Diese Methode wird wahrscheinlich nur für Entwicklungen in einem Maßstab nützlich sein, der "die Kontrolle über das gesamte Protokoll übernimmt" und "sich um die Komponenten im Detail kümmert". Wenn sich der Umfang des von Ihnen abgewickelten Dienstes auf den führenden BtoC in Japan bezieht, hängt dies von der Auslastung ab, aber Sie werden wahrscheinlich keine solche Strategie verfolgen.
Ich denke nicht, dass diese Methode sehr vielseitig ist, aber indem ich dies konsequent in dem Maße mache, in dem ich persönlich damit umgehe, hat sich der Protokollausblick für dieses Projekt erheblich verbessert.
Erstens denke ich, dass es neben dem kleinen Maßstab noch einen "Kodawari" -Teil gibt. Ich denke, es ist fraglich, ob das Protokoll gut oder schlecht ist, aber es ist immer noch besser als ** print () **. Wenn ein anderer Techniker führend ist und eine andere Protokollierungskonvention als Codierungskonvention hat, wird diese stillschweigend befolgt.
Dies ist nicht viel anders als zuvor, und das Problem ist, dass "Logger.info ()" und "Logger.debug ()" allein zu körnig sind. Logger.trace () (unter debug (). Es ist in Ordnung für die Start- und Endebene der Funktion) Ich möchte es (vielleicht Zabbix-Begriff) Logger.average () (über Warnung, aufgrund eines Fehlers) Es gibt einen Moment, in dem ich möchte (unten oder zwischen Info und Warnung) (auch dies spielt möglicherweise keine Rolle, wenn die Software-Skala zunimmt).
Wenn Sie einen Wrapper für Logger erstellen, können Sie dies wahrscheinlich tun. In Python sind DEBUG, INFO usw. konstante Werte, und zwischen diesen konstanten Werten besteht eine ausreichende Lücke (https://docs.python.org/3/library/logging.html#logging-levels).
Es gibt jedoch auch eine empirische Regel, dass es auf lange Sicht besser funktioniert, wenn Sie sich an den "Standard" der Sprache oder des Frameworks halten, und es scheint nicht intuitiv "seltsam klug" zu sein, aber es gibt eine Geschichte des Zögerns. Ich beneide nur den Logback, der die Spur von Anfang an enthält.
Dieses Mal hatte ich keine hohen Emotionen und schrieb es einfach angemessen, so dass es vielleicht nicht interessant war, aber ich schrieb es als Folge.