운영 에이전트 데이터 수집 문제 해결

이 문서에서는 실행 중인 운영 에이전트에서 로그 및 측정항목에 대한 데이터 수집 문제를 진단하고 해결하는 데 도움이 되는 정보를 제공합니다. 운영 에이전트가 실행되고 있지 않으면 설치 및 시작 문제 해결을 참조하세요.

시작하기 전에

문제 해결을 시도하기 전에 에이전트의 상태 점검 상태를 확인하세요.

Google Cloud 콘솔에서 운영 에이전트 설치가 '대기중' 상태로 멈춰 있음

운영 에이전트를 성공적으로 설치한 후에도 Google Cloud 콘솔에 여전히 '대기 중' 상태가 표시될 수 있습니다. gcpdiag를 사용하여 운영 에이전트 설치를 확인하고 에이전트가 VM 인스턴스에서 로그 및 측정항목을 전송하는지 확인합니다.

설치 실패의 일반적인 이유

다음과 같은 이유로 운영 에이전트 설치가 실패할 수 있습니다.

VM에 연결된 서비스 계정이 없는 경우. VM에 서비스 계정을 연결한 다음 운영 에이전트를 재설치합니다.
VM에 이미 레거시 에이전트 중 하나가 설치되어 있어 운영 에이전트를 설치할 수 없는 경우. 레거시 에이전트를 제거한 다음 운영 에이전트를 다시 설치합니다.

원격 분석 전송 실패의 일반적인 이유

설치 및 실행 중인 운영 에이전트는 다음과 같은 이유로 VM에서 로그, 측정항목, 또는 둘 다를 전송하지 못할 수 있습니다.

VM에 연결된 서비스 계정에 roles/logging.logWriter 또는 roles/monitoring.metricWriter 역할이 누락된 경우.
로깅 또는 모니터링 액세스 범위가 사용 설정되지 않은 경우. 액세스 범위를 확인하고 업데이트하는 방법에 대한 정보는 액세스 범위 확인을 참조하세요.
Logging API 또는 Monitoring API가 활성화되지 않은 경우

에이전트 상태 점검을 이용하여 근본 원인과 해당하는 해결책을 파악하세요.

에이전트가 실행 중이지만 데이터가 수집되지 않음

측정항목 탐색기를 사용하여 에이전트 uptime 측정항목을 쿼리하고, 에이전트 구성요소 google-cloud-ops-agent-metrics 또는 google-cloud-ops-agent-logging이 측정항목에 작성하고 있는지 확인합니다.

Google Cloud 콘솔에서 측정항목 탐색기 페이지로 이동합니다.
측정항목 탐색기로 이동

검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
빌더 코드 라벨이 지정된 전환 버튼에서 코드를 선택한 후 언어를 MQL로 설정합니다.

다음 쿼리를 입력한 다음 실행을 클릭합니다.

fetch gce_instance
| metric 'agent.googleapis.com/agent/uptime'
| align rate(1m)
| every 1m

에이전트가 Cloud Logging으로 로그를 전송하나요?

에이전트가 실행 중이지만 로그를 전송하지 않으면 에이전트 런타임 상태 점검의 상태를 확인합니다.

파이프라인 오류

런타임 오류 LogPipelineErr('운영 에이전트 로깅 파이프라인 실패')이 표시되면 Logging 하위 에이전트에 로그 작성 관련 문제가 발생한 것입니다. 다음 조건을 확인하세요.

Logging 하위 에이전트의 스토리지 파일에 액세스할 수 있는지 확인합니다. 다음 위치에서 이러한 파일을 찾을 수 있습니다.
- Linux: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
- Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
VM 디스크가 가득 찼는지 확인합니다.
로깅 구성이 올바른지 확인합니다.

이들 단계에서는 SSH를 통해 VM에 연결해야 합니다.

로깅 구성을 변경하거나 버퍼 파일에 액세스할 수 있고 VM 디스크가 가득 차지 않은 경우 운영 에이전트를 다시 시작합니다.

Linux

에이전트를 다시 시작하려면 인스턴스에서 다음 명령어를 실행합니다.
```
sudo systemctl restart google-cloud-ops-agent
```
에이전트가 다시 시작되었는지 확인하려면 다음 명령어를 실행하고 '측정항목 에이전트' 및 'Logging 에이전트' 구성요소가 시작되었는지 확인합니다.
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

RDP 또는 유사한 도구를 사용하여 인스턴스에 연결하고 Windows에 로그인합니다.
PowerShell 아이콘을 마우스 오른쪽 버튼으로 클릭하고 관리자 권한으로 실행을 선택하여 관리자 권한이 있는 PowerShell 터미널을 엽니다.
에이전트를 다시 시작하려면 다음 PowerShell 명령어를 실행합니다.
```
Restart-Service google-cloud-ops-agent -Force
```
에이전트가 다시 시작되었는지 확인하려면 다음 명령어를 실행하고 '측정항목 에이전트' 및 'Logging 에이전트' 구성요소가 시작되었는지 확인합니다.
```
Get-Service google-cloud-ops-agent*
```

로그 파싱 오류

런타임 오류 LogParseErr('운영 에이전트에서 로그를 파싱할 수 없음')이 표시되면 로깅 프로세서 구성에서 문제가 발생한 가능성이 가장 높습니다. 이 문제를 해결하려면 다음을 수행합니다.

parse_json 프로세서 구성이 올바른지 확인합니다.
parse_regex 프로세서 구성이 올바른지 확인합니다.
parse_json 또는 parse_regex 프로세서가 없으면 다른 로깅 프로세서의 구성을 확인합니다.

이들 단계에서는 SSH를 통해 VM에 연결해야 합니다.

로깅 구성을 변경하는 경우 운영 에이전트를 다시 시작합니다.

Linux

에이전트를 다시 시작하려면 인스턴스에서 다음 명령어를 실행합니다.
```
sudo systemctl restart google-cloud-ops-agent
```
에이전트가 다시 시작되었는지 확인하려면 다음 명령어를 실행하고 '측정항목 에이전트' 및 'Logging 에이전트' 구성요소가 시작되었는지 확인합니다.
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

RDP 또는 유사한 도구를 사용하여 인스턴스에 연결하고 Windows에 로그인합니다.
PowerShell 아이콘을 마우스 오른쪽 버튼으로 클릭하고 관리자 권한으로 실행을 선택하여 관리자 권한이 있는 PowerShell 터미널을 엽니다.
에이전트를 다시 시작하려면 다음 PowerShell 명령어를 실행합니다.
```
Restart-Service google-cloud-ops-agent -Force
```
에이전트가 다시 시작되었는지 확인하려면 다음 명령어를 실행하고 '측정항목 에이전트' 및 'Logging 에이전트' 구성요소가 시작되었는지 확인합니다.
```
Get-Service google-cloud-ops-agent*
```

로컬 측정항목 확인

이들 단계에서는 SSH를 통해 VM에 연결해야 합니다.

로깅 모듈이 실행 중인가요? 다음 명령어를 사용하여 확인합니다.

Linux

sudo systemctl status google-cloud-ops-agent"*"

Windows

관리자 권한으로 Windows PowerShell을 열고 다음을 실행합니다.

Get-Service google-cloud-ops-agent

서비스 앱에서 서비스 상태를 확인하고 작업 관리자 앱에서 실행 중인 프로세스를 검사할 수도 있습니다.

로깅 모듈 로그 확인

이 단계에서는 VM에 SSH를 통해 연결해야 합니다.

Linux는 /var/log/google-cloud-ops-agent/subagents/*.log, Windows는 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log에서 로깅 모듈 로그를 찾을 수 있습니다. 로그가 없으면 에이전트 서비스가 제대로 실행되고 있지 않다는 것을 의미합니다. 에이전트가 설치되었지만 실행되고 있지 않음 섹션으로 이동하여 해당 조건을 수정합니다.

Logging API에 작성할 때 403 권한 오류가 발생할 수 있습니다. 예를 들면 다음과 같습니다.

[2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error
{
"error": {
  "code": 403,
  "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
  "status": "PERMISSION_DENIED",
  "details": [
    {
      "@type": "type.googleapis.com/google.rpc.Help",
      "links": [
        {
          "description": "Google developers console API activation",
          "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769"
        }
      ]
    }
  ]
}
}

이 오류를 해결하려면 Logging API를 사용 설정하고 로그 작성자 역할을 설정합니다.

Logging API의 할당량 문제가 발생할 수 있습니다. 예를 들면 다음과 같습니다.

error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"

이 오류를 해결하려면 할당량을 늘리거나 로그 처리량을 줄이세요.

모듈 로그에 다음과 같은 오류가 표시될 수 있습니다.
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
또는
```
can't fetch token from the metadata server
```
이러한 오류는 서비스 계정이나 지정된 사용자 인증 정보가 없는 에이전트를 배포했다는 의미일 수 있습니다. 이 문제 해결에 대한 자세한 내용은 운영 에이전트 승인을 참조하세요.

에이전트가 Cloud Monitoring으로 측정항목을 전송하나요?

측정항목 모듈 로그 확인

이 단계에서는 VM에 SSH를 통해 연결해야 합니다.

syslog에서 측정항목 모듈 로그를 찾을 수 있습니다. 로그가 없으면 에이전트 서비스가 제대로 실행되고 있지 않음을 나타냅니다. 에이전트가 설치되었지만 실행되고 있지 않음 섹션으로 이동하여 해당 조건을 수정합니다.

Monitoring API에 기록할 때 PermissionDenied 오류가 표시될 수 있습니다. 이 오류는 운영 에이전트의 권한이 제대로 구성되지 않은 경우에 발생합니다. 예를 들면 다음과 같습니다.

Nov  2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}

이 오류를 해결하려면 Monitoring API를 사용 설정하고 Monitoring 측정항목 작성자 역할을 설정합니다.

Monitoring API에 기록할 때 ResourceExhausted 오류가 표시될 수 있습니다. 이 오류는 프로젝트가 Monitoring API 할당량 한도에 도달할 때 발생합니다. 예를 들면 다음과 같습니다.

Nov  2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}

이 오류를 해결하려면 할당량을 늘리거나 측정항목 처리량을 줄이세요.

모듈 로그에 다음과 같은 오류가 표시될 수 있습니다.
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
또는
```
can't fetch token from the metadata server
```
이러한 오류는 서비스 계정이나 지정된 사용자 인증 정보가 없는 에이전트를 배포했다는 의미일 수 있습니다. 이 문제 해결에 대한 자세한 내용은 운영 에이전트 승인을 참조하세요.

네트워크 연결 문제

에이전트가 실행 중이지만 로그와 측정항목이 모두 전송되지 않으면 네트워킹 문제가 발생할 수 있습니다. 발생할 수 있는 네트워킹 연결 문제의 종류는 애플리케이션의 토폴로지에 따라 다릅니다. Compute Engine 네트워킹의 개요는 VM의 네트워킹 개요를 참조하세요.

연결 문제의 일반적인 원인은 다음과 같습니다.

수신 트래픽을 방해하는 방화벽 규칙. 방화벽 규칙에 대한 자세한 내용은 VPC 방화벽 규칙 사용을 참조하세요.
HTTP 프록시 구성의 문제
DNS 구성

운영 에이전트는 네트워크 연결 오류를 감지하는 상태 점검을 실행합니다. 연결 오류에 대해 수행할 수 있는 권장 작업은 상태 점검 문서를 참조하세요.

운영 에이전트 버전 2.28.0부터 운영 에이전트는 버퍼 청크를 저장하는 데 사용할 수 있는 디스크 공간을 제한합니다. 운영 에이전트는 로깅 데이터를 Cloud Logging API로 전송할 수 없는 경우 버퍼 청크를 만듭니다. 제한이 없으면 이 청크가 사용 가능한 공간을 모두 차지해 VM의 다른 서비스를 방해할 수 있습니다. 네트워크 중단으로 버퍼 청크가 디스크에 기록될 때 운영 에이전트는 플랫폼별 디스크 공간을 사용하여 청크를 저장합니다. 다음 예시와 같은 메시지가 Linux VM의 /var/log/google-cloud-ops-agent/subagents/logging-module.log 또는 Windows VM의 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log에 VM이 Cloud Logging API에 버퍼 청크를 전송할 수 없는 경우 표시됩니다.

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

측정항목 또는 로그 둘 중 하나만 수집하려는 경우

기본적으로 운영 에이전트는 측정항목과 로그를 모두 수집합니다. 측정항목 또는 로그 수집을 사용 중지하려면 기본 파이프라인에 수신자가 포함되지 않도록 운영 에이전트 config.yaml 파일을 사용하여 기본 logging 또는 metrics 서비스를 재정의합니다. 자세한 내용은 다음을 참조하세요.

운영 에이전트 하위 에이전트 서비스 'Logging 에이전트' 또는 'Monitoring 에이전트'를 사용 중지하여 데이터 수집을 중지하면 지원되지 않는 잘못된 구성이 발생합니다.

측정항목을 수집 중이지만 문제가 발생함

에이전트에서 '내보내기 실패. 재시도' 메시지가 로깅됨

누적 측정항목의 첫 번째 데이터 포인트가 삭제되면 '내보내기 실패' 로그 항목이 표시됩니다. 다음 로그는 유해하지 않으므로 무시해도 됩니다.

  Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:25:18.061-07:00": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/uptime'.", "interval": "23.491024535s"}
  Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:26:18.061-07:00": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/monitoring/point_count'.", "interval": "21.556591578s"}

에이전트에서 '시계열을 기록할 수 없음: 포인트를 순서대로 기록해야 합니다' 메시지가 로깅됨

기존 Monitoring 에이전트에서 운영 에이전트로 업그레이드했으며 누적 측정항목을 작성할 때 다음 오류 메시지가 표시되는 경우 해결 방법은 VM을 재부팅하는 것입니다. 운영 에이전트와 Monitoring 에이전트는 누적 측정항목의 시작 시간을 다르게 계산하므로 포인트가 잘못된 순서로 표시될 수 있습니다. VM을 재부팅하면 시작 시간이 재설정되고 이 문제가 해결됩니다.

  Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
  Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
  One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
  gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}

에이전트에서 '토큰은 단기 토큰(60분)이고 합당한 기간 이내여야 합니다' 메시지가 로깅됨

에이전트가 측정항목을 쓸 때 다음 오류 메시지가 표시되면 시스템 시계가 올바르게 동기화되지 않은 것입니다.

  Invalid JWT: Token must be a short-lived token (60 minutes) and in a
  reasonable timeframe. Check your iat and exp values in the JWT claim.

시스템 시계 동기화에 대해서는 VM에서 NTP 구성을 참조하세요.

에이전트에서 "nvml" 유형의 측정항목 수신자를 지원하지 않습니다'가 로깅됨

nvml 수신자를 사용하여 NVIDIA Management Library(NVML) GPU 측정항목(agent.googleapis.com/gpu)을 수집하는 경우 NVML 측정항목 미리보기를 지원하는 운영 에이전트 버전을 한 것입니다. 이러한 측정항목에 대한 지원은 일반적으로 운영 에이전트 버전 2.38.0에서 제공됩니다. GA 버전에서는 nvml 수신자에서 수행된 측정항목 컬렉션이 hostmetrics 수신자에 병합되고 nvml 수신자가 삭제되었습니다.

미리보기 nvml 수신자를 사용했고 사용자 지정 구성 파일에 기본 수집 간격을 재정의한 경우 운영 에이전트 버전 2.38.0 이상을 설치하면 "nvml" 유형의 측정항목 수신지를 지원하지 않습니다'라는 오류 메시지가 표시됩니다. 이 오류는 nvml 수신자가 더 이상 존재하지 않지만 사용자 지정 구성 파일에서 계속 참조하기 때문에 발생합니다.

이 문제를 해결하려면 대신 hostmetrics 수신자에서 수집 간격을 재정의하도록 사용자 지정 구성 파일을 업데이트합니다.

GPU 측정항목이 누락됨

운영 에이전트에서 일부 측정항목을 수집하지만 NVIDIA Management Library(NVML) GPU(agent.googleapis.com/gpu) 측정항목이 일부 또는 전부 누락된 경우 구성에 문제가 있거나 GPU를 사용하는 프로세스가 없을 수 있습니다.

어떠한 GPU 측정항목도 수집되지 않으면 GPU 드라이버를 확인합니다. 운영 에이전트에서 GPU 측정항목을 수집하려면 VM에 GPU 드라이버를 설치하고 구성해야 합니다. 드라이버를 확인하려면 다음을 수행합니다.

드라이버가 설치되어 올바르게 실행 중인지 확인하려면 다음 단계를 수행하여 GPU 드라이버가 설치되어 있는지 확인합니다.

드라이버가 설치되지 않으면 다음을 수행합니다.

GPU 드라이버를 설치합니다.
운영 에이전트를 다시 시작합니다.

GPU 드라이버를 설치하거나 업그레이드한 후에는 운영 에이전트를 다시 시작해야 합니다.

운영 에이전트 로그를 확인하여 통신이 성공적으로 시작되었는지 확인합니다. 로그 메시지는 다음과 유사합니다.

Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.

GPU 드라이버가 설치되었고 운영 에이전트 로그에 운영 에이전트가 드라이버와 통신하고 있다고 표시되지만 GPU 측정항목이 표시되지 않는 경우 사용 중인 차트의 문제일 수 있습니다. 차트 문제 해결 방법은 차트에 데이터가 표시되지 않음을 참조하세요.

일부 GPU 측정항목을 수집하고 있지만 processes 측정항목(processes/max_bytes_used 및 processes/utilization)이 누락된 경우 GPU에서 실행 중인 프로세스가 없는 것입니다. GPU에서 실행 중인 프로세스가 없으면 GPU processes 측정항목이 수집되지 않습니다.

일부 측정항목이 누락되거나 일관되지 않음

운영 에이전트 버전 2.0.0 이상은 일부 측정항목을 '미리보기' 버전의 운영 에이전트(2.0.0 미만 버전) 또는 Monitoring 에이전트와 다르게 처리합니다.

다음 표에서는 운영 에이전트와 Monitoring 에이전트에서 수집된 데이터의 차이를 설명합니다.

측정항목 유형, `agent.googleapis.com` 생략	운영 에이전트(GA)^†	운영 에이전트(미리보기)^†	Monitoring 에이전트
`cpu_state`	Windows에 가능한 값은 `idle`, `interrupt,` `system`, `user`입니다.	Windows에 가능한 값은 `idle`, `interrupt,` `system`, `user`입니다.	Windows에 가능한 값은 `idle`, `used`입니다.
`disk/bytes_used` 및 `disk/percent_used`	`device` 라벨의 전체 경로로 수집됨(예: `/dev/sda15`) `tmpfs` 및 `udev`와 같은 가상 기기에는 수집되지 않음	`device` 라벨의 경로에서 `/dev` 없이 수집됨(예: `sda15`) `tmpfs` 및 `udev`와 같은 가상 기기에서 수집됨	`device` 라벨의 경로에서 `/dev` 없이 수집됨(예: `sda15`) `tmpfs` 및 `udev`와 같은 가상 기기에서 수집됨

^† GA 열은 운영 에이전트 버전 2.0.0 이상을 나타냅니다. 미리보기 열은 운영 에이전트 버전 2.0.0 미만을 나타냅니다.

Windows 고유 문제

다음 섹션은 Windows에서 실행되는 운영 에이전트에만 적용됩니다.

Windows에서 손상된 성능 카운터

측정항목 하위 에이전트가 시작되지 않으면 Cloud Logging에 다음 오류 중 하나가 표시될 수 있습니다.

Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"

이 오류는 시스템의 성능 카운터가 손상되면 발생할 수 있습니다. 성능 카운터를 다시 빌드하여 오류를 해결할 수 있습니다. PowerShell에서 관리자 권한으로 다음을 실행합니다.

cd C:\Windows\system32
lodctr /R

이전 명령어는 가끔 실패할 수 있습니다. 이 경우 PowerShell을 새로고침하고 성공할 때까지 다시 시도하세요.

명령어가 성공하면 운영 에이전트를 다시 시작합니다.

Restart-Service -Name google-cloud-ops-agent -Force

에이전트 상태를 완전히 재설정

에이전트가 복구 불가능한 상태로 전환되면 다음 단계를 수행하여 에이전트를 초기 상태로 복원합니다.

Linux

에이전트 서비스를 중지합니다.

sudo service google-cloud-ops-agent stop

에이전트 패키지를 삭제합니다.

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo

디스크에서 에이전트의 자체 로그를 삭제합니다.

sudo rm -rf /var/log/google-cloud-ops-agent

디스크에서 에이전트의 로컬 버퍼를 삭제합니다.

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

참고: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ 디렉터리에는 다음 유형의 파일이 포함됩니다.

버퍼 파일: 이러한 파일은 운영 에이전트에서 테일링되고 처리되었지만 아직 Cloud Logging에 수집되지 않은 버퍼링된 로그 항목입니다. 손상된 청크가 있으면 운영 에이전트는 2.15.0 이상 버전에서 이를 건너뛰어야 합니다. 경우에 따라 수동으로 삭제해야 합니다. 이러한 파일은 /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*과 같은 중첩 폴더에 저장됩니다.
로그 파일 테일링 위치 파일: 이러한 파일은 운영 에이전트에서 이미 테일링한 로그 파일의 위치를 기록합니다. 이러한 파일이 삭제되면 운영 에이전트는 테일링하도록 구성된 파일의 맨 위부터 시작합니다. 이 파일을 삭제하면 이전에 해당 로그가 성공적으로 수집된 경우에 로그 중복이 발생할 수 있습니다. 이러한 파일은 /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*와 같은 디렉터리에 파일로 직접 저장됩니다.

이전 명령어의 .../buffers/*/ 문법은 버퍼 파일만 삭제되도록 합니다. 위치 파일은 삭제되지 않습니다.

에이전트를 재설치하고 다시 시작합니다.

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart

Windows

에이전트 서비스를 중지합니다.

Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";

에이전트 패키지를 삭제합니다.

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"

디스크에서 에이전트의 자체 로그를 삭제합니다.

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";

디스크에서 에이전트의 로컬 버퍼를 삭제합니다.

Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}

에이전트를 재설치하고 다시 시작합니다.

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"

버퍼 파일을 저장하면서 재설정

VM에 손상된 버퍼 청크가 없는 경우(즉, 운영 에이전트의 자체 로그 파일에 format check failed 메시지가 없는 경우) 에이전트 상태를 재설정할 때 로컬 버퍼를 삭제하는 이전 명령어를 건너뛸 수 있습니다.

VM에 손상된 버퍼 청크가 있으면 이를 삭제해야 합니다. 다음 옵션에서는 버퍼를 처리하는 여러 가지 방법을 설명합니다. 에이전트 상태 완전 재설정에 설명된 다른 단계는 여전히 적용 가능합니다.

옵션 1: buffers 디렉터리 전체를 삭제합니다. 가장 쉬운 옵션이지만 위치 파일이 손실되므로 손상되지 않은 버퍼링된 로그가 손실되거나 로그 중복이 발생할 수 있습니다.

Linux
```
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers
```
Windows
```
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
```
옵션 2: buffers 디렉터리에서 버퍼 하위 디렉터리를 삭제하지만 위치 파일을 그대로 둡니다. 이 방법은 에이전트 상태를 완전히 재설정에 설명되어 있습니다.

옵션 3: 모든 버퍼 파일을 삭제하지는 않으려면 에이전트의 자체 로그에서 손상된 버퍼 파일의 이름을 추출하여 손상된 버퍼 파일만 삭제하면 됩니다.

Linux

grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f

Windows

$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};

옵션 4: 손상된 버퍼가 많고 모든 로그 파일을 다시 처리하려면 옵션 3의 명령어를 사용하여 로그 파일별로 운영 에이전트 진행 상황을 저장하는 위치 파일도 삭제하면 됩니다. 위치 파일을 삭제하면 이미 성공적으로 수집된 모든 로그에 로그 중복이 발생할 수 있습니다. 이 옵션은 현재 로그 파일만 다시 처리합니다. 이미 순환된 파일이나 다른 소스(예: TCP 포트)의 로그를 다시 처리하지 않습니다. 위치 파일은 buffers 디렉터리에 저장되지만 파일로 저장됩니다. 로컬 버퍼는 buffers 디렉터리에 하위 디렉터리로 저장됩니다.

Linux

grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete

Windows

$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};
Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}

최근 운영 에이전트 출시 버전의 알려진 문제

다음 섹션에서는 최근 운영 에이전트 출시 버전에 대한 알려진 문제를 설명합니다.

운영 에이전트 버전 2.47.0, 2.48.0, 2.49.0 비정상 종료 루프

버전 2.47.0, 2.48.0, 2.49.0에 로깅에 대해 잘못된 FluentBit 구성요소가 포함되었습니다. 이 구성요소가 특정 로그 줄에서 실패하여 운영 에이전트의 비정상 종료 루프를 일으킵니다.

이 문제는 운영 에이전트 버전 2.50.0에서 해결되었습니다.

Prometheus 측정항목 네임스페이스가 운영 에이전트 버전 2.46.0부터 인스턴스 ID 외에 인스턴스 이름도 포함함

운영 에이전트 버전 2.46.0부터 Prometheus 수집 형식으로 측정항목을 수집할 때 namespace 라벨의 일부로 VM 이름이 포함됩니다. 이전 버전에서 Prometheus 측정항목은 namespace 라벨의 일부로 VM의 인스턴스 ID만 사용했지만 버전 2.46.0부터는 namespace가 INSTANCE_ID/INSTANCE_NAME으로 설정됩니다.

namespace 라벨을 사용하는 차트, 대시보드, 알림 정책이 있으면 운영 에이전트를 버전 2.46.0 이상으로 업그레이드한 후 쿼리를 업데이트해야 할 수 있습니다. 예를 들어 PromQL 쿼리가 http_requests_total{namespace="123456789"}과 같은 경우 namespace 라벨이 INSTANCE_ID/INSTANCE_NAME 형식이기 때문에 http_requests_total{namespace=~"123456789.*"}로 변경해야 합니다.

운영 에이전트 버전 2.39.0부터 유형화되지 않은 Prometheus 측정항목에서 측정항목 유형 변경

버전 2.39.0부터 운영 에이전트에서 알 수 없는 유형의 Prometheus 측정항목을 수집할 수 있습니다. 이전 버전에서 이러한 측정항목은 운영 에이전트에서 게이지로 취급되지만 버전 2.39.0부터는 유형화되지 않은 측정항목이 게이지 및 카운터로 취급됩니다. 이제 사용자는 이러한 측정항목에 대한 누적 작업을 사용할 수 있게 되었습니다.

MQL을 사용하여 유형화되지 않은 Prometheus 측정항목을 쿼리하는 차트, 대시보드 또는 알림 정책이 있는 경우 운영 에이전트를 버전 2.39.0 이상으로 업그레이드한 후 MQL 쿼리를 업데이트해야 합니다. 유형화되지 않은 측정항목을 prometheus.googleapis.com/METRIC_NAME/gauge로 쿼리하는 대신 측정항목 유형을 다음과 같이 변경합니다.

측정항목의 게이지 버전에 prometheus.googleapis.com/METRIC_NAME/unknown을 사용합니다.
측정항목의 카운터 버전에 prometheus.googleapis.com/METRIC_NAME/unknown:counter를 사용합니다.

PromQL을 사용하여 유형화되지 않은 Prometheus 측정항목을 쿼리하는 차트, 대시보드 또는 알림 정책을 변경할 필요는 없지만 운영 에이전트를 버전 2.39.0 이상으로 업그레이드한 후 이러한 측정항목에 누적 작업을 적용할 수 있습니다.

Windows VM에서 높은 메모리 사용량(버전 2.27.0~2.29.0)

Windows의 운영 에이전트 버전 2.27.0~2.29.0에서는 에이전트에서 소켓이 누수되는 원인이 되는 버그로 인해 메모리 사용량이 증가하고 fluent-bit.exe 프로세스에서 처리하는 핸들이 많아졌습니다.

이 문제를 해결하려면 버전 2.30.0 이상으로 운영 에이전트를 업그레이드하고 에이전트를 다시 시작합니다.

Windows에서 이벤트 로그 시간대가 잘못됨(버전 2.15.0~2.26.0)

VM의 시간대를 UTC에서 변경하는 경우 Cloud Logging의 Windows 이벤트 로그와 연결된 타임스탬프가 잘못될 수 있습니다. 이 문제는 운영 에이전트 2.27.0에서 수정되었지만 알려진 Windows 높은 메모리 문제로 인해 만일 이 문제를 접하는 경우에는 최소한 Ops Agent 2.30.0 이상으로 업그레이드하는 것이 좋습니다. 업그레이드할 수 없는 경우 다음 해결 방법 중 하나를 시도해 볼 수 있습니다.

UTC 시간대 사용

PowerShell에서 다음 명령어를 관리자로 실행합니다.

Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

로깅 하위 에이전트 서비스의 시간대 설정만 재정의

PowerShell에서 다음 명령어를 관리자로 실행합니다.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Windows에서 파싱된 타임스탬프의 시간대가 잘못됨(2.27.0 이전 버전).

타임스탬프를 파싱하는 로그 프로세서를 사용하면 Windows에서 시간대 값이 올바르게 파싱되지 않습니다. 이 문제는 운영 에이전트 2.27.0에서 수정되었지만 알려진 Windows 높은 메모리 문제로 인해 만일 이 문제를 접하는 경우에는 최소한 Ops Agent 2.30.0 이상으로 업그레이드하는 것이 좋습니다.

이전 운영 에이전트 출시 버전의 알려진 문제

다음 섹션에서는 이전 운영 에이전트 출시 버전에서 발생하는 것으로 알려진 문제를 설명합니다.

해롭지 않은 로그(버전 2.9.1 이하)

유사 프로세스 또는 제한된 프로세스에서 측정항목을 스크랩할 때 오류가 표시될 수 있습니다. 다음 로그는 유해하지 않으므로 무시해도 됩니다. 이러한 메시지를 제거하려면 운영 에이전트를 버전 2.10.0 이상으로 업그레이드합니다.

    Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z        error        scraperhelper/scrapercontroller.go:205        Error scraping metrics        {"kind"
  : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for
  pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid
  5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r
  eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl
  ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli
  nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli
  nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli
  nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli
  nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli
  nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli
  nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file
   or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file
   or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file
   or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file
   or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file
   or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file
   or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi
  le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc
  h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no
   such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe
  : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500
  /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"}
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186

에이전트 자체 로그에서 CPU, 메모리, 디스크 공간을 너무 많이 소비함(버전 2.16.0 이하)

운영 에이전트 2.17.0 이전 버전은 손상된 버퍼 청크로 인해 Linux VM의 /var/log/google-cloud-ops-agent/subagents/logging-module.log 파일이나 Windows VM의 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log 파일을 통해 CPU, 메모리, 디스크 공간을 많이 소비할 수 있습니다. 이 경우 logging-module.log 파일에 다음과 같은 메시지가 대량으로 표시됩니다.

  [2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb

이 문제를 해결하려면 버전 2.17.0 이상으로 운영 에이전트를 업그레이드하고 에이전트 상태를 완전히 재설정합니다.

시스템에서 여전히 대량의 에이전트 자체 로그가 생성되는 경우 로그 로테이션을 사용하는 것이 좋습니다. 자세한 내용은 로그 로테이션 설정을 참조하세요.