Best Practices für die Protokollierung von Unternehmensanwendungen (aus Sicht eines Supportingenieurs)

Anwendungsprotokolle enthalten Informationen zu externen und internen Ereignissen, die die Anwendung während der Ausführung sieht. Wenn während einer Bereitstellung ein Fehler, ein Hack oder eine Anomalie auftritt, sind Protokolle der nützlichste und zuverlässigste Beweis für die Analyse der Ursachen des Vorfalls.



Lassen Sie uns einen Blick darauf werfen, wie Sie nützliche Nachrichten in das Tagebuch schreiben, die jeder lieben wird.

1. Was soll protokolliert werden?

Eingehende und ausgehende Nachrichten

Wenn die Komponenten mithilfe von Nachrichten miteinander interagieren, müssen Sie eingehende und ausgehende Nachrichten aufzeichnen, die die URLs der API-Endpunkte, Anforderungsparameter, anfängliche und mittlere IP-Anforderungen, Anforderungsheader, Informationen zum Autor, Anforderungs- und Antwortkörper sowie den Geschäftskontext angeben , Zeitstempel und interne Verarbeitungsschritte.



Es ist sehr wichtig, dass jeder Nachricht eine eindeutige Kennung zugewiesen wird (normalerweise auf API-Manager- oder Serviceebene generiert). Dies ist erforderlich, um den Nachrichtenaustausch zwischen Diensten im System zu verfolgen.

Aufrufen von Diensten und Funktionen

Wenn Sie einen Dienst oder eine Funktion aufrufen, ist es wünschenswert, deren Kontext detaillierter zu protokollieren, hauptsächlich zum Debuggen (verwenden Sie TRACE oder DEBUG). Mithilfe dieser Protokolle können Sie Probleme mit der Geschäftslogik beheben, insbesondere wenn Sie nicht berechtigt sind, einen Debugger an eine Anwendung anzuhängen (z. B. bei der Bereitstellung in einer Test-, Staging- oder Pre-Prod-Umgebung).

Benutzeraktionen und Geschäftsstatistiken

Jede Anwendung verfügt über einzigartige Geschäftsszenarien und Benutzerreisen, die spezialisierten Fachleuten viele Informationen bieten. Zum Beispiel, ob eine bestimmte Transaktion zu lange gedauert hat oder ob Benutzer an bestimmten Funktionen hängen bleiben - all dies sind aus Sicht der Benutzererfahrung sehr wichtige Daten. Andere geschäftsbezogene Informationen - die Anzahl der Transaktionen und aktiven Benutzer sowie deren Phasen - sind wichtig, um kausale Zusammenhänge zu finden, und können sogar in der Geschäftsanalyse verwendet werden.

Datenoperationen (Audit Trail)

Aus Sicherheits- und regulatorischen Gründen benötigen die meisten Unternehmensanwendungen separate Transaktionsprotokolle mit allen wichtigen Informationen wie Zugriffs-IDs (Benutzer und Systeme), genauen verwendeten Dienstinstanzen und Rollenberechtigungen, Zeitstempeln, Datenanforderungen und Snapshots und der neue Zustand der geänderten Daten (diff). Der Audit-Trail sollte alle Vorgänge mit Daten (Zugriff, Import, Export usw.) sowie CRUD-Vorgänge (Erstellen, Lesen, Aktualisieren, Löschen) aufzeichnen, die von Benutzern, anderen Systemen und Diensten ausgeführt werden.

Systemereignisse

Dazu gehören Informationen zum Verhalten (Starts, Stopps, Neustarts und sicherheitsrelevante Ereignisse), Übergangsmodi (Kalt, Aufwärmen, Heiß), dienstübergreifende Kommunikation (Handshake, Status des Verbindungsaufbaus - verbunden, getrennt, erneut verbunden, Wiederholungsversuche), Kennungen Dienstinstanzen, aktive Bereitstellung von APIs, aktives Abhören von IP- und Portbereichen, geladene Konfigurationen (Bootstrap und dynamische Updates), allgemeiner Dienststatus und alles andere, was Ihnen helfen kann, das Systemverhalten zu verstehen.

Leistungsstatistik

Sorgfalt ist ein großartiges Merkmal von Computergeräten, aber sie funktionieren möglicherweise nicht perfekt. Es kann jederzeit zu Leistungsproblemen oder plötzlichen unerwarteten Leistungseinbußen kommen (hauptsächlich aufgrund nicht behandelter Fehler und beschädigter Daten). Um diese zu ermitteln, wird immer empfohlen, Statistiken über den Gesamtzustand und die Leistung des Systems zu veröffentlichen. Es kann Informationen wie API-Anrufzähler (erfolgreich und fehlgeschlagen), Netzwerklatenz, durchschnittliche Roundtrip-Dauer, Speicherverbrauch und andere anwendungsspezifische Informationen enthalten (normalerweise abhängig vom Geschäftskontext).

Bedrohungen und Schwachstellen

Das Aufdecken von Bedrohungen und Schwachstellen mithilfe von Laufzeitanwendungen und -protokollen ist eine Kunst, die jeder Entwickler von Unternehmenssoftware beherrschen muss. Hacks und Pannen treten normalerweise nicht plötzlich auf. Meistens gibt es Anzeichen dafür, dass niemand es zuerst bemerkt. Daher sollten Sie immer verdächtige menschliche Aktivitäten protokollieren (z. B. fehlerhafte Authentifizierungs- und Verifizierungsversuche mit der Anwendung aller Informationen auf niedriger Ebene wie verwendete Netzwerke, Anforderungsquellen, Benutzerrollen und -berechtigungen) sowie das Systemverhalten (z. B. eine Zunahme von Spitzen in den Ressourcenverbrauchsmustern, hohe Belastung) Webserver, gelegentliche Dienstausfälle). Wenn Sie ein verdächtiges Ereignis bemerken, stellen Sie sicher, dass die Protokolle alle damit verbundenen Informationen enthalten. Perfekt,Es handelt sich also um einen Full-Stack-Trace mit Parameterwerten und zusätzlichen Informationen aus dem Anwendungskontext.

2. Was Sie nicht protokollieren müssen

Persönliche Informationen

Nahezu alle Datenschutzgesetze (z. B. GDPR, CCPA) empfehlen Entwicklern ausdrücklich, keine personenbezogenen Daten zu protokollieren. Dies umfasst Name, Spitznamen, Geschlecht, Geburtstag, Straße, E-Mail, Telefonnummern, Sozialversicherungsnummer und Kreditkartennummern.

Firmennamen und Kontaktinformationen

Stellen Sie sicher, dass Sie keine Firmennamen, Mitarbeiter-, Kunden-, Lieferanteninformationen oder Unternehmens- und individuellen Kontaktinformationen notieren. Das Journal sollte niemals Geschäftsbeziehungen und Transaktionen mit Dritten offenlegen. Verwenden Sie zum Verfolgen bestimmter Transaktionen vom System generierte Ereignis-IDs anstelle von echten Namen und geben Sie diese an andere Dienste weiter.

Finanzdaten (Bankkonten, Bankkartendaten, gesendete Beträge usw.)

Laut Gesetz müssen alle Finanzdaten vollständig entfernt oder maskiert werden. Die Offenlegung solcher Informationen in Magazinen kann leicht zu schwerwiegenden rechtlichen Schritten führen (bis hin zur strafrechtlichen Verantwortlichkeit). Vermeiden Sie dies auf jeden Fall.

Passwörter, Sicherheitsschlüssel und -geheimnisse, Authentifizierungstoken

Anmeldeinformationen und Authentifizierungstoken gelten als vertrauliche Informationen, sodass Angreifer aufgrund ihrer Anwesenheit in Protokollen leicht Lücken im System finden können. Lassen Sie diese Daten daher nicht in die Protokolle.



Hinweis: Sie können leicht bestimmen, welche Informationen aus den Protokollen ausgeblendet werden sollen, wenn Sie jedem Feld ein Attribut hinzufügen, das den Grad der Sichtbarkeit bestimmt (z. B. Anzeigen, Maskieren, Ausblenden, Verschlüsseln). Wenn Sie über einen solchen Mechanismus verfügen, können Sie die Sichtbarkeit der Felder ändern, indem Sie einfach die Eigenschaften in der Konfiguration aktualisieren. Dies ist eine gute Lösung in Fällen, in denen Sie einige Benutzerinformationen in Umgebungen außerhalb des Kampfes protokollieren müssen, insbesondere zum Testen und Debuggen. Sie können auch Parser schreiben, die Protokolle filtern und vertrauliche Felder gemäß vorab geschriebenen Anweisungen für die Umgebung verarbeiten.

3. Best Practices

Wissen, wann eine bestimmte Protokollierungsstufe verwendet werden muss

Die Protokollebene wird verwendet, um den Schweregrad jedes Elements im System anzugeben. Die meisten Protokollierungsframeworks haben folgende Ebenen:

• FATAL : Sehr schwerwiegende Fehler, die höchstwahrscheinlich zur Beendigung der Anwendung führen. Dies führt normalerweise zu schwerwiegenden Fehlern.
• FEHLER : Fehler, mit denen die Anwendung weiterhin arbeiten kann, jedoch mit der Verschlechterung bestimmter Funktionen.
• WARNUNG : Weniger gefährliche Ereignisse im Vergleich zu Fehlern. Sie verschlechtern oder stürzen die Anwendung normalerweise nicht ab. Dies sind jedoch immer noch wichtige Ereignisse, die untersucht werden müssen.
• INFO : Wichtige Ereignisbanner und Informationsmeldungen im Anwendungsverhalten.
• DEBUG: , . .
• TRACE: , , . .

Linux Syslog hat auch schwerwiegendere Ebenen wie Notfall, Warnung, Kritisch, Fehler, Warnung, Benachrichtigung, Information und Debug.



Unabhängig von der Komplexität und Tiefe der einzelnen Protokollierungsstufen müssen wir sie in unserem Code ordnungsgemäß konfigurieren, um in jedem Szenario die optimale Informationsmenge bereitzustellen. Beispielsweise sollten alle Daten, die von Entwicklern für das Debuggen und die technische Analyse verwendet werden, auf DEBUG- oder TRACE-Ebene gehen, und Banner mit Systemdaten sollten unter INFO liegen.

Benutze Englisch

Einige Tools und Konsolen unterstützen die Ausgabe und Speicherung von Protokollen mit bestimmten Unicode-Zeichen nicht. Daher können Lokalisierung und andere Verbesserungen schwierig sein. Halten Sie sich an Englisch und verwenden Sie zum Schreiben von Nachrichten immer einen weit verbreiteten Zeichensatz.

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Entwicklerfreundliche Nachrichten hinzufügen (prägnant und aussagekräftig)

Wenn zu wenig protokolliert wird, können wir nicht die Informationen abrufen, die wir benötigen, um den Kontext jedes wichtigen Ereignisses neu zu erstellen. Wenn Sie zu viel protokollieren, wird die Leistung beeinträchtigt: Durch das Schreiben einer großen Protokolldatei wird der Ressourcenverbrauch für E / A und Festplattenspeicher erhöht. Wenn das Dateisystem dies nicht unterstützt, wird die Gesamtsystemleistung verringert.



Um Nachrichten zu optimieren, benötigen Sie ein klares Verständnis der funktionalen und nicht funktionalen Erwartungen des Systems und die Planung der gewünschten Qualität und Quantität von Nachrichten. Jedes Tagebuch sollte aussagekräftig und dem Kontext angemessen sein: Schreiben Sie immer kurz und auf den Punkt.

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)

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Erstellen Sie Referenzkennungen, Aliase und vereinfachte Vorlagen für häufig verwendete und lange Nachrichten

Versuchen Sie, anstatt jedes Mal eine vollständige Beschreibung aufzuschreiben, Referenzkennungen oder vereinfachte Vorlagen zu erstellen, um lange, sich wiederholende Beschreibungen im Protokoll darzustellen. Dies reduziert die Gesamtzahl und Länge der Nachrichten und erhöht auch die Flexibilität, bestimmte Informationen auszublenden. Anstatt beispielsweise eine Sicherheitsanfälligkeit in einem Textprotokoll zu beschreiben, ist es besser, einen Alias ​​oder eine Kennung zu verwenden, damit nur spezialisierte Experten das aktuelle Szenario verstehen können.

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Verwenden Sie die richtigen Zeitstempel

Mit Zeitstempeln können Sie die Abfolge der Ereignisse verstehen. Sie sind für das Debuggen und die Analyse erforderlich. Bei der Festlegung der Zeit wird empfohlen, die detailliertesten Werte zu verwenden (z. B. Millisekunden oder Mikrosekunden), damit benachbarte Ereignisse leichter identifiziert werden können. Stellen Sie außerdem sicher, dass sich die Zeitstempel am Anfang der Nachricht im Format JJJJ-MM-TT HH: MM: SS befinden. Geben Sie immer Ihre Zeitzone an, es sei denn, Sie verwenden die Standardzeit (UTC) des Servers.

// 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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Geben Sie die Quelle oder den Ursprung der Protokolldaten an (für DEBUG, TRACE, ERROR).

Dies ist sehr nützlich, um den Ort, der zur entsprechenden Nachricht geführt hat, eindeutig zu identifizieren. Bei einigen Protokollierungsframeworks können Sie Quellen auf der detailliertesten Ebene angeben (bis auf den Namen der Dateien mit Zeilennummern). In den meisten Fällen reicht es jedoch aus, nur die Klasse, Funktion oder den Dateinamen anzugeben.

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...

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Jedes Journal muss innerhalb des Systems eindeutig sein

Die meisten Neulinge machen den gleichen Fehler: Kopieren Sie eine Beispielnachricht und fügen Sie sie in verschiedene Dateien ein. Dabei wird das endgültige Protokoll aus denselben Zeilen gesammelt, die aus verschiedenen Teilen des Systems stammen. In diesem Fall ist es schwierig, den bestimmten Ort zu finden, der das Ereignis ausgelöst hat. Wenn der Satz von Wörtern nicht geändert werden kann, erwähnen Sie zumindest die Quelle in der Nachricht, damit sich die Zeilen in der endgültigen Datei voneinander unterscheiden. Wenn die Protokollierung von der übergeordneten Klasse verwaltet wird, senden Sie während der Initialisierung eine Kennung und zeichnen Sie damit Nachrichten über das Verhalten der untergeordneten Klassen auf.

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Fügen Sie der Nachricht eine verfolgte ID oder ein Nachrichtentoken hinzu

Wenn ein Ereignis oder eine Nachricht das System erreicht, wird ihm normalerweise eine eindeutige Kennung zugewiesen. Es kann an andere Verarbeitungsstufen übergeben werden, um die Bewegung eines Ereignisses durch das System zu verfolgen. Dies ist nützlich für das Debuggen, die gleichzeitige Verarbeitung und datenbezogene Vorgänge. Idealerweise sollte das System in allen Modulen und Diensten eine eindeutige Ereigniskennung haben.

[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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Übereinstimmungskennungen an Übergangspunkten

In bestimmten Fällen, insbesondere beim Übertragen eines Ereignisses von einem System zu einem anderen, ändern sich die Kennungen gemäß der im anderen System angenommenen Konvention. An solchen Übergangspunkten muss die Entsprechung zwischen der alten und der neuen Kennung in einer separaten Nachricht explizit angegeben werden, wobei der erforderliche Kontext hinzugefügt wird.

[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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Geben Sie Bezeichner für alle Dienstinstanzen an

Die meisten Unternehmenssysteme sind verteilte Computerplattformen, auf denen es viele Instanzen derselben Dienste mit verschiedenen Anwendungskonfigurationen, Ressourcen, Versionen und Netzwerkeigenschaften gibt. Es wird empfohlen, Instanzen Bezeichner zuzuweisen und diese für die dienstübergreifende Kommunikation zu verwenden.

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)

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Konfigurieren Sie eine aktive Protokollierungsstufe

Die aktive Protokollierungsstufe sollte je nach Bereitstellungsumgebung geändert werden. Für die Produktion wird empfohlen, Protokolle bis zur INFO-Ebene auszugeben. In anderen Umgebungen werden Protokolle abhängig von der Detailstufe, die von den Entwicklungs- und Betriebsteams benötigt wird, bis auf die DEBUG- oder TRACE-Ebene ausgegeben.

// 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...

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Stellen Sie einen ausreichenden Kontext für Fehler und Abstürze bereit

Fehler und Ausfälle erfordern eine gründliche Untersuchung. Zu diesem Zweck muss die Anwendung den Fachexperten die benötigten Informationen sowie den Technologie- und Geschäftskontext bereitstellen. Wenn beispielsweise eine Anforderung oder Nachricht nicht verarbeitet werden konnte, ist es sehr nützlich, zusätzlich zum Fehler den Hauptteil der fehlgeschlagenen Anforderung zu protokollieren.

[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": {...........}
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Sichern Sie Datentransaktionen mit Beweisen (nicht annehmen!)

Nehmen Sie für jede Datenoperation nicht an, dass sie erfolgreich war. Überprüfen Sie den Endzustand immer mit Beweisen. Wenn Sie beispielsweise einen Datensatz in der Datenbank erstellen, aktualisieren oder löschen, wird ein Zähler der geänderten Datensätze und des aktualisierten Datensatzes selbst zurückgegeben. Überprüfen Sie immer den erwarteten Zähler oder das erwartete Ergebnis. Ein weiteres Beispiel: Wenn Sie einen Datensatz in eine Datenstruktur (z. B. in eine Warteschlange) einfügen, überprüfen Sie, ob seine Größe zugenommen hat. Angenommen, Ihr System verwendet gleichzeitige Vorgänge, die Warteschlange unterstützt sie jedoch nicht. Dann können Sie einige Datensätze verlieren, und die einzige Möglichkeit, solche versteckten Fehler im Code zu erkennen, besteht darin, die Länge zu überprüfen.

DEBUG  BatchWriter:28 - Successfully connected to DB. Trying to insert 24 accounts...DEBUG  BatchWriter:35 - Successfully inserted 24 accounts. Total DB rows affected: 24

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Vertrauliche Daten verschlüsseln oder maskieren

Normalerweise schreibt das Gesetz vor, dass vertrauliche Informationen von Benutzern und internen Systemen maskiert und / oder verschlüsselt werden müssen. Die regulatorischen Anforderungen können je nach Branche und Arbeitsplatz variieren. Finden Sie alle Nuancen heraus und implementieren Sie die richtigen Verfahren in der Anwendung. In einigen Fällen müssen Sie möglicherweise Ihre Protokollierungsstrategie beim Sicherheitsdienst einreichen und deren Genehmigung oder Zertifizierung vor der Operationalisierung einholen.

[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”}
]
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Konfigurieren Sie die Benennung von Protokolldateien, Rotationsrichtlinien, Speichergrößen und Sicherungsverfahren

Wenn Sie Protokolle in Dateien schreiben, stellen Sie sicher, dass diese auf einer separaten Festplatte gespeichert sind, die die laufende Anwendung in keiner Weise beeinflusst (Sie können beispielsweise ein Volume auf einem Remoteserver zuweisen und es an den Anwendungsserver anhängen). Informieren Sie sich auch über die Häufigkeit des Journaling und wie die Dateien wachsen. Stellen Sie sicher, dass Sie über eine Protokollrotationsrichtlinie mit korrekten Namenskonventionen verfügen (z. B. Hinzufügen eines Zeitstempels zum Namen beim Erstellen), um die ideale Größe und Anzahl der Dateien beizubehalten. Sie sollten auch einen Mechanismus zum Sichern alter Protokolle an einem sicheren Ort und einen Mechanismus zum regelmäßigen Aufräumen des Speichers haben. Abhängig von Ihrer Branche können Sie eine zeitgesteuerte Sicherung einrichten (normalerweise alle paar Monate oder Jahre), wobei alle vorherigen Dateien am Ende des Zeitraums zerstört werden.

[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.

Unter Entwicklern von Unternehmensanwendungen ist es sehr üblich, einen zentral zugänglichen Server oder Speicherort zum Sammeln von Protokollen zu erstellen. In der Regel verfolgen solche Aggregatoren Protokolle nicht nur von Anwendungen, sondern auch von Geräten und Betriebssystemen (z. B. Linux Syslog), Netzwerken, Firewalls, Datenbanken usw. Außerdem trennen sie Protokolldateien von Anwendungsservern und ermöglichen es Ihnen, Protokolle in mehr zu speichern geschützte, geordnete und effiziente Formate für eine längere Zeit. In einigen Branchen (z. B. Bank- und Finanzwesen) müssen Protokolle sowohl im lokalen als auch im zentralen Speicher gespeichert werden, damit Angreifer nicht gleichzeitig auf beide Orte zugreifen und Beweise für ihre Aktivitäten entfernen können. Datenredundanz und Dateninkongruenz zwischen den beiden Speichern können daher helfen, Eingriffe zu erkennen.

Schreiben Sie Parser und verfolgen Sie Protokolle umsichtig

Die Fähigkeit, Parser und Filter zu schreiben, ist in die meisten Protokollüberwachungstools integriert - die sogenannte SIEM-Integration ( Security Information and Event Management ) . Parser helfen dabei, Protokolle in optimierten Formaten zu halten, und Abfragedaten werden viel einfacher und schneller. Außerdem können ordnungsgemäß organisierte Daten an Überwachungs- und Anomaliesuchsysteme übertragen werden, um zukünftige Ereignisse proaktiv zu überwachen und vorherzusagen. Diese Tools sind sehr leistungsfähig bei der grafischen Darstellung von Daten basierend auf Zeitreihen und in Echtzeit.

Richten Sie Warnungen und Push-Benachrichtigungen für kritische Vorfälle ein

Mit fast allen Tools zur Protokollüberwachung können Sie bestimmte Schwellenwerte für bestimmte Ebenen festlegen. Wenn das System diese Werte erreicht, erkennt das Tool sie im Voraus, hilft beim Protokollieren von Daten und benachrichtigt Systemadministratoren über Warnungen, Push-Benachrichtigungs-APIs (z. B. Slack Audit Logs API ), E-Mails usw. Sie können auch vorkonfiguriert werden, um automatisierte Prozesse zu initiieren. B. dynamische Skalierung, Systemsicherungen, Lastschleudern usw. Wenn Sie jedoch in kommerzielle Protokollüberwachungssoftware investieren, sollten Sie sich diese genauer ansehen, da solche Tools für kleine bis mittlere Softwaresysteme redundant sein können.

5. Empfohlene Werkzeuge

Protokollierungs-Frameworks

JavaScript / Typoskript: Log4js / pino

Java: Log4j

Golang: Logrus

Serverless-Funktionen: aws-Lambda-Elektrowerkzeuge-python / Selbst geschrieben

Durchsuchen, Aggregieren und Überwachen von Protokollen

CLI-Tools: weniger, vim

Cloud-Tools: Fluentd, AWS

CloudWatch SIEM-Tools: SolarWinds, Splunk, McAfee ESM, DataDog, IBM QRadar

Andere: ELK Stack (ElasticSearch, Logstash, Kibana, Beats), Loggly