Proposal: Expanded Application Lifecycle Schema (Class 6002)

[pladamgregory]

---

Proposal: Expanded Application Lifecycle Schema (Class 6002)

Description: This proposal introduces additional activities and attributes to the Application Lifecycle (Class 6002) schema. The goal is to enhance this class by covering operational metrics, configuration changes, data access, and user activities.

Application Lifecycle [6002] Class

Category: Application Activity
Application Lifecycle events capture installation, removal, start, stop, and other essential activities related to an application's operation and lifecycle.

---

Updated Activity IDs

Activity ID

Activity ID	Name	Description
0	Unknown	Reserved for unknown activity types.
1	Install	Initiates the installation of a software or component.
2	Remove	Uninstalls or deletes a software or component.
3	Start	Begins the execution of a process or service.
4	Stop	Halts the execution of a process or service.
5	Restart	Stops and then starts a process or service again.
6	Enable	Activates a feature or component within a system.
7	Disable	Deactivates a feature or component within a system.
8	Retry	Attempts to re-execute a failed action due to temporary issues.
9	Backup	Initiates a backup process to preserve data.
10	Recovery	Restores data or services following a failure or interruption.
11	Create_Config	Records the creation of a new configuration setting.
12	Update_Config	Tracks changes made to existing configuration settings.
13	Delete_Config	Logs the deletion of a configuration setting.
14	Data_Access	Tracks access to critical data, including read operations.
15	User_Activity	Logs actions taken by users, such as logins and feature use.
16	Notification	Tracks alerts and notifications sent by the system.
17	Error	Logs a significant error that occurs within a process or service.
18	Debug	Captures detailed logs for troubleshooting issues within the system.
19	Transaction	Logs the start, checkpoints, and end of complex transactions.
20	Session	Records details about user sessions, including duration and type.
21	Metric	Tracks performance metrics such as CPU and memory usage.
22	Trace	Provides detailed tracing information for debugging and observability.
99	Other	Use activity_name for data source-specific values not covered in the list.

---

New trace_info Object & Profile

Trace Object: Defines key application Trace Information for trace events. (Included Via trace profile)

Trace ID: trace_id (Required, String): Unique identifier for tracing this event across systems. Trace Type: trace_type (Required, Integer): Identifier for the trace type, linking related events. Trace Description: trace_description (Optional, String): Explanation or additional context about the trace type. OTeL Span Name: span_name (Required, String): The OTeL span name, as defined by the span_id. OTeL Span ID: span_id (Required, Integer): Spans represent specific operations in and between systems and is defined by https://opentelemetry.io/docs/specs/semconv/general/trace/,

• General: General Semantic Conventions.
• Cloud Providers: Semantic Conventions for cloud providers libraries.
• CloudEvents: Semantic Conventions for the CloudEvents specification.
• Database: Semantic Conventions for database operations.
• Exceptions: Semantic Conventions for exceptions.
• FaaS: Semantic Conventions for Function as a Service (FaaS) operations.
• Feature Flags: Semantic Conventions for feature flag evaluations.
• Generative AI: Semantic Conventions for generative AI (LLM, etc.) operations.
• GraphQL: Semantic Conventions for GraphQL implementations.
• HTTP: Semantic Conventions for HTTP client and server operations.
• Messaging: Semantic Conventions for messaging operations and systems.
• Object Stores: Semantic Conventions for object stores operations.
• RPC: Semantic Conventions for RPC client and server operations.
• System: System Semantic Conventions.

OTeL Attribues: otel_attributes (Optional, JSON): A dictionary of KV pairs containing the relevant attributes present within a particular OTeL log within Span for a particular event.

Integration via Trace Profiles:

The trace_info object will be added through a trace profile, allowing the association of trace IDs with events beyond application activities, such as HTTP activities or API calls. This ensures that all relevant events within a stack trace, which may belong to different activity classifications, can be included in observability correlation analysis. By associating a common trace_id, we can facilitate comprehensive tracking of related operations across various event types, enabling deeper insights into system behavior and performance.

Type ID Values:

ID	Trace Log Type	Description
1	Function/Method Entry and Exit Logs	Marks entry/exit points in functions, capturing parameters, return values, and timing for call sequences.
2	Transaction Boundary Logs	Tracks the start, checkpoints, and end of complex transactions, with status and timing, crucial for transaction integrity.
3	Dependency and External Service Interaction Logs	Captures interactions with external systems, including requests, responses, and latency for dependency insights.
4	Request and Response Lifecycle Logs	Logs the full lifecycle of requests, including metadata, response data, and processing time, for user request troubleshooting.
5	Error and Exception Trace Logs	Provides details on errors, including type, message, and stack trace, essential for diagnosing failures.
6	Conditional and Decision Branch Logs	Captures branching logic and outcomes, aiding in troubleshooting and analyzing behavior under different conditions.
7	Latency and Performance Logs	Tracks time taken by functions or components, identifying performance bottlenecks.
8	State and Variable Monitoring Logs	Logs critical variable values at execution points, useful for debugging complex transformations.
9	Loop Iteration Logs	Tracks loop iterations, especially in cases of item-by-item processing, isolating inefficiencies or issues within loops.
10	User Session and Authentication Trace Logs	Monitors session and authentication details for user behavior and security purposes.
11	Resource Management and Allocation Logs	Tracks resource usage, allocation, and deallocation, aiding in resource management and identifying potential memory leaks.
12	Event or Signal-Based Tracing Logs	Monitors event-driven interactions, providing insights into event handling in asynchronous systems.
0	Unknown	Reserved for unknown trace log types.
99	Other	Reserved for other trace log types not covered in the list.

---

Updated metric Object & Profile

Metric Object: Defines key application Metric Information for metric events. (Included Via metric profile)

Name: name (Required, String): Metric name (e.g., CPU usage, latency). Value: value (Required, String): Metric value. Type ID: type_id (Optional, Integer): Normalized ID for the metric type. OTeL Metric Name: metric_name (Required, String): The OTeL metric name, as defined by the metric_id. OTeL Metric ID: metric_id (Required, Integer): Metrics represent specific metrics within systems as defined by defined by https://opentelemetry.io/docs/specs/semconv/general/trace/,

• General Guidelines: General metrics guidelines.
• Database: For SQL and NoSQL client metrics.
• FaaS: For Function as a Service metrics.
• HTTP: For HTTP client and server metrics.
• Messaging: For messaging systems (queues, publish/subscribe, etc.) metrics.
• RPC: For RPC client and server metrics.
• System metrics
• System: For standard system metrics.
• Hardware: For hardware-related metrics.
• Process: For standard process metrics.
• Runtime Environment: For runtime environment metrics.

OTeL Attribues: otel_attributes (Optional, JSON): A dictionary of KV pairs containing the relevant attributes present within a particular OTeL log within Metric for a particular event.

Integration via Metric Profiles:

The metrics object will be added through a metrics profile, allowing the association of metrics with events beyond application activities, such as HTTP activities or API calls. This ensures that all relevant events which may contain a metric, which may belong to different activity classifications, can be included in observability correlation analysis. By associating common events with metrics in addition to application type events, we can facilitate comprehensive tracking of related operations across various event types, enabling deeper insights into system behavior and performance.

Examples of Type ID Values:

Type ID	Description
0	Unknown
1	Timestamp
2	Duration
3	Frequency
4	Latency
10	CPU Usage
11	Memory Usage
12	Disk I/O
13	Network Throughput
14	Queue Length
15	Thread Count
16	Execution Time
17	Resource Utilization
18	Disk Space Usage
19	Heap Size
20	Cache Hit Rate
21	Transaction Rate
22	Error Rate
23	Request Count
24	Success Rate
25	Concurrency
26	Response Time
27	Active Users
28	Session Duration
29	User Actions
30	Page Views
31	Error Count
32	Failure Rate
33	Retry Count
34	Downtime
35	System Uptime
36	Service Availability
37	Temperature
38	Battery Level
39	Data Volume
40	Data Quality
41	Compression Ratio
42	API Request Rate
43	API Error Rate
44	Cost Utilization
45	Instance Uptime
46	Threat Detection Rate
47	Security Event Count
48	Failed Authentication
49	Intrusion Detection
51	Model Accuracy
52	Model Latency
53	Training Time
54	Inference Count
55	Data Drift
56	Revenue
57	Customer Churn Rate
58	Conversion Rate
59	Customer Satisfaction
99	Other — See type_name

[pagbabian-splunk]

Much needed Adam, thanks. I think we should have clear descriptions of what constitutes a component vs a setting in addition to the descriptions and examples.

[pladamgregory]

Much needed Adam, thanks. I think we should have clear descriptions of what constitutes a component vs a setting in addition to the descriptions and examples.

I've made some changes to the activities, let me know what you think

[jonrau-at-queryai]

This feels like it could be a modification of Application Lifecycle which is a pretty limited Event Class in its own right currently.

[pladamgregory]

This feels like it could be a modification of Application Lifecycle which is a pretty limited Event Class in its own right currently.

I've made significant changes here to reflect the collective feedback @pagbabian-splunk @jonrau-at-queryai. Would love a re-review on the new context.