Follow

How to collect performance data

The Live Counters Metrics resource reports on InfiniBox performance counters. This is the same API that is used by the InfiniBox GUI to display performance charts. It is recommended to explore the Performance section in the InfiniBox GUI in order to see what can be achieved using this API.

Each performance counter is a combination of a filter and a collector. The filter is used to slice-and-dice the stream of I/O operations passing through the system, in order to define the subset of operations that should be counted. For example, a filter that is limited to the SAN protocol type matches all SAN I/O operations. A filter that is limited to the SAN protocol type and to a specific pool matches only SAN I/O operations on that pool. The collector defines how to summarize the operations matched by the filter, and which metrics to collect (e.g. IOPS, throughput per second, or average latency). There are four types of collectors, suitable for different use cases:

  • COUNTER - this is the simplest type of collector. It simply counts the operations that match the filter.
  • TOP - used to find out which entities in the system have the highest value in some parameter. For example, which hosts are doing the most read IOPS, or which filesystems have the highest write latencies.
  • HISTOGRAM - counts operations that match the filter, separating them into "buckets" according to some parameter. A typical use case would be to count the number of I/O operations per block size (e.g. 4Kb, 8Kb, 16Kb etc.) or per type (read, write, xcopy etc.).
  • AGGREGATOR - this collector counts operations across all entities of a specific type. For example, it could collect write operations per volume in the system, or read operations per pool.

(info) All collectors return performance counters in 1 second intervals, except for aggregators which use 10 second intervals by default.

The following steps are needed to create and use a performance counter:

  1. Create a filter.
  2. Add one or more filtering criteria to the filter.
  3. Create a collector (attaching it to the filter).
  4. Poll the collector periodically to retrieve the performance metrics.
  5. Delete the collector when it is no longer needed.

(warning) A collector that isn't polled gets automatically garbage-collected after 500 seconds of inactivity (this value is different in case of AGGREGATOR collectors - see below for details).

The following sections describe the relevant API calls in detail.

Creating a filter 

When creating a filter we must first specify the protocol or protocol type this filter will be applied to. The API supports discovery of all available filter and collector fields, so we can use this request to get a list of available protocols and types:

Available Protocols Request
GET /api/rest/metrics/available_fields
Available Protocols Response
{
  "result": {
    "available_filter_fields": [{
      "name": "protocol",
      "type": "enum",
      "values": ["NFS", "NFS_QOS", "FC", "iSCSI"]
    }, {
      "name": "protocol_type",
      "type": "enum",
      "values": ["RMR", "SAN", "SAN_QOS"]
    }]
  },
  "error": null,
  "metadata": {
    "ready": true
  }
}


To create the filter we'll send a POST request to the filters endpoint, and specify the wanted protocol or protocol type. For example to create filter which will apply to SAN I/O operations: 

Create Filter Request
POST /api/rest/metrics/filters
{
  "protocol_type": "SAN"
}
Create Filter Response
{
  "result": {
    "id": 35184372088996
  },
  "error": null,
  "metadata": {
    "ready": true
  }
}

Refining the filter

We now have a filter that matches all I/O operations under a specific protocol or protocol type. We can refine it further, so that it will match only a subset of the operations.

The response of the POST request above contains the id of the filter that was created. Using this id we can discover the available filter fields that can be used for refining the filter:

Available Fields Request
GET /api/rest/metrics/filters/<filter_id>/available_fields
Available Fields Response
{
  "result": {
    "id": 35184372088996,
    "available_filter_fields": [{
      "name": "protocol",
      "type": "enum",
      "values": [
        "FC", "iSCSI"
      ]
    }, {
      "name": "operation_category",
      "type": "enum",
      "values": [
        "login", "other", "read", "unmap", "write", "writesame", "xcopy"
      ]
    }, {
      "name": "operation_type",
      "type": "enum",
      "values": [
        "caw", "format_unit", "inquiry", "log_sense", "login", "mode_select",
        "mode_sense", "persistent_reserve_in", "persistent_reserve_out", "read", 
        "read_buf", "read_capacity", "receive_copy_result", "release", "report_luns", 
        "request_sense", "reserve", "rtpg", "send_diagnostic", "start_stop_unit", 
        "sync_cache", "task_management_functions",  "test_unit_ready", 
        "unmap", "verify", "write", "write_buf", "write_same", "xcopy"
      ]
    }, {
      "name": "scsi_status",
      "type": "enum",
      "values": [
        "busy", "error", "good"
      ]
    }, {
      "name": "pool_id",
      "type": "uint"
    }, {
      "name": "vol_id",
      "type": "uint"
    }, {
      "name": "host_id",
      "type": "uint"
    }, 
    .... SNIP ...
    ],
    "available_collector_fields": [{
      "name": "operation_size",
      "unit": "B",
      "description": "Total size of all SCSI operations (successful and failed)"
    }, {
      "name": "throughput",
      "unit": "B/Sec",
      "description": "Total size of successful SCSI operations"
    }, {
      "name": "external_latency",
      "unit": "ms",
      "description": "The total latency to complete the SCSI command, from the initial request was received until the storage sent the final status. 
                      External latency may increase due to host / fabric delays"
    }
    .... SNIP ...
    }]
  },
  "error": null,
  "metadata": {
    "ready": true
  }
}

(warning) The request above lists only the basic fields. To see the full list, add ?level=ADVANCED to the URL. This document includes below a reference of all filter fields and collector fields per protocol / protocol type.

We can now use the filter id and any of the available filter fields to further limit the I/O operations that will be matched by our filter. For example if we want to count only read operations:

Modify Filter Request
PUT /api/rest/metrics/filters/<filter_id>
{
  "operation_category": "read"
}
Modify Filter Response
{
  "result": {
    "id": 35184372088996
  },
  "error": null,
  "metadata": {
    "ready": true
  }
}

(warning) It is not possible to send more than one filtering field per request. Send a separate PUT request for each field.

Creating a COUNTER collector

Three parameters are required to create a COUNTER collector:

  • filter_id - the id of the filter that was previously created
  • type - "COUNTER"
  • collected_fields - a list of field names to collect, out of the available collector fields for the filter's protocol or protocol type.
Create COUNTER Collector Request
POST /api/rest/metrics/collectors
{
    "filter_id": 35184372088996,
    "type": "COUNTER",
    "collected_fields": ["ops", "throughput"]
}
Create COUNTER Collector Response
{
    "result": {
        "id": 35184372089045,
        "filter_id": 35184372088996,
        "collected_fields": ["ops", "throughput"],
        "type": "COUNTER"
    },
    "error": null,
    "metadata": {
        "ready": true
    }
}


It is also possible to create a filter and a COUNTER collector using a single API request, without creating the filter in advance:

Create Filter and COUNTER Collector Request
POST /api/rest/metrics/collectors
{
  "type": "COUNTER",
  "filters": {
    "protocol_type": "SAN",
    "operation_category": "read"
  },
  "collected_fields": ["ops", "throughput"]
}
Create Filter and COUNTER Collector Response
{
  "result": {
    "id": 35184372089047,
    "filters": {
      "protocol_type": "SAN",
      "operation_category": "read"
    },
    "filter_id": 35184372089046,
    "collected_fields": [
      "ops",
      "throughput"
    ],
    "type": "COUNTER"
  },
  "error": null,
  "metadata": {
    "ready": true
  }
}

Collecting the metrics

Once the collector is created, it starts accumulating data. We need to periodically poll the collector to retrieve the data which was collected so far. The data is requested using the collector id; up to 40 COUNTER collector ids can be specified in a single request if they belong to the same protocol.

Get Collector Data Request
GET /api/rest/metrics/collectors/data?collector_id=in:[<id>,<id>,...]
Get Collector Data Response
{
  "result": {
    "collectors": [{
      "id": 35184372089043,
      "fields": ["ops", "throughput"],
      "data": [
        [14451, 467937729],
        [12736, 413005671]
      ],
      "collector_type": "COUNTER",
      "interval_milliseconds": 1000,
      "end_timestamp_milliseconds": 1496922832312
    }]
  },
  "error": null,
  "metadata": {
    "ready": true
  }
}

The response contains a list of collectors, with one item for each collector id that was requested. Each item includes the following fields:

  • id - the collector id
  • fields - names of the collected data fields
  • data - a list of collected entries, one entry per second. Each entry is a list of values ordered according to the field names that appear under fields.
  • interval_milliseconds - the number of milliseconds covered by each entry in the data list.
  • end_timestamp_milliseconds - the timestamp of the last entry in the data list, in milliseconds since the epoch. Using the timestamp and the interval, it is possible to calculate the timestamp of all entries in the list.

So the response above contains the following metrics:

TimestampOpsThroughput
1496922831312 (2017-06-08 11:53:51.312 UTC)
14451
467937729
1496922832312 (2017-06-08 11:53:52.312 UTC)
12736
413005671

Creating a TOP collector

Several parameters are required to create a TOP collector:

  • filter_id - the id of the filter that was previously created
  • type - "TOP"
  • collected_fields - a list of field names to collect, out of the available collector fields for the filter's protocol or protocol type.
  • grouping_field - a filtering field that defines the type of entities we're interested in. For example vol_id, pool_id, source_ip etc.
  • sorting_field - a collector field that defines which parameter to sort the entities by. For example ops, throughput, errors, etc.
  • max_results - the number of entities to return (up to 1000).
  • sort_ascending - when true, sorts the sorting_field from low to high. Otherwise, sorts it from high to low (this is the default).

You can understand how these parameters work together by putting them into a sentence: Return the top <max_results> <grouping_field> ordered by <sorting_field>.

For example, the top <10> <vol_id> ordered by <ops> :

Create TOP Collector Request
POST /api/rest/metrics/collectors
{
    "type": "TOP",
    "filter_id": 35184372089056,
    "collected_fields": ["ops", "throughput"],
    "grouping_field": "vol_id",   
    "sorting_field": "ops",
    "max_results": 10
}
Create TOP Collector Response
{
    "result": {
        "id": 35184372089057,
        "filter_id": 35184372089056,
        "collected_fields": [
            "ops",
            "throughput"
        ],
        "grouping_field": "vol_id",
        "sorting_field": "ops",
        "max_results": 10,
        "sort_ascending": false,
        "type": "TOP"
    },
    "error": null,
    "metadata": {
        "ready": true
    }
}

Collecting the metrics

Once the collector is created, it starts accumulating data. We need to periodically poll the collector to retrieve the data which was collected so far. The data is requested using the collector id; up to 2 TOP collector ids can be specified in a single request if they belong to the same protocol.

Get Collector Data Request
GET /api/rest/metrics/collectors/data?collector_id=in:[<id>,<id>,...]
Get Collector Data Response
{
    "result": {
        "collectors": [{
            "id": 35184372089057,
            "fields": ["vol_id", "ops", "throughput"],
            "data": [
                [
                    ["61321", 2794, 67253941],
                    ["61317", 2352, 101169969],
                    ["61319", 2324, 77666658]
                ],
                [
                    ["61321", 4636, 111570820],
                    ["61319", 3479, 116310076],
                    ["61317", 3471, 149286622]
                ]
            ],
            "collector_type": "TOP",
            "interval_milliseconds": 1000,
            "end_timestamp_milliseconds": 1497258041312,
            "grouping_field": "vol_id",
            "sorting_field": "ops"
        }]
    },
    "error": null,
    "metadata": {
        "ready": true
    }
}

The response contains a list of collectors, with one item for each collector id that was requested. Each item includes the following fields:

  • id - the collector id
  • fields - names of the collected data fields
  • data - a list of collected entries, one entry per second. Each entry is a list of up to max_results top entities. The values in each entity are ordered according to the field names that appear under fields.
  • interval_milliseconds - the number of milliseconds covered by each entry in the data list.
  • end_timestamp_milliseconds - the timestamp of the last entry in the data list, in milliseconds since the epoch. Using the timestamp and the interval, it is possible to calculate the timestamp of all entries in the list.

So the response above contains the following metrics:

TimestampTop volume idsOpsThroughput
1497258040312 (2017-06-12 09:00:40.312 UTC)
 
 
61321
2794
67253941
61317
2352
101169969
61319
2324
77666658
1497258041312 (2017-06-12 09:00:41.312 UTC)
  
61321
4636
111570820
61319
3479
116310076
61317
3471
149286622

Creating a HISTOGRAM collector

Four parameters are required to create a HISTOGRAM collector:

  • filter_id - the id of the filter that was previously created.
  • type - "HISTOGRAM"
  • collected_fields - a list of field names to collect, out of the available collector fields for the filter's protocol or protocol type.
  • histogram_field - a filter field of type enum or histogram. The possible values of this field define the "buckets" of the histogram.

For example if we want to collect the number of I/O operations and the total throughput per SAN operation category (read, write, xcopy, etc.):

Create HISTOGRAM Collector Request
POST /api/rest/metrics/collectors
{
    "type": "HISTOGRAM",
    "filter_id": 35184372089058,
    "collected_fields": ["ops", "throughput"],
    "histogram_field": "operation_category"
}
Create HISTOGRAM Collector Response
{
    "result": {
        "id": 35184372089061,
        "filter_id": 35184372089058,
        "collected_fields": ["ops", "throughput"],
        "histogram_field": "operation_category",
        "type": "HISTOGRAM"
    },
    "error": null,
    "metadata": {
        "ready": true
    }
}

Collecting the metrics

Once the collector is created, it starts accumulating data. We need to periodically poll the collector to retrieve the data which was collected so far. The data is requested using the collector id; up to 10 HISTOGRAM collector ids can be specified in a single request if they belong to the same protocol.

Get Collector Data Request
GET /api/rest/metrics/collectors/data?collector_id=in:[<id>,<id>,...]
Get Collector Data Response
{
    "result": {
        "collectors": [{
            "id": 35184372089061,
            "fields": ["ops", "throughput"],
            "data": [
                [
                    [641, 30521856], [3751, 111668224], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0]
                ],
                [
                    [1837, 87529598], [10901, 323443980], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0]
                ]
            ],
            "collector_type": "HISTOGRAM",
            "interval_milliseconds": 1000,
            "end_timestamp_milliseconds": 1497259383017,
            "histogram_field": "operation_category",
            "ranges": ["read", "write", "xcopy", "unmap", "writesame", "login", "other"]
        }]
    },
    "error": null,
    "metadata": {
        "ready": true
    }
}

The response contains a list of collectors, with one item for each collector id that was requested. Each item includes the following fields:

  • id - the collector id.
  • fields - names of the collected data fields.
  • data - a list of collected entries, one entry per second. Each entry contains buckets matching the buckets listed under ranges. Inside each bucket is a list of values ordered according to the field names that appear under fields.
  • interval_milliseconds - the number of milliseconds covered by each entry in the data list.
  • end_timestamp_milliseconds - the timestamp of the last entry in the data list, in milliseconds since the epoch. Using the timestamp and the interval, it is possible to calculate the timestamp of all entries in the list.
  • ranges - a list of names, one for each bucket in the histogram.

So the response above contains the following metrics:

TimestampHistogram bucketOpsThroughput
1497259382017 (2017-06-12 09:23:02.017 UTC)






read
641
30521856
write
3751
111668224
xcopy
0
0
unmap
0
0
writesame
0
login
0
other
1497259383017 (2017-06-12 09:23:03.017 UTC)
read
1837
87529598
write
10901
323443980
xcopy
0
0
unmap
0
0
writesame
0
0
login
0
0
other
0
0

Creating an AGGREGATOR collector

Four parameters are required to create a AGGREGATOR collector:

  • filter_id - the id of the filter that was previously created
  • type - "AGGREGATOR"
  • collected_fields - a list of field names to collect, out of the available collector fields for the filter's protocol or protocol type.
  • grouping_field - a filtering field that defines the type of entities we're interested in. For example vol_id, pool_id, source_ip etc.

It is also possible to specify the interval_milliseconds to be used by the aggregator - see below.

For example if we want to collect the number of I/O operations and the total throughput for all volumes:

Create AGGREGATOR Collector Request
POST /api/rest/metrics/collectors
{
    "type": "AGGREGATOR",
    "filter_id": 35184372089062,
    "collected_fields": ["ops", "throughput"],
    "grouping_field": "vol_id"
}
Create AGGREGATOR Collector Response
{
    "result": {
        "id": 35184372089063,
        "filter_id": 35184372089062,
        "collected_fields": ["ops", "throughput"],
        "grouping_field": "vol_id",
        "type": "AGGREGATOR"
    },
    "error": null,
    "metadata": {
        "ready": true
    }
}

Setting the metrics collection interval

Aggregators collect data in 10 second intervals by default. It is possible to select another interval from the table below by passing it as the value of interval_milliseconds when creating the AGGREGATOR collector. The chosen interval also controls how often the collector must be polled for data. Failing to do so will lead to the collector's deletion.

Interval (ms)In wordsMaximum polling time
10001 second80 seconds
1000010 seconds80 seconds
3000030 seconds3 minutes
600001 minute6 minutes
1200002 minutes12 minutes
3000005 minutes30 minutes

Collecting the metrics

Once the collector is created, it starts accumulating data. We need to periodically poll the collector to retrieve the data which was collected so far. The data is requested using the collector id; up to 2 AGGREGATOR collector ids can be specified in a single request if they belong to the same protocol.

Get Collector Data Request
GET /api/rest/metrics/collectors/data?collector_id=in:[<id>,<id>,...]
Get Collector Data Response
{
  "result": {
    "collectors": [{
      "id": 35184372089064,
      "fields": ["vol_id", "ops", "throughput"],
      "data": [
        [
          [61321, 42269, 1017175338],
          [61319, 36030, 1207902580],
          [61317, 36014, 1548901690]
        ],
        [
          [61319, 34874, 1169198774],
          [61321, 41330, 994592385],
          [61317, 34928, 1502204618]
        ]
      ],
      "collector_type": "AGGREGATOR",
      "interval_milliseconds": 10000,
      "end_timestamp_milliseconds": 1497258041312,
      "grouping_field": "vol_id"
    }]
  },
  "error": null,
  "metadata": {
    "ready": true
  }
}

The response contains a list of collectors, with one item for each collector id that was requested. Each item includes the following fields:

  • id - the collector id.
  • fields - names of the collected data fields.
  • data - a list of collected entries, one entry per 10 seconds. Each entry contains all the entities that performed I/O (entities that did not do any I/O are omitted). For each entity there is a list of values ordered according to the field names that appear under fields.
  • interval_milliseconds - the number of milliseconds covered by each entry in the data list.
  • end_timestamp_milliseconds - the timestamp of the last entry in the data list, in milliseconds since the epoch. Using the timestamp and the interval, it is possible to calculate the timestamp of all entries in the list.

The response above contains the following metrics, for all volumes that did any I/O:

TimestampVolume idOpsThroughput
1497258031312 (2017-06-12 09:00:31.312 UTC)
 
 
61321
42269
1017175338
61319
36030
1207902580
61317
36014
1548901690
1497258041312 (2017-06-12 09:00:41.312 UTC)
  
61319
34874
1169198774
61321
41330
994592385
61317
34928
1502204618

(warning) Note that even though AGGREGATORS can collect data in multi-second intervals, the collected fields contain values averaged over the entire interval. So In the table above, 42269 is the average number of operations per second.

Field Reference

NFS

Filter fields

Name

Type

Allowed values

operation_type

enum

  • access
  • commit
  • create
  • dump
  • export
  • fs_information
  • fs_statistics
  • get_attributes
  • link
  • lookup
  • make_directory
  • make_node
  • mount
  • null_mnt
  • null_nfs
  • path_configuration
  • read
  • read_directory
  • read_directory_plus
  • read_link
  • remove
  • remove_directory
  • rename
  • set_attributes
  • symbolic_link
  • unmount
  • unmount_all
  • write

user_id

uint


group_id

uint


fs_entity_id

uint


export_id

uint


offset

uint


source_ip

uint


destination_ip

uint


operation_category

enum

  • meta_data
  • read
  • write

file_path

uint[]

The file_path parameter is a combination of the fs_id and the file_path

treequint[]The treeq parameter is a combination of the fs_id and the treeq

pool_id

uint


operation_size_histogram

histogram

  • ge_32k_lt_64k
  • ge_4k_lt_8k
  • ge_512k
  • ge_64k_lt_512k
  • ge_8k_lt_32k
  • lt_4k

Collector fields

Name

Unit

Description

ops

n/a

The number of Operations per second

operation_size

bytes

Breakdown of operations by size

average_operation_size

bytes

Average operations size

throughput

bytes/sec

Total throughput per second

latency

ms

Average latency for all operations

worker_time

ms

Average latency for all operations excluding waiting time in the queue

sections_read

n/a

The total number of sections which have been read

sections_read_from_cache

n/a

The number of sections which have been read from cache

sections_read_from_ssd

n/a

The number of sections which have been read from ssd

sections_read_from_disk

n/a

The number of sections which have been read from disk

Collector fields

Name

Unit

Description

qos_latency

ms

The total time it took QOS to answer

approved_ios

n/a

The number of approved operations per second

approved_throughput

n/a

Total size of approved operations per second

FC

Filter fields

Name

Type

Allowed values

protocol_type

enum

  • SAN
  • SAN_QOS

operation_category

enum

  • login
  • other
  • read
  • unmap
  • write
  • writesame
  • xcopy

operation_type

enum

  • caw
  • format_unit
  • inquiry
  • log_sense
  • login
  • mode_select
  • mode_sense
  • persistent_reserve_in
  • persistent_reserve_out
  • read
  • read_buf
  • read_capacity
  • receive_copy_result
  • release
  • report_luns
  • request_sense
  • reserve
  • rtpg
  • send_diagnostic
  • start_stop_unit
  • sync_cache
  • task_management_functions
  • test_unit_ready
  • unmap
  • verify
  • write
  • write_buf
  • write_same
  • xcopy

scsi_status

enum

  • busy
  • error
  • good

pool_id

uint


vol_id

uint


lba

uint


host_id

uint


initiator_port_key

uint


target_WWPN

uint


target_port

uint


source_ip

uint


destination_ip

uint


network_space_id

uint


initiator_WWPN

uint


initiator_IQN

uint


operation_size_histogram

histogram

  • ge_32k_lt_64k
  • ge_4k_lt_8k
  • ge_512k
  • ge_64k_lt_512k
  • ge_8k_lt_32k
  • lt_4k

Collector fields

Name

Unit

Description

operation_size

bytes

Total size of all SCSI operations (successful and failed)

throughput

bytes/sec

Total size of successful SCSI operations

external_latency

ms

The total latency to complete the SCSI command, from the initial request was received until the storage sent the final status. External latency may increase due to host / fabric delays

internal_latency

ms

The total latency incured waiting for the InfiniBox backend to complete the operation. Internal latency is not affected by host / fabric delays.

external_latency_wout_err

ms

Same as extenal latency, not counting errors

internal_latency_wout_err

ms

Same as intenal latency, not counting errors

sections_read

n/a

The total number of sections which have been read

sections_read_from_cache

n/a

The number of sections which have been read from cache

sections_read_from_ssd

n/a

The number of sections which have been read from ssd

sections_read_from_disk

n/a

The number of sections which have been read from disk

ops

n/a

The number of Operations per second

aborted_task

n/a

Number of tasks aborted by the InfiniBox backend

errors

n/a

Number of errors detected in SCSI operations

average_operation_size

bytes

Average size of all SCSI operation (successful and failed)

iSCSI

Filter fields

Name

Type

Allowed values

protocol_type

enum

  • SAN
  • SAN_QOS

operation_category

enum

  • login
  • other
  • read
  • unmap
  • write
  • writesame
  • xcopy

operation_type

enum

  • caw
  • format_unit
  • inquiry
  • log_sense
  • login
  • mode_select
  • mode_sense
  • persistent_reserve_in
  • persistent_reserve_out
  • read
  • read_buf
  • read_capacity
  • receive_copy_result
  • release
  • report_luns
  • request_sense
  • reserve
  • rtpg
  • send_diagnostic
  • start_stop_unit
  • sync_cache
  • task_management_functions
  • test_unit_ready
  • unmap
  • verify
  • write
  • write_buf
  • write_same
  • xcopy

scsi_status

enum

  • busy
  • error
  • good

pool_id

uint


vol_id

uint


lba

uint


host_id

uint


initiator_port_key

uint


target_WWPN

uint


target_port

uint


source_ip

uint


destination_ip

uint


network_space_id

uint


initiator_WWPN

uint


initiator_IQN

uint


operation_size_histogram

histogram

  • ge_32k_lt_64k
  • ge_4k_lt_8k
  • ge_512k
  • ge_64k_lt_512k
  • ge_8k_lt_32k
  • lt_4k

Collector fields

Name

Unit

Description

operation_size

bytes

Total size of all SCSI operations (successful and failed)

throughput

bytes/sec

Total size of successful SCSI operations

external_latency

ms

The total latency to complete the SCSI command, from the initial request was received until the storage sent the final status. External latency may increase due to host / fabric delays

internal_latency

ms

The total latency incured waiting for the InfiniBox backend to complete the operation. Internal latency is not affected by host / fabric delays.

external_latency_wout_err

ms

Same as extenal latency, not counting errors

internal_latency_wout_err

ms

Same as intenal latency, not counting errors

sections_read

n/a

The total number of sections which have been read

sections_read_from_cache

n/a

The number of sections which have been read from cache

sections_read_from_ssd

n/a

The number of sections which have been read from ssd

sections_read_from_disk

n/a

The number of sections which have been read from disk

ops

n/a

The number of Operations per second

aborted_task

n/a

Number of tasks aborted by the InfiniBox backend

errors

n/a

Number of errors detected in SCSI operations

average_operation_size

bytes

Average size of all SCSI operation (successful and failed)

RMR

Filter fields

Name

Type

Allowed values

operation_type

enum

  • read
  • write

io_type

enum

  • delta
  • delta_with_unmap
  • offline_unmap
  • unmap

replica_id

uint


replication_typeenum
  • async
  • sync

dataset_id

uint


pair_dataset_id

uint


node_id

uint


Collector fields

Name

Unit

Description

ops

n/a

The number of Operations per second

average_operation_size

bytes

Average operations size

throughput

bytes/sec

Total throughput per second

latency_histogram

ms

Breakdown of operations by latency

latency

ms

Average latency for all operations

sections_read_from_cache

n/a

The number of sections which have been read from cache

sections_read_from_disk

n/a

The number of sections which have been read from disk

sections_read_from_ssd

n/a

The number of sections which have been read from ssd

sections_read

n/a

The total number of sections which have been read

SAN

Filter fields

Name

Type

Allowed values

protocol

enum

  • FC
  • iSCSI

operation_category

enum

  • login
  • other
  • read
  • unmap
  • write
  • writesame
  • xcopy

operation_type

enum

  • caw
  • format_unit
  • inquiry
  • log_sense
  • login
  • mode_select
  • mode_sense
  • persistent_reserve_in
  • persistent_reserve_out
  • read
  • read_buf
  • read_capacity
  • receive_copy_result
  • release
  • report_devid
  • report_id
  • report_luns
  • request_sense
  • reserve
  • rtpg
  • send_diagnostic
  • start_stop_unit
  • sync_cache
  • task_management_functions
  • test_unit_ready
  • unmap
  • verify
  • write
  • write_buf
  • write_same
  • xcopy

scsi_status

enum

  • busy
  • error
  • good

pool_id

uint


vol_id

uint


lba

uint


host_id

uint


initiator_port_key

uint


target_WWPN

uint


target_port

uint


source_ip

uint


destination_ip

uint


network_space_id

uint


initiator_WWPN

uint


initiator_IQN

uint


operation_size_histogram

histogram

  • ge_32k_lt_64k
  • ge_4k_lt_8k
  • ge_512k
  • ge_64k_lt_512k
  • ge_8k_lt_32k
  • lt_4k

Collector fields

Name

Unit

Description

operation_size

bytes

Total size of all SCSI operations (successful and failed)

throughput

bytes/sec

Total size of successful SCSI operations

external_latency

ms

The total latency to complete the SCSI command, from the initial request was received until the storage sent the final status. External latency may increase due to host / fabric delays

internal_latency

ms

The total latency incured waiting for the InfiniBox backend to complete the operation. Internal latency is not affected by host / fabric delays.

external_latency_wout_err

ms

Same as extenal latency, not counting errors

internal_latency_wout_err

ms

Same as intenal latency, not counting errors

sections_read

n/a

The total number of sections which have been read

sections_read_from_cache

n/a

The number of sections which have been read from cache

sections_read_from_ssd

n/a

The number of sections which have been read from ssd

sections_read_from_disk

n/a

The number of sections which have been read from disk

ops

n/a

The number of Operations per second

aborted_task

n/a

Number of tasks aborted by the InfiniBox backend

errors

n/a

Number of errors detected in SCSI operations

average_operation_size

bytes

Average size of all SCSI operation (successful and failed)

SAN_QOS

Filter fields

Name

Type

Allowed values

qos_status

enum

  • lag
  • reject
  • success

qos_pool_id

uint


qos_entity_id

uint


resource_type

enum

  • entity
  • pool

resource_unit

enum

  • bw
  • io

Collector fields

Name

Unit

Description

qos_latency

ms

The total time it took QOS to answer

approved_ios

n/a

The number of approved operations per second

approved_throughput

n/a

Total size of approved operations per second



interval_milliseconds

Was this article helpful?
0 out of 0 found this helpful

0 out of 0 found this helpful

Comments