Monitoring 에이전트 문제 해결

이 페이지는 Monitoring 에이전트의 설치 또는 실행 문제를 진단하는 데 도움이 됩니다.

참고: Linux 가상 머신(VM)에 다음 메시지가 표시되면 무시해도 무방합니다.

Need to set
  STACKDRIVER_API_KEY in /etc/sysconfig/stackdriver Not starting. Configuration
  error.

이 메시지는 점진적으로 교체 중인 기존 서비스에서 보내는 메시지로서 심각한 문제가 아니며 나중에 없어집니다.

체크리스트

Monitoring 에이전트를 설치하거나 사용하는 데 문제가 있는 경우 다음 사항을 확인하세요.

Linux 설치 명령어에서 오류가 발생하면 설치 명령어의 프리픽스가 sudo인지 확인합니다.
에이전트 서비스가 VM 인스턴스에서 실행되는지 확인합니다.
- Windows VM의 경우 다음 PowerShell 명령어를 사용합니다.
```
Get-Service -Name StackdriverMonitoring
```
  Stackdriver Monitoring이라는 서비스를 검색합니다. 에이전트가 실행되고 있지 않으면 에이전트를 다시 시작해야 할 수도 있습니다.
- Linux VM의 경우 다음 명령어를 사용합니다.
```
sudo service stackdriver-agent status
```
  에이전트가 실행되고 있지 않으면 다음 명령어를 사용하여 다시 시작해야 할 수 있습니다.
```
sudo service stackdriver-agent restart
```
  다시 시작할 수 없고 로그 출력에 '메타데이터를 통해 사용 중지됨'이 표시되면 Monitoring 에이전트가 기본적으로 사용 중지된 Google Cloud Marketplace에서 이미지가 실행되고 있을 가능성이 있습니다. 이 문제는 google-monitoring-enable 인스턴스 메타데이터 키(값 0)로 제어됩니다. 에이전트를 다시 사용 설정하려면 이 키를 삭제하거나 값을 1로 설정합니다(인스턴스 메타데이터 설정 참조).
  
  에이전트가 메타데이터를 통해 사용 중지되지 않으면 에이전트를 다시 설치합니다. 이 프로세스에 대한 자세한 내용은 Monitoring 에이전트 다시 설치를 참조하세요.
에이전트가 로그에 오류 메시지를 작성했는지 확인합니다.
- Windows의 경우 Monitoring 에이전트는 Windows 이벤트 로그에 메시지를 작성합니다.
- Linux에서 Monitoring 에이전트는 collectd 패키지이며 /var/log/syslog 또는 /var/log/messages에 메시지를 로깅합니다. 로그 메시지에는 collectd 또는 stackdriver-agent라는 프리픽스가 붙습니다.
  - HTTP 429 오류가 발생하는 경우 Monitoring API 할당량을 초과했을 수 있습니다. Google Cloud 콘솔에서 API 및 서비스 > 대시보드를 선택하여 사용 가능한 할당량을 확인할 수 있습니다. Monitoring API를 선택합니다.
  - 프록시 문제가 발생하는 경우 HTTP 프록시를 올바르게 구성했는지 확인합니다. Linux 및 Windows에 설치의 안내를 참조하세요.
  - API 액세스 또는 승인 문제가 발생하거나 'collectd 엔드포인트를 확인할 수 없음'과 같은 오류 메시지가 나타나는 경우 다음에 나오는 프로젝트 및 사용자 인증 정보 확인 섹션을 참조하세요.
  - 로그에 '지원되지 않는 collectd 플러그인/유형 조합' 또는 '지원되지 않는 collectd id'와 같은 오류가 있는 경우 지원되지 않는 에이전트 측정항목을 전송 중일 수 있습니다. 다음과 같은 경우 이 오류가 발생할 수 있습니다.
    - 에이전트 타사 애플리케이션 구성 중 하나를 수정했습니다. 변경사항을 되돌리려면 관련 문서 페이지의 안내에 따라 특정 플러그인의 구성을 다시 설치하면 됩니다. 에이전트를 사용하여 해당 측정항목을 Monitoring으로 전송하려면 사용자 정의 측정항목으로 변환하는 것이 좋습니다.
    - 타사 애플리케이션 플러그인 중 하나가 Monitoring에 알 수 없는 새 측정항목을 전송하고 있습니다. 이러한 측정항목을 검토하고 분류하는 요청을 제출하는 방법에 대한 자세한 내용은 지원 페이지를 참조하세요.
에이전트가 정상적으로 실행되는 것 같지만 데이터가 없거나 알림 정책이 예상대로 작동하지 않는 경우 에이전트가 올바른 프로젝트에 데이터를 전송하고 있는지 확인해야 합니다. 다음에 나오는 프로젝트 및 사용자 인증 정보 확인 섹션을 참조하세요.

프로젝트 및 사용자 인증 정보 확인

Monitoring 에이전트가 액세스 또는 승인 오류를 보고하거나, 에이전트가 정상적으로 실행되는 것 같지만 데이터가 없거나, 알림 정책이 예상대로 작동하지 않는 경우 올바른 프로젝트가 지정되었는지, 그리고 VM 인스턴스의 사용자 인증 정보가 올바른지 확인해야 합니다.

비공개 키가 아닌 표준 사용자 인증 정보로 Compute Engine VM 인스턴스를 사용하고 있는 경우 데이터가 잘못된 프로젝트로 갈 가능성은 없지만 사용자 인증 정보가 부족할 수 있습니다. 사용자 인증 정보에 대한 자세한 내용은 Monitoring 에이전트 승인을 참조하세요. 사용자 인증 정보를 확인하려면 Compute Engine 사용자 인증 정보 확인을 참조하세요.
Amazon EC2 VM 인스턴스를 사용하고 있거나, Compute Engine 인스턴스에 비공개 키 사용자 인증 정보를 사용하고 있는 경우 사용자 인증 정보가 유효하지 않거나 잘못된 프로젝트에서 가져온 것일 수 있습니다. AWS 계정의 경우 에이전트에서 사용하는 프로젝트는 측정항목을 전송하는 Google Cloud 프로젝트여야 합니다. 사용자 인증 정보에 대한 자세한 내용은 Monitoring 에이전트 승인을 참조하세요. 사용자 인증 정보를 확인하려면 비공개 키 사용자 인증 정보 확인을 참조하세요.

그래도 문제가 해결되지 않으면 Monitoring 에이전트 다시 설치를 참조하세요.

Compute Engine 사용자 인증 정보 확인하기

Google Cloud 콘솔의 Compute Engine VM 인스턴스 페이지를 사용하여 Compute Engine VM 인스턴스가 Monitoring 에이전트에 적절한 사용자 인증 정보를 갖고 있는지 확인합니다. 사용자 인증 정보는 대개 모든 새 Compute Engine VM 인스턴스의 기본 서비스 계정에 추가되지만 인스턴스를 만들 때 이러한 기본값을 덮어쓸 수 있습니다.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동

검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Compute Engine인 결과를 선택합니다.

필요한 경우 현재 Google Cloud 프로젝트를 Compute Engine VM 인스턴스와 연결된 프로젝트로 변경합니다. 예를 들어 결제 사용 설정 메시지가 나타나면 현재 프로젝트에 Compute Engine VM 인스턴스가 없는 것입니다.
VM 인스턴스 페이지에서 VM 인스턴스의 이름을 클릭합니다. VM 인스턴스의 세부정보 페이지가 나타납니다.
VM 인스턴스 세부정보 페이지에서 Cloud API 액세스 범위 제목 아래를 봅니다.
- '모든 Cloud APIs에 대한 전체 액세스 허용'이 표시되면 적절한 사용자 인증 정보가 있는 것입니다.
- Cloud Monitoring API의 이전 이름인 Stackdriver Monitoring API 옆에 쓰기 전용 또는 전체 권한이 있는 것으로 표시되면 적절한 사용자 인증 정보가 있는 것입니다.
- 그렇지 않으면 에이전트에 필요한 사용자 인증 정보가 인스턴스의 기본 서비스 계정에 없는 것입니다. 인스턴스에서 에이전트를 사용하려면 비공개 키 서비스 계정 사용자 인증 정보를 추가해야 합니다. 사용자 인증 정보 추가의 안내를 참조하세요.

올바른 기본 사용자 인증 정보가 있으면 Linux 및 Windows에 설치로 건너뜁니다.

비공개 키 사용자 인증 정보 확인

VM 인스턴스에 유효한 비공개 키 사용자 인증 정보가 설치되어 있는지 확인하려면 먼저 사용자 인증 정보 파일이 예상 위치에 있는지 확인한 다음 사용자 인증 정보 파일의 정보가 유효한지 확인합니다. Google Cloud 콘솔의 IAM 및 관리자 > 서비스 계정 섹션을 사용하여 이전의 유효 사용자 인증 정보를 취소할 수 있습니다. 유효한 사용자 인증 정보가 없는 경우 사용자 인증 정보 추가를 참조하여 기존 사용자 인증 정보를 바꾸거나 새로 추가합니다.

사용자 인증 정보가 있나요?

비공개 키 서비스 계정 사용자 인증 정보가 인스턴스에 있는지 확인하려면 인스턴스에서 다음 Linux 명령어를 실행합니다.

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

두 명령어 중 하나가 다음과 같은 파일을 표시하면 인스턴스에 유효한 비공개 키 사용자 인증 정보가 있는 것입니다. 두 명령어 모두 파일을 표시하면 GOOGLE_APPLICATION_CREDENTIALS가 나타내는 파일이 사용됩니다.

{
  "type": "service_account",
  "project_id": "{your-project-id}",
  "private_key_id": "{your-private-key-id}",
  "private_key": "{your-private-key}",
  "client_email": "{your-project-number}-{your-key}@developer.gserviceaccount.com",
  "client_id": "{your-client-id}",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

사용자 인증 정보 파일이 없는 경우 사용자 인증 정보 추가를 참조하세요.

사용자 인증 정보가 유효한가요?

사용자 인증 정보 파일에서 project_id 필드는 Google Cloud 프로젝트이고, client_email은 프로젝트의 서비스 계정을 식별하고, private_key_id는 서비스 계정의 비공개 키를 식별합니다. 이 정보를 Google Cloud 콘솔의 IAM 및 관리자 > 서비스 계정 섹션에 표시된 정보와 비교합니다.

다음 중 하나에 해당하는 경우 사용자 인증 정보가 유효하지 않습니다.

Compute Engine VM 인스턴스를 확인하고 있지만 사용자 인증 정보 파일의 Google Cloud 프로젝트가 인스턴스를 포함하는 프로젝트가 아닙니다.
Amazon EC2 인스턴스를 확인하고 있지만 사용자 인증 정보 파일의 Google Cloud 프로젝트가 AWS 계정에서 측정항목을 전송하는 Google Cloud 프로젝트가 아닙니다.
나열된 서비스 계정이 존재하지 않습니다. 삭제되었을 수 있습니다.
나열된 서비스 계정에 사용 설정된 올바른 역할이 없습니다. 서비스 계정에 최소한 측정항목 수집을 위한 roles/monitoring.metricWriter(모니터링 측정항목 작성자)와 로그 작성을 위한 roles/logging.logWriter(로그 작성자)가 있어야 합니다.
비공개 키가 없습니다. 취소되었을 수 있습니다.

서비스 계정에 문제가 없지만 비공개 키가 취소된 경우 새 비공개 키를 만들어 인스턴스에 복사할 수 있습니다. 그렇지 않으면 다음에 나오는 사용자 인증 정보 추가 섹션의 설명에 따라 새 서비스 계정을 만들어야 합니다.

새 사용자 인증 정보 생성

사용자 인증 정보가 유효하지 않은 경우 다음 단계를 따르세요.

비공개 키로 승인해야 하는 인스턴스가 포함된 연결된 각 프로젝트(https://www.googleapis.com/auth/monitoring.write 액세스 범위를 포함하지 않고 생성된 Compute Engine 인스턴스가 포함된 각 프로젝트)에서 서비스 계정을 만들고 아직 비공개 키가 없으면 비공개 키를 생성합니다. 아래 단계를 따르세요.
1. Google Cloud 콘솔에서 설정 페이지로 이동합니다.
  설정으로 이동
  
  검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
2. Netric 범위 탭을 선택합니다.
3. 해당 Compute Engine 리소스가 포함된 프로젝트를 식별하고 Google Cloud 콘솔로 이동합니다.
4. Google Cloud 콘솔의 IAM 서비스 계정 페이지로 이동하여 Google Cloud 프로젝트를 선택하고 새 서비스 계정을 만든 다음 해당 서비스 계정의 비공개 키를 새로 생성합니다.
  이 단계를 수행하려면 다음 중 하나를 따릅니다.
  - IAM 서비스 계정 페이지로 이동하여 Google Cloud 프로젝트를 선택한 다음 서비스 계정 만들기의 단계를 따르세요.
    
    IAM 서비스 계정으로 이동
  - 다음 버튼을 클릭한 후 Google Cloud 프로젝트를 선택합니다.
    
    서비스 계정 만들기 및 키 다운로드
    
    이전 버튼은 키를 만들고 에이전트별 서비스 계정의 로컬 시스템에 다운로드하는 프로세스를 자동화합니다. 또한 필요한 경우 프로세스가 필요한 서비스 계정을 만들고 서비스 계정에 올바른 권한이 있는지 확인합니다. 에이전트 특정 서비스 계정에는 stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com과 비슷한 이름이 사용됩니다. 다음과 같은 대화상자를 통해 이 작업이 완료되었다는 알림을 받습니다.
  참고: 서비스 계정은 최대 10개의 키를 사용할 수 있습니다. 자세한 내용은 한도를 참조하세요.
문제의 서비스 계정에 해당하는 인스턴스에서 비공개 키를 바꿉니다.
- Linux의 경우 /etc/google/auth/application_default_credentials.json에 있는 비공개 키를 바꿉니다.
- Windows의 경우 C:\ProgramData\Google\Auth\application_default_credentials.json에 있는 비공개 키를 바꿉니다. 자세한 내용은 인스턴스에 비공개 키 복사를 참조하세요.
에이전트 다시 시작
- Linux의 경우 sudo service stackdriver-agent restart를 실행합니다.
- Windows의 경우 서비스 관리 콘솔로 이동하고 Cloud Monitoring 서비스를 다시 시작합니다.

새 비공개 키가 필요한 프로젝트가 여러 개인 경우 각 프로젝트에 대해 이 절차를 반복합니다.

비공개 키가 올바른지 확인하려면 사용자 인증 정보가 있나요?를 참조하세요. 구체적으로는 다음과 같습니다.

인스턴스의 비공개 키 JSON 파일을 읽습니다. 예: sudo cat /etc/google/auth/application_default_credentials.json(Linux의 경우)
project_id 필드의 값이 사용자 인증 정보를 생성한 모니터링 프로젝트의 값과 일치하는지 확인합니다.

에이전트 데이터 확인하기

에이전트가 측정항목을 올바르게 전송하고 있는지 확인하려면 Monitoring API의 timeSeries.list 메서드를 사용하여 VM 인스턴스의 최근 시계열 데이터를 찾습니다. 메서드의 문서 페이지에서 API 탐색기를 사용하여 메서드를 호출할 수 있습니다. 데이터가 표시되지 않으면 에이전트가 잘못된 프로젝트에 데이터를 전송하고 있을 가능성이 있습니다. 이를 확인하려면 프로젝트 및 사용자 인증 정보 확인을 참조하세요.

다음에서는 timeSeries.list 메서드 사용을 자세히 설명합니다.

에이전트를 설치한 VM 인스턴스의 인스턴스 ID를 확인합니다.
- Compute Engine 인스턴스: 인스턴스의 Compute Engine 세부정보 페이지로 이동합니다. 페이지 하단에서 동등한 REST를 클릭합니다. ID는 19자리 숫자입니다.
- Amazon EC2 인스턴스: 각 인스턴스의 ID가 인스턴스 목록에 표시됩니다. ID는 i-1a2b3c4d와 같습니다.
timeSeries.list 메서드의 문서 페이지로 이동합니다.
API 탐색기 양식을 작성합니다.
1. VM 인스턴스를 포함하는 프로젝트로 이름을 설정합니다. 이때 projects/를 프리픽스로 사용합니다. 예를 들면 projects/[YOUR_PROJECT_ID]입니다.
2. 필터를 다음 줄로 설정하여 VM 인스턴스에서 에이전트 측정항목을 선택합니다. 에이전트 측정항목을 복사하여 API 탐색기에 붙여넣은 다음 VM 인스턴스 ID를 변경합니다.
```
metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"
```
3. 검색 시간 간격을 설정합니다. 약 5분 간격이 적당합니다.
  - interval.endTime을 time.is/GMT에서 확인할 수 있는 현재 GMT 시간으로 설정합니다. 시간 형식은 다음 예시와 같아야 합니다. 시간을 큰따옴표로 묶지 마세요.
```
2016-10-31T14:10:00Z
```
  - 동일한 형식을 사용하여 interval.startTime을 종료 시간 약 5분 전으로 설정합니다.
4. 다른 필드는 모두 비워 둡니다.
실행을 클릭합니다.

다음과 같은 출력이 표시되어야 합니다.

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

위와 같이 API 호출이 VM 인스턴스의 시계열 데이터를 반환하는 경우 에이전트가 제대로 작동하고 있는 것이므로 사용자가 더 이상 수행할 작업은 없습니다.

시계열 데이터가 표시되지 않는 경우 다음을 확인합니다.

API 호출로 인해 오류 메시지가 표시되더라도 에이전트 문제는 아닙니다. API 탐색기 필드가 올바르게 입력됐는지 확인합니다.
- '잘못된 인수' 오류는 프로젝트 ID, 필터 또는 두 가지 타임스탬프의 철자와 형식에 문제가 있을 수 있음을 나타냅니다.
  
  타임스탬프 인수 요구사항은 지정한 측정항목 유형에 따라 다릅니다. 측정항목 유형은 GAUGE, DELTA 또는 CUMULATIVE 데이터를 기록합니다. 자세한 내용은 MetricKind를 참조하세요.
  
  DELTA 측정항목과 CUMULATIVE 측정항목에는 시작 시간과 종료 시간 모두 필요하며 종료 시간은 시작 시간 이후여야 합니다. 이러한 측정항목 유형 종류는 시간 경과에 따라 측정된 변경사항을 기록하므로 시작 시간과 종료 시간에서는 0이 아닌 간격을 정의해야 합니다.
- '승인되지 않음' 오류는 프로젝트 ID의 철자가 잘못되었을 수 있음을 나타냅니다.
- '찾을 수 없음' 오류는 '이름' 필드에 필수 projects/ 프리픽스가 생략되어 있을 수 있음을 나타냅니다.
문제를 수정하고 API 호출을 다시 시도하세요.
API 호출은 성공했지만 빈 응답({ })만 표시되면 필터와 시간 간격이 올바른지 확인합니다. 타임스탬프 형식이 잘못된 경우 데이터가 반환되지 않습니다. 아무 문제도 없어 보이지만 데이터가 없는 경우 에이전트가 측정항목 데이터를 전송하고 있지 않거나 사용자 예상과 다른 프로젝트에 데이터를 전송하고 있는 것입니다. 이는 사용자 인증 정보 문제를 의미하는 것일 수 있습니다. 비공개 키 사용자 인증 정보 확인을 참조하세요.

Monitoring 에이전트 다시 설치

최신 버전의 에이전트를 설치하면 많은 문제가 해결됩니다.

사용자 인증 정보 관련 문제가 아닌 경우에는 Linux에 설치 및 Windows에 설치로 건너뛸 수 있습니다.
에이전트 전체 설치와 필요한 사용자 인증 정보에 대해서는 Monitoring 에이전트 설치를 참조하세요.

에이전트가 설치된 Linux VM 확인

다음 쿼리를 실행하여 에이전트를 실행 중인 Linux VM을 확인합니다.
- API 탐색기
- 측정항목 탐색기
각 쿼리에 대해 프로젝트 이름을 입력하고 시간 범위를 조정해야 합니다.

자동으로 에이전트 다시 시작

에이전트가 실행 중인지 확인한 후 다운된 경우 에이전트를 다시 시작하도록 스크립트를 설정할 수 있습니다.

예를 들어 Linux에서 다음 crontab 항목을 만들어 5분마다 에이전트 상태를 확인할 수 있습니다.

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

알려진 문제

다음 섹션에서는 Monitoring 에이전트에 알려진 문제를 설명합니다.

데이터 액세스 문제 처리(Windows)

Windows 이벤트 로그에 다음과 유사한 에이전트 오류 메시지가 표시될 수 있습니다.

Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)

이 메시지는 에이전트가 사용자 시스템에서 이 데이터에 액세스할 수 없음을 나타냅니다. 이 메시지가 표시되지 않도록 하려면 SYSTEM 사용자가 오류 메시지에 나열된 프로세스 및 서비스의 프로세스 데이터를 읽을 수 있도록 충분한 권한을 제공할 수 있습니다. 이 데이터가 필요하지 않으면 이 정보 제공용 메시지를 무시해도 안전합니다.

메타데이터 캐시 문제(Linux)

Linux 시스템 로그 파일(Debian/Ubuntu의 경우 /var/log/syslog 또는 Red Hat/CentOS/SLES의 /var/log/messages)에 다음과 유사한 오류 메시지가 표시될 수 있습니다.

collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
value time = 1511345468.180; last cache update = 1511345468.180;
write_gcm: wg_update_stats failed.
write_gcm: uc_update returned an error.

이러한 메시지는 무해한 경고이며 데이터 손실을 나타내는 것은 아닙니다. 이러한 메시지는 타임스탬프 불일치가 있을 때 현재 프로세스 플러그인 구현에 의해 생성됩니다.

무한 값 데이터 포인트 삭제 문제(Linux)

Linux 시스템 로그 파일(Debian/Ubuntu의 경우 /var/log/syslog 또는 Red Hat/CentOS/SLES의 /var/log/messages)에 다음과 유사한 오류 메시지가 표시될 수 있습니다.

write_gcm: can not take infinite value

이 메시지는 형식이 잘못된 단일 데이터 포인트가 삭제되었음을 나타냅니다. 이는 일반적으로 무해하며 무시해도 됩니다.

메타데이터 키 제한 문제(Linux)

Linux 시스템 로그 파일(Debian/Ubuntu의 경우 /var/log/syslog 또는 Red Hat/CentOS/SLES의 /var/log/messages)에 다음과 유사한 오류 메시지가 표시될 수 있습니다.

collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed

이 메시지는 메모리 제한 상태 업데이트가 한 번 실패했음을 나타냅니다. 이는 일반적으로 무해하지만 에이전트의 메모리 부족 상태를 나타내는 징후일 수 있으며 자주 발생하는 경우 특히 더 그렇습니다.

Cloud Monitoring API 할당량 부족 문제(Linux)

Linux 시스템 로그 파일(Debian/Ubuntu의 경우 /var/log/syslog 또는 Red Hat/CentOS/SLES의 /var/log/messages)에 다음과 유사한 오류 메시지가 표시될 수 있습니다.

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

이 메시지는 Cloud Monitoring API 할당량 한도에 도달했음을 나타냅니다. 할당량 한도 관리에 대한 자세한 내용은 할당량 가이드를 참조하세요.

낮은 `COLLECTD_INTERVAL`로 인한 높은 메모리 사용량(Linux)

COLLECTD_INTERVAL이 10 seconds와 같이 기본값 60 seconds보다 짧게 구성된 경우 에이전트 메모리 사용량이 높게 표시될 수 있습니다. 이것은 단일 스레드에서 직렬로 요청을 전송하기 때문에 발생하는 에이전트의 알려진 제한사항입니다. 이 문제를 해결하기 위해서는 필요한 측정항목으로만 COLLECTD_INTERVAL을 줄이고 나머지 측정항목은 기본 간격 그대로 두는 것이 좋습니다.

토큰 버퍼 오버플로 문제(Linux)

Linux 시스템 로그 파일(Debian/Ubuntu의 경우 /var/log/syslog 또는 Red Hat/CentOS/SLES의 경우 /var/log/messages)에 다음과 유사한 오류 메시지가 표시될 수 있습니다.

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

이러한 메시지는 6.1.2 버전 이상으로 모니터링 에이전트를 업그레이드해야 함을 나타냅니다.

저장소가 'Origin' 값(Linux)을 변경함

Debian/Ubuntu Linux에서 에이전트 업그레이드, 에이전트 설치 또는 apt-get update 실행 시 다음과 유사한 오류 메시지가 표시될 수 있습니다.

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

이 메시지는 Package Repository 캐시가 소스에서 분기되었을 수 있음을 나타냅니다. 이를 해결하려면 다음 명령어를 실행합니다.

apt-get --allow-releaseinfo-change update

그런 다음 업그레이드를 실행하거나 다시 설치합니다.

Google Cloud 콘솔에서 설치된 것으로 보고된 에이전트를 삭제했음

에이전트를 제거한 후 Google Cloud 콘솔에서 이 변경사항을 보고하는 데 최대 1시간이 걸릴 수 있습니다.

Monitoring 에이전트가 Windows 제거 프로그램 목록에 표시되지 않음

Windows 제어판의 프로그램 제거 목록에 표시되지 않는 Monitoring 에이전트를 제거하려면 에이전트를 설치한 디렉터리에서 uninstall.exe를 실행합니다.

Monitoring 에이전트 문제 해결

체크리스트

프로젝트 및 사용자 인증 정보 확인

Compute Engine 사용자 인증 정보 확인하기

비공개 키 사용자 인증 정보 확인

사용자 인증 정보가 있나요?

사용자 인증 정보가 유효한가요?

새 사용자 인증 정보 생성

에이전트 데이터 확인하기

Monitoring 에이전트 다시 설치

에이전트가 설치된 Linux VM 확인

자동으로 에이전트 다시 시작

알려진 문제

데이터 액세스 문제 처리(Windows)

메타데이터 캐시 문제(Linux)

무한 값 데이터 포인트 삭제 문제(Linux)

메타데이터 키 제한 문제(Linux)

Cloud Monitoring API 할당량 부족 문제(Linux)

낮은 COLLECTD_INTERVAL로 인한 높은 메모리 사용량(Linux)

토큰 버퍼 오버플로 문제(Linux)

저장소가 'Origin' 값(Linux)을 변경함

Google Cloud 콘솔에서 설치된 것으로 보고된 에이전트를 삭제했음

Monitoring 에이전트가 Windows 제거 프로그램 목록에 표시되지 않음

낮은 `COLLECTD_INTERVAL`로 인한 높은 메모리 사용량(Linux)