Logging for DNS Services
IBM Cloud services, such as DNS Services, generate platform logs that you can use to investigate abnormal activity and critical actions in your account, and troubleshoot problems.
You can use IBM Cloud Logs Routing, a platform service, to route platform logs in your account to a destination of your choice by configuring a tenant that defines where platform logs are sent. For more information, see About Logs Routing.
You can use IBM Cloud Logs to visualize and alert on platform logs that are generated in your account and routed by IBM Cloud Logs Routing to an IBM Cloud Logs instance.
As of 28 March 2024, the IBM Log Analysis service is deprecated and will no longer be supported as of 30 March 2025. Customers will need to migrate to IBM Cloud Logs before 30 March 2025. During the migration period, customers can use IBM Log Analysis along with IBM Cloud Logs. Logging is the same for both services. For information about migrating from IBM Log Analysis to IBM Cloud Logs and running the services in parallel, see migration planning.
Locations where platform logs are generated
DNS Services generates platform logs to IBM Log Analysis in the regions indicated in the following table.
Dallas (us-south) |
Washington (us-east) |
Toronto (ca-tor) |
Sao Paulo (br-sao) |
|---|---|---|---|
| No | No | No | No |
Tokyo (jp-tok) |
Sydney (au-syd) |
Osaka (jp-osa) |
Chennai (in-che) |
|---|---|---|---|
| No | No | No | No |
Frankfurt (eu-de) |
London (eu-gb) |
Madrid (eu-es) |
|---|---|---|
| Yes | No | No |
Locations where logs are sent to IBM Log Analysis
DNS Services sends platform logs to IBM Log Analysis in the regions indicated in the following table.
Dallas (us-south) |
Washington (us-east) |
Toronto (ca-tor) |
Sao Paulo (br-sao) |
|---|---|---|---|
| No | No | No | No |
Tokyo (jp-tok) |
Sydney (au-syd) |
Osaka (jp-osa) |
Chennai (in-che) |
|---|---|---|---|
| No | No | No | No |
Frankfurt (eu-de) |
London (eu-gb) |
Madrid (eu-es) |
|---|---|---|
| Yes | No | No |
Locations where logs are sent by IBM Cloud Logs Routing
DNS Services sends logs by IBM Cloud Logs Routing in the regions that are indicated in the following table.
Dallas (us-south) |
Washington (us-east) |
Toronto (ca-tor) |
Sao Paulo (br-sao) |
|---|---|---|---|
| No | No | No | No |
Tokyo (jp-tok) |
Sydney (au-syd) |
Osaka (jp-osa) |
Chennai (in-che) |
|---|---|---|---|
| No | No | No | No |
Frankfurt (eu-de) |
London (eu-gb) |
Madrid (eu-es) |
|---|---|---|
| Yes | No | No |
Platform logs that are generated
The following three types of platform logs are generated for DNS services:
link_zone_action- Logs are created during key steps of the process of linking a zone between DNS Services instances. This includes when a request to link is created, and when the link is granted access. Learn more about cross-account access.
health_check_event- Logs are created when there is critical activity regarding a healthcheck appliance. These logs can be related to the status of the appliance VSI itself, or to any of the origins that the healthcheck is monitoring. Learn more about creating a health check.
custom_resolver_event- Logs are created when there is critical activity regarding custom resolvers. Activities such as create and delete events for custom resolver locations and status updates of the locations all fall under this category.Learn more about working with custom resolvers.
Viewing logs
Launching IBM Cloud Logs from the Observability page
For more information about launching the IBM Cloud Logs UI, see Launching the UI in the IBM Cloud Logs documentation.
Fields by log type
For information about fields included in every platform log, see Fields for platform logs.
| Field | Type | Description |
|---|---|---|
logSourceCRN |
Required | Defines the account and DNS Services instance where the log is published. |
saveServiceCopy |
Required | Defines whether IBM saves a copy of the record for operational purposes. |
message |
Required | Description of the log that is generated. |
messageID |
Required | ID of the log that is generated. |
msg_timestamp |
Required | The timestamps when the log is generated. |
resolution |
Optional | Guidance on how to proceed if you receive this log record. |
documentsURL |
Optional | More information on how to proceed if you receive this log record. |
Analyzing DNS Services logs
linked_zones_action logs
Notable fields:
permitted_network- Identifies the permitted network that is being granted access to the linked zone.
requestor_info- Contains the account, instance, and zone information of the requestor.
Common messages to look for:
-
"Linked DNS zone <zone ID> under instance <instance ID> is approved by zone owner"- indicates that a request to link a zone was approved. -
"The permitted network <VPC ID> on linked dns zone <zone ID> under instance <instance ID>"' is removed by zone owner- indicates that a previously allowed linked zone has been revoked.
health_check_event logs
Notable fields:
pool:healthy- The overall health status of the pool being monitored.
origins:health_status_code- The health status of each origin configured in the pool.
Common messages to look for:
"The healthy status of origin <origin name> is changed to <UP/DOWN>"- This indicates that the healthcheck for a given pool has identified a change in response from a given origin. Health status changes to the DOWN state should be monitored as they can indicate issues with either a configured network or origin.
custom_resolver_event logs
Notable fields:
id- An identifier for the custom resolver.
healthy- Overall health status of the custom resolver.
locations:healthy- Health status of individual custom resolver locations.
Common messages to look for:
"The status of custom resolver location <id> is changed from <up/down> to <up/down>"- This message indicates that a custom resolver appliance has changed health status. This can be due a planned maintenance/update or from a unexpected outage.