Open theDevelopper opened 5 years ago
There's no way to accomplish that.
The logs are automatically put there by AWS, not by the serverless framework.
That's one of the reasons even without this plugin the --stage is part of the function name of the deployed lambda function.
I'd recommend you to not use more than one stage for the same lambda. The log streams are separated by instance by version, so I'd recommend you to add the following settings to your provider
provider:
...
logRetentionInDays: 14
versionFunctions: true
...
With that, every time you deploy it will generate a version, and that version number will be part of the log stream's name
We are currently in the process of moving to serverless with AWS. We are using serverless-aws-alias to utilise AWS's stage logic rather than the one provided by Serverless Framework. So far all seems to work fine with on exception which makes it a bit harder to debug customer errors.
Every Lambda log into a LogGroup on CW Logs. For every stage and every lambda Serverless creates a LogGroup and each lambda instance creates a Log Stream within these LogGroups. So far so good.
the structure looks like this:
/aws/lambda/{service}-{stage}-{function}
on top of that there is another LogGroup i do not know the purpose of:
/serverless/{service}-{alias}
now every lambda writes into the LogGroup defined by its name. So a lambda function
hello
for stagedev
and servicetest
writes to:/aws/lambda/test-dev-hello
My issue is that it uses this LogGroup independent of the alias. We never need to change the stage from Serverless as we only need on Serverless stage with multiple aliases. So if i look for log entries specific from the dev alias I probably won't succeed if there are tons of staging and production logs in the same LogGroup as well.
Is there a way to add the alias into the LogGroup name? Like
/aws/lambda/{service}-{alias}-{function}
or/aws/lambda/{service}-{stage}-{function}-{alias}
?To be clear: We tried overwriting the LogGroup names with no success. We were able to create the groups but lambdas stopped logging. And on top of that a deploy to a new alias complained that the Resource already exists for another alias.
Example of how it does not work: