Skip to content
This repository has been archived by the owner on Dec 6, 2024. It is now read-only.

Commit

Permalink
Revisions
Browse files Browse the repository at this point in the history
  • Loading branch information
churanc committed Jun 11, 2020
1 parent ed7877e commit 63cbe99
Showing 1 changed file with 2 additions and 7 deletions.
9 changes: 2 additions & 7 deletions text/0000-template.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,11 +19,6 @@ The user must then set up the config service. This can be done throught the coll
Our protocol will support this call:

```
// DynamicConfig is a service on the collector that enables updating metric
// schedules, trace parameters, and other configurations on an agent/SDK without
// having to restart the instrumented application. The collector may also act as
// a bridge between third-party configuration services and the agent/sdk, piping
// updated configs from a third-party source to an instrumented application.
service DynamicConfig {
rpc GetConfig (ConfigRequest) returns (ConfigResponse);
}
Expand Down Expand Up @@ -170,15 +165,15 @@ have integrated remote configurations.

There are performance concerns, given that the agent is periodically reading from a service and using this config to update itself. Everything will be implemented optionally, so this will have minimal impact on users who opt not the dynamically update their configs.

The configuration service can be a potential attack vector for an application instrumented with Open Telemetry, depending on what we allow in the protocol. We can highlight in the protocol comments that we should be cautious about what kind of information the agent divulges in its request as well as the sort of behaviour changes that can come about from a config change.
As mentioned [here](https://github.com/open-telemetry/opentelemetry-proto/pull/155#issuecomment-640582048), the configuration service can be a potential attack vector for an application instrumented with Open Telemetry, depending on what we allow in the protocol. We can highlight in the protocol comments that we should be cautious about what kind of information the agent divulges in its request as well as the sort of behaviour changes that can come about from a config change.

## Prior art and alternatives

The alternative is to stick with the status quo, where the agent has a [fixed collection period](https://github.com/open-telemetry/opentelemetry-go/blob/34bd99896311a81cf843475779cae2e1c05e6257/sdk/metric/controller/push/push.go#L72-L76) and a fixed sampling rate.

## Open questions

- What happens if a malicious/accidental config change overwhelms the application/monitoring system? Is it the responsibility of the user to be cautious while making config changes? Should we automatically decrease telemetry exporting if we can detect performance problems?
- As mentioned here [https://github.com/open-telemetry/opentelemetry-proto/pull/155#issuecomment-640582048]. what happens if a malicious/accidental config change overwhelms the application/monitoring system? Is it the responsibility of the user to be cautious while making config changes? Should we automatically decrease telemetry exporting if we can detect performance problems?

## Future possibilities

Expand Down

0 comments on commit 63cbe99

Please sign in to comment.