svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ssid(7)
ssid(7) Standards, Environments, Macros, Character Sets, and miscellanyssid(7)
NAME
ssid - Statistics Store Identifier
DESCRIPTION
The Oracle Solaris Statistics Store uses statistics identifiers known
as ssids, ssids name system resources, statistics and events. SSIDs
also specify arithmetic and statistical operations on statistics and
formatting of event output.
ssids are used by the sstore(1) command and the libsstore(3LIB) library
calls. ssids can be defined through metadata, as described in the ssid-
metadata(7) man page.
Overview
An ssid is a string where only //: is a reserved sequence to separate
the components of the ssid. Each component can have its own character
restrictions.
A //:class and //:res component pair is required to identify a system
resource. The following example identifies CPU 0:
//:class.cpu//:res.id/0
The //:stat component identifies a statistic. The following SSID repre‐
sents the usage of CPU 0:
//:class.cpu//:res.id/0//:stat.usage
Some statistics can be viewed either as an aggregate or by selected
partitions, which are described in the //:part section. For example,
CPU usage can be broken down by mode (kernel, user, and so on):
//:class.cpu//:res.id/0//:stat.usage//:part.mode
An event is a time-specific change to a resource or class. The follow‐
ing SSID describes a fault of CPU 0:
//:class.cpu//:res.id/0//:event.fault
A variety of operations are available for statistics. For example:
//:class.cpu//:res.id/0//:stat.usage//:part.mode//:op.rate
A pre-defined set of formatting operations is available for events.
//:class.cpu//:res.id/0//:event.fault//:fmt.summary
Relationships between system resources can be represented as topology
in an ssid.
Slices and wildcard notation can be used to match multiple items in an
ssid. * is a simple wildcard character. The following examples show the
matching of CPUs in an ssid:
To match all CPUs //:class.cpu//:res.id/*
To match specific CPUs //:class.cpu//:res.id///:s.[0:5]
Each component of an SSID has metadata with information such as de‐
scription and data type. Use the info subcommand of sstore(1) to re‐
trieve this information.
Collections are references to groups of statistics and events.
Components
SSIDs can have the following components:
//:system
The system on which a statistic is produced. The default is //:sys‐
tem.name/localhost. Currently, only //:system.name/localhost is
supported.
//:class and //:res
A system resource is identified by a combination of class, the re‐
source type, and the resource name. A class defines how resources
can be named within that class. A single resource might be avail‐
able through multiple names within the same class. For example,
both of the following names refer to the same device.
o //:class.disk//:res.dev/zvblk0
o //:class.disk//:res.name/zvblk0
Resource names in SSIDs typically are the same as resource names
used in administrative commands.
In addition, note that some resources can appear in multiple
classes under different names, formally known as aliases. For exam‐
ple, a disk can appear in both //:class.disk and //:class.dev. How‐
ever, not all aliases for a given resource are always available.
Class names can contain only alphanumeric characters (lowercase
strongly encouraged) and the hyphen character (-), and must start
with an alphanumeric character. Resource names have no restric‐
tions.
As a best practice, use a unique company name when you add a class.
//:class.solaris/ and //:class.s/ are explicitly reserved.
//:class.site is available for administrative use.
Viewing Classes
The current list of classes on a specific system can be viewed
with the following command:
$ sstore list //:class.*
Viewing Resources
Resources within a class can be viewed with the following com‐
mand:
$ sstore list //:class.cpu//:res.*
Topology
Relationships between resources are represented in the ssid namespace
as topology links. Regardless of topology, you can reference any re‐
source in the system by the last class and resource in the ssid. Re‐
sources are never named solely by their topology.
While you do not need to know system topology to name a resource, there
are many situations in which exploring and representing topology are
useful. You represent topologies by allowing a class/resource pair af‐
ter other related resources, as in the following example:
//:class.chip//:res.id/0//:class.cpu//:res.id/0
//:class.chip//:res.id/0//:class.cpu//:res.id/1
This explains that chip 0 contains cpus 0 and 1.
A topology is only valid at a specific point in time as topologies
change. You may query the topology at a point of time in the past by
exploring the namespace at that time range.
//:stat
Both resources and classes can have statistics. A statistic is any
piece of information about the resource or class. There is a common
set of supported statistic types such as counters (preferred) and
scalars. See sstore(7) for more information about metadata in gen‐
eral and statistic types in particular.
//:class.link/phys//:res.name/net0//:stat.in-bytes
//:part
You can partition only statistics. Partitions provide a dynamic
view of entities that constitute that statistic. Partitions can be
defined as static or dynamic. A static partition includes a full
enumeration (in metadata) of the exact names of the entities in
that partition. One such static partition is the mode partition of
CPU usage shown as follows:
//:class.cpu//:stat.usage//:part.mode
A dynamic partition returns a different list of entities depending
on when you query it. In general, you should define partitions as
complete. Combining all entities in a partition should yield 100%
of the statistic. You can discover partitions on a statistic by us‐
ing the sstore list command as follows:
$ sstore list //:class.cpu//:stat.usage//:part.*
//:event
Events are time-specific information about changes to a resource or
class. Currently, events are captured for faults and administrative
actions on various resources.
For example, administrative actions, faults, and alerts for all
CPUs are respectively as follows:
o //:class.cpu//:res.id/*//:event.adm-action
o //:class.cpu//:res.id/*//:event.fault
o //:class.cpu//:res.id/*//:event.alert
//:op
A pre-defined set of mathematical and statistical operations is al‐
lowed on statistics. The operations available for any specific sta‐
tistic or event are constrained by its type and metadata.
The full list of operations is documented in ssid-op(7) and can be
shown by the following command:
//:class.cpu//:stat.usage//:part.mode//:op.rate
//:fmt
A pre-defined set of formatting operations is allowed for events.
The full list of formatting operations is documented in ssid-op(7)
and can be shown by the following command:
//:class.cpu//:res.id/0//:event.fault//:fmt.summary
//:collection
For more information, see the ssid-collection.json(5) man page
//:s and wildcards
You can use the * as a simple wildcarding mechanism. For example,
you can match all classes as follows:
//:class.*
The * can appear at any time and matches to the next //: separator.
For example, you can match all classes as follows:
//:clas*
You can also match a list of resources, statistics, partitions, and
other entities in the namespace using slices. This can be very
helpful when you are using operations.
You can use slices to match CPUs with ID 0-5 as shown in the fol‐
lowing example:
//:class.cpu//:res.id///:s.[0:5]
SEE ALSO
sstore(1), ssid-collection.json(5), ssid-metadata(7), ssid-op(7),
sstoreadm(1)
Oracle Solaris 11.4 11 May 2021 ssid(7)