source: trunk/man/arm_register_metric.3 @ 704

.\" Copyright (c) 2005-2008 David Carter <dcarter@arm4.org> and others.
.\" All rights reserved.   This program and the accompanying materials
.\" are made available under the terms of the Eclipse Public License v1.0
.\" which accompanies this distribution, and is available at
.\" http://www.eclipse.org/legal/epl-v10.html
.TH "arm_register_metric" 3 "August 2008" "arm4.org" "ARM 4 Programmer's Manual"
.SH NAME
arm_register_metric \- describe metrics
.SH SYNOPSIS
.B #include <arm4.h>
.sp
\fBarm_error_t
.br
arm_register_metric( 
.br
    const arm_id_t *\fIapp_id\fB, 
.br
    const arm_char_t *\fIname\fB, 
.br
    const arm_metric_format_t \fIformat\fB, 
.br
    const arm_metric_usage_t \fIusage\fB, 
.br
    const arm_char_t *\fIunit\fB, 
.br
    const arm_id_t *\fIinput_metric_id\fB, 
.br
    const arm_int32_t \fIflags\fB,
.br
    const arm_buffer4_t *\fIbuffer4\fB,
.br
    arm_id_t *\fIoutput_metric_id\fB);\fR
.SH DESCRIPTION
\fBarm_register_metric()\fR describes metadata about a metric. 

The application uses \fBarm_register_metric()\fR to inform the ARM library of metadata about each 
metric the application provides. 

ARM generates an ID that is passed in the metric binding sub-buffer to 
\fBarm_register_transaction()\fR. 

\fIapp_id\fR is an application ID returned from an \fBarm_register_application()\fR call in the same 
process. 

\fIbuffer4\fR is a pointer to the user data buffer, if any. If the pointer is null, there is no buffer. No 
sub-buffer types are currently valid with this function call, so the pointer should be 
null (\fBARM_BUF4_NONE\fR).
 
\fIflags\fR contains 32-bit flags. No values are currently defined. The field should be zero 
(\fBARM_FLAG_NONE\fR).
 
\fIformat\fR describes the data type. The value must be one of the following values:
 
.IP 1
(\fBARM_METRIC_FORMAT_COUNTER32\fR) = arm_int32_t counter 
.IP 2
(\fBARM_METRIC_FORMAT_COUNTER64\fR) = arm_int64_t counter 
.IP 3
(\fBARM_METRIC_FORMAT_CNTRDIVR\fR) = arm_int32_t counter + arm_int32_t 
divisor 
.IP 4
(\fBARM_METRIC_FORMAT_GAUGE32\fR) = arm_int32_t gauge 
.IP 5
(\fBARM_METRIC_FORMAT_GAUGE64\fR) = arm_int64_t gauge 
.IP 6
(\fBARM_METRIC_FORMAT_GAUGEDIVR32\fR) = arm_int32_t gauge + 
arm_int32_t divisor 
.IP 7
(\fBARM_METRIC_FORMAT_NUMERICID32\fR) = arm_int32_t numeric ID 
.IP 8
(\fBARM_METRIC_FORMAT_NUMERICID64\fR) = arm_int64_t numeric ID 
.IP 9
deprecated 
.IP 10
(\fBARM_METRIC_FORMAT_STRING32\fR) = string (null-terminated) of a 
maximum length of 32 characters (33 including the null termination character) 
.P
\fIinput_metric_id\fR is a pointer to an optional 128-bit ID (16 bytes) that is unique and that can be treated as 
an alias for the other metadata. It can be any value except all zeros or all ones. If the 
pointer is null (\fBARM_ID_NONE\fR), no ID is provided. 
 
An ID is unique if the probability of the ID being associated with more than one set 
of metadata is vanishingly small. The selection of 128-bit IDs yields 3.4 x 10**38 
unique IDs, so the objective is to select an ID that makes use of all 128 bits and is 
reasonably likely to not be selected by another person creating an ID of the same 
form. Two suggested algorithms that generate 128-bit values with these 
characteristics are: 
 
.IP 1.
The Universal Unique Identifier (UUID) algorithm that is part of The Open 
Group specification: DCE 1.1: Remote Procedure Call. A developer could use the 
algorithm at the time the application is developed using a utility on his or her 
system, and be reasonably certain that nobody else would generate the same 128-bit 
ID. 
 
.IP 2.
The MD5 Message-Digest Algorithm, described in IETF RFC 1321. Applying 
this algorithm to a concatenation of all the metadata properties would almost 
certainly result in a value that would not collide with any other ID created with a 
different set of metadata properties. 
.P 
If an ARM implementation is passed an ID that was previously registered within 
this process, the implementation can ignore the other metadata parameters and 
assume they are identical to the previously registered metadata. The metric 
metadata consists of the following fields: \fIapp_id\fR, \fIname\fR, \fIformat\fR, \fIusage\fR, and \fIunit\fR.
 
\fIname\fR is a pointer to a null-terminated string containing the name of the metric. The maximum 
length of the string is 128 characters, including the termination character. It serves 
no purpose and is illegal to make this call if the pointer is null. The name should not 
contain trailing blank characters or consist of only blank characters. 
 
The name can be any string, with one exception. Strings beginning with the four 
characters "ARM:" are reserved for the ARM specification. The specification will 
define names with known semantics using this prefix. One name format is currently 
defined. Any name beginning with the eight character prefix "ARM:CIM:" 
represents a name defined using the DMTF CIM (Distributed Management Task 
Force Common Information Model) naming rules. For example, 
"ARM:CIM:CIM_SoftwareElement.Name" indicates that the metric value has the 
semantics of the Name property of the CIM_SoftwareElement class. It is anticipated 
that additional naming semantics are likely to be added in the future. 

\fIoutput_metric_id\fR is a pointer to a 16-byte field. ARM will store a 16-byte value. There are no 
requirements on the value it is set to, except that it must be possible to pass it in the 
metric binding sub-buffer on the \fBarm_register_transaction()\fR call, without the 
application needing to do any error checking. 

\fIunit\fR is a pointer to a null-terminated string containing the units (such as "files transferred") 
of the metric. The maximum length of the string is 128 characters, including the 
termination character. The pointer may be null. 

\fIusage\fR describes how the metric is used. The value must be one of the following values, or 
a negative value (any negative value is specific to the application; the negative 
values are not expected to be widely used). 
 
.IP 0
(\fBARM_METRIC_USE_GENERAL\fR) = a metric without a specified usage. Most 
metrics are described with a GENERAL usage. 
.IP 1
(\fBARM_METRIC_USE_TRAN_SIZE\fR) = a metric that indicates the "size" of a 
transaction. The "size" is something that would be expected to affect the response 
time, such as the number of bytes in a file transfer or the number of files backed up 
by a "backup" transaction. ARM implementations can use this knowledge to better 
interpret the response time. 
.IP 2
(\fBARM_METRIC_USE_TRAN_STATUS\fR) = a metric that further explains the 
transaction status passed on \fBarm_stop_transaction()\fR, such as a sense code that 
explains why a transaction failed. 
.SH "RETURN VALUE"
On success, the function returns \fBARM_SUCCESS\fR. A non-zero value indicates
an error.
.SH ERRORS
If the return code is negative, an error occurred. If the return code is not negative, an error may
or may not have occurred - the determination of what is an error and whether an error code is
returned is at the discretion of the ARM implementation. The application can test the return code
if it wants to provide its own error logging.

The following errors are recognized by this implementation, but may not be portable to other implementations:

.TP
.B ARM_FAILURE_NULL_ARGUMENT
The \fIoutput_metric_id\fR pointer must not be null.
.TP
.B ARM_FAILURE_INVALID_ARGUMENT
One of \fIname\fR or \fIunit\fR is invalid.
.TP
.TP
.B ARM_FAILURE_BAD_ALIAS
The alias provided contains all 0's or all 1's.
.TP
.B ARM_FAILURE_DUPLICATE_ALIAS
The alias provided already refers to a metric with different metadata.
.B ARM_FAILURE_INTERNAL_ERROR
An internal error has occurred that prevented the operation from completing. Check your
system log for more details.
.SH "CONFORMING TO"
ARM Issue 4.0 C Language Bindings, Version 2
.SH EXAMPLE
None.
.SH "SEE ALSO"
.BR arm_register_application (3),
.BR arm_register_transaction (3)