42ity/fty-metric-cache

Cache most recent valid metrics

fty-metric-cache

WARNING : This component is obsoleted and no longer used in the product.

Agent fty-metric-cache serves as in-memory cache of most recent metrics.

How to build

To build fty-metric-cache project run:

./autogen.sh
./configure
make
make check # to run self-test

How to run

To run fty-metric-cache project:

• from within the source tree, run:

./src/fty-metric-cache

For the other options available, refer to the manual page of fty-metric-cache

• from an installed base, using systemd, run:

systemctl start fty-metric-cache

Agent also has a command line interface fty-metric-cache-cli.

For further information, refer to the manual page of fty-metric-cache-cli.

Configuration file

Configuration file - fty-metric-cache.cfg - is currently ignored.

Agent reads environment variable BIOS_LOG_LEVEL to set verbosity level.

Agent has a state file stored in /var/lib/fty/fty-metric-cache/state_file.

Architecture

Overview

fty-metric-cache has 1 actor:

• fty-metric-cache-server: main actor

It also has one built-in timer, which runs every 30 seconds and deletes outdated metrics from the cache.

Protocols

Published metrics

Agent doesn't publish any metrics.

Published alerts

Agent doesn't publish any alerts.

Mailbox requests

Agent fty-metric-cache can be requested for:

• listing devices with (some) metrics available

• getting metrics for specified device

List devices with (some) metrics available

The USER peer sends the following message using MAILBOX SEND to FTY-METRIC-CACHE-SERVER ("fty-metric-cache") peer:

• zuuid/LIST - request list of devices with (some) metrics available

where

• '/' indicates a multipart string message
• subject of the message MUST be "latest-rt-data".

The FTY-METRIC-CACHE-SERVER peer MUST respond with this message back to USER peer using MAILBOX SEND.

• zuuid/OK/LIST/devices

where

• '/' indicates a multipart frame message
• 'devices' is a string of device names separated by newline
• subject of the message MUST be "latest-rt-data".

Get current metrics for specified asset

The USER peer sends the following message using MAILBOX SEND to FTY-METRIC-CACHE-SERVER ("fty-metric-cache") peer:

• zuuid/GET/element/[filter] - request current metrics for asset 'element'

where

• '/' indicates a multipart string message
• 'element' MUST be name of existing asset or a regex about asset name
• 'filter' is an optional parameter which filter as a regex type of metric
• subject of the message MUST be "latest-rt-data".

The FTY-METRIC-CACHE-SERVER peer MUST respond with this message back to USER peer using MAILBOX SEND.

• zuuid/OK/GET/element/metric-1/.../metric-n

where

• '/' indicates a multipart frame message
• 'metric-1',...,'metric-n' are ALL the current metrics (with valid TTL) available for 'element'
• subject of the message MUST be "latest-rt-data".

Stream subscriptions

Agent is subscribed to METRICS stream.

Received metrics are stored into local cache.

fty-metric-cache's Issues

Recent master failed memcheck

Today got some interesting faults in fty_metric_cache_server... only happen in memcheck, two different patterns. I wonder if it is some timing issue? Granted, the component is AFAIK deprecated, but the issues in it might be present elsewhere. So FYI

Two runs failed with lt-fty_metric_cache_selftest: src/fty_metric_cache_server.c:267: fty_metric_cache_server_test: Assertion encoded' failed.` and one failed nearby in the test log, but apparently had some encoded value which was not expected or something?

D: 19-05-16 13:41:09 [041] 28AAA10100000000000000005CDD6872000000050B74656D7065726174757265037570... lt-fty_metric_cache_selftest: src/fty_metric_cache_server.c:179: test_assert_proto: Assertion ... (lots of macro text expanded) failed

and the non-memchecks did run and did pass, so i'd guess timing... (latency with shm if involved
?..)

Jana Rapava wrote: Jim, from my previous investigation, I think it's a malamute issue... metrics/messages are there, but are not sent

struct _rt_t had to be revived in generated header file

Comment about customization left there; possibly re-generation should involve more files and the struct landed into another header with current zproject templates?..

(SPEC) Packaging had to be amended to deliver /etc/projname/ directory

no_config flag in project.xml is broken

According to a comment in .gitignore, we could not tell zproject to NOT generate service configs where we did not want them.