Metoro

Metoro의 수집기는 DaemonSet으로 돌며 eBPF로 커널에 걸린다. 그래서 SDK를 더하거나 컨테이너 하나를 재시작하지 않고도 stdout/stderr 로그, RED와 USE 메트릭, 분산 트레이스, CPU와 메모리의 지속적 프로파일링을 얻는다. 설정은 관리형 클러스터든 베어메탈이든 같아서, 공급자 사이를 옮겨도 새 계측 프로젝트를 강요당하지 않는다. eBPF 모니터링 중 가장 번거롭지 않은 형태다.

에이전트는 요청 지연이 튀었다고 알려 주는 데서 멈추지 않는다. 그 이상 징후를 메트릭, 로그, 트레이스, 쿠버네티스 이벤트에 걸쳐 연관 짓고, 근거로 뒷받침된 근본 원인을 돌려준다. 각 탐지는 팀에 도달하기 전에 조사와 검증을 거친다. Metoro가 보통은 알림을 부르는 잡음을 이렇게 걸러 낸다고 주장하는 방식이다. 이 검증 단계가 중요하다. 새벽 3시에 거짓 경보를 울리는 에이전트는 아무도 원하지 않는다.

에이전트가 문제의 변경을 짚어 내면, 수정과 RCA 요약, 텔레메트리 링크, 뒷받침 근거를 담은 풀 리퀘스트를 작성한다. 저절로 병합되는 건 없으므로 엔지니어가 통제권을 쥔다. 워크플로는 병합 전 검토다. 이것이 자동 복구 부분이고, 정확한 커밋을 찾느라 지친 팀에게는 실제로 시간을 아껴 주는 부분이다.

모든 롤아웃은 git SHA, 작성자, PR, 그리고 건드린 워크로드에 묶인다. Metoro는 새 배포의 서비스별, 엔드포인트별 동작을 기준선과 비교하고, 뭔가 회귀하면 Slack에 알리고 롤백 PR을 미리 작성한다. 나쁜 배포를 내보낸 몇 분 뒤에 잡는 편이 고객에게서 듣는 것보다 낫다.

팀에 다른 도구에서 오는 알림이 이미 있다면 Metoro가 그것도 조사한다. 시끄러운 알림과 진짜 장애를 나누고, 그럴듯한 원인과 근거, 제안하는 수정을 Slack으로 보낸다. 기존 알림은 그대로 두고, 알림이 실제로 무슨 뜻인지 설명하는 층을 더하는 셈이다.

하나의 저장소가 일곱 가지 신호 유형을 모두 담고, 하나의 쿼리 언어가 그것들을 가로지른다. eBPF가 보지 못하는 것은 OpenTelemetry와 Prometheus 호환성으로 덮여서 기존 익스포터가 그대로 동작한다. 탭은 줄고, 장애 중 도구 사이에서 복사해 붙이는 일도 줄어든다.

Metoro는 런타임 동작을 그것을 만들어 낸 코드와 설정에 되짚고, 배포와 ConfigMap, CRD의 모든 변경을 전체 이력과 함께 저장한다. 시점별 diff로 건강한 상태와 깨진 상태 사이에서 정확히 무엇이 바뀌었는지 볼 수 있다.