Oracle Cloud Infrastructure

이 페이지는 아직 한국어로 제공되지 않으며 번역 작업 중입니다. 번역에 관한 질문이나 의견이 있으시면 언제든지 저희에게 연락해 주십시오.

Overview

Oracle Cloud Infrastructure (OCI) is an infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) used by enterprise-scale companies. With a full suite of managed services for hosting, storage, networking, databases, and more.

Use Datadog’s OCI integration to forward your logs and metrics to Datadog, where they can power dashboards, help with troubleshooting, and be monitored for security and compliance posture.

Setup

Metric collection

To forward your OCI metrics to Datadog:

For a visual representation of this architecture, see the Architecture section.

Enter tenancy info

  • Your OCI user account needs the Cloud Administrator role to complete these steps.

  • Tenancy OCID

  • Home Region

Enter the OCID and home region of the tenancy you want to monitor in the Datadog OCI integration tile.

Create OCI policy stack

Ensure that the home region of the tenancy is selected in the top right of the screen.

This policy stack should only be deployed once per tenancy.

  1. Click the Create Policy Stack button on the Datadog OCI integration tile.
  2. Accept the Oracle Terms of Use.
  3. Leave the option to use custom Terraform providers unchecked.
  4. Use the default name and compartment for the stack, or optionally provide your own descriptive name or compartment.
  5. Click Next.
  6. Name the dynamic group, user group, and policy to be created, or use the default names provided.
  7. Click Next.
  8. Click Create.

Enter DatadogAuthUser info

  • OCID of the DatadogAuthUser

  • OCI API key and fingerprint value

  1. In the OCI console search bar, search for DatadogAuthUser and click on the User resource that appears.
  2. Copy the user’s OCID value.
  3. Paste the value into the User OCID field in the Datadog OCI integration tile.
  4. Returning to the OCI console, generate an API key with these steps:
    a. In the bottom left corner of the screen, under Resources, click API keys.
    b. Click Add API key.
    c. Click Download private key.
    d. Click Add.
    e. A Configuration file preview popup appears, but no action is needed; close the popup.

The Add API Key page in the OCI console

  1. Copy the fingerprint value, and paste it into the Fingerprint field on the Datadog OCI integration tile.
  2. Copy the private key value with these steps:
    a. Open the downloaded private key .pem file in a text editor, or use a terminal command such as cat to display the file’s contents.
    b. Copy the entire contents, including -----BEGIN PRIVATE KEY----- and -----END PRIVATE KEY-----.
  3. Paste the private key value into the Private Key field on the Datadog OCI integration tile.

Create OCI metric forwarding stack

  • Your user account must be able to create resources in the compartment.
  • Datadog API Key value
  • Username and auth token for a user with the REPOSITORY_READ and REPOSITORY_UPDATE permissions to pull and push images to a Docker repo.

Note: To verify the Docker registry login is correct, see Logging in to Oracle Cloud Infrastructure Registry.

The metric forwarding stack must be deployed for each combination of tenancy and region to be monitored. For the simplest setup, Datadog recommends creating all the necessary OCI resources with the ORM stack provided below. Alternatively, you can use your existing OCI networking infrastructure.

All resources created by Datadog’s ORM stack are deployed to the compartment specified, and for the region currently selected in the top right of the screen.

  1. Click the Create Metric Stack button on the Datadog OCI integration tile.
  2. Accept the Oracle Terms of Use.
  3. Leave the Custom providers option unchecked.
  4. Name the stack and select the compartment to deploy it to.
  5. Click Next.
  6. In the Datadog API Key field, enter your Datadog API key value.
    1. In the Network options section, leave Create VCN checked.

    If using an existing VCN, the subnet’s OCID must be provided to the stack. Make sure that the VCN:

    • Is allowed to make HTTP egress calls through NAT gateway.
    • Is able to pull images from OCI container registry using service gateway.
    • Has the route table rules to allow NAT gateway and service gateway.
    • Has the security rules to send HTTP requests.
    1. In the Network options section, uncheck the Create VCN option and enter your VCN information:
      a. In the vcnCompartment field, select your compartment.
      b. In the existingVcn section, select your existing VCN.
      c. In the Function Subnet OCID section, enter the OCID of the subnet to be used.
    1. In the Metrics settings section, optionally remove any metric namespaces from collection.
    2. In the Metrics compartments section, enter a comma-separated list of compartment OCIDs to monitor. Any metric namespace filters selected in the previous step are applied to each compartment.
    3. In the Function settings section, provide an OCI Docker registry user name and auth token in their respective fields. See Getting an Auth Token for more information.
    4. Click Next.
    5. Click Create.
    6. Return to the Datadog OCI integration tile and click Create Configuration.

    Notes:

    • By default, only the root compartment is selected, and all of the metric namespaces supported by the Datadog OCI integration are enabled (up to 50 namespaces are supported per connector hub). If you choose to monitor additional compartments, any metric namespace exclusion filters are applied to each compartment.
    • You should manage who has access to the Terraform state files of the resource manager stacks. See the Terraform State Files section of the Securing Resource Manager page for more information.

    Validation

    View oci.* metrics in the OCI integration overview dashboard or Metrics Explorer page in Datadog.

    OCI function metrics (oci.faas namespace) and container instance metrics (oci_computecontainerinstance namespace) are in Preview.

    Configuration

    Add regions

    To monitor an additional region in a tenancy, navigate to that tenancy in the OCI Integration tile.

    1. In the Configure an Additional Region section, click Create Metric Stack.
    2. Switch to the region you wish to monitor in the top right of the screen.
    3. Complete the steps in Create OCI metric forwarding stack for the new region.
    Add compartments or metric namespaces

    To add compartments or edit the list of metric namespaces enabled, click Edit on the newly created Connector Hub.

    • Click + Another compartment to add compartments.
    • In the Configure source section, add or remove namespaces from the Namespaces dropdown.

    Architecture

    Metric forwarding resources

    A diagram of the OCI resources mentioned in this page and displaying the flow of data

    This integration creates an OCI connector hub, function app, and secure networking infrastructure to forward OCI metrics to Datadog. The ORM stack for these resources creates a function container repository for the region in the tenancy, and the Docker image is pushed to it to be used by the function.

    IAM resources

    A diagram of the OCI resources and workflow used for integration authentication

    This integration creates:

    • A dynamic group with resource.type = 'serviceconnectors', to enable access to the connector hub.
    • A user called DatadogAuthUser, which Datadog uses to read tenancy resources.
    • A group to which the created user is added for policy access.
    • A policy in the root compartment to allow connector hubs to read metrics and invoke functions. In addition, it gives the created user group read access to the tenancy resources. The following statements are added to the policy:
    Allow dynamic-group <GROUP_NAME> to read metrics in tenancy
Allow dynamic-group <GROUP_NAME> to use fn-function in tenancy
Allow dynamic-group <GROUP_NAME> to use fn-invocation in tenancy
Allow dynamic-group Default/<GROUP_NAME> to read metrics in tenancy
Allow dynamic-group Default/<GROUP_NAME> to use fn-function in tenancy
Allow dynamic-group Default/<GROUP_NAME> to use fn-invocation in tenancy
Allow group Default/<USER_GROUP_NAME> to read all-resources in tenancy

    Metric namespaces

    IntegrationMetric Namespace
    Autonomous Databaseoci_autonomous_database
    Block Storageoci_blockstore
    Computeoci_computeagent, rdma_infrastructure_health, gpu_infrastructure_health, oci_compute_infrastructure_health
    Container Instances (Preview)oci_computecontainerinstance
    Databaseoci_database, oci_database_cluster
    Dynamic Routing Gatewayoci_dynamic_routing_gateway
    FastConnectoci_fastconnect
    File Storageoci_filestorage
    Functions (Preview)oci_faas
    HeatWave MySQLoci_mysql_database
    Kubernetes Engineoci_oke
    Load Balanceroci_lbaas, oci_nlb
    NAT Gatewayoci_nat_gateway
    Object Storageoci_objectstorage
    Queueoci_queue
    Service Connector Huboci_service_connector_hub
    Service Gatewayoci_service_gateway
    VCNoci_vcn
    VPNoci_vpn
    Web Application Firewalloci_waf

    Log collection

    Send logs from your Oracle Cloud Infrastructure to Datadog by following either process:

      1. Configure an OCI log.
      2. Create an OCI function.
      3. Setup an OCI Service Connector.

      The instructions below use the OCI portal to set up the integration.

      OCI logging

      1. In the OCI portal, navigate to Logging -> Log Groups.
      2. Select your compartment and click Create Log Group. A side panel opens.
      3. Enter data_log_group for the name, and optionally provide a description and tags.
      4. Click Create to set up your new Log Group.
      5. Under Resources, click Logs.
      6. Click to Create custom log or Enable service log as desired.
      7. Click Enable Log, to create your new OCI Log.

      For more information on OCI Logs, see Enabling Logging for a Resource.

      OCI function

      1. In the OCI portal, navigate to Functions.
      2. Select an existing application or click Create Application.
      3. Create a new OCI function within your application. See the Oracle Overview of Functions for details.
      4. It is recommended to create a boilerplate Python function first and replace the auto generated files with Datadog’s source code:
        • Replace func.py with code from the Datadog OCI repo.
        • Replace func.yaml with code from the Datadog OCI repo. DATADOG_TOKEN and DATADOG_HOST must be replaced with your Datadog API key and region logs intake link.
        • Replace requirements.txt with code from the Datadog OCI repo.

      OCI service connector hub

      1. In the OCI portal, navigate to Logging -> Service Connectors.
      2. Click Create Service Connector to be directed to the Create Service Connector page.
      3. Select the Source as Logging and Target as Functions.
      4. Under Configure Source Connection select a Compartment name, Log Group, and Log. (The Log Group and Log created in the first step)
      5. If you also want to send Audit Logs, click +Another Log and select the same Compartment while replacing “_Audit” as your Log Group.
      6. Under Configure target select a Compartment, Function application, and Function. (The Function Application and Function created in the previous step)
      7. If you are prompted to create a policy, click Create from the prompt.
      8. Click Create at the bottom to finish creating your Service Connector.

      For more information on OCI Object Storage, see Oracle’s Service Connector blog post.

      1. Configure an OCI log.
      2. Create an OCI object store and enable read/write access for OCI logs.
      3. Create an OCI function.
      4. Set up an OCI event.

      The instructions below use the OCI portal to set up the integration.

      OCI logging

      1. In the OCI portal, navigate to Solutions and Platform -> Logging -> Logs.
      2. Click Create Custom Log to be directed to the Create Custom Log page.
      3. Give your new OCI log a name.
      4. Select a Compartment and Log Group. These selections remain consistent across the entire installation.
      5. Click Create Custom Log to be directed to the Create Agent Config page.
      6. Click Create new configuration.
      7. Give your new configuration a name. Your compartment is preselected for you.
      8. Set the group type to Dynamic Group and group to one of your existing groups.
      9. Set the input type to Log Path, enter your preferred input name and use “/” for file paths.
      10. Click Create Custom Log, then your OCI log is created and available on the logs page.

      For more information on OCI Logs, see Enabling Logging for a Resource.

      OCI object storage

      1. In the OCI portal, navigate to Core Infrastructure -> Object Storage -> Object Storage.
      2. Click Create Bucket to be directed to the Create Bucket form.
      3. Select Standard for your storage tier and check Emit Object Events.
      4. Complete the rest of the form based on your preference.
      5. Click Create Bucket, then your bucket is created and available in the bucket list.
      6. Select your new bucket from the active bucket list and click Logs under resources.
      7. Toggle read to enabled which directs you to an Enable Log side menu.
      8. Select a Compartment and Log Group (use the same selections as your OCI log).
      9. Enter a name for the Log Name and select your preferred log retention.

      For more information on OCI Object Storage, see Putting Data into Object Storage.

      OCI function

      1. In the OCI portal, navigate to Solutions and Platform -> Developer Services -> Functions.
      2. Select an existing application or click Create Application.
      3. Create a new OCI function within your application. See the Oracle Overview of Functions for more details.
      4. It is recommended to create a boilerplate Python function first and replace the auto generated files with Datadog’s source code:
        • Replace func.py with code from the Datadog OCI repo.
        • Replace func.yaml with code from the Datadog OCI repo. DATADOG_TOKEN and DATADOG_HOST must be replaced with your Datadog API key and region logs intake link.
        • Replace requirements.txt with code from the Datadog OCI repo.

      OCI event

      1. In the OCI portal, navigate to Solutions and Platform -> Application Integration -> Event Service.
      2. Click Create Rule to be directed to the Create Rule page.
      3. Give your event rule a name and description.
      4. Set your condition as Event Type, service name as Object Storage, and event type as Object - Create.
      5. Set your action type as Functions.
      6. Ensure that your function compartment is the same selection you made for OCI Log, OCI Bucket, and OCI Function.
      7. Select your function application and function (according to the previous installation step.)
      8. Click Create Rule, then your rule is created and available in the rules list.

      For more information on OCI Object Storage, see Getting Started with Events.

      Data Collected

      Metrics

      oci.blockstore.volume_guaranteed_iops
      (gauge)      		Rate of change for guaranteed IOPS per SLA. Expressed as the average of guaranteed IOPS during a given time interval.
      Shown as operation
      oci.blockstore.volume_guaranteed_throughput
      (gauge)      		Rate of change for guaranteed throughput per SLA. Expressed as megabytes per interval.
      Shown as megabyte
      oci.blockstore.volume_guaranteed_vpus_per_gb
      (gauge)      		Rate of change for currently active VPUs/GB. Expressed as the average of active VPUs/GB during a given time interval.
      Shown as operation
      oci.blockstore.volume_read_ops
      (count)      		Activity level from I/O reads. Expressed as reads per interval.
      Shown as operation
      oci.blockstore.volume_read_throughput
      (gauge)      		Read throughput. Expressed as bytes read per interval.
      Shown as byte
      oci.blockstore.volume_replication_seconds_since_last_sync
      (gauge)      		Time elapsed since the last synced cross region replica. Expressed in seconds.
      Shown as second
      oci.blockstore.volume_replication_seconds_since_last_upload
      (gauge)      		Time elapsed since the last cross region replica was uploaded. Expressed in seconds.
      Shown as second
      oci.blockstore.volume_throttled_ios
      (count)      		Total sum of all the I/O operations that were throttled during a given time interval.
      Shown as operation
      oci.blockstore.volume_write_ops
      (count)      		Activity level from I/O writes. Expressed as writes per interval.
      Shown as operation
      oci.blockstore.volume_write_throughput
      (gauge)      		Write throughput. Expressed as bytes written per interval.
      Shown as byte
      oci.fastconnect.bits_received
      (count)      		Number of bits received on the FastConnect interface at the Oracle end of the connection. For a cross-connect group (LAG), the value is the sum across all cross-connects in the group.
      Shown as bit
      oci.fastconnect.bits_sent
      (count)      		Number of bits sent from the FastConnect interface at the Oracle end of the connection. For a cross-connect group (LAG), the value is the sum across all cross-connects in the group.
      Shown as bit
      oci.fastconnect.bytes_received
      (count)      		Number of bytes received on the FastConnect interface at the Oracle end of the connection. For a cross-connect group (LAG), the value is the sum across all cross-connects in the group.
      Shown as byte
      oci.fastconnect.bytes_sent
      (count)      		Number of bytes sent from the FastConnect interface at the Oracle end of the connection. For a cross-connect group (LAG), the value is the sum across all cross-connects in the group.
      Shown as byte
      oci.fastconnect.connection_state
      (gauge)      		The values are up (1) or down (0). For a virtual circuit, the operational state of the virtual circuit's interface. For a cross-connect group, this reflects the overall operational state of the cross-connects that make up the cross-connect group (LAG). If at least one of the cross-connects is up, this value is up (1). If all the cross-connects in the group are down, this value is down (0).
      oci.fastconnect.ipv_4bgp_session_state
      (gauge)      		The values are up (1) or down (0). The status of the IPv4 BGP session for a virtual circuit.
      oci.fastconnect.ipv_6bgp_session_state
      (gauge)      		The values are up (1) or down (0). The status of the IPv6 BGP session for a virtual circuit.
      oci.fastconnect.packets_discarded
      (count)      		Number of packets discarded at the Oracle end of the connection.
      Shown as packet
      oci.fastconnect.packets_error
      (count)      		Number of packets dropped at the Oracle end of the connection. Dropped packets indicate a misconfiguration in some part of the overall system. Check if there's been a change to the configuration of your VCN, the virtual circuit, or your CPE. For a cross-connect group (LAG), the value is the sum across all cross-connects in the group.
      Shown as packet
      oci.fastconnect.packets_received
      (count)      		Number of packets received on the FastConnect interface at the Oracle end of the connection. For a cross-connect group (LAG), the value is the sum across all cross-connects in the group.
      Shown as packet
      oci.fastconnect.packets_sent
      (count)      		Number of packets sent from the FastConnect interface at the Oracle end of the connection. For a cross-connect group (LAG), the value is the sum across all cross-connects in the group.
      Shown as packet
      oci.filestorage.file_system_read_average_latency_by_size
      (gauge)      		Read latency by size. Expressed as average read latency per second, grouped by size.
      Shown as second
      oci.filestorage.file_system_read_requests_by_size
      (gauge)      		Read requests by size. Expressed as operation per second, grouped by size.
      Shown as operation
      oci.filestorage.file_system_read_throughput
      (count)      		Read throughput for the file system. If the file system is exported through multiple mount targets, total throughput for all mount targets is displayed. Expressed as bytes read per second.
      Shown as byte
      oci.filestorage.file_system_usage
      (gauge)      		Total space utilization for a file system. Expressed as GiB consumed per second.
      Shown as byte
      oci.filestorage.file_system_write_average_latency_by_size
      (gauge)      		Write latency by size. Expressed as average write latency per second, grouped by size.
      Shown as second
      oci.filestorage.file_system_write_requests_by_size
      (count)      		Write requests by size. Expressed as operation per second, grouped by size.
      Shown as operation
      oci.filestorage.file_system_write_throughput
      (count)      		Write throughput for the file system. If the file system is exported through multiple mount targets, total throughput for all mount targets is displayed. Expressed as bytes written per second.
      Shown as byte
      oci.filestorage.kerberos_errors
      (count)      		Kerberos errors seen by the mount target while receiving IO from an NFS client. Expressed as a sum of errors per interval.
      Shown as error
      oci.filestorage.ldap_connection_errors
      (count)      		Connection failures between mount targets and the LDAP server for this outbound connector. Expressed as error count by error type per interval.
      Shown as error
      oci.filestorage.ldap_request_average_latency
      (gauge)      		Mount target to LDAP server request latency for this outbound connector. Expressed as mean latency, in seconds, by request type.
      Shown as second
      oci.filestorage.ldap_request_errors
      (count)      		LDAP query failures over an established connection between mount targets and the LDAP server for this outbound connector. Expressed as error count by error type per interval.
      Shown as error
      oci.filestorage.ldap_request_throughput
      (count)      		Requests from the mount target to the LDAP server through its outbound connector. Expressed as request type and outbound connector per interval.
      Shown as request
      oci.filestorage.metadata_iops
      (gauge)      		IOPs (Input/Output Operations Per Second) for the following NFS operations: CREATE, GETATTR, SETATTR, and REMOVE. Expressed as operations per second.
      Shown as operation
      oci.filestorage.metadata_request_average_latency
      (gauge)      		Average metadata request latency for the following NFS operations: CREATE, GETATTR, SETATTR, and REMOVE. Expressed as average latency per second, grouped by operation.
      Shown as second
      oci.filestorage.mount_target_connections
      (count)      		Number of client connections for the mount target. Expressed as total connection count at the interval.
      Shown as connection
      oci.filestorage.mount_target_health
      (gauge)      		Number of successfully executed NFS API requests. Expressed as a percentage of total requests per interval.
      Shown as percent
      oci.filestorage.mount_target_read_throughput
      (count)      		Read throughput for the mount target. If the mount target exports multiple file systems, total throughput for all file systems is displayed. Expressed as bytes read per interval.
      Shown as byte
      oci.filestorage.mount_target_write_throughput
      (count)      		Write throughput for the mount target. If the mount target exports multiple file systems, total throughput for all file systems is displayed. Expressed as bytes written per interval.
      Shown as byte
      oci.filestorage.replication_egress_throughput
      (count)      		Data that has been copied out of the source region. Only applicable for cross-region replication. Expressed as a sum of bytes written per interval.
      Shown as byte
      oci.filestorage.replication_recovery_point_age
      (gauge)      		Age of the last fully copied snapshot that was applied to the target file system. Or, how much older the data on the target file system is than the source file system. Expressed as time since the source snapshot was taken. Monitor this metric to ensure that the data on the target file system isn't older than your requirements allow (RPO).
      Shown as time
      oci.filestorage.replication_throughput
      (count)      		Throughput of the data transferred out of the source file system. Expressed as bytes read per interval.
      Shown as byte
      oci.mediastreams.egress_bytes
      (count)      		Total egress of data streamed through the Distribution Channel (in GB).
      Shown as byte
      oci.mediastreams.request_count
      (count)      		Total number of requests made to the Distribution Channel.
      Shown as request
      oci.network_firewall.byte_received_count
      (count)      		The number of bytes received through the firewall.
      Shown as byte
      oci.network_firewall.byte_sent_count
      (count)      		The number of bytes sent through the firewall.
      Shown as byte
      oci.network_firewall.decryption_rule_hit_count
      (count)      		The number of times a connection matches a decryption rule.
      oci.network_firewall.icmp_fragment_attacks_count
      (count)      		The number of ICMP fragment attacks detected.
      oci.network_firewall.ip_spoof_count
      (count)      		Number of IP spoof attacks detected.
      oci.network_firewall.land_attacks_count
      (count)      		The number of land attacks detected.
      oci.network_firewall.mac_spoof_count
      (count)      		The number of MAC spoof attacks detected.
      oci.network_firewall.packet_drop_count
      (count)      		The number of packets dropped through the firewall.
      Shown as packet
      oci.network_firewall.packet_received_count
      (count)      		The number of packets received at the firewall from the network, after drops.
      Shown as packet
      oci.network_firewall.packet_received_in_error_count
      (count)      		Number of packets received through the firewall that have errors.
      Shown as packet
      oci.network_firewall.packet_sent_count
      (count)      		The number of packets sent from the firewall to the network, after drops.
      Shown as packet
      oci.network_firewall.ping_of_death_attacks_count
      (count)      		The number of ping of death attacks detected.
      oci.network_firewall.security_rule_hit_count
      (count)      		The number of times a connection matches a security rule.
      oci.network_firewall.teardrop_attacks_count
      (count)      		The number of teardrop attacks detected.
      oci.objectstorage.all_requests
      (count)      		The total number of all HTTP requests made in a bucket. Emit frequency: every 100 ms
      Shown as request
      oci.objectstorage.client_errors
      (count)      		The total number of 4xx errors for requests made in a bucket. Emit frequency: every 100 ms
      Shown as error
      oci.objectstorage.enabled_olm
      (gauge)      		Indicates whether a bucket has any executable Object Lifecycle Management policies configured. EnabledOLM emits: 1 if policies are configured 0 if no policies are configured Emit frequency: every 3 hours
      oci.objectstorage.first_byte_latency
      (gauge)      		The per-request time measured from the time Object Storage receives the complete request to when Object Storage returns the first byte of the response. Emit frequency: every 100 ms
      Shown as millisecond
      oci.objectstorage.object_count
      (count)      		The count of objects in the bucket, excluding any multipart upload parts that have not been discarded (aborted) or committed. Emit frequency: every hour
      oci.objectstorage.post_requests
      (count)      		The total number of HTTP Post requests made in a bucket. Emit frequency: every 100 ms
      Shown as request
      oci.objectstorage.put_requests
      (count)      		The total number of PutObject requests made in a bucket. Emit frequency: every 100 ms
      Shown as request
      oci.objectstorage.stored_bytes
      (gauge)      		The size of the bucket, excluding any multipart upload parts that have not been discarded (aborted) or committed. Emit frequency: every hour
      Shown as byte
      oci.objectstorage.total_request_latency
      (gauge)      		The per-request time from the first byte received by Object Storage to the last byte sent from Object Storage. Emit frequency: every 100 ms
      Shown as millisecond
      oci.objectstorage.uncommitted_parts
      (gauge)      		The size of any multipart upload parts that have not been discarded (aborted) or committed. Emit frequency: every hour
      Shown as byte
      oci.oke.apiserver_request_count
      (count)      		Number of requests received by the Kubernetes API Server.
      Shown as request
      oci.oke.apiserver_response_count
      (count)      		Number of different non-200 responses (that is, error responses) sent from the Kubernetes API server.
      Shown as response
      oci.oke.kubernetes_node_condition
      (gauge)      		Number of worker nodes in different conditions, as indicated by the Kubernetes API server.
      Shown as node
      oci.oke.node_state
      (gauge)      		Number of compute nodes in different states.
      Shown as node
      oci.oke.unschedulable_pods
      (gauge)      		Number of pods that the Kubernetes scheduler is unable to schedule. Not available in clusters running versions of Kubernetes prior to version 1.15.x.
      oci.oracle_appmgmt.active_requests_by_application
      (gauge)      		Number of executions active grouped by category.
      Shown as request
      oci.oracle_appmgmt.active_user_sessions
      (gauge)      		Current Active User Sessions by username.
      Shown as session
      oci.oracle_appmgmt.active_user_sessions_by_responsibility
      (gauge)      		Current Active User Sessions grouped by responsibility.
      Shown as session
      oci.oracle_appmgmt.capacity_utilization_of_concurrent_managers
      (gauge)      		Utilized capacity of the concurrent manager.
      Shown as percent
      oci.oracle_appmgmt.completed_requests_by_application
      (gauge)      		Percentage of executions completed grouped by category.
      Shown as percent
      oci.oracle_appmgmt.concurrent_processing_component_status
      (gauge)      		Status of the component. Values are: 1 = Up 0 = Down.
      Shown as resource
      oci.oracle_appmgmt.concurrent_requests_by_status
      (count)      		Concurrent requests by status.
      Shown as request
      oci.oracle_appmgmt.deferred_records
      (count)      		Deferred records grouped by status.
      Shown as record
      oci.oracle_appmgmt.executed_programs_by_running_time
      (gauge)      		Running time of each execution of the program (raw data).
      Shown as millisecond
      oci.oracle_appmgmt.forms_database_sessions_per_application
      (count)      		Number Of Forms Sessions.
      Shown as session
      oci.oracle_appmgmt.forms_database_sessions_per_user
      (count)      		Number Of Forms Sessions.
      Shown as session
      oci.oracle_appmgmt.hourly_completed_concurrent_requests_rate
      (gauge)      		Concurrent Requests Completed by category.
      Shown as percent
      oci.oracle_appmgmt.inbound_notifications
      (count)      		Inbound records grouped by status.
      Shown as record
      oci.oracle_appmgmt.internal_concurrent_manager_status
      (gauge)      		Status of the resource. Values are: 1 = Up 0 = Down.
      Shown as resource
      oci.oracle_appmgmt.long_active_concurrent_requests
      (gauge)      		For pending requests, pending time. For running requests, running time.
      Shown as millisecond
      oci.oracle_appmgmt.monitoring_status
      (gauge)      		Status of the resource. Values are: 1 = Up 0 = Down.
      Shown as resource
      oci.oracle_appmgmt.outbound_notifications
      (count)      		Outbound records grouped by status.
      Shown as record
      oci.oracle_appmgmt.queue_details
      (count)      		Requests grouped by status.
      Shown as request
      oci.oracle_appmgmt.users_with_most_pending_requests
      (gauge)      		Number of requests.
      Shown as user
      oci.oracle_appmgmt.users_with_most_running_requests
      (gauge)      		Number of requests.
      Shown as user
      oci.postgresql.buffer_cache_hit_ratio
      (gauge)      		The percentage of pages found in the buffer cache without reading from disk.
      Shown as percent
      oci.postgresql.connections
      (count)      		The number of database connections.
      Shown as connection
      oci.postgresql.cpu_utilization
      (gauge)      		The CPU utilization expressed as a percentage. The utilization percentage is reported with respect to the number of CPUs the database is allowed to use, which is two times the number of OCPUs.
      Shown as percent
      oci.postgresql.deadlocks
      (count)      		The number of locks on a database row where two or more transactions are waiting for another transaction to give up a locked row.
      Shown as lock
      oci.postgresql.memory_utilization
      (gauge)      		The percentage of total RAM that's in use.
      Shown as percent
      oci.postgresql.read_iops
      (gauge)      		The number of reads per second.
      Shown as read
      oci.postgresql.read_latency
      (gauge)      		Read latency in milliseconds.
      Shown as millisecond
      oci.postgresql.read_throughput
      (gauge)      		Reads in kilobytes per second.
      Shown as kilobyte
      oci.postgresql.used_storage
      (gauge)      		The amount of storage used, expressed in GB.
      Shown as gigabyte
      oci.postgresql.write_iops
      (gauge)      		The number of writes per second.
      Shown as write
      oci.postgresql.write_latency
      (gauge)      		Write latency in milliseconds.
      Shown as millisecond
      oci.postgresql.write_throughput
      (gauge)      		Writes in kilobytes per second.
      Shown as kilobyte
      oci.queue.consumer_lag
      (gauge)      		Difference in time between the oldest message in the queue and the current time
      Shown as minute
      oci.queue.messages_count
      (count)      		Count of messages sent and received per queue
      Shown as message
      oci.queue.messages_in_queue_count
      (gauge)      		Count of messages in the queue
      oci.queue.queue_size
      (gauge)      		Bytes in the queue
      Shown as byte
      oci.queue.request_success
      (count)      		Indicates the success of the requests sent and received per queue
      oci.queue.requests_latency
      (gauge)      		Latency of the requests to the queue
      Shown as millisecond
      oci.queue.requests_throughput
      (gauge)      		Bytes sent and received per queue
      Shown as byte
      oci.service_connector_hub.bytes_read_from_source
      (count)      		Number of bytes read from the source. Note: This value is emitted each time Connector Hub reads data from the source. If failures occur at the task or destination and Connector Hub needs to reread data from the source, the value is emitted again.
      Shown as byte
      oci.service_connector_hub.bytes_read_from_task
      (count)      		Number of bytes moved from the task to Connector Hub.
      Shown as byte
      oci.service_connector_hub.bytes_written_to_target
      (count)      		Number of bytes written to the target. Note: Use this metric as a general indicator of success. BytesWrittenToTarget might not match BytesReadFromSource or BytesReadFromTask. For example, consider a 10MB read intended for an Object Storage target. Connector Hub might compress the data, converting 10MB read into 1MB written.
      Shown as byte
      oci.service_connector_hub.bytes_written_to_task
      (count)      		Number of bytes moved by Connector Hub to the task.
      Shown as byte
      oci.service_connector_hub.data_freshness
      (gauge)      		Indicates age of the oldest processed record of the most recent set.
      Shown as millisecond
      oci.service_connector_hub.errors_at_source
      (count)      		Number of errors that affect retrieving data from source. Tip: To troubleshoot errors, view the errorCode and errorType dimension values. For example, an errorCode value that starts with 5, such as 500, implies a partner service outage, while the errorCode value –1 implies a network outage or timeout.
      Shown as error
      oci.service_connector_hub.errors_at_target
      (count)      		Number of errors that affect writing data to target. Tip: To troubleshoot errors, view the errorCode and errorType dimension values. For example, an errorCode value that starts with 5, such as 500, implies a partner service outage, while the errorCode value –1 implies a network outage or timeout.
      Shown as error
      oci.service_connector_hub.errors_at_task
      (count)      		Number of errors while writing to the task. Tip: To troubleshoot errors, view the errorCode and errorType dimension values. For example, an errorCode value that starts with 5, such as 500, implies a partner service outage, while the errorCode value –1 implies a network outage or timeout.
      Shown as error
      oci.service_connector_hub.latency_at_source
      (gauge)      		Time-to-first-byte when retrieving data from source. Useful for customers to troubleshoot with complex tasks (log rules).
      Shown as millisecond
      oci.service_connector_hub.latency_at_target
      (gauge)      		Time-to-first-byte when writing data to target.
      Shown as millisecond
      oci.service_connector_hub.latency_at_task
      (gauge)      		Time-to-first-byte for task; includes latency reading from the source, errors at the task, and errors writing to the target.
      Shown as millisecond
      oci.service_connector_hub.messages_read_from_source
      (count)      		Number of records read from the source. Note: The value for this metric is cumulative.
      Shown as message
      oci.service_connector_hub.messages_read_from_task
      (count)      		Number of messages moved from the task to Connector Hub.
      Shown as message
      oci.service_connector_hub.messages_written_to_target
      (count)      		Number of records written to the target.
      Shown as message
      oci.service_connector_hub.messages_written_to_task
      (count)      		Number of messages moved by Connector Hub to the task.
      Shown as message
      oci.service_connector_hub.service_connector_hub_errors
      (count)      		Number of errors in Connector Hub that affect moving data from source to target.
      Shown as error
      oci.service_gateway.bytes_from_service
      (count)      		The number of bytes successfully sent from the service gateway toward customer instances.
      Shown as byte
      oci.service_gateway.bytes_to_service
      (count)      		The number of bytes successfully sent from the service gateway toward Oracle services.
      Shown as byte
      oci.service_gateway.packets_from_service
      (count)      		The number of packets successfully sent from the service gateway toward customer instances.
      Shown as packet
      oci.service_gateway.packets_to_service
      (count)      		The number of packets successfully sent from the service gateway toward Oracle services.
      Shown as packet
      oci.service_gateway.sgw_drops_from_service
      (count)      		The number of packets dropped while sending packets from the service gateway toward customer instances.
      Shown as packet
      oci.service_gateway.sgw_drops_to_service
      (count)      		The number of packets dropped while sending packets from the service gateway toward Oracle services.
      Shown as packet
      oci.waf.bandwidth
      (gauge)      		Bandwidth rate calculated by dividing total data egress in a minute by 60.
      Shown as byte
      oci.waf.number_of_requests
      (count)      		The total number of requests serviced by the WAF.
      Shown as request
      oci.waf.number_of_requests_detected
      (count)      		The number of requests that triggered a detect (alert) for a WAF policy.
      Shown as request
      oci.waf.traffic
      (gauge)      		Data egress from the WAF (compressed by default) measured in one minute intervals.
      Shown as byte

      Service Checks

      The OCI integration does not include any service checks.

      Events

      The OCI integration does not include any events.

      Troubleshooting

      Need help? Contact Datadog support.

      Further Reading

      Additional helpful documentation, links, and articles: