Guide for Persistence
Store Daemon Statistics

This section contains details on the Store's Daemon Statistics feature. You should already be familiar with the general information contained in Daemon Statistics.


Store Daemon Statistics Structures  <-

The different message types are:

Each one has a specific structure associated with it, as detailed in umedmonmsgs.h.

Note that message types ending with "_CONFIG" are in the config category, while message types ending with "_STATS" are in the stats category. See Daemon Statistics Structures for information on how the two categories are handled differently.


Store Daemon Statistics Byte Swapping  <-

A monitoring application receiving these messages must detect if there is an endian mismatch (see Daemon Statistics Binary Data). The header structure umestore_dmon_msg_hdr_t contains a 16-bit field named magic which is set equal to LBM_UMESTORE_DMON_MAGIC. The receiving application should compare it to LBM_UMESTORE_DMON_MAGIC and LBM_UMESTORE_DMON_ANTIMAGIC. Anything else would represent a serious problem.

If the receiving app sees:

then it can simply access the binary fields directly. However, if it sees:

then most (but not all) binary fields need to be byte-swapped. See umedmon.c for an example, paying special attention to the macros COND_SWAPxx (which conditionally swaps based on the magic test) and the functions byte_swapXX() (which performs the byte swapping).

However, there are some binary fields which must never be swapped, regardless of the endian. This is indicated in the documentation. For example, umestore_store_dmon_config_msg_t_stct::store_iface says "NOTE: This field should NOT be byte-swapped." Here's how that field might be accessed:

in.s_addr = msg->store_iface;
printf("Store IP address / port: %s / %d\n",
inet_ntoa(in), COND_SWAP16(msg_swap, msg->store_port));

As you can see, store_iface is not byte swapped, but store_port (conditionally) is swapped.


Store Daemon Statistics String Buffers  <-

There are some messages which contain string buffers at the ends of the messages. Strings in these data structures are always null-terminated. Be aware that these messages are not sent as fixed-length equal to the size of the data structure, but rather are sent with only the bytes required by the string (including the final null). For example, the structure umestore_store_pattern_dmon_config_msg_t contains the field umestore_store_pattern_dmon_config_msg_t_stct::pattern_buffer which is char array of size LBM_UMESTORE_DMON_TOPIC_PATTERN_STRLEN. If pattern_buffer is set to ".*", then only 3 bytes (including the null string terminator) are sent for that field.

Contrast this with UM Router Daemon Statistics String Buffers.

This becomes more complicated when there are multiple strings in one message. For example, consider umestore_store_dmon_config_msg_t. This message contains three strings: store name, cache directory name, and state directory name. But a single char array is declared:

char string_buffer[LBM_UMESTORE_DMON_STORE_NAME_STRLEN + (2 * LBM_UMESTORE_DMON_FILENAME_MAX_STRLEN)

The three strings are packed into that buffer, only taking up as much space as is necessary. I.e. if the three strings are "a", "b", and "c", only 6 bytes of the buffer will be consumed (each string has a null).

To make it easier for the code to find the three strings, the structure has three offset variables: store_name_offset, disk_cache_dir_offset, and disk_state_dir_offset. These are byte offsets from the start of the entire structure. So, to access the store name, the monitoring application might use:

umestore_store_dmon_config_msg_t *store_config_msg = ... /* ptr to incoming msg */
char *state_dir_name = (char *)store_config_msg +
store_config_msg->store_name_offset;

(The practice of using offsets from the start of the structure allows for greater flexibility in ensuring inter-version compatibility.)


Store Daemon Statistics Retx Counts  <-

There is a set of fields in umestore_store_dmon_stat_msg_t which give statistics on recovery operations initiated by receivers:

The web monitor's Store Web Monitor Store Page has a manual function labeled Reset Rate Stats which clears those "ume_retx_..._count" fields. This is a useful function for users who use the web monitor as their primary monitoring tool, but for users who depend on the published Daemon Statistics, it can be disruptive for the counts to be cleared on-demand.

The field umestore_store_dmon_stat_msg_t_stct::ume_retx_stat_interval contains the seconds since the last Reset Rate Stats operation. If the user has not used Reset Rate Stats, then ume_retx_stat_interval contains the seconds since the store's startup.


Store Daemon Statistics Configuration  <-

There are two places in the Store configuration file that Daemon Statistics are configured:

  • The <daemon-monitor> element inside the <daemon> definition. Configures all aspects of the Store Daemon Statistics feature, including publishing intervals.
  • The <publishing-interval> inside a <store> definition. Configures only the publishing intervals on a store basis.

Here is an example of configuring daemon statistics.

<ume-store version="1.3">
<daemon>
<daemon-monitor topic="bozo">
...
<publishing-interval>
<group name="default" ivl="3"/>
<group name="config" ivl="120"/>
</publishing-interval>
<remote-snapshot-request allow="1"/>
<remote-config-changes-request allow="1"/>
</daemon-monitor>
<daemon>
<stores>
<store name="store0" port="12000">
<publishing-interval>
<group name="default" ivl="6"/>
<group name="config" ivl="120"/>
</publishing-interval>
...
</store>
<store name="store1" port="12001">
...
</store>
</stores>

In this example, all stats-type messages are (conditionally) published on a 3-second interval, except those of store0, which are published (conditionally) on a 6-second interval. All config-type messages are published (unconditionally) on a 120-second interval.


Store Daemon Statistics Requests  <-

The Store Daemon supports a monitoring application to send a specific set of requests to control the operation of Daemon Statistics. The <remote-snapshot-request> and <remote-config-changes-request> elements control whether the Store enables this request feature (defaults to disabled).

If enabled, the monitoring application can send a command message to the store in the form of a topicless unicast immediate "request" message (see lbm_unicast_immediate_request() with NULL for topic). The format of the message is a simple ascii string, with or without null termination. Due to the simple format of the message, no data structure is defined for it.

When the Store receives and validates the command, it sends a UM response message back to the requesting application containing a status message (which is not null-terminated). If the status was OK, the Store also performs the requested action.

The example program umedcmd.c demonstrates the correct way to send the messages and receive the responses.

Commands enabled by <remote-snapshot-request>:

version
The Store returns in its command response the value of LBM_UMESTORE_DMON_VERSION. No daemon statistics messages are published.
snap memory
The Store immediately publishes the memory usage message LBM_UMESTORE_DMON_MPG_SMART_HEAP_STATS.
snap src
The Store immediately publishes the source repository statistics message(s) LBM_UMESTORE_DMON_MPG_REPO_STATS.
snap rcv
The Store immediately publishes the receiver statistics message(s) LBM_UMESTORE_DMON_MPG_RCV_STATS.
snap disk
The Store immediately publishes the disk statistics message(s) LBM_UMESTORE_DMON_MPG_DISK_STATS.
snap store
The Store immediately publishes the store statistics message(s) LBM_UMESTORE_DMON_MPG_STORE_STATS.
snap config
The Store immediately publishes the store config category messages LBM_UMESTORE_DMON_MPG_STORE_CONFIG, LBM_UMESTORE_DMON_MPG_STORE_PATTERN_CONFIG, LBM_UMESTORE_DMON_MPG_STORE_TOPIC_CONFIG, LBM_UMESTORE_DMON_MPG_REPO_CONFIG, and LBM_UMESTORE_DMON_MPG_RCV_CONFIG

Commands enabled by <remote-config-changes-request>:

memory N
Set the publishing interval for memory usage.
For example: memory 5
src N
Set the publishing interval for source repository statistics messages. This command can be preceded by a store name in double quote marks to only set the publishing interval for that store.
For example: "store1" src 5
rcv N
Set the publishing interval for receiver statistics messages. This command can be preceded by a store name in double quote marks to only set the publishing interval for that store.
For example: "store1" rcv 5
disk N
Set the publishing interval for disk statistics messages. This command can be preceded by a store name in double quote marks to only set the publishing interval for that store.
For example: "store1" disk 5
store N
Set the publishing interval for store statistics messages. This command can be preceded by a store name in double quote marks to only set the publishing interval for that store.
For example: "store1" store 5
config N
Set the publishing interval for config category messages. This command can be preceded by a store name in double quote marks to only set the publishing interval for that store.
For example: "store1" config 5