Telemetry (Beta)

Using realtime product telemetry is like the first time you used a web browser. It can be difficult to wrap your head around the implications, but once you experience well-crafted and integrated content, you won’t want to go without it. Skycapp telemetry enablement is now in beta, with a sample “Skycapp Telemetry Bundle” ready for users to add to any platform configuration. Telemetry is currently opt-in at the platform environment level.

When enabled in platform environment settings, below, products that emit OpenTelemetry-compliant tracing or metrics data will be automatically configured with product-specific configuration settings established by the catalog curators.

Product developers may now begin experimenting with integrated OpenTelemetry tracing and metrics by emitting data to the following default endpoints. Products should generally disable telemetry by default, and be enabled via documented environment variables. If you do not have these settings established, it is suggested to use the following conventions:

  • SKYCAPP_TELEMETRY_TRACES_ENABLED=true (default should be false)
  • SKYCAPP_TELEMETRY_TRACES_URL=http://otel-collector:4318/v1/traces (using HTTP)
  • SKYCAPP_TELEMETRY_METRICS_ENABLED=true (default should be false)
  • SKYCAPP_TELEMETRY_METRICS_URL=http://otel-collector:4318/v1/metrics (using HTTP)

Curators will set certain variables to be present under the following conditions:

  1. User-Enabled Telemetry:
    • The user has enabled runtime telemetry.
  2. Documented Licensing Requirements:
    • The product has a documented licensing requirement that necessitates the variables be present by default.
    • This may be necessary to meet compliance or reporting requirements.

Below is a non-conventional, but compatible, example of configuration parameters as provided with HAPI FHIR.

Product Bundles: Multiple Copies of a Sub-Product

Products may now bundle multiple copies of the same supplementary product, which will recursively also include additional copies of it’s own sub-dependencies. They do not need to use the same configuration nor build version. This is useful to support use cases such as:

  • Connectivity between different instances of the same product, as is common when transmitting data between different parties.
  • Testing product upgrade paths between different versions or configurations of a product.

Product Bundles: Configuration Overrides

You can now attach runtime configuration overrides to any bundled product. This makes inter-vendor dependency maintenance much less fragile to underlying and upstream product changes, and makes it easier to deviate from configuration settings provided by an upstream vendor.

Additional Changes

  • Improvements to internal access controls, resolving quirks with anonymous access to published, invisible products.
  • Ability to override a default image run commands.
  • Adding product configurations to platform environments is now done purely on the server side, and resolves user issues with inaccessible product dependencies.
  • Many fixes and usability improvements!

Similar Posts