인프라 모니터링 에이전트를 사용하여 로그를 New Relic에 전달할 수 있습니다. 이렇게 하면 모든 로깅 데이터를 한 위치에서 사용할 수 있고 애플리케이션과 플랫폼 성능 데이터에 대한 더 깊은 가시성을 제공합니다.
로그를 New Relic에 전달하면 로그 데이터를 수집, 처리, 탐색, 쿼리 및 경고하는 향상된 로그 관리 기능을 제공한다.
기본 프로세스
안내 설치 프로세스를 사용하여 로그 관리 및 인프라 모니터링을 함께 빠르고 쉽게 설치할 수 있습니다! 안내된 설치 프로세스가 작동하는 방법과 New Relic One에 있는 로깅 데이터를 사용하는 방법을 알아보려면 유튜브 (14:46분) 에서 이 Nerdlog 비디오를 시청한다.
로그 UI에서 로그 데이터를 탐색 하고 인프라 에이전트가 자동으로 삽입한 로그 속성을 활용하십시오.
다음은 호스트 UI에 대한 로그 예제이다. 선택한 기간 동안의 이벤트 컨텍스트에서 로그를 확인하고 강조표시된 속성에 대한 자세한 데이터로 드릴 다운할 수 있습니다. 더 많은 기능을 활용하려면 여기에서 조회 로그 를 클릭하여 로그 UI로 직접 이동하십시오.
다음은 이벤트와 관련된 호스트 로그의 예제입니다.
호스트 내 통합에 대한 로깅 활성화
인프라 에이전트를 설치하면 가장 널리 사용되는 호스트 내 통합에 대한 자동 로그 구문 분석 및 전달을 한 단계로 활성화할 수 있습니다. 이 기능을 활성화하려면 on-host-log.yml.example 파일의 이름을 on-host-log.yml 합니다. 완료되면 통합 로그가 자동으로 구문 분석되어 New Relic으로 전송됩니다.
Elasticsearch elasticsearch-log.yml.example 파일을 Elasticsearch elasticsearch-log.yml 로 복사(또는 이름 변경)하여 자동 Elasticsearch JSON 형식 로그 구문 분석 및 New Relic으로 전달을 활성화합니다. 에이전트를 다시 시작할 필요가 없습니다.
logging.yml 구성 파일을 작성하고 필요한 매개변수를 추가하십시오. logging.d 디렉토리에는 참조 또는 시작점으로 사용할 수 있는 다양한 .yml.example 파일이 있습니다.
에이전트는 인프라 모니터링 서비스를 다시 시작하지 않고도 자동으로 새 구성 파일을 처리합니다. 이에 대한 유일한 예외는 사용자 정의 유동성 비트 구성을 구성하는 경우입니다.
전달 매개변수 로그
인프라 로그 전달 .yml 구성은 다음 매개변수를 지원합니다.
이름 (필수)
시작하려면 New Relic에 전달할 로그의 name 을 정의하십시오.
로그 소스 (필수)
로그 소스에 사용하는 것은 로그를 전달할 위치에 따라 다릅니다. 다음과 같은 사용 가능한 옵션
로그 파일 또는 파일에 대한 경로입니다. 에이전트는 tail -f shell과 유사한 방식으로 로그 파일의 변경사항을 추적합니다.
예시:
logs:
- name: example-log
file: /var/log/example.log # Path to a single log file
- name: example-log-two
file: /var/log/example-two.log # Path to another single log file
file 매개변수는 이름과 확장자에 와일드카드를 사용하여 특정 로그 파일이나 여러 파일을 가리킬 수 있습니다. 예: /logs/*.log . 파일 경로의 디렉토리 대신 와일드카드를 사용할 수 있습니다. 이 와일드카드는 다른 디렉토리에 있는 파일을 꼬리말하는 데 사용할 수 있습니다.
예시:
logs:
- name: docker-logs
file: /var/lib/docker/containers/*/*.log # Path to multiple folders and files
중요
와일드카드를 사용하면 파일 설명자의 수가 크게 증가할 수 있으며 inotify는 Fluent Bit 프로세스가 열린 상태를 유지하여 호스트의 파일 설명자 제한에 도달하면 로그 수집을 방해할 수 있습니다. 많은 수의 파일을 처리하려면 운영 체제에서 허용하는 파일 설명자와 inotify 감시자의 최대 수를 늘려야 할 수 있습니다. 로그 파일을 늘리는 방법에 대한 자세한 내용 은 많은 양의 로그 파일을 추적할 때 발생하는 오류를 참조하십시오.
Linux 환경에서 journald 데몬이 수집한 로그 메시지를 전달하려면 systemd 매개변수를 사용하십시오. 이 입력 유형을 사용하려면 에이전트가 루트 모드 에서 실행되어야 합니다.
예시:
logs:
- name: systemd-example
systemd: cupsd
시스템 로그 데이터 소스입니다.
매개변수:
uri: Syslog 소켓. 형식은 프로토콜에 따라 다릅니다.
TCP/UDP 네트워크 소켓: [tcp/udp]://LISTEN_ADDRESS:PORT
Unix 도메인 소켓: unix_ [tcp/udp]: //+/socket/path
parser: Syslog 파서. 기본값은 rfc3164 입니다. 메시지에 소수 자릿수 초가 포함된 경우 rfc5424 를 사용하십시오. 참고: rfc3164 는 현재 SuSE에서 작동하지 않습니다.
unix_permissions: 도메인 소켓의 경우 기본값은 0644 입니다. 이는 루트로 실행되는 프로세스에 대한 항목을 제한합니다. 0666 을 사용하여 사용자 자신의 위험에 따라 루트가 아닌 프로세스를 청취할 수 있습니다.
권한 모드에서 에이전트를 실행하는 경우 다른 프로세스가 소켓에 로그를 기록할 수 있도록 0666 파일 권한과 함께 nri-agent가 포트 및 소켓을 사용하거나 소유해야 합니다.
logs:
# TCP network socket
- name: syslog-tcp-test
syslog:
uri: tcp://0.0.0.0:5140 # Use the tcp://LISTEN_ADDRESS:PORT format
parser: rfc5424 # Default syslog parser is rfc3164
# UDP network socket
- name: syslog-udp-test
syslog:
uri: udp://0.0.0.0:6140 # Use the udp://LISTEN_ADDRESS:PORT format
max_line_kb: 35
# Unix TCP domain socket
- name: syslog-unix-tcp-test
syslog:
uri: unix_tcp:///var/unix-tcp-socket-test
unix_permissions: 0666 # Default is 0644. Change at your own risk
# Unix UDP domain socket
- name: syslog-unix-udp-test
syslog:
uri: unix_udp:///var/unix-udp-socket-test
parser: rfc5424
TCP 연결을 통해 검색된 로그.
매개변수:
uri: 들어오는 데이터를 수신 대기하는 TCP/IP 소켓입니다. URI 형식은 tcp://LISTEN_ADDRESS:PORT
format: 데이터 형식. json 또는 none일 수 있습니다.
separator:format: none 을 사용하는 경우 레코드 분할을 위한 구분자 문자열을 정의할 수 있습니다(기본값: \n ).
logs:
- name: tcp-simple-test
tcp:
uri: tcp://0.0.0.0:1234 # Use the tcp://LISTEN_ADDRESS:PORT format
format: none # Raw text - this is default for 'tcp'
separator: \t # String for separating raw text entries
max_line_kb: 32
- name: tcp-json-test
tcp:
uri: tcp://0.0.0.0:2345 # Use the tcp://LISTEN_ADDRESS:PORT format
format: json
Windows 로그 채널에서 이벤트를 수집한다.
매개변수:
channel: 채널 로그의 이름이 수집됩니다.
collect-eventids: 수집하여 New Relic에 전달할 Windows 이벤트 ID 목록입니다. 이벤트 ID 범위가 지원됩니다.
exclude-eventids: 콜렉션에서 제외할 Windows 이벤트 ID 목록. 이벤트 ID 범위가 지원된다.
기본적으로 모든 이벤트가 지정된 채널에서 수집됩니다. 원하지 않는 로그를 New Relic 계정에 보내지 않도록 collect-eventids 및 exclude-eventids 섹션을 구성하십시오.
이벤트 ID 또는 범위를 collect-eventids 또는 exclude-eventids 에 추가하여 특정 이벤트를 전달하거나 삭제합니다. 두 섹션에 동일한 이벤트 ID가 있는 경우 exclude-eventids 가 collect-eventids 보다 우선합니다.
예시:
logs:
# Winlog log ingestion with eventId filters.
- name: windows-security
winlog:
channel: Security
collect-eventids:
- 4624
- 4265
- 4700-4800
exclude-eventids:
- 4735
# entries for the application, system, powershell, and SCOM channels
로그 항목/줄의 최대 크기(KB)입니다. 로그 항목이 제한을 초과하면 건너뜁니다. 기본값은 128 입니다.
외부 유동성 비트 구성 및 구문 분석기 파일. 정의된 경우, 인프라 에이전트가 생성한 기존 구성 및 구문 분석기 파일과 병합됩니다.
인프라 에이전트는 logging.d 디렉토리에 있는 구성 파일을 처리하고 적절한 [INPUT], [FILTER] 및 [OUTPUT] 섹션이 포함된 런타임 F넉넉 Bit 구성 파일을 생성합니다. 선택적으로 fluentbit 옵션을 통해 외부 F유동성 비트 구성 파일을 제공한 경우에도 @INCLUDE 를 선언합니다.
런타임 파일은 [SERVICE] 섹션 을 정의하지 않고 모든 기본 Fluent Bit 구성 값을 유지합니다. 외부 Fluent Bit 구성 파일에서 고유한 [SERVICE] 섹션을 정의하고 fluentbit 옵션을 통해 포함하여 Fluent Bit의 기본 설정을 무시할 수 있습니다.
매개변수:
config_file: 기존의 유동성 비트 구성 파일에 대한 경로입니다. 겹치는 소스를 사용하면 새 릴릭 로그에 중복 메시지가 생성됩니다.
parsers_file: 기존 Fluent Bit 파서 파일의 경로입니다. 다음 파서 이름이 예약되어 있습니다: rfc3164 , rfc3164-local 및 rfc5424 .
중요
인프라 에이전트는 이 문서에 설명된 대로 logging.d/ 디렉토리의 YAML 파일에서 단순 로그 전달 구성을 정의하여 가장 일반적인 유스 케이스에 대한 전달 로그를 허용합니다. 이러한 파일은 올바른 형식 및 sane 구성 기본값을 사용하여 유동성 비트 구성 파일로 내부적으로 변환됩니다. 새 릴리스는 생성된 구성 파일이 올바르고 작동하는지 확인하기 때문에 이러한 구성 옵션에 대한 공식적인 지원을 제공합니다.
그럼에도 불구하고 지원되는 구성 옵션에서 다루지 않는 사용 사례의 경우 fluentbit , config_file 및 parsers_file 옵션을 사용하여 외부에서 생성된 Fluent Bit 구성 및 파서 파일을 사용할 수 있는 가능성을 제공합니다.
제공된 구성이 완전히 임의적이며 에이전트에 의해 생성/검증되지 않는다는 점을 감안할 때 이 경우 전달된 로그의 올바른 작동을 보장할 수 없습니다. 따라서 New Relic은 이러한 옵션을 통해 지정된 외부 구성에 대한 공식 지원을 제공하지 않습니다.
샘플 구성 파일
다음은 YAML 형식의 logging.d/ 구성 파일의 예입니다. 더 많은 구성 예는 인프라 에이전트 저장소 을 참조하십시오.
# Remember to only use spaces for indentation
logs:
# Example of 'file' source
- name: file-with-attributes
file: /var/log/test.log # Path to a single file or pattern
attributes: # You can use custom attributes to enrich your data
logtype: nginx
team: The A Team
pattern: Error # Regular expression to filter log entries
# Example of 'systemd' source (Linux only)
- name: systemd-example
systemd: cupsd
# Examples of 'syslog' source, one per protocol
# TCP network socket
- name: syslog-tcp-test
syslog:
uri: tcp://0.0.0.0:5140 # Use the tcp://LISTEN_ADDRESS:PORT format
parser: rfc5424 # Default syslog parser is rfc3164
# UDP network socket
- name: syslog-udp-test
syslog:
uri: udp://0.0.0.0:6140 # Use the udp://LISTEN_ADDRESS:PORT format
max_line_kb: 35
# Paths for Unix sockets are defined by combining protocol and path:
# unix_udp:// + /path/socket - for example, unix_udp:///tmp/socket
# Unix TCP domain socket
- name: syslog-unix-tcp-test
syslog:
uri: unix_tcp:///var/unix-tcp-socket-test
unix_permissions: 0666 # Default is 0644. Change at your own risk
# Unix UDP domain socket
- name: syslog-unix-udp-test
syslog:
uri: unix_udp:///var/unix-udp-socket-test
parser: rfc5424
# Examples of 'tcp' source for formats 'none' and 'json'
- name: tcp-simple-test
tcp:
uri: tcp://0.0.0.0:1234 # Use the tcp://LISTEN_ADDRESS:PORT format
format: none # Raw text - this is default for 'tcp'
separator: \t # String for separating raw text entries
attributes: # You can add custom attributes to any source of logs
tcpFormat: none
someOtherAttribute: associatedValue
max_line_kb: 32
- name: tcp-json-test
tcp:
uri: tcp://0.0.0.0:2345 # Use the tcp://LISTEN_ADDRESS:PORT format
format: json
attributes:
tcpFormat: json
yetAnotherAttribute: 12345
# Example of Fluent Bit configuration import
- name: fluentbit-import
fluentbit:
config_file: /path/to/fluentbit.config
parsers_file: /path/to/fluentbit/parsers.conf
로그 데이터 보기
모든 것이 올바르게 구성되어 있고 데이터가 수집되는 경우 두 위치 모두에 로그 데이터가 표시되어야 합니다.
로그 관리 기능을 활성화한 후에도 데이터가 나타나지 않으면 표준 로그 문제 해결 절차 를 따르십시오.
로그 전달 기능을 사용하려면 에이전트에 데이터 소스를 읽을 수 있는 권한이 있어야 합니다. 인프라 에이전트를 특권 또는 비특권 모드 로 실행할 때 전달하려는 로그 파일(및 해당 경로의 모든 중간 디렉토리)을 nri-agent 를 실행하는 사용자가 읽을 수 있는지 확인하십시오.
예: Linux에서 파일 액세스 확인
nri-agent 사용자가 /var/log/restrictedLogs/logFile.log 파일을 모니터할 수 있는지 확인하십시오. Linux에서는 namei 명령을 사용하여 빠른 확인을 수행할 수 있습니다.
인프라 에이전트 구성 지침 에 설명된 대로 proxy 매개변수는 HTTP 또는 HTTPS를 사용해야 하며 https :// user : password @ hostname : port 형식이어야 합니다. 에이전트는 HTTP 또는 HTTPS 없이 매개변수를 구문 분석할 수 있지만 로그 전달자는 할 수 없습니다. 에이전트 상세 로그에 다음과 같은 오류가 표시됩니다.
[ERROR] building HTTP transport: parse \"hostname:port\":
first path segment in URL cannot contain colon
이 문제를 해결하려면 newrelic-infra.yml 파일을 확인하고 proxy 매개변수가 이 형식을 준수하는지 확인하십시오.
인증서를 지정하기 위해 caBundleFile 또는 caBundleDir 을 사용하는 경우 각 OS에 대해 아래 규칙을 따르는 것이 좋습니다.
LinuxHTTP 프록시의 경우 인증서를 설정할 필요가 없습니다. 플러그인은 시스템 인증서를 로드하고 새 릴릭은 로깅 엔드포인트로 로그를 전송합니다. 그러나 caBundleFile 또는 caBundleDir 매개변수를 사용하여 프록시 자체 서명 인증서 (PEM 파일) 를 지정할 수 있습니다.
윈도우
HTTP 프록시의 경우 인증서를 설정할 필요가 없습니다. 플러그인은 시스템 인증서를 로드합니다.
HTTPS 의 경우 다음 방법 중 하나로 구성할 수 있습니다.
프록시 인증서를 시스템 풀로 가져오십시오 (권장) MMC 도구를 사용하여 프록시 자체 서명 인증서 (PEM 파일) 를 가져오십시오. 이 링크를 참조하고 단계 2 에서 Intermediate Certification Authorities대신 Trusted Root Certification Authorities으로 가져오도록 하십시오.
Windows에서 caBundleFile 및 caBundleDir 매개변수를 사용하여, 시스템 인증 풀과 caBundleFilecaBundleDir 매개변수로 지정된 인증서를 둘 다 로드할 수 없습니다. 따라서 caBundleFile 또는 caBundleDir을 사용하는 경우, 다음 인증서가 동일한 PEM 파일 ( caBundleFile을 사용하는 경우) 또는 동일한 디렉토리 ( caBundleDir사용 시) 에 있는지 확인하십시오.
프록시 인증서 ( HTTPS 프록시이므로).
로깅 엔드포인트 인증서 (예: https://log-api.newrelic.com/log/v1) 를 참조하십시오.
이 구성은 에이전트를 문제 해결 모드로 설정하지만 로그 전달자( Fluent Bit 기반)는 상세하지 않은 모드에서 계속됩니다.
때로는 로그 전달자 자체에 문제가 있을 수 있습니다. 예를 들어, Windows 로그 이벤트를 전달할 때나 특정 로그 파일에 액세스할 때 특정 채널에 액세스하는 데 문제가 있을 수 있습니다. 이러한 상황에서는 로그 전달자에 대해 자세한 정보 표시 모드를 활성화할 수도 있습니다.
verbose 를 0이외의 값으로 설정하십시오.
구성 옵션 trace: ["log.fw"]을 추가하십시오.
주의
[fluentbit] 옵션을 사용 중인지 확인하십시오. verbose: 3및trace: ["log.fw"]을 설정할 때 외부 F유동성 비트 구성 파일에서 stdout 을 가리키는 [OUTPUT] 섹션을 정의하지 않았는지 확인하십시오.
중요
부유 비트의 테일 플러그인은 네트워크 드라이브를 지원하지 않습니다.
2016년 이전 Linux 버전의 경우 OpenSSL 라이브러리를 1.1.0(또는 그 이상)으로 업데이트해야 할 수 있습니다. 이 문제가 있는지 확인하려면:
infra-agent 를 실행하여 유동성 비트를 시작했는지 확인하십시오.
ps -aux | grep td-agent-bit
실행 중이 아니면 /var/db/newrelic-infra/newrelic-integrations/logging으로 이동하여 다음을 실행합니다:
./fluent-bit -i systemd -o stdout
다음 오류가 발생하면 OpenSSL을 1.1.0이상으로 업데이트한다:
error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
Windows에서 로그 전달을 활성화할 때 다음 오류 메시지 중 하나가 나타날 수 있습니다.
The code execution cannot proceed because VCRUNTIME140.dll was not found.
또는
error="exit status 3221225781" process=log-forwarder
많은 양의 파일을 테일링하려고 할 때 다음 오류 메시지 중 하나에 직면하는 것이 일반적입니다.
열려 있는 파일이 너무 많음
inotify 감시의 총 수에 대한 사용자 제한에 도달했거나 커널이 필요한 리소스를 할당하지 못했습니다.
운영 체제는 할당 가능한 파일 디스크립터의 최대량 (일반적으로 1024기본) 및 최대 할당 가능한 Inotify 시계 (일반적으로 기본적으로 8192) 를 정의합니다. 위의 오류 중 하나를 리턴하여 이러한 한계를 넘으려는 모든 프로세스가 실패합니다.
로그를 전달하는 데 사용하는 기본 기술인 Fluent Bit 은 하나의 파일 설명자를 열고 전달하도록 구성한 각 파일에 대해 inotify 감시를 설정합니다. 게다가, 이 섹션을 작성하는 시점에서 Fluent Bit는 정상 작동을 위해 32개의 추가 파일 디스크립터 세트를 사용하고 종료될 때 또 다른 추가 파일 디스크립터를 사용합니다. 따라서 많은 양의 파일을 캡처하려면 파일 설명자와 inotify 감시 제한이 모두 추적하려는 로그 파일의 양보다 약간 더 큰지 확인해야 합니다 .
다음 지침은 10,000개의 로그 파일을 추적하려는 경우 이러한 제한을 늘리는 방법을 요약합니다. 또한 인프라 에이전트가 root실행 모드 로 설치되어 있다고 가정하므로 root 사용자를 사용하여 실행해야 합니다.
프로세스당 파일 디스크립터의 양에 대한 현재 하드 한계를 확인하십시오. 일반적으로 이 한계는 상당히 높아야 하며 수정할 필요가 없습니다.
ulimit -Hn
/etc/security/limits.conf에 다음 행을 추가하십시오. 10000 대신 여기에 10100 한계를 지정하여 작업해야 할 수 있는 여분의 파일 설명자를 할당할 수 있습니다.
root soft nofile 10100 # replace root by nri-agent for non-root (privileged and unprivileged) installations
다음 행을 /etc/pam.d/common-session 에 추가하여 재시작 시 이전 한계가 적용되도록 하십시오.
session required pam_limits.so
/etc/sysctl.conf 에 다음 행을 추가하여 사용자당 허용되는 Inotify 관측자의 양을 늘리십시오. root 사용자에게 여전히 8192 사용 가능한 Inotify 시계 (기본값) 가 있도록 18192 의 한계를 10000 으로 지정했습니다.
fs.inotify.max_user_watches=18192
시스템을 다시 시작하십시오.
다음을 실행하여 새 한계가 적용되었는지 확인하십시오.
ulimit -Sn # Should return 10100
cat /proc/sys/fs/inotify/max_user_watches # Should return 18192
버전 1.19.0 (또는 SLES 12.5의 경우 버전 1.20.3 ) 이전에 Linux 인프라 에이전트가 유동성 비트 바이너리로 번들되었습니다. 이 버전에서 시작하여, F넉넉 Bit는 이제 별도의 recommended 패키지 종속성으로 포함됩니다.
이는 에이전트와 별도로 유동성 비트를 설치, 업데이트 또는 다운그레이드할 수 있음을 의미합니다. 사용자의 편의를 위해 인프라가 생활하는 동일한 저장소에 여러 개의 부유한 비트 패키지를 포함시켰으므로, 유동성 있는 비트를 업그레이드하기 위해 추가 저장소를 설치할 필요가 없습니다.
에이전트는 사용 가능한 최신 버전을 사용하여 처음 설치할 때 Fluent Bit를 자동으로 설치합니다. 처음 설치한 후에는 일반적으로 Linux 패키지를 사용하는 것처럼 Fluent Bit를 업그레이드할 수 있습니다.
다음을 실행하여 사용 가능한 여유 비트 버전을 나열할 수 있습니다.
예:
sudo yum check-update
yum list td-agent-bit --showduplicates
뎁:
sudo apt update
apt-cache showpkg td-agent-bit
특정 F부유층 Bit 버전으로 업그레이드하려면 다음 예제에서는 1.8.12 버전이 사용됩니다.
예:
# Remove command only required when downgrading to a previous version