Publishes raw metric data points to the Monitoring service. For a data point to be posted, its timestamp must be near current time (less than two hours in the past and less than 10 minutes in the future).

For more information about publishing metrics, see Publishing Custom Metrics and Custom Metrics Walkthrough. For information about developing a metric-posting client, see Developer Guide. For an example client, see For important limits information, see Limits on Monitoring.

Per-call limits information follows.

  • Dimensions per metric group*. Maximum: 20. Minimum: 1. * Unique metric streams*. Maximum: 50. * Transactions Per Second (TPS) per-tenancy limit for this operation: 50.

*A metric group is the combination of a given metric, metric namespace, and tenancy for the purpose of determining limits. A dimension is a qualifier provided in a metric definition. A metric stream is an individual set of aggregated data for a metric with zero or more dimension values. For more information about metric-related concepts, see Monitoring Concepts.

Note: The endpoints for this operation differ from other Monitoring operations. Replace the string telemetry with telemetry-ingestion in the endpoint, as in the following example:


oci monitoring metric-data post [OPTIONS]

Required Parameters

--metric-data [complex type]

A metric object containing raw metric data points to be posted to the Monitoring service. This is a complex type whose value must be valid JSON. The value can be provided as a string on the command line or passed in as a file using the file://path/to/file syntax.

The --generate-param-json-input option can be used to generate an example of the JSON which must be provided. We recommend storing this example in a file, modifying it as needed and then passing it back in via the file:// syntax.

Optional Parameters

--batch-atomicity [text]

Batch atomicity behavior. Requires either partial or full pass of input validation for metric objects in PostMetricData requests. The default value of NON_ATOMIC requires a partial pass: at least one metric object in the request must pass input validation, and any objects that failed validation are identified in the returned summary, along with their error messages. A value of ATOMIC requires a full pass: all metric objects in the request must pass input validation.



Accepted values are:

--content-encoding [text]

The optional Content-Encoding header that defines the content encodings that were applied to the payload.

--from-json [text]

Provide input to this command as a JSON document from a file using the file://path-to/file syntax.

The --generate-full-command-json-input option can be used to generate a sample json file to be used with this command option. The key names are pre-populated and match the command option names (converted to camelCase format, e.g. compartment-id –> compartmentId), while the values of the keys need to be populated by the user before using the sample file as an input to this command. For any command option that accepts multiple values, the value of the key can be a JSON array.

Options can still be provided on the command line. If an option exists in both the JSON document and the command line then the command line specified value will be used.

For examples on usage of this option, please see our “using CLI with advanced JSON options” link:

Example using required parameter

Copy and paste the following example into a JSON file, replacing the example parameters with your own.

    oci monitoring metric-data post --generate-param-json-input metric-data > metric-data.json

Copy the following CLI commands into a file named Run the command by typing “bash” and replacing the example parameters with your own.

Please note this sample will only work in the POSIX-compliant bash-like shell. You need to set up the OCI configuration and appropriate security policies before trying the examples.

    oci monitoring metric-data post --metric-data file://metric-data.json