[ Datadog ] SSH Check

Z CARE 수정 날짜: 목, 2월 29, 2024 시간: 10:09 AM

SSH Check 활용
구성 시 고려사항
SSH Check Integration 설정
- Linux
- Windows
- Kebernetes
SSH Check Monitor 설정

SSH Check 활용

SAN 스위치를 포함한 모니터링의 사각에 있는 장비의 상태 점검을 위해 SSH를 활용합니다.
SSH Check Integration은 개선 과제의 내용과 동일 효과의 기능 제공합니다.

구성 시 고려사항

모니터링 대상 장비와 네트워크 통신 가능한 Host
Datadog Agent에 구성되며 Host 모니터링 목적 외의 추가로 발생할 부하를 고려하여 서비스 중요도가 낮은 Host의 Agent 선정합니다.
Note: 대상 instances를 과도하게 등록하는 경우 Agent의 오버헤드 발생할 수 있으므로, 호스트 당 최대 4개 까지 등록하는 것을 권장합니다.

SSH Check Integration 설정

Linux

설정파일 경로: /etc/datadog-agent/conf.d/ssh_check.d/conf.yaml

conf.yaml 설정 예

init_config:

instances:
  - host: "<SOME_REMOTE_HOST>"                      # required
    username: "<SOME_USERNAME>"                     # required
    password: "<SOME_PASSWORD>"                     # or use private_key_file
    add_missing_keys: true                          # default is False
    min_collection_interval: 15                     # 수집 주기. default 15로 주기 변경 필요 시 설정
    # private_key_file: <PATH_TO_PRIVATE_KEY>       # private_key_type:                                                # rsa or ecdsa; default is rsa
    # port: 22                                      # default is port 22
    # sftp_check: false                             # set False to disable SFTP check; default is True

private_key_file의 경로는 datadog 계정(dd-agent 혹은 ddagentuser)가 접속가능한 경로 및 권한 필요기존에 사용하는 ssh 접속용 id_rsa파일을 필요 경로에 복사하여 사용
```
instances:
  - host: "<SOME_REMOTE_HOST>"
    ......
    private_key_file: /opt/datadog-agent/id_rsa
```
Checks type의 Integration은 check_runners 모듈(default: 4)의 관리를 받으며 instances를 과도하게 등록하는 경우 Agent의 오버헤드가 발생 할 수 있습니다.

설정 후 Agent 재기동

sudo systemctl restart datadog-agent.service

*참고링크: SSH Integration

Windows

설정파일 경로 : C:\ProgramData\Datadog\conf.d\ssh_check.d\conf.yaml
Datadog Agent Manager 에서 변경시 :
Checks > Manage Checks 메뉴에서 상단 select box를 Edit Enabled Checks로 선택,
목록에 ssh_check.d/conf.yaml 를 선택합니다.
목록에 없는경우 상단 select box를 Add a check를 선택 한 후 ssh_check 를 선택 후
우측에 Add Check를 선택하면 Edit Enabled Check 목록에 ssh_check.d/conf.yaml가 추가 됩니다.

conf.yaml 설정 예

init_config:

instances:
  - host: "<SOME_REMOTE_HOST>"                      # required
    username: "<SOME_USERNAME>"                     # required
    password: "<SOME_PASSWORD>"                     # or use private_key_file
    add_missing_keys: true                          # default is False
    min_collection_interval: 15                     # 수집 주기. default 15로 주기 변경 필요 시 설정
    # private_key_file: <PATH_TO_PRIVATE_KEY>       # private_key_type:                                                # rsa or ecdsa; default is rsa
    # port: 22                                      # default is port 22
    # sftp_check: false                             # set False to disable SFTP check; default is True

private_key_file의 경로는 datadog 계정(dd-agent 혹은 ddagentuser)가 접속가능한 경로 및 권한 필요기존에 사용하는 ssh 접속용 id_rsa파일을 필요 경로에 복사하여 사용
```
instances:
  - host: "<SOME_REMOTE_HOST>"
    ......
    private_key_file: C:\ProgramData\Datadog\id_rsa
```
Checks type의 Integration은 check_runners 모듈(default: 4)의 관리를 받으며 instances를 과도하게 등록하는 경우 Agent의 오버헤드가 발생 할 수 있습니다.

설정 후 Agent 재기동
Windows CMD Prompt를 관리자모드로 실행한 뒤 아래 command를 실행합니다.
```
"%ProgramFiles%\Datadog\Datadog Agent\bin\agent.exe" restart-service
```

*참고링크: SSH Integration

Kebernetes

ConfigMap 으로 등록하며, values.yaml의 confd에 추가 후 helm 배포하는 것을 권고
confd 설정 전 values.yaml에 ‘useConfigMap: true’으로 설정 필요

values.yaml 파일 내 confd 설정 예

confd: 
 
    ssh_check.yaml: |-
      init_config:
      instances:
        - host: "<SOME_REMOTE_HOST>"          # required
          username: "<SOME_USERNAME>"         # required
          password: "<SOME_PASSWORD>"         # or use private_key_file
          add_missing_keys: true              # default is False

Checks type의 Integration은 check_runners 모듈(default: 4)의 관리를 받으며 instances를 과도하게 등록하는 경우 Agent의 오버헤드가 발생 할 수 있습니다.

설정 후 Agent 재기동
변경된 values.yaml 재배포

helm upgrade -f values.yaml <RELEASE_NAME> datadog/datadog

*참고Link : SSH Integration, Kubernetes 통합 자동 탐지

SSH Check Monitor 설정

Service Check Alert 설정을 진행합니다.

메뉴 경로: Monitors > New Monitor > Service Check

Service Check Monitor 구성
① Pick a Service Check
- 모니터링 가능한 Service Check 대상 선택. 이 경우 ssh.can_connect 선택 합니다.
② Pick monitor scope: Tag 기반의 범위 설정
- 모니터링 범위 설정
: 동일 Service Check이 갖고 있는 전체 host부터 tag 기반의 범위 선택 지원 합니다.
Scope의 조건을 선택 시는 AND 조건의 로직으로 동작 합니다.
전체 host를 대상으로 할 시 ‘All Monitored Hosts’로 선택 하시면 됩니다.
- Excluding 조건 적용
: Tag 기반의 제외 범위 선택을 지원 합니다.
Excluding 조건 적용 시에는 OR 조건의 로직으로 동작 합니다.
③ Set alert conditions: alert 발생 조건 설정
▶ Aelrt 발생 조건 설정
- SSH Check를 Monitor를 설정 시에는 Check Alert으로 선택 합니다.
a. Check Alert : 단일 Service 별 alert 발생 조건 설정. 연속 alert 실패 회수로 조정.
b. Cluster Alert : Cluster 그룹 내 Service Check 실패 비율로 alert 발생 조건 설정
▶ Alert 발생 group by 조건 설정.
- Host를 선택합니다.
▶ Alert 발생 및 해소 조건 설정
- Critical/OK 상태가 되는 조건 설정 합니다.
- Critical에는 연속 실패 횟수를 / OK에는 성공 횟수를 선택.
- Critical은 연속 5회로 선택(5번 연속 실패 시 Alert이 발생함)
▶ Do not notify / Notify 설정
- 데이터 수집이 없을 시 알림에 대한 설정 입니다.
- Default는 ‘Do not notify’ 이며, Nofiy 로 설정 시 설정된 시간 동안 데이터가 없는 경우
Nodata 알람이 발생합니다.
▶ Alert 자동 Resolve 설정
- Alert 발생 후 상황이 해제되어 resolve가 되지 않아 Alert 상태가 지속되는 경우
설정된 시간이 지나면 자동적으로 resolve 처리를 하는 기능입니다.
- Default는 ‘Never’로 자동 resolve를 하지 않습니다. 자동 resolve 처리를 하시려면
시간을 선택하시면 됩니다.
④ Notify your team: 전파 설정

▶ Alert Title
- 알람 발생시 전파되는 Message의 제목입니다.
- 예시 : [SSH Check][심각] {{host.name}} ssh의 응답이 없습니다.
▶ Alert Message
- 알람 발생시 전파되는 Message의 내용입니다.
- 예시

발생시간(ST): {{local_time 'last_triggered_at' 'Asia/Seoul'}}

[심각] {{host.name}} ssh가 연속 5회 응답이 없습니다. 확인 하시기 바랍니다.

발생시간(KST): {{local_time 'last_triggered_at' 'Asia/Seoul'}}

[심각 해제] {{host.name}} ssh의 응답이 정상으로 돌아왔습니다.

▶ Use Message Template Variables
- Alert title과 Message 본문에 사용 가능한 Template 및 변수 사용법을 확인할 수 있습니다.
▶ Notify your services and your team members 설정
- opsgenie / slack / TEAMS / webhook 등 integration된 채널 및 email 등의 Noti 채널이 표시됩니다.
알람을 전파할 채널 혹은 대상 email을 설정하시기 바랍니다.
▶ Content displayed 설정(Message 구성 내용 설정)
- query / snapshot 등 자동 추가되는 내용을 Message에 포함 할지 여부 설정 합니다.
▶ Include Triggering tags in notification title 설정
- 알람 발생시 전파되는 Message의 제목에 알람이 발생된 대상에 대한 tag를 표시합니다.
▶ Aggregation 설정
- SSH check 대상 host 별로 알람을 발생시키므로 Multi Alert - Host 가 선택되어야 합니다.
▶ Renotification 설정
- Alert(Warning) 혹은 Nodata가 지속될 경우 선택한 시간마다 재알람을 전파합니다.
▶ Tags 설정
- Manage Monitors 에서 조회시, Downtime schedule 설정시 사용가능한
moniotor를 위한 Tag를 설정합니다.
▶ Priority 설정
- P1~P5로 알람의 심각도(중요도) 등을 설정합니다.

⑤ Define permission and audit notifications

▶ Restrict editing 설정
- Alert에 대한 수정 권한을 설정합니다.
Role 선택시 해당 role을 가진 User들은 모두 수정이 가능합니다
▶ Test Notifications
- 버튼을 클릭하면 설정된 내용을 선택한 채널로 Test 알람을 발송합니다.
▶ Create
- 버튼을 클릭하면 설정된 내용을 저장합니다.

Korean