프로젝트 경험

프로젝트 경험

요점

Kubernetes 생산용

클라우드 호스트 신축

로그 수집 플랫폼 ELK

모니터링 플랫폼zabbix ~ prometheus

코드 출시 플랫폼 Jenkins

요새기 jumpserver

타점 서비스 애플리케이션 prometheus

Kubernetes 생산 응용 프로그램

관건:

서비스의 탄성 신축, deployment을 이용하여 Horizontal Pod Autoscaling에 대한 탄성 신축

은 pod과 ingress을 이용한 대내외 서비스 제공

권한 관리, service 및 namespace을 통한

rdac 패키지 관리 도구

helm 노드의 탄성 신축, 클라우드 호스트에 대한 탄성 신축을 이용하여

실현
모니터링

node

로그 수집
노드에서 로그를 수집하기 위해 kube-prometheus을 실행하지만 agent 모드에서는

알리 클라우드 로그 서비스

DaemonSet

FELK에 pod 용기를 포함하여 응용 로그를 수집합니다

각 sidecar에 pod 또는 fluentd 컨테이너 수집 로그를 외부 filebeat에

응용 프로그램에서 로그 정보를 채집 백엔드로 직접 전송합니다
코드 게시

ELK (현재 비교 low)

은 jenkins shell 또는 drone을 사용할 수 있습니다.

직접 쓰세요.이미 대략적인 사고방식이 있다.

클라우드 본체의 탄성 신축.

호스트에 대한 신축성 신축 서비스입니다. 이것은 클라우드 서비스 업체가 제공하는 서비스입니다.\신축성 신축은 주로 설정된 신축 규칙에 따라 업무 수요가 증가할 때 자동으로 jenkins-pipeline 실례를 증가하여 계산 능력을 확보하고, 업무 수요가 감소할 때 자동으로 ECS 실례를 감소하여 원가를 절약합니다.\제품은 주로 ECS 뒤에 SLB을 마운트합니다.cpu나 메모리 사용률에 대한 감시를 실현하고 메모리나 cpu가 일정한 한도값을 초과하면 이전에 정의한 신축 전략을 이용하여 이전에 만들어진 거울을 이용하여 ECS을 신축한다.\다음 문제를 가져오다
문제.
새로 발표된 코드는 오래된 이미지에 있을 수 없습니다.신축성이 신축되면 새로 추가된 ECS의 코드는 온라인 코드와 일치하지 않습니다.
해결하다
개인적으로는 ECS에 비해 발표가 무겁다.그러나 low에서는 이런 문제가 존재하지 않는다.
코드를 발표한 후 클라우드 서비스 업체의 Kubernetes을 호출하여 새 API에 렌즈를 설치하고 프로젝트의 탄력적인 신축 전략을 수정하며 새 렌즈 id를 낡은 렌즈 id로 바꿉니다.

로그 수집

ECS

a. elk+kafka filebeat 의 일지를 수집하여 nginx

b. logstash에서 로그를 필드 분할하여 logstash까지 씁니다.elasticicsearch을 이용하면 kafka을 쓰기 전에 elasticicsearch을 쓰고 kafka을 elasticicsearch에서 데이터를 얻는다.

c. kafka을 활용한 프레젠테이션

d. kibana에서 서로 다른 업무에 따라 kibana, request_time, upstream_time 등의 status_code을 미리 배치하여 포지셔닝 문제를 편리하게 한다.

. 경고:

은 각본을 작성하고 서로 다른 업무의 dashboard, request_time, upstream_time을 정기적으로 검사한다.시간 초과 또는 status_code이 status_code이면

에게 경고

프로그램 부분 로그 수집 및 경고
요구 사항:
게이트웨이 5XX 서비스는 nginx을 생성합니다. 이 요청 뒤에 있는 일련의 요청은 모두 이 request_id을 가지고 로그를 씁니다.목적지에서 문제를 포지셔닝하기 편리하다.request_id에서 nginx 등 오류가 발생했을 때 이 요청의 5xx에 따라 프로그램에 대응하는 일련의 요청을 찾을 수 있어 구체적인 문제가 어디에 있는지 신속하게 파악할 수 있다.자원: 자원 문제를 고려하여 현재 request_id/warn/error 세 등급의 프로그램 로그만 수집하여 fatal에 가져옵니다.elk의 빠른 포지셔닝 프로그램 문제에 따라
경고:
정시 임무는 최근 1분간 어떤 항목에 10개의 request_id이 나타나거나 error이 나타나면 경고한다.매일 항목이 나타난 fatal횟수를 통계하다.우편물을 보내다.프로젝트 warn이 많은 (warn개 500)은 추가 경고를 보내서 개발 처리를 하도록 합니다.

모니터링

warn부터 mysql+zabbix+grafana+ / 까지
주요 모니터링 지점

prometheus+grafana+alertmanager + 사용률

메모리 사용량/사용률

서버 부하

디스크 용량/cpu

네트워크 트래픽

io 연결

출처 tcp 연결

액세스 IP 연결

서비스 모니터링:"

IP: redis, 메모리 사용량, cpu, hit, miss, get, set, ops...

elasticsearch: cpu, jvm, 메모리, gc, indics, 건강 상태, ops...

mongodb : cpu 、 mem 、 ops ...

prometheus으로 마이그레이션한 이유

prometheus은 리소스에 대한 요구 사항이 매우 낮습니다.2진법 문제 하나만 실행하면 된다.

은 zabbix이 100대의 서버를 모니터링한 후에 모니터링을 볼 때 현저히 느려졌다.

prometheus에 경고를 추가하면 더욱 뚜렷하고 편리하다.

Jenkins 코드 발표

개발 요구 사항:

      ，      ，     `makefile` 。        `make build`   

대략적인 절차:

은 먼저 git 창고에서 대응하는 tag 또는 branch에 따라 코드를 얻는다.

jenkins의 shell 기능을 활용하여 make build

에서 build의 코드를 얻었고 rsync에서 서버에 도착했습니다.

서비스 재개 supervisor

건강검진;포트 및 프로세스가 올바른지 확인하는 sleep 3s또한 건강검진 인터페이스를 요청해 서비스가 정상인지 확인한다.

여기까지입니다.하지만 다음 단계를 촉발할 수 있다.백그라운드 운행.

은 api을 이용하여 새로 발표된 프로젝트 중의 어느 ecs을 거울로 삼았다.보통 10분 정도

의 탄성 신축 전략을 수정한 거울 ID은 a단계에서 발생한 거울 ID이다.

압정과 메일 알림.주로 항목 이름, 수정 전후의 미러 이름이 포함됩니다.

요새기jumpserver

목적:

은 현재 모든 프로그램 로그를 수집하지 않고 가끔 서버에 개발하여 해당하는 debug 로그를 볼 수 있습니다.

개발에 서버가 필요하면 권한 관리에 문제가 생깁니다.그것을 쓰는 것은 주로 이 문제를 해결하기 위해서이다.

이점:

서로 다른 개발, 서버에 대한 액세스 권한

리소스 통합 관리

운영 감사 등 타점 서비스, 자원 사용 현황 포지셔닝 prometheus+pushgateway+grafana+alertmanager+ 의 목적은 다음과 같은 문제에 자주 부딪히는데 특정한 서비스, 자원의 cpu 또는 메모리가 급증한다.똑똑히 알기 위해서.이 자원들이 급격히 높아지기 위해 어떤 서비스로 인해 우리는 타점 서비스에 가입했다.시나리오:

프로그램은 의존하는 자원을 호출할 때 시퀀스 데이터베이스에 점을 찍는다.

prometheus을 시차 데이터베이스로 한다.

pushgateway은 prometheus 시퀀스 데이터베이스의 스위치이다.

grafana 전시

alertmanager + 스파이크, 경고

저자: lvnian