Translated 2022 day77-83 to korean

Author: Me1e

2022/ko/Days/day77.md

@@ -0,0 +1,83 @@
+---
+title: '#90DaysOfDevOps - The Big Picture: Monitoring - Day 77'
+published: false
+description: 90DaysOfDevOps - The Big Picture Monitoring
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048715
+---
+
+## 큰 그림: 모니터링
+
+이 섹션에서는 모니터링이란 무엇이며 왜 필요한지에 대해 설명합니다.
+
+### 모니터링이란 무엇인가요?
+
+모니터링은 전체 인프라를 면밀히 주시하는 프로세스입니다.
+
+### 모니터링이란 무엇이며 왜 필요한가요?1
+
+애플리케이션 서버, 데이터베이스 서버, 웹 서버와 같은 다양한 특수 서버를 포함하여 수천 대의 서버를 관리한다고 가정해 봅시다. 또한 퍼블릭 클라우드 서비스 및 Kubernetes를 비롯한 추가 서비스와 다양한 플랫폼으로 인해 이 문제는 더욱 복잡해질 수 있습니다.
+
+![](/2022/Days/Images/Day77_Monitoring1.png)
+
+우리는 서버의 모든 서비스, 애플리케이션, 리소스가 정상적으로 실행되고 있는지 확인할 책임이 있습니다.
+
+![](/2022/Days/Images/Day77_Monitoring2.png)
+
+어떻게 하나요? 세 가지 방법이 있습니다:
+
+- 모든 서버에 수동으로 로그인하여 서비스 프로세스 및 리소스에 대한 모든 데이터를 확인합니다.
+- 우리를 대신하여 서버에 로그인하고 데이터를 확인하는 스크립트를 작성합니다.
+
+이 두 가지 옵션 모두 상당한 양의 작업이 필요합니다,
+
+세 번째 옵션은 더 쉬운 방법으로, 시중에 나와 있는 모니터링 솔루션을 사용할 수 있습니다.
+
+Nagios와 Zabbix는 쉽게 사용할 수 있는 솔루션으로, 원하는 만큼 서버를 포함하도록 모니터링 인프라를 확장할 수 있습니다.
+
+### Nagios
+
+Nagios는 같은 이름의 회사에서 만든 인프라 모니터링 도구입니다. 이 도구의 오픈 소스 버전은 Nagios core라고 하며 상용 버전은 Nagios XI라고 합니다. [Nagios 웹사이트](https://www.nagios.org/)
+
+이 도구를 사용하면 서버를 모니터링하고 서버가 충분히 활용되고 있는지 또는 해결해야 할 장애 작업이 있는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day77_Monitoring3.png)
+
+기본적으로 모니터링을 통해 서버와 서비스의 상태를 확인하고 인프라의 상태를 파악하는 두 가지 목표를 달성할 수 있으며, 전체 인프라에 대한 40,000피트 뷰를 제공하여 서버가 제대로 작동하고 있는지, 애플리케이션이 제대로 작동하는지, 웹 서버에 연결할 수 있는지 여부를 확인할 수 있습니다.
+
+특정 서버에서 지난 10주 동안 디스크가 10%씩 증가하고 있으며, 향후 4~5일 이내에 완전히 소진될 것이고 곧 응답하지 못할 것임을 알려줍니다. 디스크 또는 서버가 위험한 상태에 있을 때 경고하여 서비스 중단을 피하기 위한 적절한 조치를 취할 수 있도록 알려줍니다.
+
+이 경우 일부 디스크 공간을 확보하여 서버에 장애가 발생하지 않고 사용자에게 영향을 미치지 않도록 할 수 있습니다.
+
+대부분의 모니터링 엔지니어에게 어려운 질문은 무엇을 모니터링할 것인가, 또는 무엇을 모니터링하지 않을 것인가입니다.
+
+모든 시스템에는 여러 리소스가 있는데, 이 중 어떤 리소스를 주시해야 하고 어떤 리소스를 간과할 수 있는지, 예를 들어 CPU 사용량을 모니터링해야 하는지에 대한 대답은 분명히 '예'이지만 그럼에도 불구하고 여전히 결정해야 할 사항은 시스템의 열린 포트 수를 모니터링해야 하는지 여부입니다. 범용 서버인 경우 상황에 따라 필요하지 않을 수도 있지만 웹 서버인 경우 다시 모니터링해야 할 수도 있습니다.
+
+### 지속적인 모니터링
+
+모니터링은 새로운 항목이 아니며 지속적인 모니터링도 많은 기업이 수년 동안 채택해 온 이상입니다.
+
+모니터링과 관련하여 세 가지 주요 영역에 중점을 둡니다.
+
+- 인프라 모니터링
+- 애플리케이션 모니터링
+- 네트워크 모니터링
+
+이 세션에서 두 가지 일반적인 시스템과 도구에 대해 언급했지만, 사용 가능한 도구는 매우 많다는 점에 유의해야 합니다. 모니터링 솔루션의 진정한 이점은 무엇을 모니터링해야 하고 무엇을 모니터링하지 않아야 하는지에 대한 질문에 답하는 데 시간을 할애했을 때 나타납니다.
+
+어떤 플랫폼에서든 모니터링 솔루션을 켜면 정보를 수집하기 시작하지만, 그 정보가 너무 많으면 솔루션의 이점을 제대로 활용하기 어렵기 때문에 시간을 들여 구성해야 합니다.
+
+다음 세션에서는 모니터링 도구를 직접 사용해 보고 무엇을 모니터링할 수 있는지 살펴보겠습니다.
+
+## 자료
+
+- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
+- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
+- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
+- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
+- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
+- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
+
+[Day 78](day78.md)에서 봐요!

2022/ko/Days/day78.md

@@ -0,0 +1,98 @@
+---
+title: '#90DaysOfDevOps - Hands-On Monitoring Tools - Day 78'
+published: false
+description: 90DaysOfDevOps - Hands-On Monitoring Tools
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049056
+---
+
+## 실습용 모니터링 도구
+
+지난 세션에서 모니터링의 큰 그림에 대해 이야기하면서 Nagios를 살펴본 이유는 두 가지였습니다. 첫 번째는 수년 동안 많이 들어본 소프트웨어이기 때문에 그 기능에 대해 조금 더 알고 싶었기 때문입니다.
+
+오늘은 Prometheus에 대해 살펴보려고 하는데요, 클라우드 네이티브 환경에서 점점 더 많이 사용되고 있지만 Kubernetes 등 외부에서도 이러한 물리적 리소스를 관리하는 데 사용할 수 있습니다.
+
+### Prometheus - 거의 모든 것을 모니터링합니다.
+
+우선, Prometheus는 컨테이너와 마이크로서비스 기반 시스템뿐만 아니라 물리적, 가상 및 기타 서비스를 모니터링하는 데 도움이 되는 오픈 소스입니다. Prometheus 뒤에는 대규모 커뮤니티가 있습니다.
+
+Prometheus에는 다양한 [통합 및 내보내기](https://prometheus.io/docs/instrumenting/exporters/)가 있습니다. 핵심은 기존 메트릭을 Prometheus 메트릭으로 내보내는 것입니다. 또한 여러 프로그래밍 언어도 지원합니다.
+
+pull 접근 방식 - 수천 개의 마이크로서비스 또는 시스템 및 서비스와 대화하는 경우 push 방식은 일반적으로 서비스가 모니터링 시스템으로 push되는 것을 볼 수 있는 곳입니다. 이 경우 네트워크 과부하, 높은 CPU 사용량, 단일 장애 지점 등의 문제가 발생합니다. pull 방식은 모든 서비스의 메트릭 엔드포인트에서 Prometheus가 끌어오는 훨씬 더 나은 경험을 제공합니다.
+
+다시 한번 Prometheus의 구성을 위한 YAML을 살펴봅니다.
+
+![](/2022/Days/Images/Day78_Monitoring7.png)
+
+나중에 이것이 Kubernetes에 배포되었을 때 어떻게 보이는지, 특히 작업/내보내기로부터 메트릭을 가져오는 **PushGateway**가 있는 것을 보게 될 것입니다.
+
+알림을 push하는 **AlertManager**가 있으며, 여기에서 이메일, 슬랙 및 기타 도구와 같은 외부 서비스와 통합할 수 있습니다.
+
+그런 다음 PushGateway에서 이러한 pull 메트릭의 검색을 관리하고 push 알림을 AlertManager로 전송하는 Prometheus Server가 있습니다. Prometheus Server는 또한 로컬 디스크에 데이터를 저장합니다. 원격 스토리지 솔루션을 활용할 수도 있습니다.
+
+또한 메트릭과 상호 작용하는 데 사용되는 언어인 PromQL도 있는데, 이는 나중에 Prometheus 웹 UI에서 볼 수 있지만, 이 섹션의 뒷부분에서 Grafana와 같은 데이터 시각화 도구에서도 어떻게 사용되는지 볼 수 있습니다.
+
+### Prometheus 배포 방법
+
+Prometheus 설치 방법은 [다운로드 섹션](https://prometheus.io/download/) 도커 이미지에서도 다양하게 확인할 수 있습니다.
+
+`docker run --name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus`
+
+하지만 여기서는 Kubernetes에 배포하는 데 집중하겠습니다. 여기에도 몇 가지 옵션이 있습니다.
+
+- 구성 YAML 파일 생성
+- 오퍼레이터 사용(모든 Prometheus 구성 요소의 관리자)
+- Helm 차트를 사용하여 오퍼레이터 배포
+
+### Kubernetes에 배포하기
+
+이 빠르고 간단한 설치를 위해 다시 로컬에서 Minikube 클러스터를 사용하겠습니다. Minikube와의 이전 접점과 마찬가지로, Helm을 사용하여 Prometheus Helm 차트를 배포할 것입니다.
+
+`helm repo add prometheus-community https://prometheus-community.github.io/helm-charts`
+
+![](/2022/Days/Images/Day78_Monitoring1.png)
+
+위에서 볼 수 있듯이 Helm 리포지토리 업데이트도 실행했으므로, 이제 `helm install stable prometheus-community/prometheus` 명령을 사용하여 Minikube 환경에 Prometheus를 배포할 준비가 되었습니다.
+
+![](/2022/Days/Images/Day78_Monitoring2.png)
+
+몇 분 후, 몇 개의 새로운 pod가 나타나는데, 이 데모에서는 기본 네임스페이스에 배포했으며, 일반적으로는 이 pod를 해당 네임스페이스에 push합니다.
+
+![](/2022/Days/Images/Day78_Monitoring3.png)
+
+모든 pod가 실행되고 나면 Prometheus의 배포된 모든 측면도 살펴볼 수 있습니다.
+
+![](/2022/Days/Images/Day78_Monitoring4.png)
+
+이제 Prometheus Server UI에 액세스하기 위해 다음 명령어를 사용하여 포팅 포워드할 수 있습니다.
+
+```Shell
+export POD_NAME=$(kubectl get pods --namespace default -l "app=prometheus,component=server" -o jsonpath="{.items[0].metadata.name}")
+  kubectl --namespace default port-forward $POD_NAME 9090
+```
+
+브라우저를 `http://localhost:9090`으로 처음 열면 다음과 같이 빈 화면이 표시됩니다.
+
+![](/2022/Days/Images/Day78_Monitoring5.png)
+
+Kubernetes 클러스터에 배포했기 때문에 Kubernetes API에서 자동으로 메트릭을 가져올 것이므로 일부 PromQL을 사용하여 최소한 `container_cpu_usage_seconds_total` 메트릭을 캡처하고 있는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day78_Monitoring6.png)
+
+앞서 말씀드린 것처럼 메트릭을 확보하는 것도 좋지만 모니터링도 중요하지만, 모니터링 대상과 그 이유, 모니터링하지 않는 대상과 그 이유를 알아야 한다는 점에서 PromQL을 배우고 이를 실제로 적용하는 것은 매우 중요합니다!
+
+다시 Prometheus로 돌아오고 싶지만, 지금은 로그 관리와 데이터 시각화에 대해 생각해 보고 나중에 다시 Prometheus로 돌아올 수 있도록 해야 할 것 같습니다.
+
+## 자료
+
+- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
+- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
+- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
+- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
+- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
+- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
+- [Promql cheat sheet with examples](https://www.containiq.com/post/promql-cheat-sheet-with-examples)
+
+[Day 79](day79.md)에서 봐요!

2022/ko/Days/day79.md

@@ -0,0 +1,81 @@
+---
+title: '#90DaysOfDevOps - The Big Picture: Log Management - Day 79'
+published: false
+description: 90DaysOfDevOps - The Big Picture Log Management
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049057
+---
+
+## 큰 그림: 로그 관리
+
+인프라 모니터링 과제와 솔루션의 연속선상에 있는 로그 관리는 전체 통합 가시성 퍼즐의 또 다른 퍼즐 조각입니다.
+
+### 로그 관리 및 집계
+
+두 가지 핵심 개념에 대해 이야기해 보겠습니다. 첫 번째는 로그 집계로, 다양한 서비스에서 애플리케이션 로그를 수집하고 태그를 지정하여 쉽게 검색할 수 있는 단일 대시보드에 저장하는 방법입니다.
+
+애플리케이션 성능 관리 시스템에서 가장 먼저 구축해야 하는 시스템 중 하나는 로그 집계입니다. 애플리케이션 성능 관리는 애플리케이션이 빌드 및 배포된 후에도 지속적으로 작동하는지 확인하여 리소스가 충분히 할당되고 사용자에게 오류가 표시되지 않도록 해야 하는 데브옵스 라이프사이클의 일부입니다. 대부분의 프로덕션 배포에서 많은 관련 이벤트가 Google의 여러 서비스에서 로그를 생성합니다. 하나의 검색이 사용자에게 반환되기 전에 10개의 다른 서비스에 도달할 수 있으며, 10개의 서비스 중 하나에 논리 문제가 있을 수 있는 예기치 않은 검색 결과가 표시되는 경우 로그 집계는 Google과 같은 회사가 프로덕션에서 문제를 진단하는 데 도움이 되며, 모든 요청을 고유 ID에 매핑할 수 있는 단일 대시보드를 구축하여 검색하면 검색에 고유 ID가 부여되고 검색이 다른 서비스를 통과할 때마다 해당 서비스가 현재 수행 중인 작업과 해당 ID가 연결되도록 합니다.
+
+이것이 바로 로그를 생성하는 모든 곳에서 로그를 효율적으로 수집하고 장애가 다시 발생할 경우 쉽게 검색할 수 있도록 하는 좋은 로그 수집 플랫폼의 핵심입니다.
+
+### 예제 앱
+
+예제 애플리케이션은 웹 앱으로, 일반적인 프론트엔드와 백엔드가 중요한 데이터를 MongoDB 데이터베이스에 저장하고 있습니다.
+
+사용자가 페이지가 모두 하얗게 변하고 오류 메시지가 인쇄되었다고 말하면 현재 스택의 문제를 진단하기 위해 사용자가 수동으로 오류를 보내야 하고 다른 세 가지 서비스의 관련 로그와 일치시켜야 합니다.
+
+### Elk
+
+예제 앱과 동일한 환경에 설치한 경우 세 가지 구성 요소인 Elasticsearch, Logstash, Kibana의 이름을 딴 인기 있는 오픈 소스 로그 집계 스택인 Elk에 대해 살펴보겠습니다.
+
+웹 애플리케이션은 프론트엔드에 연결되고, 프론트엔드는 백엔드에 연결되며, 백엔드는 Logstash로 로그를 전송하고, 이 세 가지 구성 요소가 작동하는 방식은 다음과 같습니다.
+
+### Elk의 구성 요소
+
+Elasticsearch, Logstash, Kibana의 구성 요소는 모든 서비스가 Logstash로 로그를 전송하고, Logstash는 애플리케이션이 방출하는 텍스트인 이 로그를 가져온다는 것입니다. 예를 들어, 웹 애플리케이션에서 사용자가 웹 페이지를 방문할 때 웹 페이지는 이 방문자가 현재 이 페이지에 액세스한 것을 기록할 수 있으며, 이것이 로그 메시지의 예입니다.
+
+그러면 Logstash는 이 로그 메시지에서 사용자가 **시간**에 **무엇**을 했다는 내용을 추출합니다. 시간을 추출하고 메시지를 추출하고 사용자를 추출하고 그것들을 모두 태그로 포함시켜서 메시지가 태그와 메시지의 객체가 되어 특정 사용자의 모든 요청을 쉽게 검색할 수 있도록 하지만 Logstash는 자체적으로 저장하는 것이 아니라 텍스트 쿼리를 위한 효율적인 데이터베이스인 Elasticsearch에 저장하고 Elasticsearch는 Kibana로 결과를 노출하고 Kibana는 Elasticsearch에 연결하는 웹 서버로서 개발자나 팀의 다른 사람들이 관리자를 허용합니다, 대기 중인 엔지니어가 주요 장애가 발생할 때마다 프로덕션에서 로그를 볼 수 있습니다. 관리자는 Kibana에 연결하고, Kibana는 사용자가 원하는 것과 일치하는 로그를 찾기 위해 Elasticsearch를 쿼리합니다.
+
+검색 창에 "오류를 찾고 싶어요"라고 말하면, Kibana는 문자열 오류가 포함된 메시지를 찾으라고 말하고, 그러면 Elasticsearch는 Logstash가 채운 결과를 반환합니다. Logstash는 다른 모든 서비스에서 이러한 결과를 전송받았을 것입니다.
+
+### Elk를 사용해 프로덕션 문제를 진단하는 방법
+
+한 사용자가 Elk 설정으로 이 작업을 수행하려고 할 때 오류 코드 1234567을 보았다고 말합니다. 검색 창에 1234567을 입력하고 엔터를 누르면 그에 해당하는 로그가 표시되고 로그 중 하나에서 내부 서버 오류가 1234567을 반환한다고 표시될 수 있으며, 그 로그를 생성한 서비스가 로그를 생성한 서비스가 백엔드임을 알 수 있고, 해당 로그가 생성된 시간을 확인할 수 있으므로 해당 로그의 시간으로 이동하여 백엔드에서 그 위와 아래의 메시지를 보면 사용자의 요청에 대해 어떤 일이 발생했는지 더 잘 파악할 수 있으며, 이 과정을 다른 서비스에서도 반복하여 사용자에게 문제가 발생한 원인을 찾을 때까지 반복할 수 있습니다.
+
+### 보안 및 로그 액세스
+
+퍼즐의 중요한 조각은 로그가 관리자(또는 액세스 권한이 필요한 사용자 및 그룹)에게만 표시되도록 하는 것입니다. 로그에는 인증된 사용자만 액세스해야 하는 토큰과 같은 민감한 정보가 포함될 수 있으며, 인증 방법 없이 Kibana를 인터넷에 노출하고 싶지 않을 것입니다.
+
+### 로그 관리 도구의 예
+
+로그 관리 플랫폼의 예는 다음과 같습니다.
+
+- Elasticsearch
+- Logstash
+- Kibana
+- Fluentd - 인기 있는 오픈 소스 선택
+- Datadog - 대기업에서 일반적으로 사용되는 호스팅 제품,
+- LogDNA - 호스트형 제품
+- Splunk
+
+클라우드 제공업체는 AWS CloudWatch Logs, Microsoft Azure Monitor, Google Cloud Logging과 같은 로깅도 제공합니다.
+
+로그 관리는 프로덕션 환경의 문제를 진단하기 위한 애플리케이션 및 인프라 환경의 전반적인 통합 가시성의 핵심 요소입니다. Elk 또는 CloudWatch와 같은 즌비된 솔루션을 설치하는 것은 비교적 간단하며 프로덕션 환경의 문제를 진단하고 분류하는 것이 훨씬 쉬워집니다.
+
+## 자료
+
+- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
+- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
+- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
+- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
+- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
+- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
+- [Promql cheat sheet with examples](https://www.containiq.com/post/promql-cheat-sheet-with-examples)
+- [Log Management for DevOps | Manage application, server, and cloud logs with Site24x7](https://www.youtube.com/watch?v=J0csO_Shsj0)
+- [Log Management what DevOps need to know](https://devops.com/log-management-what-devops-teams-need-to-know/)
+- [What is Elk Stack?](https://www.youtube.com/watch?v=4X0WLg05ASw)
+- [Fluentd simply explained](https://www.youtube.com/watch?v=5ofsNyHZwWE&t=14s)
+
+[Day 80](day80.md)에서 봐요!