v1.0~v1.4의 4회 반복 후 SREWorks의 핵심 기반은 매우 높은 안정성과 성숙도를 보여주었습니다. v1.5 버전에서 SREWorks 개발 팀은 코어 기반에서 더 많은 디지털 인텔리전스 기능을 반복했습니다. 동시에 디지털 인텔리전스의 반복적인 프로세스에서 SREWorks 사용자와 높은 빈도의 커뮤니케이션도 유지합니다. 우리는 사람들이 일반적으로 모니터링 데이터를 기반으로 디지털 인텔리전스 기능에 더 많은 관심을 기울이는 것을 발견했기 때문에 이러한 점에 대해 심층 분석을 수행한 결과 일반적으로 다음과 같은 문제에 직면한다는 것을 발견했습니다.
- 자체 개발 모니터링 시스템의 데이터 양이 증가한 후 신뢰성이 떨어졌습니다.
- 로그와 같은 다양한 유형의 비정형 데이터의 도입으로 인해 엔지니어링 복잡성이 급격히 증가하고 실시간 성능 측면에서 더 큰 문제가 발생했습니다.
- 단순한 표현으로는 사업 다각화의 모니터링 요구를 충족할 수 없는 경우가 많습니다.
따라서 많은 사용자들이 자체 개발한 모니터링 시스템에서 플로우 컴퓨팅 엔진인 Flink로 전환을 선택하지만 Flink Job 자체의 사용 임계값과 운영 및 유지 관리가 큰 문제가 되었습니다. 몇 차례의 분석과 연구 끝에 SREWorks 개발 팀은 이러한 문제를 두 단계로 나누기로 결정했습니다.
- Flink 작업을 사용하기 위한 임계값을 낮추고, SRE가 운영 및 유지 관리 요구 사항을 컴퓨팅 성능으로 신속하게 변환할 수 있도록 하고, SRE가 진정으로 데이터를 다룰 수 있는 능력을 갖도록 합니다.
- SREWorks 엔지니어링 기능을 사용하여 오픈 소스 Flink 운영 및 유지 관리 제품을 구축하여 Flink 운영 및 유지 관리의 어려움을 더욱 줄입니다.
v1.5 버전에서는 먼저 Phase 1의 오픈 소스를 완성할 예정입니다. 동시에 실시간 운영 플랫폼에서는 모두가 이런 종류의 모범 사례로 요구한 로그 클러스터링을 도입할 것입니다. 디지털 지능 능력: Flink ML을 통해 대규모 로그의 실시간 집계 효율성을 크게 향상시킵니다 . 2단계와 관련하여 Flink의 지능형 진단 도구인 Flink Advisor에 대한 소개는 가까운 시일 내에 공개될 예정이며 이 기사에서는 확장되지 않습니다. 1단계의 오픈 소스 제품인 실시간 운영 플랫폼부터 시작하겠습니다.
실시간 운영 플랫폼
SREWorks가 처음 오픈 소스화되었을 때 SREWorks는 Flink 작업을 관리하기 위해 Ververica Platform의 커뮤니티 버전을 포함했기 때문에 한동안 vvp의 커뮤니티 버전 사용에 대한 질문에 답변하는 데 사용자와의 커뮤니케이션 시간의 대부분을 차지했습니다. 따라서 이러한 요구 사항을 침전 및 연마한 후 실시간 처리 링크를 운영 플랫폼에 통합했습니다.운영 플랫폼의 작업은 예정된 작업과 실시간 작업으로 나뉩니다.
- 예약된 작업은 분 단위의 작업 실행 일정을 제공하므로 데이터 양이 적고 적시성이 낮은 일괄 처리 시나리오에 적합합니다.
- 실시간 작업은 Flink + Community Edition Ververica 플랫폼을 기반으로 실시간 작업 관리를 제공합니다.
많은 사용자 피드백을 수집한 후 SRE의 단계별 오케스트레이션 기능을 실시간 작업에 통합하여 SRE 사용 임계값을 더 줄이기로 결정했습니다. 최종 기능은 다음 그림과 같습니다 . Flink Job은 손쉬운 관리를 위해 세 가지 구조로 나뉩니다.
- 입력 소스 : Flink의 소스 소스에 해당하며 여러 개의 입력 소스가 있을 수 있습니다.
- Python 처리 : 현재 pyFlink를 기반으로 하는 Flink에서 요약한 처리 프로세스에 해당하며 Python 스크립트를 직접 작성하거나 비즈니스 요구에 따라 여러 Python 처리 프로세스로 분할할 수 있습니다.
- 출력 : Flink의 Sink에 해당하며 출력이 여러 개 있을 수 있습니다.
입력 소스 및 출력
입력 및 출력 섹션에서는 사용자가 선택할 수 있도록 Ververica 플랫폼의 등록된 커넥터를 직접 읽고 매개변수를 구성할 때 드롭다운 알림을 표시하여 사용자가 CREATE TABLE을 직접 작성할 때 필드 및 매개변수의 누락을 크게 방지합니다.
운영 환경
Python을 자주 사용하는 학생들은 Python 운영 환경 관리가 번거로운 문제라는 것을 알 수 있습니다. Docker 이미지를 사용하여 패키징 프로세스를 관리하면 너무 길고 요구 사항을 사용하여 관리하면 종종 다음과 같은 문제에 직면합니다. 포장할 수 없습니다. 따라서 실시간 운영 플랫폼에서는 절충안을 만들고 관리를 위해 Python 가상 환경을 사용했습니다.
동시에 Flink의 컨테이너 이미지 및 PyFlink의 런타임 Jar 패키지와 같은 일련의 개체가 환경의 설정으로 계산되는 환경 개념을 결합하여 확장했습니다. 환경이 모든 가변 리소스를 수렴하므로 SRE 유지 관리 작업의 복잡성이 크게 줄어들고 여러 런타임 리소스 간의 버전 비호환성 문제가 사라지고 동일한 환경의 모든 작업이 동일한 조합을 사용합니다.
현재 v1.5는 flink-ml과 default의 두 가지 환경을 제공하며 환경의 자체 관리 기능은 다음 버전에서 출시될 예정입니다.
Flink 작업 운영 및 유지보수
실시간 작업 플랫폼은 작업 제출 프로세스를 단순화하는 더 많은 추상화를 만들었지만 Flink 작업 운영 및 유지 관리의 복잡성을 잘 알고 있으며 Flink 대시보드를 실행 관찰로 직접 사용하여 너무 많은 추가 패키징을 수행하지 않았습니다. 플랫폼 Flink에 익숙한 학생들이 빠르게 시작하고 문제를 해결할 수 있도록 편리합니다. 다음 그림은 실시간 작업 플랫폼에서 작업을 시작하기 위한 Flink 대시보드 페이지를 보여줍니다.
로그 클러스터링
실시간 운영 플랫폼에서 이번 v1.5 버전도 로그 클러스터링 알고리즘을 오픈 소스로 공개했다. 소스 엔지니어링.
로그 클러스터링의 알고리즘 코드는 https://github.com/alibaba/SREWorks/tree/master/saas/aiops/api/log-clustering 디렉토리에 있습니다.
├── db-init.py
├── log-clustering-job
│ ├── pythons
│ │ └── log_cluster_pattern.py
│ ├── settings.json
│ ├── sinks
│ │ └── pattern_output.json
│ ├── sources
│ │ └── log_input.json
│ └── template.py
└── ...
카탈로그는 주로 두 부분으로 구성됩니다.
- db-init.py : 로그 키워드 목록 및 로그 템플릿 기능을 초기화하기 위해 소수의 일반적인 로그 샘플을 사용해야 하는 기능 엔지니어링을 위한 데이터베이스 초기화.
- log-clustering-job/*: v1.5 버전에서 기본적으로 작업 플랫폼으로 가져오는 로그 클러스터링 알고리즘 작업으로, 수동으로 zip 패키지로 가져오면 동일한 효과를 얻을 수 있습니다.
다음으로 이 오픈 소스 프로젝트를 기반으로 전체 로그 클러스터링 실습을 완료합니다. 이 실습의 입력은 Kafka(SREWorks의 내장 Kafka)의 로그 스트림이고 출력은 MySQL의 기능 라이브러리입니다.
STEP 1 기능 엔지니어링 초기화
이 연습에서는 SREWorks의 애플리케이션 엔진(AppManager) 로그를 예로 들어 보겠습니다.
먼저 name=sreworks-appmanager-server 레이블을 사용하여 AppManager Pod의 이름을 쿼리합니다. 이 레이블은 나중에 컬렉션에서 사용됩니다.
$ kubectl get pods -l name=sreworks-appmanager-server -n sreworks
NAME READY STATUS RESTARTS AGE
sreworks-appmanager-server-c9b6c7776-m98wn 1/1 Running 0 5h39m
그런 다음 Pod의 소량의 로그를 초기화 로그 샘플로 추출하고 파일 이름을 example.log 로 저장합니다 .
kubectl logs --tail=100 sreworks-appmanager-server-c9b6c7776-m98wn -n sreworks > example.log`
example.log 의 로그 내용은 대략 다음과 같습니다.
[2023-05-26 21:46:02 525] DEBUG [http-nio-7001-exec-6][o.s.web.servlet.DispatcherServlet:119]- GET "/realtime/app-instances?stageIdList=prod&appId=&clusterId=1id&optionKey=source&optionValue=app", parameters={masked}
[2023-05-26 21:46:02 526] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestMappingHandlerMapping:522]- Mapped to com.alibaba.tesla.appmanager.server.controller.RtAppInstanceController#list(RtAppInstanceQueryReq, HttpServletRequest, OAuth2Authentication)
[2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor:268]- Using 'application/json', given [*/*] and supported [application/json, application/*+json]
[2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor:119]- Writing [TeslaBaseResult(code=200, message=SUCCESS, requestId=null, timestamp=1685137562527, data=Pagination( (truncated)...]
[2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.web.servlet.DispatcherServlet:1131]- Completed 200 OK.
..
db-init.py를 사용하여 기능 엔지니어링 데이터베이스를 초기화합니다. 이 작업은 데이터베이스에 테이블을 추가하고 example.log 의 로그를 기능 행으로 처리하여 테이블에 저장합니다.
pyon3 ./db-init.py example.log --host *** --user *** --password *** --database *** --table***
이 데이터베이스의 연결 변수를 기억하십시오. 다음 단계에서 사용됩니다.
STEP 2 작업 매개변수 실행 구성 및 시작
SREWorks에서 실시간 작업 플랫폼을 열고 "로그 클러스터링 패턴 추출" 작업에 해당하는 [매개변수 실행] 버튼을 클릭한 다음 시작 매개변수에서 STEP1의 데이터베이스 연결 매개변수를 입력합니다.
채우기를 완료한 후 시작할 작업을 직접 클릭할 수 있습니다. 작업이 시작된 후 [실행 중] 상태를 클릭하여 Flink 대시보드로 바로 이동하여 전체 스트림 컴퓨팅 처리 링크가 준비되었지만 아직 로그 입력이 없는지 확인할 수 있습니다.
STEP 3 로그 수집 입력 및 클러스터링
ilogtail은 Alibaba Cloud의 수집 시나리오에서 널리 사용되는 Alibaba Cloud의 오픈 소스 관찰 가능 도구입니다. ilogtail도 클라우드 네이티브에 매우 잘 적응하고 있으며 DaemonSet의 방식을 채택하여 각 노드에서 풀업하고 Pod에 해당 레이블이 포함되어 있는 한 수집합니다.
따라서 운영 및 유지보수 시장을 통해 ilogtail을 클러스터에 쉽게 설치할 수 있으며, 동시에 설치 시 해당 수집 레이블을 name=sreworks-appmanager-server 로 구성하여 애플리케이션 엔진( 앱 매니저).
로그 수집이 시작된 후 Flink 대시보드를 통해 원래 비어 있던 실시간 처리 링크가 갑자기 바빠지는 것을 확인할 수 있습니다.공장 조립 라인처럼 각 컴퓨팅 장치는 지속적으로 처리 데이터를 송수신합니다. MySQL의 패턴 테이블을 보면 로그 기능이 처리된 후 STEP 2에서 정의한 MySQL 테이블에 드롭된 것을 확인할 수 있습니다.
기능 테이블에서 몇 가지 핵심 사항에 주의를 기울일 수 있습니다.
- 특성 테이블은 로그 특성의 수렴으로 초기에는 데이터 양이 급격히 증가하다가 일정 시간이 지나면 새로운 특성이 없으면 데이터 양이 안정화됩니다.
- feature 테이블의 필드 패턴은 이 로그 라인의 요약이며 top_pattern 필드 는 클러스터링 후 중앙의 로그 요약입니다. **top_pattern**을 통해 전체 로그 유형을 쉽게 셀 수 있으며, 우리는 또한 클래스 로그 아래의 각각의 What are the logs를 볼 수 있습니다.
아래 그림과 같이 매우 유사하지만 다른 텍스트를 가진 디버그 로그가 동일한 **top_pattern** 아래에 모여 있음을 알 수 있습니다.
로그 클러스터링의 실용화
로그 클러스터링 알고리즘을 중심으로 많은 데이터 인텔리전스 사례를 수행할 수 있습니다. 위의 엔지니어링 사례와 결합된 "Flink ML 기반 지능형 운영 및 유지 관리 알고리즘 서비스 및 애플리케이션"의 공개된 사례에 중점을 두고 전체 링크를 살펴볼 수 있습니다.
- STEP 3에서 살펴본 특징(패턴) 테이블은 SRE가 운영 및 유지 보수 경험을 기반으로 레이블링하도록 안내하는 로그 지식 베이스로 더 발전할 수 있습니다.
- 로그 지식 베이스에 축적된 로그는 Q&A 코퍼스로 Q&A 로봇에 입력되어 사용자의 문제를 신속하게 해결하고 작업 지시를 줄입니다.
로그 클러스터링 알고리즘 통합 및 사용 후 피드백을 기다리며, SREWorks 팀은 내부 운영 효과 및 피드백을 기반으로 디지털 인텔리전스 운영 및 유지 보수 알고리즘을 지속적으로 연마하겠습니다.
향상된 엔터프라이즈 애플리케이션 개발 및 배포
v1.5 버전에서는 다음 기능을 포함하여 기반의 애플리케이션 개발 기능도 향상되었습니다.
- 엔터프라이즈 응용 프로그램은 다중 버전 개발 기능을 추가하여 기업의 다중 버전 반복 요구 사항에 적응합니다.
- 엔터프라이즈 애플리케이션 인스턴스는 완전한 OAM 시각화를 배포합니다.
엔터프라이즈 애플리케이션 측면에서 우리는 종종 SREWorks 일선 사용자의 의견을 결합하여 SREWorks 사용자에게 제품 연마 및 최적화를 통해 내부 사용을 위한 강력한 기능을 제공합니다. 우리는 또한 클라우드 네이티브 애플리케이션 개발 모델과 디지털 인텔리전스 운영 및 유지 관리 시스템이 기업이 비즈니스 가치에 집중하고 신속한 기능적 제품 개발 반복을 수행하는 데 도움이 될 수 있기를 바라며 이 상태를 유지할 것입니다.
현재 버전에서 v1.5로 업그레이드하는 방법
- 업그레이드에는 기지가 포함되며 5~10분 동안 페이지에 액세스하지 못할 수 있습니다.
- 사용자가 개발한 클라우드 네이티브 애플리케이션은 영향을 받지 않으며(재시작 없음) SREWorks 게이트웨이에서 애플리케이션으로의 트래픽이 중단됩니다.
git clone http://github.com/alibaba/sreworks.git -b v1.5 sreworks
cd sreworks
./sbin/upgrade-cluster.sh --kubeconfig="****"
사용 중 문제가 발생하면 GitHub에서 문제를 제기하거나 풀 요청을 환영합니다.
SREWorks 오픈 소스 주소: https://github.com/alibaba/sreworks
딩톡 그룹( 그룹 번호: 35853026 ) 에 가입하셔서 공유하고 소통하세요~