에이전트 유형

에이전트 유형 정의는 에이전트 컨트롤이 특정 에이전트를 식별, 다운로드, 설정 및 실행하는 방법을 설명하는 YAML 파일입니다. 선언된 변수는 플릿 컨트롤이 플릿에서 하위 에이전트를 배포하거나 업데이트할 때 운영자에게 노출하는 설정 스키마를 형성하기도 합니다. 모든 정의는 세 가지 주요 섹션인 metadata, variables, deployment와 파일이 작성된 스키마 언어의 버전을 지정하는 최상위 protocol_version 필드로 구성됩니다.

메타데이터

메타데이터 섹션은 에이전트 유형, 즉 name, namespace, version, 타겟 platform (host 또는 kubernetes) 및 operating_system (호스트 기반 유형에 필요)을 식별합니다. 에이전트 컨트롤은 이러한 필드를 사용하여 정의를 고유하게 지정하고 올바른 배포 엔진으로 전달합니다.

변수

변수 섹션은 운영자가 설정에 하위 에이전트를 추가할 때 설정할 수 있는 구성 가능한 입력을 선언합니다. 각 변수에는 type (예: string, bool 또는 yaml), 선택적 default 및 허용되는 값의 선택적 variants 목록이 있습니다. 변수는 ${nr-var:variable_name}을(를) 사용하여 배포 섹션 전체에서 참조됩니다.

전개

배포 섹션에서는 에이전트 컨트롤이 타겟 플랫폼에 에이전트를 설치하고 실행하는 방법을 설명합니다. 이 섹션은 여러 하위 섹션으로 구성됩니다.

• packages: 에이전트가 시작되기 전에 다운로드할 OCI 아티팩트 ― 일반적으로 에이전트 바이너리 또는 통합 패키지입니다.
• executables: 에이전트 컨트롤이 시작, 모니터 및 다시 시작할 프로세스 목록입니다. 이 섹션이 없는 에이전트 유형은 관리형 통합(OHI)으로 처리되며, 에이전트 컨트롤은 해당 아티팩트를 처리하지만 실행은 다른 에이전트에 위임합니다.
• health: 에이전트 컨트롤이 에이전트의 정상 여부를 결정하는 방법 ― 프로세스 존재 여부, HTTP 엔드포인트 확인 또는 둘 다를 통해 결정합니다.
• filesystem: 설정 파일이나 인증서와 같이 에이전트를 시작하기 전에 에이전트 제어가 호스트에 쓰는 개별 파일 또는 디렉터리입니다.
• shared_filesystem: 동일한 에이전트 컨트롤 인스턴스에서 관리하는 다른 에이전트가 액세스할 수 있는 공유 드롭 존에 기록된 항목입니다. OHI 에이전트 유형이 설정 및 바이너리를 인프라 에이전트에 전달하는 데 사용됩니다.

전체 스키마 참조 및 사용 가능한 모든 필드는 에이전트 유형 스키마 참조를 확인해 주십시오.

에이전트 유형 정의를 가져옵니다.

에이전트 컨트롤은 정의의 메타데이터 섹션에 선언된 namespace, name 및 version로 식별되는 원격 OCI 레지스트리에서 에이전트 유형 정의를 가져옵니다.

기본적으로 에이전트 컨트롤은 newrelic/agent-control-agent-types 저장소를 사용하여 docker.io에서 가져옵니다.

에이전트 컨트롤은 각 정의를 가져오기 전에 뉴렐릭 공개 키로 서명을 검증합니다.

에이전트 패키지와 동일한 방식으로 이 레지스트리를 미러링할 수 있습니다.

연결된 에이전트 유형

한 에이전트 유형이 공유 파일 시스템에 아티팩트(설정, 바이너리 또는 기타 파일)를 쓰고 다른 에이전트 유형이 동일한 경로에서 읽도록 설정된 경우 두 에이전트 유형이 연결 됩니다. 작성자에게는 executables 섹션이 없을 수 있으며, 에이전트 컨트롤은 아티팩트를 관리하지만 이를 위한 프로세스를 시작하지는 않습니다. 대신, 리더 에이전트에는 공유 파일 시스템의 잘 알려진 경로에서 바이너리 및 설정을 검색하고 실행하는 기본 제공 로직이 있어 작성자를 대신하여 애드온을 효과적으로 실행합니다.

공유 파일 시스템 루트는 다음과 같습니다.

동일한 Agent Control 인스턴스에서 관리하는 모든 에이전트는 이 루트를 공유합니다. 하위 디렉터리 이름은 연결된 에이전트 유형 간의 규칙에 따라 선택됩니다.

온-호스트 통합(OHI)

온-호스트 통합(OHI)은 에이전트 제어에서 연결된 에이전트의 주요 예이며, 다른 에이전트는 에이전트 제어에 의해 시작되는 프로세스를 가지고 있지만, OHI 에이전트는 자체 프로세스가 없으며 에이전트 제어가 이를 시작하지 않습니다. 이를 통해 Agent Control은 뉴렐릭 Infrastructure 통합의 전체 수명 주기를 관리하여 다운로드, 구성, 업그레이드 및 제거를 수행하는 동시에, 공유 파일 시스템에서 통합 바이너리를 검색하고 실행하는 인프라 에이전트에 실행을 위임할 수 있습니다.

인프라 에이전트 및 OHI 에이전트 관계

1. OHI 에이전트 유형이 설치되면 Agent Control은 OCI를 통해 통합 바이너리를 다운로드하고 공유 파일 시스템에 두 개의 항목을 기록합니다:

   • infra-agent-ohi-configs/ 아래의 설정 파일(예: nri-redis.yaml)
   • infra-agent-ohi-binaries/ 아래의 통합 바이너리(예: nri-redis)

2. 인프라 에이전트 하위 에이전트는 이러한 공유 디렉터리를 가리키는 환경 변수로 구성됩니다:

   변하기 쉬운	공유 파일 시스템 경로	목적
   NRIA_PLUGIN_DIR	…/infra-agent-ohi-configs	통합 설정 검색
   NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR	…/infra-agent-ohi-binaries	통합 바이너리 검색
   NRIA_SAFE_BIN_DIR	…/infra-agent-ohi-binaries	허용된 바이너리 실행 경로

3. 인프라 에이전트는 다음 스캔 주기에서 구성 및 바이너리를 가져와 통합 실행을 시작합니다.

   shared-filesystem/
   ├── infra-agent-ohi-configs/      # Integration YAML configs (read by NRIA_PLUGIN_DIR)
   │   ├── nri-redis.yaml
   │   └── nri-mysql.yaml
   └── infra-agent-ohi-binaries/     # Integration binaries (read by NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR)
       ├── nri-redis
       └── nri-mysql

   카피

지원되는 에이전트 유형

현재 지원

다음 표는 에이전트 제어가 지원하는 에이전트 유형과 환경 전반의 가용성을 보여줍니다.

에이전트 유형별 필수 권한

다음 표에는 각 에이전트 유형에 필요한 주요 권한과 해당 권한이 적용되는 환경이 나열되어 있습니다.

호스트에서 Fluent Bit 구성

호스트에서 Fluent Bit는 자체 최상위 에이전트 유형으로 배포되지 않습니다(위의 지원 표 참조). 대신 로그 포워딩이 활성화되면, 독립 실행형으로 설치될 때와 동일한 방식으로 뉴렐릭 인프라 에이전트 자체에서 Fluent Bit를 생성하고 관리합니다. 에이전트 컨트롤은 인프라 에이전트, 해당 데이터, Fluent Bit 바이너리 및 플러그인이 디스크에 상주하는 위치만 변경합니다.

로그 포워딩 자체(logging.d/*.yml 구문, 입력, 필터, 속성 등)를 구성하는 방법은 다음을 참조하십시오:

• 로그 관리 활성화
• Fluent Bit로 로그 포워딩

설정 위치

에이전트 컨트롤과 관련된 유일한 세부 사항은 로그 포워딩 파일이 저장되는 위치입니다. 이 파일은 인프라 에이전트 설정의 config_logging 필드를 통해 로그 소스당 하나의 항목으로 하위 에이전트의 logging.d 폴더에 저장됩니다. 하위 에이전트의 설정(예: local_config.yaml)에서 직접 설정하고 이를 에이전트 컨트롤로 보내십시오:

config_logging:
  syslog.yaml: |
    logs:
      - name: syslog
        file: /var/log/syslog
        attributes:
          logtype: linux_syslog
  app.yaml: |
    logs:
      - name: app-log
        file: /var/log/app.log
        attributes:
          service: api
          env: production

Fluent Bit의 위치 및 업데이트 방법