Closed kingkool68 closed 7 years ago
Sometimes errors get missed during development, but when they're on production they're more likely to be triggered because of the number of people accessing different parts of the site. I find it really helpful to have errors on live yell at me — it's a little unnerving to have error logs buried in the server where I'm unlikely to access them on an everyday basis.
Though really is kind of a sad thing where we find out if we broke something when the errors start getting triggered… just another case for more unit tests…
Setting up CloudWatch log agent: http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html
This was the output after running through the Interactive config:
------------------------------------------------------
- Configuration file successfully saved at: /var/awslogs/etc/awslogs.conf
- You can begin accessing new log events after a few moments at https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#logs:
- You can use 'sudo service awslogs start|stop|status|restart' to control the daemon.
- To see diagnostic information for the CloudWatch Logs Agent, see /var/log/awslogs.log
- You can rerun interactive setup using 'sudo python ./awslogs-agent-setup.py --region us-east-1 --only-generate-config'
------------------------------------------------------
See http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html See http://cloudacademy.com/blog/centralized-log-management-with-aws-cloudwatch-part-1-of-3/