Echa un vistazo al contexto de tu función. Tiene la propiedad context.logStreamName . Puede cambiarlo a cualquier nombre único.

Tenga en cuenta que si desea agregar sus registros a una transmisión existente, debe conservar su token. Fue la razón por la que creé un nuevo flujo de registro para cada llamada lambda. Además, estoy usando guid para crear el nombre de la transmisión (como: reason why log created + guid() , la marca de tiempo también está bien).

Consulte más detalles en el siguiente artículo: el objeto de contexto (Node.js)

EDITAR : No preste atención a mi respuesta anterior. Estaba completamente equivocado.

Revisé mi código cómo implementé la misma funcionalidad. No es posible cambiar el nombre del grupo o de la secuencia desde el contexto. Pero podría usar CloudWatchLogs en su código para colocar registros en grupos y transmisiones específicos.

Mi código:

 var AWS = require('aws-sdk'); exports.handler = (event, context, callback) => { // TODO implement var cloudwatchlogs = new AWS.CloudWatchLogs({ apiVersion: '2014-03-28' }); // create new stream name for each request // because I don't persist sequenceToken var logStreamName = "myStreamName" + Math.random() var params = { logGroupName: 'myLogGroup', logStreamName: logStreamName }; cloudwatchlogs.createLogStream(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else { var params = { logEvents: [{ message: 'log message', timestamp: new Date().getTime() }, { message: 'one more log message', timestamp: new Date().getTime() } ], logGroupName: 'myLogGroup', logStreamName: logStreamName }; cloudwatchlogs.putLogEvents(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response }); } }); callback(null, 'Hello from Lambda'); };

Las desventajas de este enfoque son:

• Su lambda crea dos grupos de registro y dos flujos de registro de acuerdo. Una de tus lambda, otra custom. console.log('') escribe en el registro lambda, putLogEvents escribe en su registro personalizado (es decir: myStreamName0.10141409975385463). Sea consciente de esto.
• Debe crear manualmente 'myLogGroup' (como lo hice) o implementar un código que creará un grupo de registro si no existe.

El resultado de este código de prueba se ve así:

Los nombres de las transmisiones de mis producciones tienen más sentido que el nombre + aleatorio. Y están usando guid o marca de tiempo como sufijo. No creo que sea seguro usar random.

No puede cambiar el nombre de Log Stream. Cada contenedor en ejecución para su función Lambda inicia sesión en un Log Stream diferente.

Si desea ver fácilmente los registros juntos como uno solo, puede transmitirlos a Amazon ElasticSearch Service para que pueda usar Kibana para navegar a través de sus registros o puede usar herramientas CLI como awscli para agregarlos y buscarlos en su terminal.

Si desea realizar un seguimiento de las ejecuciones de todos modos, como en mi caso, también hay un enfoque menos redundante:

Simplemente cree una tabla de dynamodb "Ejecuciones" y asegúrese de insertar una nueva entrada en cada ejecución de lambda con logStreamName (al que se puede acceder desde el contexto) y su nombre personalizado u otra información personalizada que necesite para buscar este logStream.

Ventajas:

• no se necesita una lógica de registro personalizado/contenedor.
• no hay entradas duplicadas en cloudwatch

Desventajas:

• es posible que deba realizar una llamada adicional a dynamodb para averiguar logStreamName, ya que logStreamName en sí mismo no tiene un valor de identificación
• no hay consideraciones sobre IAM y acceso hasta ahora. tienes que tener eso en cuenta en tu configuración