I am a little confused. Am I supposed to configure each controller to specifically log to cloudwatch (and if so, how?) or is each controller supposed to have its own log group by default? Currently none of my controller functions has a cloudwatch log group. Please advice.
Naw, the CloudWatch log groups should automatically be created. They get created when the lambda functions execute. Wondering if you could try hitting the lambda function directly in the Lambda Console (web browser). Then after that, check CloudWatch logs. You should see the Log group to verify that the lambda function ran.
Here are also some video and tutorials that may help:
- Jets Debugging CloudWatch Logs - Useful CloudWatch log intro.
- Jets Tutorial Debugging Logs Part 3: AWS Lambda Ruby - Shows how to find the log group with a demo Jets application deployed.
- AWS Lambda Function: Jets AWS Introduction Series Part 1 - This covers AWS Lambda function essentials. This shows the process of creating a Lambda function manual. Jets automates this for you but found it to be helpful for folks.
Had another thought. Wondering if your AWS Lambda console is in the right region. Try running aws logs describe-log-groups from the terminal where you deployed the Jets application. It should show the log groups that way also. Also, aws lambda list-functions should show the deployed functions.
Think here’s a similar question
https://community.rubyonjets.com/t/lambda-and-api-gateway-not-being-generated/37/3
Everything is configured to ‘us-east-1’. I am able to execute the api via console, via postman etc, but no logs. There is however a log group created: project_name…-jets-base-path-20190609…
Inspecting the lambdas, they don’t even have the cloudwatch trigger enabled, so there’s no way they’d be able to generate logs.
Ah I see. The project_name…-jets-base-path-20190609… log group is from a lambda function that is created when using Custom Domains. Can you first try disabling the Custom Domain setting and deploying without it.
It sometimes helps to deploy incrementally first. Then after that is successfully deployed, enable the custom domain and debug only that portion. Otherwise the CloudFormation stack rolls back to the start and you end up waiting longer.
Think this might be a custom domain specific issue. Another person had an issue with the custom domain before but haven’t been able to reproduce yet. 
Can you also provide the logs in the project_name…-jets-base-path-20190609… group when you get a chance?
Also, are you getting any CloudFormation stack rollback errors? Here’s how you can check: https://rubyonjets.com/docs/debugging/cloudformation/
No Rollbacks. Successful deploy each time. I deployed again sans custom domain and still no cloudwatch log groups.
Shouldn’t I at least see AWS::Logs::LogGroup in one of the cloudformation templates?
Naw. Though it’s true the template can have a AWS::Logs::LogGroup Jets doesn’t add it to the template. The CloudWatch log group is inferred from the AWS::Lambda::Function resource.
- AWS Lambda Function: Jets AWS Introduction Series Part 1 - Have you tried this? Would try to create a Lambda function manually. Test it. And confirm that creates a CloudWatch log group. Thinking that will provide some debugging clues.
I found the problem. I had defined specific IAM policies for my application - this must be overwriting the default policies. Inspection of the lambda policy itself after deployment revealed a lack of cloudwatch actions. I added the following to the iam policies and everything seems to work fine now. I will fine tune the resources some more for better security.
config.iam_policy = [
{
action: [
'logs:CreateLogStream',
'logs:PutLogEvents',
'logs:CreateLogGroup',
'logs:DescribeLogStreams'
],
effect: 'Allow',
resource: ['arn:aws:logs:*:*:*']
}
...
...
]Ah I see. Was wondering if your app overrode the default application-wide IAM policy, but didn’t ask.
If you’re overriding the default IAM policy, you may want to append to the default one. The reason is that default one is actually calculated depending on features you might use, like Shared Resources. Example of using the Jets::Application.default_iam_policy policy and adding more of your own.
Jets.application.configure do |config|
# ...
config.iam_policy = [
Jets::Application.default_iam_policy,
{
action: ["dynamodb:*"],
effect: "Allow",
resource: "arn:aws:dynamodb:#{Jets.aws.region}:#{Jets.aws.account}:table/#{Jets.project_namespace}-*",
}
]
end
It’s also covered in the docs. https://rubyonjets.com/docs/iam-policies/ Pulled the example from the docs.
1 Like
Doh 
… RTFM
On a separate note @tung your quick responses to questions on an open source project I imagine you’re maintaining by yourself has been absolutely stellar. Happy to help where I can.
1 Like