Update Trigger Actions implementation

Dbus trigger action names were modified to reflect separation of
Telemetry Service from Redfish:
- LogToLogService is renamed to LogToJournal,
- RedfishEvent was renamed to LogToRedfishEventLog

Both of those logging actions, now also include trigger id and threshold
name. Threshold naming logic:
- For discrete triggers, it can be specified by user, if left empty it
  will be changed to "{Severity} condition".
- Numeric triggers have no way of naming threshold, instead its type
  will be converted to string, example "UpperWarning"
- Discrete OnChange threshold will always be named "OnChange"

Additionally, defect was found with timestamp attached to Trigger Logs:
it was a steady_clock timestamp instead of system_clock. The function
which was supposed to format it was also working incorrectly, and was
improved to work with milliseconds. This change required major refactor
of unit tests, especially for numeric threshold.

Testing done:
- LogToJournal action is working properly,
- LogToRedfishEventLog action is working properly,
- UTs are passing.

Signed-off-by: Szymon Dompke <szymon.dompke@intel.com>
Change-Id: Iae2490682f0e9e2a610b45fd8af5cc5e21e66f35
23 files changed
tree: 0b35a417fc1cfdde754e5583a61cfdc50291f1d1
  1. redfish-tests/
  2. scripts/
  3. src/
  4. subprojects/
  5. tests/
  6. .clang-format
  7. .gitignore
  8. LICENSE
  9. MAINTAINERS
  10. meson.build
  11. meson_options.txt
  12. OWNERS
  13. README.md
  14. xyz.openbmc_project.Telemetry.service.in
README.md

Telemetry

This component implements middleware for sensors and metrics aggregation.

Capabilities

This application is implementation of Telemetry proposed in OpenBMC design docs [1].

It's responsible for:

  • on-demand creation of metric reports,
    • aggregated sets of sensor values available in system [2],
  • access to metric report in both pull and push model (triggers),
  • run-time monitoring of sensor[3] updates.

Use-cases

  • generic and centralized way to observe telemetry data inside system
  • back-end for Redfish TelemetryService[4]

How to build

There are two way to build telemetry service:

  • using bitbake in yocto environment
  • using meson as native build

To build it using bitbake follow the guide from OpenBMC docs[5]. To build it using meson follow the quick guide to install meson[6] and then run below commands

meson build
cd build
ninja

After successful build you should be able to run telemetry binary or start unit tests

./tests/telemetry-ut
./telemetry

In case if system is missing boost dependency, it is possible to build it locally and set BOOST_ROOT environment variable to location of built files for meson. After this change meson should be able to detect boost dependency. See [7] for more details.

Notes

More information can be found in OpenBMC docs repository [8].

References

  1. OpenBMC platform telemetry design
  2. Sensor support for OpenBMC
  3. dbus-sensors
  4. Redfish TelemetryService
  5. Yocto-development
  6. Meson-Quick-Guide
  7. Meson-Boost-dependency
  8. OpenBMC-docs-repository