I'm trying to forward the EC2 Launch logs to cloudwatch from my win 2016-based EC2 instance.
For some reason I can't see the log groups for this specific category.
Here's example of my AWS.EC2.Windows.CloudWatch.json:
{
"IsEnabled": true,
"EngineConfiguration": {
"PollInterval": "00:00:15",
"Components": [
{
"Id": "Ec2Config",
"FullName": "AWS.EC2.Windows.CloudWatch.CustomLog.CustomLogInputComponent,AWS.EC2.Windows.CloudWatch",
"Parameters": {
"LogDirectoryPath": "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Log",
"TimestampFormat": "yyyy-MM-ddTHH:mm:ss.fffZ:",
"Encoding": "UTF-8",
"Filter": "UserdataExecution.log",
"CultureName": "en-US",
"TimeZoneKind": "UTC"
}
},
{
"Id": "EC2ConfigSink",
"FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
"Parameters": {
"Region": "eu-west-1",
"LogGroup": "/my-customer/deployment/ec2config-userdata",
"LogStream": "ec2config-userdata"
}
}
...
I have a few more definitions in this file
...],
"Flows": {
"Flows":
[
"Ec2Config,EC2ConfigSink",
... other references here
]
}
}
Cloudwatch agent starts and doesn't report any errors, I can see data from other sources (some application log files - I skipped the definitions intentionally)
It means the cloudwatch config file is correct and is applied / placed in a correct directory.
Logs are coming through with no problem except for the EC2 launch logs.
I'm wondering if anybody ran into this problem? It works perfectly on Windows 2012 - based images
Apparently, the SSM Agent starts after the EC2 Launch executes UserDatascript. I can see it from the SSM Agent's log file modification timestamps.
Therefore, there's no log forwarding happening during the EC2 Launch.
When the SSM Agent starts and loads the cloudwatch plugin, the log files are already filled with entries and never change (wallpaper log is the only exception) So they never end up in cloudwatch console.
There's been a lot of changes implemented on AWS side: they switch to .Net core, removed EC2 config service and moved the log forwarding logic to SSM Agent (cloudwatch Plugin) for Windows 2016-based AMIs
It looks like the behavior has changed quite significantly too so there's no way to get the EC2 launch logs in cloudwatch (when using AWS toolset-only)
Basically we have to stick to our Application logs only which is very unfortunate. We rely on EC2 launch logs to see if the instance started & successfully executed user data.
Related
I have tried creating AWS Data pipelines using the CLI and also using the GUI. Either way, when I specify more than one slave node, it doesn't get created properly. Here is an example definition:
{
"name": "EmrClusterForLoad",
"coreInstanceCount": "16",
"coreInstanceType": "r3.xlarge",
"releaseLabel": "emr-5.13.0",
"id": "EmrClusterForLoad",
"masterInstanceType": "r3.xlarge",
"region": "#{myDDBRegion}",
"type": "EmrCluster"
},
Any suggestions or thoughts?
The only reason I can think of, if you are exhausting your account's EC2 resource limit. Datapipeline honors this limit.
If you are not exhausting limit, then go to AWS console for EMR, find the corresponding booted cluster >> Debug >> check logs for steps, see if something stands out.
You can also launch a EMR cluster directly from console, and see if you can spin up more than 1 slave core nodes.
Other than that configuration wise you look good, I would recommend reaching out to AWS support for further debugging.
Weird. I think this may be a bug. The "fix" was to change the value of the "Resize Cluster Before Running:" from true to false. If it's not a bug, then I am not sure I understand the option.
If you are creating the pipeline via CLI, then the entry is:
"resizeClusterBeforeRunning": "false"
When I changed this value, all of the sudden the EC2 instances started to be created.
We have developed an AWS Serverless Lambda application using dotnetcore to perform operations on EC2 Instances, say start or stop EC2 instance and integrated with Aws API Gateway.
serverless.template in dotnetcore application
"StartInstanceById" : {
"Type" : "AWS::Serverless::Function",
"Properties": {
"Handler": "EC2_Monitoring_Serverless::EC2_Monitoring_Serverless.Functions::StartInstanceById",
"Runtime": "dotnetcore2.1",
"CodeUri": "",
"MemorySize": 256,
"Timeout": 30,
"Role": "arn:aws:iam::2808xxxx1013:role/lamda_start_stop",
"Policies": [ "AWSLambdaBasicExecutionRole" ],
"Events": {
"PutResource": {
"Type": "Api",
"Properties": {
"Path": "/instances",
"Method": "Get"
}
}
}
}
}
The above Lambda function is working fine for starting ec2 instance when I invoking the API gateway url.
For calling these API's, We have created Angular 6 application and provided authentication using Aws Cognito Userpools.
So the cognito user logins into the website and gets all EC2 informations.
If the user wants to stop / start the EC2 instance, user will click on the particular button which invokes the relevant api gateway url of the lambda functions and It's working fine.
Now the question is who performed that action. After so much of research on stackoverflow and aws community forums for knowing who started or stopped the EC2 instances , I found Aws CloudTrail logs the information when user start or stopped the instance.
So I created a trail and I can see the logs in S3 buckets. But in every log I opened, I saw that the role "arn:aws:iam::2808xxxx1013:role/lamda_start_stop" is captured. I know this is because of the Lambda function. But I want to know who really stopped the instance.
Please advice how to capture user details!
The reason lambda execution role is getting printed in cloudtrail, is because it has initiated the process to stop the ec2 instance. Here the role is assumed (instead of actual user).
To print your actual user, you need to implement logs at your lambda, which will print logs to Cloudwatch. You can get the actual user or any other custom information from those logs.
One of RDS instance running within our account is deleted. We would like to find out who and when it is deleted.
Is there a way to find a log of that somewhere?
How can I see the events on RDS instance which is deleted
The when can be checked form the Events of your RDS dashboard page:
You can retrieve events for your RDS resources through the AWS Management Console, which shows events from the past 24 hours
If it happened earlier, you can use the CLI which retrieves events up to 14 days
[xxx#xxxx ~]# aws rds describe-events --source-identifier test --source-type db-instance
{
"Events": [
{
"Date": "2016-05-20T12:58:26.529Z",
"Message": "DB instance deleted",
"SourceIdentifier": "test",
"EventCategories": [
"deletion"
],
"SourceType": "db-instance"
}
]
}
I want to make alarm in case that there is 10% left in my disk space.
I read some articles of how monitoring free disk space with Cloud Watch but I think it seems to be only for linux.
Do you have any solution for monitoring free disk space for windows?
Thanks in advance.
This is how to configure a Windows 2016 EC2 instance to report free disk space (or any other performance counter on your server)
Download a sample AWS.EC2.Windows.CloudWatch.json file. This is where I found one.
https://s3.amazonaws.com/ec2-downloads-windows/CloudWatchConfig/AWS.EC2.Windows.CloudWatch.json
Copy the sample AWS.EC2.Windows.CloudWatch.json file on your Windows Server 2016 EC2 Instance here
C:\Program Files\Amazon\SSM\Plugins\awsCloudWatch\
Edit AWS.EC2.Windows.CloudWatch.json and set IsEnabled true
Add additional metrics as required. There is a sample one in the config for memory usage. Copy/paste this and alter the Metric name like this:
{
"Id": "PerformanceCounterDisk",
"FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
"Parameters": {
"CategoryName": "LogicalDisk",
"CounterName": "% Free Space",
"InstanceName": "C:",
"MetricName": "FreeDiskPercentage",
"Unit": "Percent",
"DimensionName": "InstanceId",
"DimensionValue": "{instance_id}"
}
}
Run Powershell as administrator and run
Restart-Service AmazonSSMAgent
New CloudWatch metrics appear almost instantly in AWS CloudWatch.
Configure AWS CloudWatch alarms as required.
Additionally, I made a short video with some tips on setting this up on Windows Server 2016.
https://www.youtube.com/watch?v=xKVrJJyG-4I
The following guide from AWS contains a step by step guide.
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/send_logs_to_cwl_instances.html#send_logs_cwl_configfile
Download and install the latest EC2Config to your windows instance (https://aws.amazon.com/developertools/5562082477397515)
Edit the settings file here C:\Program Files\Amazon\Ec2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json
Insert some counters in the appropriate place
{
"Id": "PerformanceCounterMemory",
"FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
"Parameters": {
"CategoryName": "Memory",
"CounterName": "Available MBytes",
"InstanceName": "",
"MetricName": "Available-Memory",
"Unit": "Gigabytes",
"DimensionName": "InstanceId",
"DimensionValue": "{instance_id}"
}
},
{
"Id": "PerformanceCounterDisk",
"FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
"Parameters": {
"CategoryName": "LogicalDisk",
"CounterName": "% Free Space",
"InstanceName": "C:",
"MetricName": "FreeDiskPct",
"Unit": "Percent",
"DimensionName": "InstanceId",
"DimensionValue": "{instance_id}"
}
}
Make sure to include them in the flow section:
"Flows": {
"Flows":
[
"(ApplicationEventLog,SystemEventLog),CloudWatchLogs",
"(PerformanceCounterMemory,PerformanceCounterDisk),CloudWatch"
]
}
Remember to set the key and secret of a user with cloudwatch policy rights.
Restart the EC2Config service. Follow progress in the log: C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2ConfigLog.txt
Create an alarm in cloudwatch on your new FreeDiskPct counter.
In Windows EC2 instance (tested on Server 2019)
Download and install CloudWatch Agent based on your instance type.
AWS CloudWatch Agent Installation
After that you'll notice a new service called Amazon CloudWatch Agent: it won't start until you configure it.
To configure that run the wizard located at C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-config-wizard.exe
Answer to all questions (you can skip log analysis and choos Basic metric for free storage percentage) and eventually a file called config.json will be created at C:\Program Files\Amazon\AmazonCloudWatchAgent
Move this file to C:\ProgramData\Amazon\AmazonCloudWatchAgent, rename it as amazon-cloudwatch-agent.json and start the service Cloudwatch Agent.
The service should start and collect metrics,check the log to see if there's are any error
If in log located at C:\ProgramData\Amazon\AmazonCloudWatchAgent\Logs you see this...
2020/05/27 16:11:27 I! Config has been translated into TOML
C:\ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.toml
2020-05-27T14:11:31Z I! cloudwatch: get unique roll up list []
2020-05-27T14:11:31Z I! Starting AmazonCloudWatchAgent
2020-05-27T14:11:31Z I! Tags enabled: host=[your host]
2020-05-27T14:11:31Z I! Agent Config: Interval:1m0s, Quiet:false,
Hostname:[your host], Flush Interval:1s 2020-05-27T14:11:31Z I!
cloudwatch: publish with ForceFlushInterval: 1m0s, Publish Jitter: 23s
2020-05-27T14:11:31Z I! Started the statsd service on :8125
2020-05-27T14:11:31Z I! Statsd listener listening on: [::]:8125
...all's gone well, as long as you have attached a IAM role to your instance to give it permissions to report to cloudwatch.
See this: CloudWatch permissions
Then you can find all your new defined metrics at CWAgent Parameters section in Cloudwatch, so that you can create an alarm
I think the basic question is for setting up the disk utilization alarm in CloudWatch for Windows instance. I hope you know that to get the disk metrics in CloudWatch you need to install the CloudWatch agent, which involves multiple steps already people have mentioned above. We get the %age of free space for Windows instance from AWS CloudWatch agent. So to set the alarm for high disk utilization we need to select alarm condition as lower than or equal to 10% or as per your requirement. I hope this answers your question.alarm condition for windows disk
I am trying to launch an autoscaling group with a single m3.medium instance and attached EBS using CloudFormation (CFN). I have succeeded in doing everything but the EBS part. I've tried adding the following block to my CFN template (as a property of the AWS::AutoScaling::LaunchConfiguration block):
"BlockDeviceMappings": [
{
"DeviceName": "/dev/sdf",
"Ebs": { "VolumeSize": 100, "VolumeType": "gp2" }
}
]
Without this the launch succeeds. When I include it, aws hangs while trying to create the autoscaling group. There are no error messages to help debug this issue. I've tried creating an EBS through aws console and attaching to the launched m3 instance manually, and this works, but I need to do it through CFN to conform to our automated deployment pipeline.
Are there other resources I need to create in the CFN template to make this work?
If that's a verbatim block, then you add quotes to volume size (doc is very misleading, as all data types are strings). Here's one that's worked fine for me, and I see no differences:
"BlockDeviceMappings": [
{
"DeviceName": {
"Ref": "SecondaryDevice"
},
"Ebs": {
"VolumeType": "gp2",
"VolumeSize": "10"
}
}
]
In general, if you need to troubleshoot ASGs, add SNS notifs for launch failures to the auto scaling group (http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html). You may find that you're on your last hundred gigs of EBS limit (not likely) or that your AMI doesn't like the device type or label you're trying to use (somewhat more likely).
Update:
After speaking with AWS support, I resolved this issue. It turns out that AWS makes a distinction between an instance-store-backed and ebs-backed ami. You can only add the BlockDeviceMappings property when using an ebs-backed ami, and I was using the other kind. Luckily, there is a way to convert instance-store-backed to ebs-backed, using this procedure:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-instance-store.html#Using_ConvertingS3toEBS