1. NTP Integration setting

How to Setup Linux / Windows 

conf.yaml settings

• When using Local NTP

  init_config:
  instances:
    - use_local_defined_servers: true         ## Local NTP 사용 시 true 변경. (Default)false

• When using a designated NTP server

  init_config:
  instances:
      ## @param host - string - optional
      ## Single NTP server hostname or IP address to connect to.
    - host: OOO.OOO.OOO.OOO             ## NTP 주소를 직접 입력

• Restart Agent after setup
  After changing the settings, you must restart the Datadog Agent for the changes to take effect.

Reference value when setting local NTP

• Linux(UNIX): Refer to /etc/ntp.conf or etc/xntp.conf
• Windows: Refer to HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer
• If the above information is not referenced in Local, it is recognized as Unknown.

How to set up Kubernetes 

Depending on whether the node created by Kubernetes managed service is Linux or Windows OS, you need to check with the cloud provider whether there are ntp-related settings in the path below and whether the local NTP server is officially supported on the worker node of each cloud provider.

## For Unix system, the servers defined in "/etc/{ntp,xntp,ntpd,chrony}.conf" and "/etc/openntpd/ntpd.conf" are used.

## For Windows system, the servers defined in registry key HKLM\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\Parameters\\NtpServer are used.

Datadog Agent Configmap setting

• When using Local NTP
  Add the setting ‘use_local_defined_servers: true’.

• When using a designated NTP server
  If you want to specify the NTP server IP directly, please add the ‘host: <IP information>’ setting.

Helm deployment values.yaml settings

• When using Local NTP (based on Linux node)

  confd: 
      ntp.yaml: |-
        init_config:
        instances:
          - use_local_defined_servers: true
  
  # agents.volumes -- Specify additional volumes to mount in the dd-agent container
  volumeMounts:
       - name: ntp
         mountPath: /etc/ntp.conf
    volumes:
       - name: ntp
         hostPath:
           path: /etc/ntp.conf

• When using a designated NTP server (based on Linux node)

  confd: 
      ntp.yaml: |-
        init_config:
        instances:
          - host: OOO.OOO.OOO.OOO

• After setting, helm chart upgrade (automatically restart Agent pod)

  helm upgrade -f values.yaml <RELEASE NAME> datadog/datadog

2. NTP inspection

NTP can be checked for collection status via Datadog's health check feature, Service Check, and once collected, the ntp.offset metric is collected.

Check Summary Status Check

• Check Summary is a menu that shows summary information of the entire Service Check. Menu path: Monitors > Check Summary

• Check the status of ntp.in_sync as follows.

  • OK : status normal

  • Critical : NTP Offset is different

  • Unknown : ntp.offset not collected

Check your metrics ntp.offset 

• You can check whether the ntp.offset metric is collected in the Summary menu of Metrics.

  

• You can check the ntp.offset metric value in the Explorer menu of Metrics. The collection cycle is 15 minutes.

  

• You can check the basic NTP alert by searching for type:custom or ntp in the search box of Monitors.

• An alarm is generated based on the NTP status values for the last 2 minutes.

  

• For the currently deployed NTP alert rule, it is set to Do not notify for Unknown status, so it is displayed as OK even when in Unknown status.

  

3. NTP Alert setting

Monitors > New Monitor > Service Check It can be set in New, and can be used by modifying the default ‘Clock in sync with NTP’ Monitor.

• Service Check Monitor composition

  

  ① Pick a Service Check
  - Select a Service Check target to monitor. In this case, select ntp.in_sync.

  

  ② Pick monitor scope: Setting the scope based on tags

  

  - Setting the monitoring scope

  : Supports tag-based scope selection from all hosts that the same Service Check has.

  When selecting the scope condition, it operates with AND condition logic.

  If targeting all hosts, select ‘All Monitored Hosts’.

  - Applying the exclusion condition

  : Supports tag-based exclusion range selection.

  When applying the exclusion condition, it operates with OR condition logic.

  ③ Set alert conditions: alert setting conditions for occurrence

  

  ▶ Set Alert occurrence conditions

  - When setting SSH Check to Monitor, select Check Alert.

  a. Check Alert: Set alert occurrence conditions for each single service. Adjust by the number of consecutive alert failures.

  b. Cluster Alert: Set alert occurrence conditions by the service check failure rate within the cluster group

  ▶ Set alert occurrence group by condition.

  - Select Host.

  ▶ Set alert occurrence and resolution conditions

  - Set the conditions for Warning/Critical/OK status.

  - Select the number of consecutive failures for Warning/Critical, and the number of successes for OK.

  - Do not notify / Notify for Unknown status settings are used to generate an alert so that you can be aware of items that are monitored as Unknown.

  ▶ Do not notify / Notify settings

  - This is the setting for notifications when there is no data collection.

  - The default is ‘Do not notify’, and when set to Nofiy, if there is no data for the set time,

  a Nodata alarm occurs.

  ▶ Alert automatic Resolve settings

  - If the Alert status continues because the situation is released and not resolved after the Alert occurs,

  this is a function that automatically resolves after the set time has passed.

  - The default is ‘Never’, which does not automatically resolve. If you want to automatically resolve,

  select the time.

  ④ Notify your team: Radio settings

  

  ▶ Alert Title

  - This is the title of the message transmitted when an alarm occurs.

  ▶ Alert Message

  - This is the content of the message transmitted when an alarm occurs.

  ▶ Use Message Template Variables

  - You can check the templates and variable usage that can be used in the alert title and message body.

  ▶ Notify your services and your team members settings

  - Integrated channels such as opsgenie / slack / TEAMS / webhook and Noti channels such as email are displayed.

  Please set the channel or target email to which the alarm will be transmitted.

  ▶ Content displayed settings (Message configuration content settings)

  - Set whether to include automatically added content such as query / snapshot in the message.

  ▶ Include Triggering tags in notification title settings

  - Display the tag for the target that triggered the alarm in the title of the message transmitted when an alarm occurs.
  ▶ Aggregation settings
  - Since alarms are generated for each SSH check target host, Multi Alert - Host must be selected.
  ▶ Renotification settings
  - If Alert (Warning) or Nodata persists, re-alarms are transmitted at selected times.
  ▶ Tags settings
  - When searching in Manage Monitors, set tags for monitors that can be used when setting the Downtime schedule.
  ▶ Priority settings
  - Set the severity (importance) of alarms from P1 to P5.
  ⑤ Define permission and audit notifications
  

  ▶ Restrict editing settings

  - Set the editing authority for Alert.

  When selecting a role, all users with the corresponding role can edit it.

  ▶ Test Notifications

  - Clicking the button will send a test alarm to the selected channel with the set contents.

  ▶ Create

  - Clicking the button will save the set contents.