Skip to content

dynamic configuration service #58

@davexroth

Description

@davexroth

Use Case

  • hypertrace agents should be able to obtain and update their configuration dynamically from a service.

Proposal

  • Define a grpc service which the hypertrace agents can use to obtain the AgentConfig configuration. If no config file is specified, and instead a HT_CONFIGURATION_ENDPOINT env var (or arg) is defined the agent will make a client request to the config endpoint to get the configuration. The agent will not start until it's successfully received its configuration.

Below is a proposed grpc service

service ConfigurationService {
  rpc InitialConfiguration(InitialConfigurationRequest) returns (InitialConfigurationRequest) {}
  rpc UpdateConfiguration(UpdateConfigurationRequest) return (UpdateConfigurationResponse) {}
}

message InitialConfigurationRequest {
  // service name is optional, but if set this
  // value will be used for the service name in the returned AgentConfig
  // if empty, the configuration service will define the config name 
  string service_name = 1;
  // hostname on which the agent is running
  string hostname = 2;
  // if running in a containerized environment the container id in which the agent is running
  string container_id = 3;
  // a map of identifiers the configuration service can use to apply a specific configuration to an agent
  map<string, string> identifiers = 4;
}

message InitialConfigurationRequest {
  // the timestamp associated with the configuration. This is the time
  // the configuration was persisted, not when it was sent.  The timestamp
  // should only change when the persisted configuration has changed.
  google.protobuf.Timestamp timestamp = 1;
  // configuration to be applied to the agent at initialization
  AgentConfig agent_config = 2;
}

message UpdateConfigurationRequest {
  // the timestamp of the current configuration
  google.protobuf.Timestamp timestamp = 1;
}

// not all configuration can be changed after the agent has started
// these are the properties which can be dynamically configured
// without restarting the agent
message UpdateConfigurationResponse {
  // the timestamp associated with the configuration
  // if there are no configuration change, this value will
  // equal UpdateConfigurationRequest.timestamp
  google.protobuf.Timestamp timestamp = 1;
  // enable or disable the agent.  This will not remove
  // any instrumentation when set to false, but the agent
  // will turn stop reporting spans, metrics etc
  google.protobuf.BoolValue enabled = 2;
  // data capture configuration which applies to all agents
  DataCapture data_capture = 3;
  // java agent specific configuration
  JavaAgent java_agent = 4;
}

The InitialConfigurationRequest will provide a number of properties which the configuration service can use to associate a configuration with the requesting agent. hostname should always be defined, and container_id should be defined whenever possible.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions