Protokolle puffern und bei Fehler automatisch leeren mit Powertools für Lambda

Die neueste Version von AWS Powertools für Lambda erleichtert die Erweiterung des Loggers um benutzerdefinierte Funktionen:

Logger-Klasse ist jetzt erweiterbarer
Sie können jetzt die Logger-Methoden createAndPopulateLogItem, printLog undprocessLogItem überschreiben, die zuvor privat waren. Dadurch können Sie den Logger erweitern und neue Funktionen hinzufügen, z. B. Ihren eigenen Nachrichtenpuffer implementieren.
Veröffentlichung v2.12.0

Ich verwende diese neue Erweiterbarkeit, um eine nützliche Funktion zu implementieren: Protokollpufferung und -löschung. Die Idee ist einfach: In einer Produktionsumgebung protokollieren wir normalerweise nur wichtige Informationen wie Warnungen und Fehler, da der Protokollspeicher teuer werden kann und Lärm verursacht. Wenn jedoch ein Fehler auftritt, möchten wir alle möglichen Informationen: Alle über eine Funktion verstreuten Debug- und Infoprotokolle sollten verfügbar sein. Das ist aber nicht der Fall, weil wir unseren Log-Level zu niedrig eingestellt haben.

Puffern und Spülen

Was wäre, wenn wir alle diese Debug- und Infoprotokolle intern sammeln und sie, wenn ein wichtiges Ereignis wie ein Fehler auftritt, auf der Konsole ausdrucken würden? Ich klassifiziere Protokolle in zwei Kategorien: Protokolle auf niedriger Ebene und Protokolle auf hoher Ebene. Wenn unsere konfigurierte Protokollstufe WARN ist, wäre ein DEBUG- oder INFO-Protokoll ein Low-Level-Protokoll und ERROR ein High-Level-Protokoll.

Wenn wir jetzt ein Low-Level-Protokoll drucken, puffern wir das Protokoll in einer internen Liste, anstatt es so zu verwerfen, wie es jetzt ist. Sobald wir ein High-Level-Protokoll haben, leeren wir alle gepufferten Protokolle an die Konsole.

Durchführung

Um diese Funktionalität hinzuzufügen, erstellen wir eine neue Klasse, die die Logger-Klasse von Powertools erweitert und processLogItem() überschreibt. Dies ist die zentrale Methode, die von den verschiedenen Protokollmethoden wie logger.debug() aufgerufen wird. Die ursprüngliche Implementierung gibt das Protokollelement auf der Konsole aus, wenn es sich auf der richtigen Ebene befindet. Durch Überschreiben dieser Methode können wir unsere spezielle Logik zum Puffern und Leeren von Protokollen abhängig von der Protokollebene hinzufügen.

import { LogItem, Logger as PowertoolsLogger } from '@aws-lambda-powertools/logger';
import type { LogItemExtraInput, LogItemMessage } from '@aws-lambda-powertools/logger/types';

export class Logger extends PowertoolsLogger {
  #buffer: Record<string, Array<[number, string]>> = {};

  get buffer(): Record<string, Array<[number, string]>> {
    return this.#buffer;
  }

  protected override processLogItem(logLevel: number, input: LogItemMessage, extraInput: LogItemExtraInput): void {
    const xRayTraceId = this['envVarsService'].getXrayTraceId() as string;

    // Flush buffer when log level is higher than the configured log level
    if (logLevel > this.level && xRayTraceId) {
      const buffer = this.#buffer[xRayTraceId] ?? [];

      // Print all log items in the buffer
      if (buffer.length) this.info(`Flushing buffer with ${buffer.length} log items`);

      for (const [bufferLogLevel, bufferLogItem] of buffer) {
        // Create a new LogItem from the stringified log item
        this.printLog(bufferLogLevel, new LogItem(JSON.parse(bufferLogItem)));
      }

      // Clear the buffer after flushing
      // This also removes entries from other X-Ray trace IDs
      this.#buffer = {};
    }

    // Buffer the log item when log level is lower than the configured log level
    if (logLevel < this.level && xRayTraceId) {
      const buffer = this.#buffer[xRayTraceId] ?? [];
      // Add the stringified log item to the buffer
      // Serializing the log item ensures it is not mutated after being added to the buffer
      buffer.push([logLevel, JSON.stringify(this.createAndPopulateLogItem(logLevel, input, extraInput))]);

      // Update the buffer with the new log item
      // This also removes other X-Ray trace IDs from the buffer
      this.#buffer = {
        [xRayTraceId]: buffer,
      };
    }

    // Call the parent method to ensure the log item is processed
    super.processLogItem(logLevel, input, extraInput);
  }
}

Sie fragen sich vielleicht, warum wir hier die X-Ray Trace ID verwenden. Es ist üblich, den Logger außerhalb der Handlerfunktion zu instanziieren. Da die Lambda-Ausführungsumgebung jedoch für potenziell mehrere Aufrufe wiederverwendet wird, könnte der Puffer Protokollelemente aus früheren Aufrufen enthalten. Aus diesem Grund wird der Puffer als Objekt und nicht als einfaches Array implementiert. Wir verwenden die X-Ray Trace-ID als Kennung, um nur Protokollelemente aus demselben Aufruf zu puffern.
Der Puffer wird als Objekt und nicht als einfaches Array implementiert. Wenn der Puffer geleert ist, können wir das Objekt einfach zurücksetzen und somit Elemente aus anderen Aufrufen entfernen.

Lokal testen

Lassen Sie uns schnell die Implementierung vor Ort überprüfen:

// set X-Ray Trace ID manually if running locally
process.env._X_AMZN_TRACE_ID = '1-abcdef12-3456abcdef123456abcdef12';

// log level = WARN
const logger = new Logger({ logLevel: 'WARN' });

logger.debug('debug'); // < log level
logger.info('info');   // < log level
logger.warn('warn');   // = log level
logger.error('error'); // > log level

Hier ist die Ausgabe, die wir erhalten:

import { LogItem, Logger as PowertoolsLogger } from '@aws-lambda-powertools/logger';
import type { LogItemExtraInput, LogItemMessage } from '@aws-lambda-powertools/logger/types';

export class Logger extends PowertoolsLogger {
  #buffer: Record<string, Array<[number, string]>> = {};

  get buffer(): Record<string, Array<[number, string]>> {
    return this.#buffer;
  }

  protected override processLogItem(logLevel: number, input: LogItemMessage, extraInput: LogItemExtraInput): void {
    const xRayTraceId = this['envVarsService'].getXrayTraceId() as string;

    // Flush buffer when log level is higher than the configured log level
    if (logLevel > this.level && xRayTraceId) {
      const buffer = this.#buffer[xRayTraceId] ?? [];

      // Print all log items in the buffer
      if (buffer.length) this.info(`Flushing buffer with ${buffer.length} log items`);

      for (const [bufferLogLevel, bufferLogItem] of buffer) {
        // Create a new LogItem from the stringified log item
        this.printLog(bufferLogLevel, new LogItem(JSON.parse(bufferLogItem)));
      }

      // Clear the buffer after flushing
      // This also removes entries from other X-Ray trace IDs
      this.#buffer = {};
    }

    // Buffer the log item when log level is lower than the configured log level
    if (logLevel < this.level && xRayTraceId) {
      const buffer = this.#buffer[xRayTraceId] ?? [];
      // Add the stringified log item to the buffer
      // Serializing the log item ensures it is not mutated after being added to the buffer
      buffer.push([logLevel, JSON.stringify(this.createAndPopulateLogItem(logLevel, input, extraInput))]);

      // Update the buffer with the new log item
      // This also removes other X-Ray trace IDs from the buffer
      this.#buffer = {
        [xRayTraceId]: buffer,
      };
    }

    // Call the parent method to ensure the log item is processed
    super.processLogItem(logLevel, input, extraInput);
  }
}

Die Warnung ist die erste Meldung, da die Debug- und Info-Protokolle gepuffert wurden. Als der Fehler protokolliert wurde, haben wir die gepufferten Protokolle geleert (und eine Info gedruckt), bevor der Fehler tatsächlich gedruckt wurde.

Bitte um Kommentare

Meine naive Implementierung weist einige Einschränkungen auf. Am wichtigsten ist, dass die Puffergröße nicht begrenzt ist, was bedeutet, dass es zu Speicherproblemen kommen kann, wenn der Puffer zu groß wird. Es gibt einige Ansätze, dieses Problem zu entschärfen, beispielsweise durch die Implementierung des Puffers als Schiebefenster, das nur die neuesten Protokolle speichert, oder durch die Begrenzung der Gesamtpuffergröße.

Darüber hinaus werden die gepufferten Protokolle nur in kontrollierten Fällen wie bei logger.error() geleert, nicht jedoch bei nicht behandelten Fehlern. Dieses Verhalten könnte leicht erreicht werden, wenn wir den Puffer öffentlich machen und eine Middleware wie Middy.js verwenden. Middy macht ein onError-Ereignis verfügbar, das wir nutzen könnten, um den Puffer zu leeren.

Ich habe darüber ausführlicher in dieser Bitte um einen Kommentar zum offiziellen AWS Powertools for Lambda-Repository geschrieben.

Wenn Sie möchten, dass diese Funktion Teil von Powertools für Lambda wird, teilen Sie uns bitte dort Ihre Ideen und Ihr Feedback mit?

Das obige ist der detaillierte Inhalt vonProtokolle puffern und bei Fehler automatisch leeren mit Powertools für Lambda. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!