StoRM Backend installation and configuration guide

Introduction

The StoRM Backend service is the core of the StoRM services. It executes all SRM functionalities and takes care of file and space metadata management. It also enforces authorization permissions on files and interacts with external Grid services.

Install the service package

Grab the latest package from the StoRM repository. See instructions here.

Install the metapackage:

yum install storm-backend-mp

Service configuration

The Backend needs to be configured for two main aspects:

• service information: this section contains all the parameter regarding the StoRM service details. It relies on the storm.properties configuration file.
• storage information: this section contains all the information regarding Storage Area and other storage details. It relies on the namespace.xml file.

Both storm.properties and namespace.xml configuration file location is:

/etc/storm/backend-server

The storm.properties configuration file contains a list of key-value pairs that represent all the information needed to configure the StoRM Backend service. When the BackEnd starts, it writes into the log file the whole set of parameters read from the configuration file.

The namespace.xml configuration file contains the storage area info like what is needed to perform the mapping functionality, the storage area capabilities, which are the access and transfer protocols supported, etc..

Service information

Service Parameters

Garbage collector  

The requests garbage collector process cleans database from the expired asynchronous SRM requests. The value of expired.request.time defines how many seconds are necessary to a request, after its submission, to be considered expired. An appropriate tuning is needed in case of high throughput of SRM requests required for long time.

Expired PUT requests Garbage Collector

This agent:

• transits ongoing srmPtP to SRM_FILE_LIFETIME_EXPIRED if the request pin-lifetime is expired (see pinLifetime.default variable into Service Information section).
• transits to SRM_FAILURE the srmPtP that after expired.inprogress.time seconds are still in SRM_REQUEST_INPROGRESS.

The agent runs each transit.interval seconds and updates all the expired requests.

Reserved Space Garbage Collector

Synchronous call

REST interface parameters

Database connection parameters

SRM Requests Picker

Worker threads

Protocol balancing

Tape recall

Disk Usage Service

The Disk Usage Service has been introduced within StoRM v1.11.18 and allows administrators to enable periodic du calls on the storage area root directory in order to compute the used space size. By default the service is disabled. Set storm.service.du.enabled in yoir storm.properties file to enable it.

Example of output from internal log with an enabled du service with 0 delay and a week as interval:

04:26:50.920 - INFO [main] - Starting DiskUsage Service (delay: 0s, period: 604800s)
04:26:50.943 - INFO [main] - DiskUsage Service started.
...
04:26:50.961 - INFO [pool-6-thread-1] - DiskUsageTask for NESTED_TOKEN on /storage/nested started ...
04:26:51.364 - INFO [pool-6-thread-1] - DiskUsageTask for NESTED_TOKEN successfully ended in 0s with used-size = 4096 bytes
04:26:51.365 - INFO [pool-6-thread-1] - DiskUsageTask for IGI_TOKEN on /storage/igi started ...
04:26:51.455 - INFO [pool-6-thread-1] - DiskUsageTask for IGI_TOKEN successfully ended in 0s with used-size = 4096 bytes
04:26:51.458 - INFO [pool-6-thread-1] - DiskUsageTask for TAPE_TOKEN on /storage/tape started ...
04:26:51.624 - INFO [pool-6-thread-1] - DiskUsageTask for TAPE_TOKEN successfully ended in 0s with used-size = 8286 bytes
04:26:51.625 - INFO [pool-6-thread-1] - DiskUsageTask for TESTVOBIS_TOKEN on /storage/test.vo.bis started ...
04:26:51.784 - INFO [pool-6-thread-1] - DiskUsageTask for TESTVOBIS_TOKEN successfully ended in 0s with used-size = 4096 bytes
04:26:51.784 - INFO [pool-6-thread-1] - DiskUsageTask for NOAUTH_TOKEN on /storage/noauth started ...
04:26:51.857 - INFO [pool-6-thread-1] - DiskUsageTask for NOAUTH_TOKEN successfully ended in 0s with used-size = 4096 bytes
04:26:51.858 - INFO [pool-6-thread-1] - DiskUsageTask for TESTVO2_TOKEN on /storage/test.vo.2 started ...
04:26:51.993 - INFO [pool-6-thread-1] - DiskUsageTask for TESTVO2_TOKEN successfully ended in 0s with used-size = 4096 bytes
04:26:51.994 - INFO [pool-6-thread-1] - DiskUsageTask for TESTVO_TOKEN on /storage/test.vo started ...
04:26:52.100 - INFO [pool-6-thread-1] - DiskUsageTask for TESTVO_TOKEN successfully ended in 0s with used-size = 4108 bytes

Storage information

Information about storage managed by StoRM is stored in a configuration file named namespace.xml located at /etc/storm/backend-server/ on StoRM Backend host. One of the information stored into namespace.xml file is what is needed to perform the mapping functionality. The mapping functionality is the process of retrieving or building the transport URL (TURL) of a file addressed by a Site URL (SURL) together with grid user credential. The Fig 3 shows the different schema of SURL and TURL.

A couple of quick concepts from SRM:

• The SURL is the logical identifier for a local data entity
• Data access and data transfer are made through the TURLs
• The TURL identify a physical location of a replica
• SRM services retrieve the TURL from a namespace database (like DPNS component in DPM) or build it through other mechanisms (like StoRM)

In StoRM, the mapping functionality is provided by the namespace component (NS).

• The Namespace component works without a database.
• The Namespace component is based on an XML configuration.
• It relies on the physical storage structure.

The basic features of the namespace component are:

• The configuration is modular and structured (representation is based on XML)
• An efficient structure of namespace configuration lives in memory.
• No access to disk or database is performed
• The loading and the parsing of the configuration file occurs:
  • at start-up of the back-end service
  • when configuration file is modified

StoRM is different from the other solution, where typically, for every SRM request a query to the data base have to be done in order to establish the physical location of file and build the correct transfer URL. The namespace functions relies on two kind of parameters for mapping operations derived from the SRM requests, that are:

• the grid user credential (a subject or a service acting on behalf of the subject)
• the SURL

The Fig.4 shows the main concepts of Namespace Component:

• NS-Filesystem: is the representation of a Storage Area
• Mapping rule: represents the basic rule for the mapping functionalities
• Approachable rule: represents the coarse grain access control to the Storage Area.

This is and example of the FS element:

    <filesystem name="dteam-FS" fs_type="ext3">
        <space-token-description>DTEAM_TOKEN</space-token-description>
        <root>/storage/dteam</root>
        <filesystem-driver>it.grid.storm.filesystem.swig.posixfs</filesystem-driver>
        <spacesystem-driver>it.grid.storm.filesystem.MockSpaceSystem</spacesystem-driver>
        <storage-area-authz>
            <fixed>permit-all</fixed>
        </storage-area-authz>
        <properties>
            <RetentionPolicy>replica</RetentionPolicy>
            <AccessLatency>online</AccessLatency>
            <ExpirationMode>neverExpire</ExpirationMode>
            <TotalOnlineSize unit="GB" limited-size="true">291</TotalOnlineSize>
            <TotalNearlineSize unit="GB">0</TotalNearlineSize>
        </properties>
        <capabilities>
            <aclMode>AoT</aclMode>
            <default-acl>
                <acl-entry>
                    <groupName>lhcb</groupName>
                    <permissions>RW</permissions>
                </acl-entry>
            </default-acl>
            <trans-prot>
                <prot name="file">
                    <schema>file</schema>
                </prot>
                <prot name="gsiftp">
                    <id>0</id>
                    <schema>gsiftp</schema>
                    <host>gsiftp-dteam-01.cnaf.infn.it</host>
                    <port>2811</port>
                </prot>
                <prot name="gsiftp">
                    <id>1</id>
                    <schema>gsiftp</schema>
                    <host>gsiftp-dteam-02.cnaf.infn.it</host>
                    <port>2811</port>
                </prot>
                <prot name="rfio">
                    <schema>rfio</schema>
                    <host>rfio-dteam.cnaf.infn.it</host>
                    <port>5001</port>
                </prot>
                <prot name="root">
                    <schema>root</schema>
                    <host>root-dteam.cnaf.infn.it</host>
                    <port>1094</port>
                </prot>
            </trans-prot>
            <pool>
                <balance-strategy>round-robin</balance-strategy>
                <members>
                    <member member-id="0"></member>
                    <member member-id="1"></member>
                </members>
            </pool>
        </capabilities>
        <defaults-values>
            <space lifetime="86400" type="volatile" guarsize="291" totalsize="291"/>
            <file lifetime="3600" type="volatile"/>
        </defaults-values>
    </filesystem>

Attributes meaning:

• <filesystem name="dteam-FS" fs_type="ext3"> : The name is the element identifier. It identifies this Storage Area in the namespace domains. The fs_type is the type of the filesystem the Storage Area is built on. Possible values are: ext3, gpfs. Please note that ext3 stands for all generic POSIX filesystem (ext3, Lustre, etc.)
• <space-token-description>DTEAM_TOKEN</space-token-description> : Storage Area space token description.
• <root>/storage/dteam</root> : Physical root directory of the Storage Area on the file system.
• <filesystem-driver>it.grid.storm.filesystem.swig.posixfs</filesystem-driver> : Driver loaded by the Backend for filesystem interaction. This driver is used mainly to set up ACLs on space and files.
• <spacesystem-driver>it.grid.storm.filesystem.MockSpaceSystem</spacesystem-driver> Driver loaded by the Backend for filesystem interaction. This is driver is used to manage space allocation. (E.g. on GPFS it uses the gpfs_prealloc() call).

Storage Area properties

    <properties>
        <RetentionPolicy>replica</RetentionPolicy>
        <AccessLatency>online</AccessLatency>
        <ExpirationMode>neverExpire</ExpirationMode>
        <TotalOnlineSize unit="GB" limited-size="true">291</TotalOnlineSize>
        <TotalNearlineSize unit="GB">0</TotalNearlineSize>
    </properties>

in details:

• <RetentionPolicy>replica</RetentionPolicy> : Retention Policy of the Storage Area. Possible values are: replica, custodial.
• <AccessLatency>online</AccessLatency> : Access Latency of the Storage Area. Possible values: online, nearline.
• <ExpirationMode>neverExpire</ExpirationMode> : Expiration Mode of the Storage Area. Deprecated.
• <TotalOnlineSize unit="GB" limited-size="true">291</TotalOnlineSize> Total on-line size of the Storage Area in GigaBytes. In case the attribute limited-size=”true”, StoRM enforce this limit at SRM level. When the space used for the Storage Area is at least equal to the size specified, every further SRM request to write files will fail with SRM_NO_FREE_SPACE error code.
• <TotalNearlineSize unit="GB">0</TotalNearlineSize> : Total near-line size of the Storage Area. This only means in case the Storage Area is in some way attached to a MSS storage system (such as TSM with GPFS).

Storage area capabilities

    <aclMode>AoT</aclMode>

This is the ACL enforcing approach. Possible values are: AoT, JiT. In case of AheadOfTime(AoT) approach StoRM sets up a physical ACL on file and directories for the local group (gid) in which the user is mapped. (The mapping is done querying the LCMAPS service con the BE machine passing both user DN and FQANs). The group ACL remains for the whole lifetime of the file. In case of JustInTime(JiT) approach StoRM sets up and ACL for the local user (uid) the user is mapped. The ACL remains in place only for the lifetime of the SRM request, then StoRM removes it. (This is to avoid to grant access to pool account uid in case of reallocation on different users.)

    <default-acl>
        <acl-entry>
            <groupName>lhcb</groupName>
            <permissions>RW</permissions>
        </acl-entry>
    </default-acl>

This is the Default ACL list. A list of ACL entry (that specify a local user (uid) or group id (gid) and a permission (R,W,RW). This ACL are automatically by StoRM at each read or write request. Useful for use cases where experiment want to allow local access to file on group different than the one that made the SRM request operation.

#### Access and Transfer protocol supported

The file protocol:

    <prot name="file">
        <schema>file</schema>
    </prot>

The file protocol means the capability to perform local access on file and directory. If user performs an SRM request (srmPtG or srmPtP) specifying the file protocol, and it is supported by the selected Storage Area, StoRM return a TURL structured as:

file:///atlas/atlasmcdisk/filename

This TURL can be used through GFAL or other SRM clients to perform a direct access on the file.

    <prot name="gsiftp">
        <id>0</id>
        <schema>gsiftp</schema>
        <host>gridftp-dteam.cnaf.infn.it</host>
        <port>2811</port>
    </prot>

The gsiftp protocol:

The gsiftp protocol means the GridFTP transfer system from Globus widely adopted in many Grid environments. This capability element contains all the information about the GridFTP server to use with this Storage Area. Site administrator can decide to have different server (or pools of server) for different Storage Areas. The id is the server identifier to be used when defining a pool. The schema have to be gsiftp. host is the hostname of the server (or the DNS alias used to aggregate more than one server). The port is the GridFTP server port, typically 2811. If user performs an SRM request (srmPtG or srmPtP) specifying the gsiftp protocol, and it is supported by the selected Storage Area, StoRM return a TURL structured as:

gsiftp://gridftp-dteam.cnaf.infn.it:2811/atlas/atlasmcdisk/filename.

The rfio protocol:

    <prot name="rfio">
        <schema>rfio</schema>
        <host>rfio-dteam.cnaf.infn.it</host>
        <port>5001</port>
    </prot>

This capability element contains all the information about the rfio server to use with this Storage Area. Like for GridFTP, site administrator can decide to have different server (or pools of server) for different Storage Areas. The id is the server identifier. The schema have to be rfio. host is the hostname of the server (or the DNS alias used to aggregate more than one server). The port is the rfio server port, typically 2811. If user performs an SRM request (srmPtG or srmPtP) specifying the rfio protocol, and it is supported by the selected Storage Area, StoRM return a TURL structured as:

rfio://rfio-dteam.cnaf.infn.it:5001/atlas/atlasmcdisk/filename.

The root protocol:

    <prot name="root">
        <schema>root</schema>
        <host>root-dteam.cnaf.infn.it</host>
        <port>1094</port>
    </prot>

This capability element contains all the information about the root server to use with this Storage Area. Like for other protocols, site administrator can decide to have different server (or pools of server) for different Storage Areas. The id is the server identifier. The schema have to be root. host is the hostname of the server (or the DNS alias used to aggregate more than one server). The port is the root server port, typically 1094. If user performs an SRM request (srmPtG or srmPtP) specifying the root protocol, and it is supported by the selected Storage Area, StoRM return a TURL structured as:

root://root-dteam.cnaf.infn.it:1094/atlas/atlasmcdisk/filename.

Pool of protocol servers

    <pool>
        <balance-strategy>round-robin</balance-strategy>
        <members>
            <member member-id="0"></member>
            <member member-id="1"></member>
        </members>
    </pool>

Here is defined a pool of protocol servers. Within the pool element pool members are declared identified by their id, the list of members have to be homogenious with respect to their schema. This id is the server identifier specified in the prot element. The balance-strategy represent the load balancing strategy with which the pool has to be managed. Possible values are: round-robin, smart-rr, random and weight.
NOTE: Protocol server pooling is currently available only for gsiftp servers.
Load balancing strategies details:

• round-robin At each TURL construction request the strategy returns the next server following the round-robin approach: a circular list with an index starting from the head and incrementd at each request.

• smart-rr An enhanced version of round-robin. The status of pool members is monitored and maintained in a cache. Cache entries has a validity life time that is refreshed when expired. If the member chosen by round-robin is marked as not responsive another iteration of round-robin is performed.

• random At each TURL construction request the strategy returns a random member of the pool.

• weight An enhanced version of round-robin. When a server is chosen the list index will not be moved forward (and the server will be choosen again in next request) for as many times as specified in its weight.

NOTE: The weight has to be specified in a weight element inside the member element:

    <pool>
        <balance-strategy>WEIGHT</balance-strategy>
        <members>
            <member member-id="0">
                <weight>5</weight>
            </member>
            <member member-id="1">
                <weight>1</weight>
            </member>
        </members>
    </pool>

Storage space information default values

    <defaults-values>
        <space lifetime="86400" type="volatile" guarsize="291" totalsize="291"/>
        <file lifetime="3600" type="volatile"/>
    </defaults-values>

Mapping rules

A mapping rule define how a certain NS-Filesystem, that correspond to a Storage Area in SRM meaning of terms, is exposed in Grid:

    <mapping-rules>
        <map-rule name="dteam-maprule">
            <stfn-root>/dteam</stfn-root>
            <mapped-fs>dteam-FS</mapped-fs>
        </map-rule>
    </mapping-rules>

The <stfn-root> is the path used to build SURL referring to that Storage Area. The mapping rule above define that the NS-Filesystem named dteam-FS has to be mapped in the /dteam SURL path. Following the NS-Filesystem element defined in the previous section, the SURL:

srm://storm-fe.cr.cnaf.infn.it:8444/dteam/testfile

following the root expressed in the dteam-FS NF-Filesystem element, is mapped in the physical root path on the file system:

/storage/dteam

This approach works similar to an alias, from the SURL stfn-root path to the NS-Filesystem root.

Approachable rules

Approachable rules defines which users (or which class of users) can approach a certain Storage Area, always expressed as NS-Filesystem element. If a user can approach a Storage Area, he can use it for all SRM operations. If a user is not allowed to approach a Storage Area, and he try to specify it in any SRM request, he will receive an SRM_INVALID_PATH. In practics, if a user cannot approach a Storage Area, for him that specific path does not exists at all. Here is an example of approachable rule for the dteam-FS element:

    <approachable-rules>
        <app-rule name="dteam-rule">
            <subjects>
                <dn>*</dn>
                <vo-name>dteam</vo-name>
            </subjects>
            <approachable-fs>dteam-FS</approachable-fs>
            <space-rel-path>/</space-rel-path>
        </app-rule>
    </approachable-rules>

• <dn>*</dn> means that everybody can access the storage Area. Here you can define regular expression on DN fields to define more complex approachable rules.

• <vo-name>dteam</vo-name> means that only users belonging to the VO dteam will be allowed to access the Storage Area. This entry can be a list of comma separeted VO-name.

Used space initialization

An administrator can initialize the status of a Storage Area by editing a configuration file, the used-space.ini configuration file, that it’s parsed once at Backend’s bootstrap time. See this configuration example for more info.

Configure the service with YAIM

StoRM Backend can be configured with YAIM tool on CentOS 6 platform.

Read more about YAIM tool here and what are the general YAIM variables for a StoRM deployment.

StoRM Backend specific YAIM variables can be found in the following file:

/opt/glite/yaim/exaples/siteinfo/services/se_storm_backend

You have to set at least these variables in your site-info.def:

• STORM_BACKEND_HOST
• STORM_DEFAULT_ROOT
• STORM_DB_PWD

and check the other variables to evaluate if you like the default set or if you want to change those settings.

The following table summaries YAIM variables for StoRM Backend component.

Storage Area variables

Then, for each Storage Area listed in the STORM_STORAGEAREA_LIST variable, which is not the name of a valid VO, you have to edit the STORM_[SA]_VONAME compulsory variable. SA has to be written in capital letters as in the other variables included in the site-info.def file, otherwise default values will be used.

For the DNS-like names, that use special characters as ‘.’ or ‘-‘ you have to remove the ‘.’ and ‘-‘.
For example the SA value for the storage area “test.vo” must be TESTVO:

STORM_TESTVO_VONAME=test.vo

For each storage area SA listed in STORM_STORAGEAREA_LIST you have to set at least these variables: STORM_[SA]_ONLINE_SIZE You can edit the optional variables summarized in the following table:

The most important (and mandatory) parameters of storm.properties are configured by default trough YAIM with a standard installation of StoRM. All the other parameters are optionals and can be used to make advanced tuning of the Backend. To change/set a new value, or add a new parameter, just edit the storm.properties file and restart the Backend daemon.

To configure the service with YAIM, run the following command:

/opt/glite/yaim/bin/yaim -c -s SITEINFO.def -n se_storm_backend

Configure the service with Puppet

The StoRM puppet module can be used to configure the service on CentOS 7 platform.

The module contains the storm::backend class that installs the metapackage storm-backend-mp and allows site administrator to configure storm-backend-server service.

Prerequisites: A MySQL or MariaDB server with StoRM databases must exist. Databases can be empty. If you want to use this module to install MySQL client and server and init databases, please read about StoRM database utility class.

The Backend class installs:

• storm-backend-mp
• storm-dynamic-info-provider

Then, the Backend class configures storm-backend-server service by managing the following files:

• /etc/storm/backend-server/storm.properties
• /etc/storm/backend-server/namespace.xml
• /etc/systemd/system/storm-backend-server.service.d/storm-backend-server.conf
• /etc/systemd/system/storm-backend-server.service.d/filelimit.conf

and deploys StoRM databases. In addiction, this class configures and run StoRM Info Provider by managing the following file:

• /etc/storm/info-provider/storm-yaim-variables.conf

The whole list of StoRM Backend class parameters can be found here.

Example of StoRM Backend configuration:

class { 'storm::backend':
  hostname              => 'backend.test.example',
  frontend_public_host  => 'frontend.test.example',
  transfer_protocols    => ['file', 'gsiftp', 'webdav'],
  xmlrpc_security_token => 'NS4kYAZuR65XJCq',
  service_du_enabled    => true,
  srm_pool_members      => [
    {
      'hostname' => 'frontend.test.example',
    }
  ],
  gsiftp_pool_members   => [
    {
      'hostname' => 'gridftp.test.example',
    },
  ],
  webdav_pool_members   => [
    {
      'hostname' => 'webdav.test.example',
    },
  ],
  storage_areas         => [
    {
      'name'          => 'dteam-disk',
      'root_path'     => '/storage/disk',
      'access_points' => ['/disk'],
      'vos'           => ['dteam'],
      'online_size'   => 40,
    },
    {
      'name'          => 'dteam-tape',
      'root_path'     => '/storage/tape',
      'access_points' => ['/tape'],
      'vos'           => ['dteam'],
      'online_size'   => 40,
      'nearline_size' => 80,
      'fs_type'       => 'gpfs',
      'storage_class' => 'T1D0',
    },
  ],
}

Starting from Puppet module v2.0.0, the management of Storage Site Report has been improved. Site administrators can add script and cron described in the how-to using a defined type storm::backend::storage_site_report. For example:

storm::backend::storage_site_report { 'storage-site-report':
  report_path => '/storage/info/report.json', # the internal storage area path
  minute      => '*/20', # set cron's minute
}

StoRM database class  

The StoRM database utility class installs mariadb server and releated rpms and configures mysql service by managing the following files:

• /etc/my.cnf.d/server.cnf;
• /etc/systemd/system/mariadb.service.d/limits.conf.

The whole list of StoRM Database class parameters can be found here.

Examples of StoRM Database usage:

class { 'storm::db':
  root_password => 'supersupersecretword',
  storm_password => 'supersecretword',
}

Logging

The Backend log files provide information on the execution process of all SRM requests. All the Backend log files are placed in the /var/log/storm directory. Backend logging is based on logback framework. Logback provides a way to set the level of verbosity depending on the use case. The level supported are FATAL, ERROR, INFO, WARN, DEBUG.

The file

/etc/storm/backend-server/logging.xml

contains the following information:

<logger name="it.grid.storm" additivity="false">
    <level value="INFO" />
    <appender-ref ref="PROCESS" />
</logger>

the value can be set to the desired log level. Please be careful, because logging operations can impact on system performance (even 30% slower with DEBUG in the worst case). The suggest logging level for production endpoint is INFO. In case the log level is modified, the Backend has not to be restarted to read the new value.

StoRM Backend log files are the followings:

• storm-backend.log, the main log file with each single request and errors are logged;
• heartbeat.log, an aggregated log that shows the number of synch and asynch requests occoured from startup and on last minute;
• storm-backend-metrics.log, a finer grained monitoring of incoming synchronous requests, contains metrics for individual types of synchronous requests.

The storm-backend.log file

The main Backend service log file is:

• storm-backend.log. All the information about the SRM execution process, error or warning are logged here depending on the log level. At startup time, the BE logs here all the storm.properties value, this can be useful to check value effectively used by the system. After that, the BE logs the result of the namespace initialization, reporting errors or misconfiguration. At the INFO level, the BE logs for each SRM operation at least who have request the operation (DN and FQANs), on which files (SURLs) and the operation result. At DEBUG level, much more information are printed regarding the status of many StoRM internal component, depending on the SRM request type. DEBUG level has to be used carefully only for troubleshooting operation. If ERROR or FATAL level are used, the only event logged in the file are due to error condition.

The heartbeat.log file

StoRM provides a bookkeeping framework that elaborates informations on SRM requests processed by the system to provide user-friendly aggregated data that can be used to get a quick view on system health.

• heartbeat.log. This useful file contains information on the SRM requests process by the system from its startup, adding new information at each beat. The beat time interval can be configured, by default is 60 seconds. At each beat, the heartbeat component logs an entry.

A heartbeat.log entry example:

    [#.....71 lifetime=1:10.01]
        Heap Free:59123488 SYNCH [500] ASynch [PTG:2450 PTP:3422]
        Last:( [#PTG=10 OK=10 M.Dur.=150] [#PTP=5 OK=5 M.Dur.=300] )

This log information can be really useful to gain a global view on the overall system status. A tail on this file is the first thing to do if you want to check the health of your StoRM installation. From here you can understand if the system is receiving SRM requests or if the system is overloaded by SRM request or if PtG and PtP are running without problem or if the interaction with the filesystem is exceptionally low (in case the M.Dur. is much more than usual).

The storm-backend-metrics.log file

A finer grained monitoring of incoming synchronous requests is provided by this log file. It contains metrics for individual types of synchronous requests.

A storm-backend-metrics.log entry example:

16:57:03.109 - synch.ls [(m1_count=286, count=21136) (max=123.98375399999999, min=4.299131, mean=9.130859862802883, p95=20.736006, p99=48.147704999999995) (m1_rate=4.469984951030006, mean_rate=0.07548032009470132)] duration_units=milliseconds, rate_units=events/second

Here is the list of current logged operations: