A logger for Node that integrates with Google Cloud Platform.

This repository enforces semantic commit messages. For more details and examples see the Conventional Commits Specification.

yarn add @aurora-is-near/gcp-logger

import { createLogger } from 'aurora-is-near/gcp-logger';

const logger = createLogger();

logger.debug('Something happened');
logger.info('Something else happened');
logger.warn('Something quite bad happened, but I can recover.');
logger.error('Something really bad happened');
logger.error(new Error('I also accept error objects'));

To include additional information about an HTTP request you can include a request object when calling createLogger(). This object should be a Node IncomingMessage, or child or an IncomingMessage, such as the request object passed to a Google Cloud Function, for example:

const requestHandler = (req, res) => {
  const logger = createLogger({ req });

  logger.debug('Something happened');
}

To include additional information about the response you can use the set function, as follows:

logger.set('httpRequest', {
  status: 500,
  responseSize: '4200',
});

See HttpRequest for more details.

If you want to set some arbitrary context that should be attached to all subsequent log messages you can do so like this:

logger.set('context', {
  user: {
    name: 'Joe Bloggs',
  },
  auth: {
    authenticated: true,
  },
});

If you want to append to some previously set context you can do so like this:

logger.append('context', {
  user: {
    age: 37,
  },
});

Using the two snippets above as an example, this would result in all subsequent log messages including the data:

{
  "jsonPayload": {
    "user": {
      "name": "Joe Bloggs",
      "age": 37
    },
    "auth": {
      "authenticated": true
    }
  }
}

Note that when appending to the context objects will be merged, primitive values and arrays will be replaced.

A logging function is provided for each of the following levels (shown in ascending order):

• debug: This is the level for something entirely ordinary going on, like a successful response being sent. These may be quite spammy, with multiple entries presenting overlapping information.
• info: This also has a neutral connotation, but represents something more rare, like a major state change. It could for example also be used for printing the results of a timed job, or usage statistics.
• warn: This is for unusual conditions that are recoverable but may cause nuisances, or later a more severe problem. For example, it could be used for optional requests failing, or when an inconsistent but uncritical data state is detected.
• error: This is for a case where the application fails to do its main job. For example, if a user request could not be served, and this cannot be attributed to a client error.

By default, if NODE_ENV=production then logs at the info level and above will be processed, otherwise all logs will be processed. You can control this more specifically by setting the logLevel when calling createLogger(), for example:

createLogger({ logLevel: 'warn' });

You can also set the log level via the LOG_LEVEL environment variable, which may be useful for enabling debug logs temporarily in a remote environment, for example.