옵저버빌리티 에이전트는 실행 시 많은 양의 리소스를 소비할 수 있습니다. 에이전트 프로그램이 너무 많은 리소스를 소비하여 불필요한 추가 비용이 발생하는 것을 방지하기 위해 에이전트 자체의 리소스 소비를 모니터링하여 리소스 소비가 합리적인 범위 내에서 유지되는지 확인할 수 있습니다.
최근에 원격 분석 데이터를 모니터링하는 필터로 사용하는 방법을 . 특히 보안상의 이유로 여러 애플리케이션이나 마이크로서비스가 관련된 경우에 적용됩니다. 따라서 합니다. OpenTelemetry Collector와 같은 통합 가시성 에이전트에는 Fluent Bit, Vector 등이 있습니다.
통합 가시성 에이전트는 통합 가시성 작동 메커니즘에서 핵심적인 역할을 합니다. 에이전트는 일반적으로 데이터 수집, 데이터 처리 및 데이터 전송을 제공하며 시스템 성능을 모니터링하는 데 핵심적인 역할을 합니다. 에이전트는 성능 문제를 해결하고 완화하기 위해 알려지지 않은 문제를 식별하는 데 도움을 줍니다. 문제 발생 시. 이것이 바로 통합 가시성 기능의 표준입니다.
이러한 방식으로 데이터 수집에 사용될 때 Observability 에이전트는 하나 이상의 소스에서 전송된 데이터를 수집합니다. 데이터를 수신할 뿐만 아니라, 예를 들어 Grafana 패널의 시각화를 위해 엔드포인트로 데이터를 전송하기도 합니다. 이를 통해 통합 가시성을 위해 특정 유형의 로그, 시스템 성능 모니터링 수집하도록 구성할 수 있습니다.
처음에는 원격 분석 데이터를 Observability Platform으로 직접 전송하는 탐지된 애플리케이션을 이미 배포하고 있는 경우 Observability 에이전트를 사용하지 않도록 선택할 수 있습니다. 수집기는 탐지할 수 없는 애플리케이션을 모니터링할 때 유용합니다. 이 또한 매우 일반적인 사용 사례이기 때문에 수집기는 탐지할 수 없는 애플리케이션을 모니터링할 때도 유용하다고 Google 소프트웨어 개발자 Braydon Kains는 The "새로운" Stack에 말했습니다.
- BC 게인 11월 6일， 2023
Observability Collector 기능이 없으면 이러한 기능을 위해 각 백엔드 또는 사용자 모니터를 개별적으로 구성해야 하므로 번거로울 수 있습니다. 대신, Observability Collector는 모든 마이크로서비스에 대한 단일 엔드포인트 역할을 수행하여 수집기가 지원하는 통합 지점을 통해 애플리케이션과 마이크로서비스에 대한 액세스를 간소화합니다. Observability Agent를 수집기로 활용하면 마이크로서비스를 중앙에서 보고 관리할 수 있어 Grafana와 같은 플랫폼 전반에서 통합된 보기를 제공합니다. Grafana는 OpenTelemetry 수집기를 사용하지 않는 몇 가지 대안을 제공하지만, 수집기는 이 프로세스를 크게 간소화합니다.
그러나 Observability 에이전트는 리소스를 많이 사용할 수 있습니다. 이 문제를 해결하기 위해 에이전트 자체에서 리소스를 과도하게 소비하지 않도록 모니터링하여 불필요한 비용을 피할 수 있습니다. 즉, OpenTelemetry Collector, Fluent Bit, Vector 등은 모두 견고함과 다양한 작업을 수행할 수 있는 능력을 보여주면서 우수한 결과를 달성했지만 상대적인 성능은 다를 수 있습니다.
리소스 문제
가장 인기 있는 대부분의 에이전트에는 로그와 데이터를 보강하기 위해 Kubernetes API에서 메타데이터를 가져오는 Kubernetes 필터와 프로세서가 있습니다. Google 소프트웨어 개발자 Braydon Kains가 자신의 KubeCon + CloudNativeCon 강연인 "어떤 비용으로 통합 가시성 에이전트 성능을 평가하는 방법 "에서 말했듯이, OpenTelemetry 외에도 Fluent Bit와 Vector도 인기가 높아지고 있습니다. 벡터의 인기도 높아지고 있습니다. "모든 에이전트에는 사용 가능한 기본값이 사용자의 요구 사항을 충족하지 못하는 경우 사용자 지정 처리를 구축할 수 있는 방법도 있습니다."라고 세션이 끝난 후 "새로운" Stack에서 Kains는 말했습니다.
"이 영역에서 가장 큰 문제는 초당 메가바이트의 데이터를 처리하는 파이프라인에서 어떤 작업을 수행하면 오버헤드에 몇 배의 영향을 미친다는 것입니다. 특히 정규식 로깅이나 JSON 로그 구문 분석의 경우 그 영향이 급격히 커집니다."라고 Kains는 말합니다. "데이터를 충분히 빠르게 전송할 수 없다면 워커 프로그램 수를 늘리거나 에이전트의 스레딩 구현을 활용할 것을 적극 권장합니다."
Kains는 내보내기가 파이프라인에서 쉽게 병렬화할 수 있는 유일한 단계라고 말합니다. 대부분의 백엔드는 타임스탬프가 약간 어긋나는 것을 처리할 수 있지만, Fluent Bit가 제공하는 기능 중 하나는 예를 들어 8개의 워커 프로그램을 설정하여 동시에 데이터를 전송하는 8개의 워커 프로그램이 포함된 스레드 풀을 만들 수 있다는 것인데, 기본적으로 프로세스가 충분하지 않은 경우 Braydon Kains 스레드 풀에 할당하고 워커 프로그램 중 하나가 느린 부분을 처리하도록 하여 파이프라인의 효율성을 크게 향상시킬 수 있다고 Kains는 설명합니다.
테스트 방법
조직은 종종 어떤 에이전트가 가장 적합한지, 예상되는 오버헤드는 얼마인지 독립적으로 결정해야 한다고 카인즈는 말합니다. "이를 위한 유일한 방법은 직접 실행해 보는 것입니다. 프로덕션 환경을 복제할 수 있다면 에이전트를 설치하여 구성하고 메트릭을 모니터링하는 것뿐입니다."라고 Kains는 말합니다. "이것이 답을 얻는 가장 좋은 방법입니다."
프로덕션 환경을 복제하는 것이 어렵다면 로그 생성기나 Prometheus 크롤링과 같은 테스트 워크로드를 고려할 것을 권장합니다. AWS의 LogBench는 로그 파이프라인을 테스트하는 데 적합한 로그 생성기입니다. Prometheus 크롤링의 경우, 텍스트 크롤링 사본이 있는 모의 서버를 설정하세요. "특히 데이터베이스 메트릭에 대해 높은 수준의 시나리오가 예상되는 경우, 높은 수준의 케이스를 강제로 생성하여 에이전트의 성능을 스트레스 테스트하세요. 평가 결과가 만족스럽지 않다면 작업을 줄이거나 오프로드하여 리소스 사용량을 줄이는 것을 고려하세요. 집계 노드와 백엔드 처리도 리소스 사용량 관리에 도움이 될 수 있습니다."라고 카인즈는 말합니다. "허용할 수 없는 성능이 발생하거나 회귀가 발견되면 그래프, CSV, Linux perf 보고서 또는 Fluent Bit 같은 관련 성능 데이터뿐만 아니라 복제 문제에 대한 세부 정보가 포함된 유지 관리를 위한 이슈를 개설하세요."
Google 내부
Google의 Kains 팀은 두 개의 에이전트를 병합하여 로그 수집에는 Fluent Bit를, 메트릭 및 추적에는 OpenTelemetry를 사용하는 Google Cloud Ops를 사용합니다. 배후에서 팀은 OpenTelemetry 및 Fluent Bit에 대한 구성을 생성하는 중앙 구성 계층을 유지 관리합니다. 이러한 구성은 주로 일반 VM과 같은 가상 머신의 사용자에게 최적화되어 OpenTelemetry를 통해 효율적인 메트릭 수집을 보장합니다.
얼마 전에는 OpenTelemetry 로그를 플루언트 비트를 대체하는 운영 에이전트로 사용할 수 있는지에 대한 관심이 있었다고 케인스는 말했습니다. "이렇게 하면 OpenTelemetry 수집기를 완전히 통합할 수 있을 것입니다."라고 Kains는 말했습니다. "당시 OpenTelemetry 로그는 Fluent Bit의 처리량과 메모리 사용량을 견딜 만큼 충분히 성숙하지 않았기 때문에 그 당시에는 더 이상 진행하지 않기로 결정했습니다."라고 Kains는 말합니다. "해당 벤치마크에 대한 업데이트가 이루어지지 않았기 때문에 현재 상황은 어떨지 말하기 어렵습니다."
그러나 대부분의 일반 사용자가 에이전트를 벤치마킹하기 위해 Google 인프라에 의존하는 것은 비용이 많이 들고 최종 사용자에게는 지나치게 복잡할 수 있습니다. "저는 커뮤니티에서 복제할 수 없는 벤치마크를 실행합니다."라고 Kains는 말합니다. "새해에는 벤치마킹 및 성능 평가 전략을 수정하고 Google의 독점 기술이나 인프라에 의존하지 않도록 노력할 계획입니다."
하지만 AWS 로그 벤치를 사용하면 에이전트에 대한 로그 로드를 수동으로 생성하고 VM의 도구를 통해 직접 메트릭을 관찰 및 비교할 수 있으며 /proc 또는 이와 유사한 콘텐츠에서 정보를 수집할 수 있는 스크립트를 사용하여 메트릭을 수집할 수 있다고 Kains는 설명합니다. "기술 수준이 낮은 사용자도 이러한 종류의 벤치마킹에 더 쉽게 접근할 수 있도록 만들고 싶습니다."라고 Kains는 말합니다. "아직 정확한 계획은 없지만 앞으로 몇 달 안에 더 많은 것을 말씀드릴 수 있기를 바랍니다."
이 문서는 ()에 처음 게시되었으며 방문을 환영합니다.
