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

[Vy Nguyen 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;
----------------
oontvoo 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.


This is implementation details, yes? if you want to not use this field, you can leave it empty and resort to your library's global field.

The reason it is here is because in some usages, there could be multiple sessions going on at once, and each of these TelemetryInfo entry have to be tagged with the correct session-id before they're sent off. 


>  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.

Sorry, not sure I understand your example here. Where exactly is the session class?
These session-id are conventionally collected from the tool  being monitored. 

> 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).

Sure, we can rename it to SessionId.


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