Skip to main content

Amazon CloudWatch

Amazon CloudWatch
CloudWatch is an AWS service which lets you monitor the performance and availability of your AWS resources. The resources include Amazon EC2 instances, Amazon DynamoDB tables, Amazon RDS DB instances, as well as custom metrics and logs generated by your own applications and services. It can also be used to monitor the billing costs.

CloudWatch can be used to collect and track metrics, collect and monitor logs, set alarms and automatically react to changes in your AWS resources.

No additional software is required for CloudWatch monitoring. However, when you launch a new EC2 instance, you have a choice of enabling detailed monitoring. Detailed monitoring has an additional charge while non-detailed monitoring is free and enabled by default. However, you can choose to enable or disable detailed monitoring at any time and only pay for what you use. This can come in handy if you want more granularity while you are troubleshooting issues with your applications running on your EC2 instances.

Monitoring data is retained for two weeks even after your instance has been terminated.

You can view the CloudWatch metrics when you highlight an instance and select the Monitoring tab. In this view, you can also create Alarms.

Another way to view the CloudWatch metrics is to go to the CloudWatch service directly using the AWS Management Console. In this section you can create a dashboard and add the metrics you want to the dashboard. You can also create Alarms.

Amazon CloudWatch Events
CloudWatch Events was recently added as a feature of CloudWatch that enables you to create rules based on events generated by your AWS resources. These rules can then route these events to AWS Lambda, Amazon Kinesis streams, Amazon SNS topics, and built-in targets. It's not available to all regions at the moment. At the start of 2016 it was available in US East (Northern Virginia), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) regions. Obviously more regions will be added to the list as time goes.

Amazon CloudWatch Logs
CloudWatch Logs can be used to monitor, store and access log files in your EC2 instances, AWS CloudTrail Logged Events, and custom sources. I am not sure what is meant by custom sources at the moment as the documentation didn't really go through what these custom sources are but I will assume that they are other AWS resources. You can search the stored logs for error messages or warnings or any particular pattern of text you want. This can aid in troubleshooting and more importantly can help system administrators to be more pro-active and recognize a potential problem occurring.

To use CloudWatch Logs on EC2 instances, you will need to install the CloudWatch Logs agent if you are running Linux :

http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CWL_GettingStarted.html


If you are running Windows, you will need to use the EC2Config Service and enable the CloudWatch Logs integration :

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/send_logs_to_cwl.html#enable_cwl_integration


More information can be found here :

https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html
https://aws.amazon.com/cloudwatch/details/#amazon-ec2-monitoring

Labels:

Comments

Post a Comment

Popular posts from this blog

How to Schedule an Exchange PowerShell Script in Task Scheduler

Exchange Management Shell Since Exchange 2007, Microsoft has provided the Exchange Management Shell so administrators can manage all aspects of the Exchange server from the command line. The Exchange Management Shell has Exchange specific PowerShell cmdlets. These Exchange cmdlets are not normally available in an ordinary PowerShell command environment. An example of what can be done in the Exchange Management Shell is to run a PowerShell script to list all the mailboxes on the Exchange server to a file. You can output columns based on display name, size of the mailbox, last logon, and other available mailbox attributes. You can also schedule a batch migration of mailboxes from one database to another such as the migration of mailboxes from Exchange 2010 to Exchange 2013. Scheduling the PowerShell Script Once you have written a PowerShell script and utilised the Exchange cmdlets, you can run it with no problems inside the Exchange Management Shell. If you were to try
Post a Comment
Read more

Custom Metrics for Amazon CloudWatch

With Amazon CloudWatch, in addition to monitoring the built-in metrics that come with AWS, you can monitor with your custom metrics. This new custom metrics feature can be used in two different ways: 1. You can add to the metrics collected for Amazon EC2 Instances, EBS Volumes, Elastic Load Balancers, and Relational Database Service DB Instances. The metrics that you store can be technical (system performance indicators) or business-related (user activity over the monitoring period). 2. You can store metrics for any generic resource. You can use CloudWatch to create a single, integrated storage and aggregation point for all of the metrics that you want to watch and to monitor. In the exam (at least the test exam) you are asked to pick which ones are custom metrics. Therefore, go through the available AWS metrics so you will get an idea of which metric is likely to be a custom metric when you are asked the question. You can browse through the list of built-in metr
1 comment
Read more

How To Migrate Mailboxes from Exchange 2010 to Exchange 2016 using PowerShell

The Scenario Your organisation have decided to migrate from Exchange 2010 to Exchange 2016. The Exchange 2016 server have been installed into your current Exchange Organization. The Mailbox role have been installed on the Exchange 2016 server and you are ready to start moving mailboxes from the Exchange 2010 server to the Exchange 2016 server. Migrating a Mailbox from Exchange 2010 to Exchange 2016 Using New-MoveRequest Migrating a single mailbox involves invoking the cmdlet New-MoveRequest from the Exchange Management Shell on the Exchange 2016 server . Make sure that your user account that you have logged into the server with have the Organization Management role. The common parameters that I use for the New-MoveRequest cmdlet is : New-MoveRequest -Identity 'useralias@somedomain.com' -TargetDatabase "DB02" -BadItemLimit 10 The -Identity parameter identifies the mailbox to be migrated. I usually use the e-mail address of the mailbox for the identity
Post a Comment
Read more