tree: 7e0fb9aae6e33a14cf54cb6730a7f9352a8195f9 [path history] [tgz]
  1. configs/
  2. fuzzer/
  3. meta/
  4. aggregate_and_upload_impl.cc
  5. aggregate_and_upload_impl.h
  6. aggregate_and_upload_impl_test.cc
  7. BUILD.gn
  8. cobalt_app.cc
  9. cobalt_app.h
  10. cobalt_app_test.cc
  11. cobalt_controller_impl.cc
  12. cobalt_controller_impl.h
  13. cobalt_controller_impl_test.cc
  14. cobalt_main.cc
  15. configuration_data.cc
  16. configuration_data.h
  17. configuration_data_test.cc
  18. diagnostics_impl.cc
  19. diagnostics_impl.h
  20. diagnostics_impl_test.cc
  21. metric_event_logger_factory_impl.cc
  22. metric_event_logger_factory_impl.h
  23. metric_event_logger_impl.cc
  24. metric_event_logger_impl.h
  25. metric_event_logger_impl_test.cc
  26. process_lifecycle_impl.h
  27. README.md
  28. system_data_updater_impl.cc
  29. system_data_updater_impl.h
  30. system_data_updater_impl_test.cc
  31. user_consent_watcher.cc
  32. user_consent_watcher.h
  33. user_consent_watcher_test.cc
  34. utils.cc
  35. utils.h
src/cobalt/bin/app/README.md

Cobalt FIDL Service

This directory contains an implementation of a FIDL service for Cobalt. The majority of the client-side logic for Cobalt lives in Cobalt Core and is imported into a Fuchsia checkout at //third_party/cobalt. The Cobalt FIDL service is an embedding of Cobalt Core into Fuchsia. The service implements Cobalt's FIDL protocols.

To use Cobalt on Fuchsia you follow these steps:

Register a metric

Before you can start using Cobalt on Fuchsia you need to register a project and a metric in the Cobalt registry. Note that Cobalt‘s registry repo is imported into a Fuchsia checkout at //third_party/cobalt_config. (The terminology config is sometimes, confusingly, used to refer to Cobalt’s registry.)

Update your BUILD.gn

Add import("//third_party/cobalt/metrics_registry.gni")

Add an invocation of metrics_registry in order to generate source code files containing constants corrsponding to the contents of your metrics registration. This facilitates your interaction with Cobalt's API. You must specify your project_id as it appears in projects.yaml.

We generate source code files for C++, Dart and Rust. Specify which languages you want generated by setting the parameters generate_cc, generate_dart, and generate_rust. These default to false. For example to generate C++ code for the memory project whose ID is 3509424520 you would add this invocation:

metrics_registry("memory_metrics_registry") {
  # This must match the ID of our Cobalt project as specified in:
  # third_party/cobalt_config/projects.yaml
  project_id = 3509424520
  namespace = "cobalt_registry"
  generate_cc = true
}

The string memory_metrics_registry is arbitrary and names the GN target so you can refer to it later. The optional namespace parameter specifies a C++ namespace into which the constant definitions will be included.

The generated code files are slightly different for each language. For C++ we generate a header file called <target_name>.cb.h where <target_name> is the name you gave to the metrics_registry target. Using the example above the generated file will be memory_metrics_registry.cb.h.

The generated code files will be created within the target gen dir for the metrics_registry target. For example assuming that the metrics_registry target given above occurs in //src/developer/memory/monitor/BUILD.gn, and assuming standard default values for GN parameters, the generated C++ file will be

out/default/gen/src/developer/memory/monitor/memory_metrics_registry.cb.h

You can peruse the generated file to see what constants are generated that can help you interact with the Cobalt API. Some examples are

  • The string name of the customer and project
  • The integer ID of the customer, project and metrics
  • Enums for the event codes

Add a dependency on the metrics_registry target

Add the metrics_registry target to the deps of any target that needs to depend on the generated code. Using our example from above, we would likely include :memory_metrics_registry in the deps of a source_set target for a C++ library that include .cc or .h files that #include memory_metrics_registry.cb.h.

Include the generated code files

Using the example from above we would add the line

#include "src/developer/memory/monitor/memory_metrics_registry.cb.h"

to any source file that needed to references the generated constants.

Initiate a connection to Cobalt's LoggerFactory Interface

Cobalt‘s LoggerFactory is a system service that is made available to every Fuchsia component and is served by Cobalt’s FIDL service. Before your program can start logging to Cobalt, it needs to establish a connection to the Cobalt FIDL service via this interface. The exact details of how this is done depend on a number of factors including

  • which programming language you are using
  • which version of the component framework is being used
  • whether you are using synchronous or asynchronous FIDL
  • whether you are using any client libraries as opposed to raw FIDL.

For example, to directly use synchronous FIDL and Components V1 you would write code similar to this:

sys::ComponentContext* context = SomehowGetTheContext();
fuchsia::cobalt::LoggerFactorySyncPtr logger_factory;
context->svc()->Connect(logger_factory.NewRequest());

There are wrapper libraries for Cobalt in C++ and Rust located here. You may use one of these libraries instead of directly using the raw FIDL code. We do not describe those libraries in this document and below we only describe the raw FIDL code.

Get a Cobalt Logger, passing in your project ID.

Continuing with the syncronous FIDL example from above

fuchsia::cobalt::Status status;
fuchsia::cobalt::LoggerSyncPtr logger;
logger_factory->CreateLoggerFromProjectId(cobalt_registry::kProjectId,
                                      logger.NewRequest(), &status);

Here cobalt_registry::kProjectId is a generated constant and the namespace cobalt_registry was specified in the example usage of metrics_registry above.

Instrument your code to gather the metrics data you wish to log to Cobalt.

This is entirely dependent on your application.

Log to Cobalt

The Logger protocol contains several methods corresponding to the different Cobalt metric types. For example the LogEvent() method corresponds to a Cobalt metric of type EVENT_OCCURRED, which is used to describe a simple occurrence in which the only data logged to Cobalt is an enum describing which event it is that occurred. Continuing with our code example from above:

logger->LogEvent(cobalt_registry::kSomeMetricId, DimensonName::EnumName, &status)

Here the names kSomeMetricId, DimensionName, and EnumName all refer to names in the generated code.