AWS

aws ec2 instance 상태이상 확인

갑자기 블로그가 안열렸다. 따로 모니터링을 설정한건 아니라서 다운된지 몰랐다. 먼저 aws console 에서 인스턴스의 상태를 확인해 보기로 했다.

상태검사를 통과 하지못한 인스턴스가 확인된다. 이럴땐 ec2 상태검사 탭을 확인한다.

서버가 죽은지 벌써10시간째. 모니터링을 설정해 놨어야 했는데 불찰이 느껴진다. 일 단 트러블 슈팅을 시작한다.

첫번째로 로그인을 진행해 본다. ssm 세션매니저를 통해서 접속해본다.

응. 안돼. 돌아가
접속할수 없다.

그럼 차선책으로 인스턴스의 스크린샷을 확인해 본다.

인스턴스 설정에서 시스템로그 가져오기는 dmesg 를 보여준다 그래서 이경우에 필요가 없다. 인스턴스가 행이 아니라 리부팅중 멈추거나 인스턴스 부팅 장애의 경우에는 시스템 로그가져오기로 봐야한다.

메모리...메ㅗㅁㅣㄹ............!!!!!!!!!!!!!!

프리티어라 죽었다.

재시작은 안되고 인스턴스를 중지한다. 재시작이 안될경우 중지/시작을 해야한다.

EIP 가 연결되지 않은 인스턴스의 경우엔 IP가 변경된다 EIP를 붙여서 사용하자

중지중이다.
중지중에 모니터링 그래프를 확인해 본다.

며칠전 포스팅했던 cloudwatch 를 이용한 메모리와 하드디스크 체크이다.
메모리가 훅 날라간게 보인다.

리부팅 완료하고 인스턴스의 상태가 정상으로 변경되었다. 그렇다면 정확한 이유를 알아야한다.

messages 로그에서 확인한 내용이다 스왑도 없고 메모리도 없어서 죽었다.
사실 프리티어라 swap 이 없다. 이후에 파일스왑으로 2G정도 만들어줄계획이다.

Aug 27 21:19:51 ip-10-0-0-12 kernel: active_anon:214310 inactive_anon:7454 isolated_anon:0#012 active_file:326 inactive_file:360 isolated_file:0#012 unevictable:0 dirty:0 writeback:0 unstable:0#012 slab_reclaimable:3331 slab_unreclaimable:5159#012 mapped:7669 shmem:7487 pagetables:3235 bounce:0#012 free:12190 free_pcp:180 free_cma:0
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 active_anon:857240kB inactive_anon:29816kB active_file:1304kB inactive_file:1440kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:30676kB dirty:0kB writeback:0kB shmem:29948kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA free:4464kB min:736kB low:920kB high:1104kB active_anon:11168kB inactive_anon:44kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15904kB mlocked:0kB kernel_stack:0kB pagetables:32kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kBAug 27 21:19:51 ip-10-0-0-12 kernel: lowmem_reserve[]: 0 932 932 932
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA32 free:44296kB min:44316kB low:55392kB high:66468kB active_anon:846072kB inactive_anon:29772kB active_file:1304kB inactive_file:1440kB unevictable:0kB writepending:0kB present:1032192kB managed:991428kB mlocked:0kB kernel_stack:6352kB pagetables:12908kB bounce:0kB free_pcp:720kB local_pcp:720kB free_cma:0kB
Aug 27 21:19:51 ip-10-0-0-12 kernel: lowmem_reserve[]: 0 0 0 0
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA: 84kB (UME) 88kB (UME) 1116kB (UE) 932kB (UE) 964kB (UME) 4128kB (UE) 5256kB (UME) 1512kB (E) 11024kB (E) 02048kB 04096kB = 4464kBAug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA32: 10224kB (UE) 4008kB (UE) 24116kB (UME) 13832kB (UME) 14364kB (UME) 61128kB (UE) 12256kB (ME) 13512kB (UE) 21024kB (UM) 02048kB 04096kB = 44296kB
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB

그럼 왜 스왑도 메모리도 없었을까? 웹서버 이므로 웹로그를 확인해 보았다.

어제 급하게 포스팅하느라 업로드한 파일들을 재대로 처리못하고 죽은거다.

아놔~~~~~~~~~~~~

이후로 모니터링 체크하나 만들어서 알럿하도록 설정하는 포스팅을 작성하겠다.

좋은하루 되시라!

사이트는 잘열리는것을 확인할수 있었다!

2019년 8월 28일 by AWS Linux 0

aws cloud watch 여러대의 인스턴스에 대한 하나의 경보 생성.ver2

cloudwatch 경보생성 입니다.

여러대의 인스턴스를 하나로 묶어서 경보생성할때 사용하는 방법입니다.

경보 생성을 누릅니다.

지표 선택을 눌러서 지표를 확인합니다.이번에 경보를 생성할 지표는 "CPUUtilization"입니다.

검색하여 체크 후에 '그래프로 표시된 지표' 를 누릅니다.
표시된 지표는 9개 까지 체크하여 추가할수 있습니다.

제한사항으로

 수학표현식을 추가합니다.
수학 표현식은 상황에 따라 잘 사용하기로 바랍니다.https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/using-metric-math.html
이번에는 CPU사용량이 1대라도 70% 를 넘을 경우 경보를 생성할 것이므로 사용한 표현식은 MAX(METRICS()) 입니다.

전체를 체크할 경우 아래와 같이 지표선택 버튼이 활성화 되지 않습니다.

사용할 수학 표현식 하나만 체크해야 생성이 가능합니다.

위와같이 지표를 생성후에 경보생성은 SNS 를 사용해야 하므로 SNS 사용법은 각자 확인해보시기 바랍니다. 

즐거운 하루되세요~

2019년 8월 26일 by AWS Linux 0

cloud watch monitoring script

WEB console
iam 추가와 watch 지표가 생성 되는 확인만 하면 된다.

필요한 권한
cloudwatch:PutMetricData
cloudwatch:GetMetricStatistics
cloudwatch:ListMetrics
ec2:DescribeTags

policy 생성

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"ec2:DescribeTags",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
}
]
}

생성한 정책을 user를 생성하여 부여

Shell 작업

로그인

스크립트를 실행하고 설치하는데 필요한 패키지를 설치한다.

centos
sudo yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64 unzip
cd ~

ubuntu
sudo apt-get install unzip libwww-perl libdatetime-perl

cloud watch monitering script download

curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O

압축해제 및 스크립트 테스트할 경로로 이동

unzip CloudWatchMonitoringScripts-1.2.2.zip && \
rm CloudWatchMonitoringScripts-1.2.2.zip && \
cd aws-scripts-mon

awscreds.conf 생성 및 입력

cp awscreds.template awscreds.conf

vi awscreds.conf
AWSAccessKeyId=
AWSSecretKey=

테스트 명령어 watch 로 전송하지 않음

./mon-put-instance-data.pl --mem-util --verify --verbose

MemoryUtilization: 20.5104909003152 (Percent)
Using AWS credentials file <./awscreds.conf>
Endpoint: https://monitoring.ap-northeast-2.amazonaws.com
Payload: {"MetricData":[{"Timestamp":156646131,"Dimensions":[{"Value":"i-0baaeb0265","Name":"InstanceId"}],"Value":20.5104909003152,"Unit":"Percent","MetricName":"MemoryUtilization"}],"Namespace":"System/Linux","__type":"com.amazonaws.cloudwatch.v2010_08_01#PutMetricDataInput"}

정상 응답확인

crontab 등록
vi /etc/crontab
#disk metric
*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ -disk-path=/home --from-cron

disk-path 는 여러개가 들어가도 상관없다.

systemctl restart crond

설치과정이 정상이라면 아래와같이 linux 시스템으로 지표가 생긴다.

이로서 모니터링 지표 생성까지 포스팅을 마쳤다.

경보생성은 다른 포스팅이 많으니 생략한다.

history

1444 sudo apt-get install unzip libwww-perl libdatetime-perl1447 ll
1448 curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O
1449 unzip CloudWatchMonitoringScripts-1.2.2.zip && rm CloudWatchMonitoringScripts-1.2.2.zip && cd aws-scripts-mon
1450 ll
1451 ./mon-put-instance-data.pl --mem-util --verify --verbose
1458 vi /etc/crontab
1459 /etc/init.d/cron restart

2019년 8월 22일 by AWS 0

aws solution architect professional C01 후기

후기는 적어보고 싶었다.

7월 4일 1차시험 7월 31일 2차시험을 봤다.

2차시험에 합격했으며 점수는 아슬아슬하게 761점이었다.

aws solution architect associate 자격증은 17년 11월에 취득했다. 이후로 aws 관련 실무를 했지만 대부분 SE 관련 서버 업무였고 SA 업무를 보게된건 19년 초 부터 이다.

SA pro 자격증은 계속 따고 싶었으나, 결심이 부족했다. 그러다 하루에 한시간씩 공부를 했다. 5월 초부터 1시간씩 매일 공부를 했으니 거의 두달가량을 매일 공부했다고 보면된다.

본격적인 공부는 6월 말경부터 시작했다 그 동안의 공부를 기반으로 제일먼저 풀이한건 예제문제 였다.

https://d1.awsstatic.com/Train%20%26%20Cert/docs/AWS_certified_solutions_architect_professional_examsample.pdf

예제 문제에 나오는 유형을 보고 나온서비스의 FnQ를 모두 보았다,

그리고 모의고사를 두번 봤다. 4만5천원 가량..내10만원..
이건 굉장히 도움이 많이됬다.

그리고 1차시험을 보기전엔 udemy 에서 나온 sap 2019 C01이라고 나온 문제들 3과목정도 봤고 비용은 10-15만원 정도 들었다. 도움이 전혀안된건 아니지만 그렇다고 해서 많은 도움이 된건 아니었다. 이유는 C01 유형이 아니라 C00유형 문제들이었다.

그래서 덤프나 유사유형 문제들이 없는것을 알고는 전략을 수정해서 https://www.aws.training/LearningLibrary
트레이닝을 먼저 다보고 aws 관련 영상을 봤다.

aws korea youtube 에서 거의 대부분의 세션을 봤다.
이것도 어느정도 도움이 됬다.

여기까지 공부하고
https://aws.amazon.com/ko/architecture/?awsf.quickstart-architecture-page-filter=highlight%23new
아키텍처 센터를 한번봤다.

그리고 자격증 백서도 좀봤다
https://github.com/serithemage/AWSCertifiedSolutionsArchitectUnofficialStudyGuide

시험을 앞두고서는 하루에 12시간 정도 공부를해서 4일정도 준비를 했다.
끊임없이 읽고 이해하려는 과정을 거쳤다.

중점적으로 본건 마이그레이션과 장애복구 부분이었다.
코스트 쪽은 주로하는 업무에 기반해서 일반구성도 마찬가지.

시나리오로 시작하는 질문이 대다수 이며 단순기능을 물어보는 질문은 없으니 참고하도록 하자.

sap 자격증을 따고난 소감을 한마디로


" 엄청좋다."

궁금한 것은 언제든 댓글로 남겨 놓으며 답변해 드리겠다.

즐거운 공부되시라!

2019년 8월 22일 by AWS Certification linuxer? 18

aws system manager session manager 이용하여 ssh 접속

간단하게 설명하면 필요한것은 AmazonEC2RoleforSSM policy 로 만든 역할, s3 bucket, cloudwatch group 다.

미리 로그 쌓을 버킷, 워치 그룹, ssm 역할 생성까지 마친후에 역할을 인스턴스에 부여해주자.

session manager 같은경우엔 신기하게 aws -> ec2 로 연결하는것이 아니다.
ec2 -> session manager로 접근하는거다.

그리고 ec2에 ssm user 를 생성해 주자 계정명은 상관 없다.

그다음에 기본설정을 넣어준다

적절히 잘넣어주자.

그리고 세션을 시작하면 된다.

그럼 잘된다

장점은 인스턴스에 퍼블릭IP가 없는 상태에서도 사용이 가능하다.
key pair 나 패스워드가 없는 상태에서도 로그인이 가능하다.

단점은 쁘띠느낌이 없다는걸까...

2019년 8월 21일 by AWS Linux 0