[llvm] [llvm]Add a simple Telemetry framework (PR #102323)

[James Henderson via llvm-commits]

================
@@ -23,82 +67,94 @@
 namespace llvm {
 namespace telemetry {
 
-using SteadyTimePoint = std::chrono::time_point<std::chrono::steady_clock>;
-
 struct TelemetryConfig {
   // If true, telemetry will be enabled.
-  bool enable_telemetry;
-
-  // Additional destinations to send the logged entries.
-  // Could be stdout, stderr, or some local paths.
-  // Note: these are destinations are __in addition to__ whatever the default
-  // destination(s) are, as implemented by vendors.
-  std::vector<std::string> additional_destinations;
+  bool EnableTelemetry;
+
+  // Implementation-defined names of additional destinations to send
+  // telemetry data (Could be stdout, stderr, or some local paths, etc).
+  //
+  // These strings will be interpreted by the vendor's code.
+  // So the users must pick the  from their vendor's pre-defined
+  // set of Destinations.
+  std::vector<std::string> AdditionalDestinations;
 };
 
+using SteadyTimePoint = std::chrono::time_point<std::chrono::steady_clock>;
+
 struct TelemetryEventStats {
-  // REQUIRED: Start time of event
-  SteadyTimePoint m_start;
-  // OPTIONAL: End time of event - may be empty if not meaningful.
-  std::optional<SteadyTimePoint> m_end;
+  // REQUIRED: Start time of an event
+  SteadyTimePoint Start;
+  // OPTIONAL: End time of an event - may be empty if not meaningful.
+  std::optional<SteadyTimePoint> End;
   // TBD: could add some memory stats here too?
 
   TelemetryEventStats() = default;
-  TelemetryEventStats(SteadyTimePoint start) : m_start(start) {}
-  TelemetryEventStats(SteadyTimePoint start, SteadyTimePoint end)
-      : m_start(start), m_end(end) {}
-
-  std::string ToString() const;
+  TelemetryEventStats(SteadyTimePoint Start) : Start(Start) {}
+  TelemetryEventStats(SteadyTimePoint Start, SteadyTimePoint End)
+      : Start(Start), End(End) {}
 };
 
 struct ExitDescription {
-  int exit_code;
-  std::string description;
+  int ExitCode;
+  std::string Description;
+};
 
-  std::string ToString() const;
+// For isa, dyn_cast, etc operations on TelemetryInfo.
+typedef unsigned KindType;
+struct EntryKind {
+  static const KindType Base = 0;
 };
 
-// The base class contains the basic set of data.
+// TelemetryInfo is the data courier, used to forward data from
+// the tool being monitored and the Telemery framework.
+//
+// This base class contains only the basic set of telemetry data.
 // Downstream implementations can add more fields as needed.
 struct TelemetryInfo {
   // A "session" corresponds to every time the tool starts.
   // All entries emitted for the same session will have
   // the same session_uuid
-  std::string session_uuid;
+  std::string SessionUuid;
----------------
jh7370 wrote:

I'm wondering whether this should really be a part of every telemetry event, or if it should somehow be attached further down the pipe, when needed. For example, in our internal telemetry library, we do have session IDs, but they're added as a "global" field within our JSON output file, and the thing that processes the JSON attaches this to each event when it sends the event over the internet to our server. Having these on every event is ultimately inefficient, given that the downstream vendor should be able to read the session ID from the session class and do with it what it wants to.

I'm also wondering whether it should HAVE to be a UUID? Whilst certainly a UUID makes sense in many cases (we use them in our internal library, for example), other tools might want to generate this value in other ways, e.g. a hash of timestamp/process ID/host ID etc. I'd just call it a session ID and leave the details to the vendor (with UUID being a "default" implementation that is used if the vendor doesn't provide an alternative mechanism).

https://github.com/llvm/llvm-project/pull/102323