linuxer-admin

aws-ec2-user-data-cloud-watch-metric-memory-disk

오늘 포스팅은 사용자 데이터에 대한 포스팅을 할거다.

오늘 추가하는 내용은 cloudwatch 사용자 매트릭을 이용하는것이므로 비용이발생한다.

정말 미미한 비용이지만 비용발생의 거부감이 있다면 따라하지 말것.

이전에 Cloud Watch 를 이용하여 메모리를 모니터링 하는법과 경보를 만드는 방법을 포스팅 했었다.

이건 기본매트릭엔 memory/disk 모니터링이 안되므로 스크립트로 매트릭을 Watch로 전송하는 방식이다. agent 방식도 있으나 내가 선호하는 방식이 아니다.

먼저 사용할 inline 정책이다.

필요 권한

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

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

일단 정책 생성누르고 json 으로 넣는다.

그리고 정책의 이름을 정해서 넣는다

사용권한

나는 ec2-monitoring-policy 로 대충 입력했다. 상황과 사용자에 따라 다르다.

이제 역할을 생성한다.

신뢰 할수있는 유형의 서비스에서 EC2를 선택한다.

미리 생성한 정책을 선택한다.

태그는 사실 대충 입력했다. 하지만 각각 사용자마다의 태그 규칙을 정하고 사용하는것이 좋다.

정상적으로 만들면 신뢰 정책 태그가 생성한 순으로 잘보일것이다.

하나라도 빠져있다면 이상한거다.

오늘의 대상이 되는 인스턴스의 OS는 ubuntu 와 amazon linux2 / contos 이다.

user data 에 사용할 스크립트다

amazon linux2 / contos7

#!/bin/bash
sudo yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64 unzip
cd ~
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
echo "#disk metric" >> /etc/crontab
echo "#*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab
systemctl restart crond

ubuntu 14 - 18

#!/bin/bash
sudo apt-get install unzip libwww-perl libdatetime-perl
cd ~
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
echo "#disk metric" >> /etc/crontab
echo "#*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab
systemctl restart crond

위의 스크립트는 UserData 에 넣어주면 된다.

현재 스크립트는 주석처리되어 삽입까지만 되고 crontab 에서는 주석처리되어 돌지 않는다. 동작시키려면

echo "#*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab
echo "*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab

변경하고 crontab 을 재시작하자.

crontab 에 삽입되며, 5분마다 memory와 disk 사용량에 대한 매트릭을 CloudWatch 로 전송한다.

인스턴스 세부정보 구성에서 아까 생성한 역할을 부여하고, 사용자 데이터에서 위에 올려둔 스크립트를 붙여넣기 한다.

[root@ip-172-31-47-207 ~]# yum history
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
ID | Command line | Date and time | Action(s) | Altered
2 | install -y perl-Switch p | 2020-04-25 00:27 | Install | 50
1 | -t -y --exclude=kernel - | 2020-04-25 00:27 | Update | 1
history list

yum history를 보면 정상적으로 패키지 설치가 된게 보이고,

[root@ip-172-31-47-207 ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
#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=/ --from-cron

정상적으로 crontab에 스크립트도 들어간게 보인다.

그래서 CloudWatch 에서 모두 > linux 시스템 이라는 이름으로 사용자 매트릭이 생성된것이 보일것이다.

여기까지 되면 이제 인스턴스의 메모리와 디스크 모니터링이 가능해졌다.

aws 에서는 기본 매트릭으로 여러가지 모니터링 환경을 제공하는데 memory 와 disk 는 모니터링이 되지 않아 불편한 부분이 있었다.

-_-; 이 포스팅이 도움이 되길 바란다.!

IT infra user group MeetUp review

사진 설명이 없습니다.

IT인프라 유저그룹에서 세션을 진행했습니다.

아무도 이야기하지 않는 클라우드 3사 솔직 비교 라는 주제였습니다.

많은 고민을 해왔던 주제고 어느정도 결론을 낸 주제이므로 나름의 자신이 있었습니다.

글을 써내려 갈때 주로 선택하는 방식이 주제와 결론을 정하고 주제에 따른 살을 입혀서 내용을 풍성하게 만드는 방식으로 주로 글을 씁니다.

퍼블릭 클라우드 3사 비교라는 주제는 자칫하면 쏠릴 수 있고 민감한 주제라 어떻게 풀어가야할지 고민을 많이했지만 평소 관심이 많은 주제라 망설임 없이 슬라이드를 작성하였습니다.

가장 신경을 쓴부분은 나의 이야기가 상대방이 공감할수 있는이야기 인가? 이부분을 최대한 고민해서 작성했습니다.

사실 결론까지 이어지는 맥이 좀 약하다 생각했습니다.

사람들이 내 결론을 잘 받아들였을까 고민될정도...

하지만 결론에 대해 갸웃? 하더라도 전달하고 싶었던 정보들은 내가 가졌던 의구심과 답답했던 과정들은 가감없이 전달될것이라 생각했기 때문에 내 불편함에 대해서 사람들이 공감할수 있다면 절반은 성공이라 생각하며 슬라이드를 작성하였습니다.

"어떤 클라우드가 싸고 좋은가요? " 이 뻔 하고 어려운 질문에 답변을 하는게 이번 세션에서 말하고 싶은 바였습니다.

그래서 저의 결론은 "더 좋고 더 나쁜 클라우드는 없다." 였습니다.

역할에 따라 취향에 따라 상황에 따라 비용에 따라 모든것은 인프라일 뿐 그저 맞춰서 사용하는것이 정답이라는 대답을 드릴수 밖에 없었습니다. 정말로 교과서 적인 대답이지만 이 답변을 드리기 위해 경험한 바를 풀어가며 살을 붙였습니다.

여러 고민 끝에 슬라이드를 작성하였고 23일 meetup에서 세션을 진행하였습니다.

긴장이 되긴 했는데 딱 적당한 긴장감이었고 처음하는 세션이라 중간중간 방향성을 잃긴 했지만 결국 방향성을 되찾았습니다.

눈을 가린 말처럼 슬라이드의 마지막장으로 달려갔습니다.

준비한 멘트는 많았지만 생각만큼 조리있게 설명하는건 쉽지 않았습니다.

말은 뇌를 거치지 않은게 더 많았습니다.

고심해서 하는 말보단 날것의 멘트가 점점 차오를 쯤 슬라이드의 마지막장에 이르렀습니다.

어려운 질문일수록 더욱 깊게 생각납니다.

"멀티클라우드 구성 관련 질문을 주셨는데 벤더락을 피하고 싶다." 라는 질문을 하셨습니다. 저는 개인적으로 아직까진 멀티 클라우드에 대해서 부정적인 입장입니다.

떨어뜨릴수 있는 서비스라면 분리해야한다 생각합니다.

이유는 비용과 트래픽의 측면을 제외 할 수 없습니다. 각 퍼블릭 클라우드의 장점인 서비스만 떼서 이용 할 수 있다면 더 할 나위없이 좋겠지만 컨셉이 정해지기 전까진 정말 답이없는 이야기라 생각이 됩니다.

어제의 세션을 저스스로 점수를 메기자면 7점 정도를 주려고 합니다.

저는 처음이었고 연초부터 쉼없이 달려왔습니다.
좀 지친 상태에서 시작했지만 즐겁게 준비했고 의도한 바는 전달한거 같습니다.

짧은 시간 준비한 세션이었고 만족하지 못한 분이 계실수도 있다 생각합니다.

이부분은 제가 따로 채우겠습니다. 궁금하신 부분이나 이상한 부분이 있다면 언제든 질문해 주세요. 답변드리겠습니다.

즐거운 세션이었고 좋은분들과 함께 해서 의미있었습니다.

먼저 흔히 할수 없는 기회를 주신 조훈님께 감사드립니다.

글읽어 주신 분들. 세션을 봐주신 분들께 감사인사를 드립니다.

마지막으로 감사합니다.

발표에 사용한 슬라이드를 첨부합니다.

GCP-Professional-Cloud Network-Engineer-PCNE-review

4월 16일 Professional Cloud Network Engineer 2차 시험에 합격했다.

3월 9일 1차 응시를 했고 보기좋게 떨어졌다. 공부가 부족했다.

4월 3일 AZ-300 시험을 보고 다시 PCNE를 준비했다.

2주의 기간동안 정말 많은 공부를 했다.

지금까지 얕게 가지고 있던 GCP의 개념들을 DOCS를 보면서 재검토하고 다시 받아들였다.

뭔가 모르는게 많았다.

사실 프로토콜이나 LB같은 개념 BGP 라우팅 이런것들은 이해하고 있던거라 어렵지 않았는데 GCP 자체적인 제한이나 방법 그리고 권한 명령어 Docs 의 상세함. 이런것들이 이전에 내가 시간에 쫒겨 보던것과 달리 찬찬히 보게되니 굉장히 많은 도움이 됬다.

과목을 늘어놓자면

https://cloud.google.com/vpc/docs/vpc-peering?hl=ko
https://cloud.google.com/vpc/docs/firewall-rules-logging
https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips#defaults_limits
https://cloud.google.com/vpc/docs/shared-vpc?hl=ko
https://cloud.google.com/vpn/docs/how-to/moving-to-ha-vpn
https://cloud.google.com/load-balancing/docs?hl=ko
https://cloud.google.com/cdn/docs/cache-invalidation-overview?hl=ko
https://cloud.google.com/interconnect/docs/concepts/overview?hl=ko
파트너 전용
https://cloud.google.com/vpc/docs/special-configurations
https://cloud.google.com/vpc/docs/configure-private-google-access

영어에 약하다보니..한글 매뉴얼로 읽고 다시한번 영문 매뉴얼로 읽고 반복했다.

1차시험준비 때는

https://github.com/sathishvj/awesome-gcp-certifications/blob/master/professional-cloud-network-engineer.md

위의 페이지를 참고했다.

Ivam Luz 의 블로깅이 굉장히 많은 참고가 됬다.

시험장은 문정 시험장을 두번다 다녀왔다.

확정메일은 하루정도 만에 왔고 자격증 스토어엔 아래 3개의 품목이 있었다.

여러번 저건 꼭내꺼다 했던..JBL Clib3 를.. 주문했다..

-_-; 이상하게 이름이 아니라 메일주소로 자격증이 발급됬다.

이로서 GCP 자격증 두개를 가지게 되었다.

같이 스터디를 진행해 주신 수진님께 감사를 드린다.

Azure-AZ-300-Microsoft Azure Architect Technologies

AZ-300: Microsoft Azure Architect Technologies 취득 후기

3월부터 4월2일까지 내내 공부했다.

하루에 한시간은 꼭 공부했다. 재택근무도 도움이 됬다. 시험일정을 잡는걸 좀 급하게 잡아서 걱정이 많았지만 그래도 이렇게 급할때 더 집중이 잘됬다.

시험은 Technologies 에 대한 시험인 만큼 범위가 넓었다.

network / storage / ad / db / backup / vm / aks / docker / logic app / appweb

등 다양한 방법과 용도에 대해서 묻는 시험이 대부분이었다.

azure 시험은 유독 독특하다.

하나의 주제에대해서 정확한 답을알면 여러 문제를 풀수있고 케이스에서 요구하는 문제는 적절한 답안을 내야한다. 또한 lab 문제는 계정을 주고 로그인해서 셋팅하는 방식이다.

또한 한번풀면 다신 풀수없는 문제도 있다.

az-301취득까지 목표니까..

기세를 살려 5월중순엔 az-301 취득이 목표다.

같이 공부해주신 민형님 / 재호님 / 진국님 / 수현님께 깊은 감사를 드린다.

aws-rds-readreplica-general_log

https://www.facebook.com/groups/awskrug/permalink/2404835746285102/

다음과 같은 질문이 올라왔다.
바로 생각난건 general_log.. 그래서 Master와 Readreplica 가 각각 다른 Parameter Group(이하 PG)를 가질수 있는지 확인해보기로 했다.

먼저 Readreplica 생성했다.

실제로 읽기복제본을 만들때는 파라메터 그룹을 수정할수 없다.

Master 의 PG를 그대로 사용한다.

이렇게 모두 생성된 Readreplica 를 수정을 눌러보면

데이터베이스 옵션에서 파라메터 그룹을 볼수있다.
그래서 나는 따로 PG를 만들어주고..general_log 도 켜줬다.

dynamic / static 으로 나뉘는데 적용유형이 dynamic이면 PG가 적용된상태에서 라이브로 적용된다. 디비의 재시작이 필요없다.

물론..PG를 변경하게 되면 RDS의 재시작이 필요하다.

그럼 1차 결론으로 마스터와 슬레이브는 생성시엔 같은 PG를 사용한다. PG는 마스터와 슬레이브는 다르게 사용하려면 수정해야한다.

현재구성은 마스터는 general_log를 사용하지 않고, 슬레이브만 사용한다. 그럼 슬레이브에서 제네럴 로그를 쌓는지 확인해 보자.

이상하게 적용이 안되서 보니..

보류중이면 말하지;

재시작 시켜서 적용해주고~

잘쌓인다..타임존이 이상하네? 그건 넘어가고..

마스터는 안쌓이는거 확인했고~

질문의 답은 확인할수 없지만..general_log 가 마스터와 슬레이브가 별개로 쌓이는 설정이 가능하고 슬레이브의 용량이 서비스에 영향을 미칠수있다.

정도로 결론 내리겠다.

급한 테스트였지만 결론을 내린다!