git-ecosystem / trace2receiver Goto Github PK

On Windows, named pipes are created with a default ACL that doesn't allow unprivileged users to connect and send data to the service. Users in the Administrators group have RW access, but the Everyone group only has R by default.

Give them RW.

My filter file reports at the expected detail level if I don't use a ruleset, e.g.:

keynames:
  nickname_key: "otel.trace2.nickname"

nicknames:
  "office": "dl:process"

defaults:
  ruleset: "dl:drop"

However, when I use a separate ruleset file, it seems to use the default detail level regardless:

keynames:
  nickname_key: "otel.trace2.nickname"

nicknames:
  "office": "rs:office"

rulesets:
  "rs:office": "C:/ProgramData/git-telemetry-service/rs-office.yml"

defaults:
  ruleset: "dl:drop"

My ruleset file:

commands:
  "git:config":             "dl:drop"
  "git:cat-file":           "dl:drop"
  "git:maintenance":        "dl:drop"
  "git:for-each-repo":      "dl:drop"

default:
  detail: "dl:process"

Yet whatever detail level I set in the ruleset, it still reports at the default detail level.

If Git dies with a BUG() error and trace2receiver process has data for the Git process, it should force dl:verbose for that process and override whatever filtering was configured so that we can capture as much information as possible about the failure in the Git process.

We were expecting that a undefined section in the YML would cause an error, rather than silently being ignored. Is there an option for this in the YML parser and/or do we need to validate the resulting dictionary for unknown/unexpected keys?

#24 (comment)

This is not urgent, but it would be nice to avoid such confusion in the future.

On Windows the collector (usually) runs as a Control Panel Service process and therefore inherits whatever system identity (LOCAL SERVICE). Logging the username of the collector in the OTLP data stream is not very useful.

We should use the feature of named pipes to get the (Windows) SID of the client process upon receiving an incoming named pipe connection and map that to a username and log that.

This is PII-sensitive, so it should only be done if requested in the pii.yml.

On Linux/Mac Unix domain sockets have a similar feature and IIRC is already being used.

I have noticed that once I introduced a filter.yml file limiting detail to "dl:summary", I no longer see git:remote-https commands in my telemetry data. Based on this section about detail levels, "dl:summary" is the default.

1. Are network calls e.g. git:remote-https intended to be filtered out at "dl:summary"?
2. Why was I getting telemetry for those commands before if the default was also "dl:summary"?
3. Is there a guide somewhere to what information/commands are reported at each detail level?

Thank you!