Modify Trigger dbus api

'AddTrigger' method is now using array of strings for actions instead
of boolean flags. The action names are following:
- 'UpdateReport' (same as old flag)
- 'LogToLogService' (old 'LogToJournal' flag)
- 'RedfishEvent' (old 'LogToRedfish' flag)
Additionally, isDiscrete flag was removed from 'AddTrigger' call, as
this value can be extracted depending on threshold.

As a result new 'AddTrigger" signature is: "sasa{os}asv"
Example call parameters:
- TestTrigger 1 UpdateReport 0 0 "a(stsd)" 1 LowerWarning 1000
  Either 42.7'
- TestTrigger 2 UpdateReport RedfishEvent 0 0 "a(ssts)" 1 userId_1
  Warning 10 15.2'

'Trigger' properties were also modified. Instead of action bool
properties (same as mentioned above), new property was introduced
'TriggerActions' - which has same values as those used in 'AddTrigger'
method. This also affects persistence: store/load functionality was
modified accordingly.

As a side change - isDiscrete is no longer stored, as this can be easily
recreated in the runtime.

Tested:
- Trigger was successfully created using dbus.
- busctl introspect was called on test trigger and properties are
  modified and working as intended.
- persistency mechanic is working propetly.

Signed-off-by: Szymon Dompke <szymon.dompke@intel.com>
Change-Id: Icd64d4032fd6d446d9b6ad248e28e9031af1fed7
14 files changed
tree: 8b2d503f54a378cfd49f2154b69ff175b4991ae8
  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