http://microsoft.github.io/DynamicTelemetry/docs/Architecture.Components.Processor.StateMachine.document/

Processor : State Machine

The State Machine Processor is a relatively simple yet highly effective component within Dynamic Telemetry. Essentially, this Processor listens to all log messages that pass by, identifying significant events and managing a state machine based on those events. When the state machine Processor detects an interesting log message, it transitions to a new state, potentially initiating an action as part of this transition.

Introduction to State Machine Processor

The State Machine Processor operates as a Directed Graph, where transitions occur upon the observation of specific logs by the Processor. This state machine is employed for tasks such as timing, counting, and measuring in contexts that pose significant challenges. The state machine is often accompanied by various actions and is utilized to initiate complex or resource-intensive operations.

Its primary function is to monitor logs and transition between states based on the analysis of log names and parameters. Initially, the state machine starts in an undefined state and then dynamically adjusts its state in response to the events it processes. This method is particularly effective for tasks such as timing, counting, and measuring in difficult contexts.

To provide an example, consider generating unique hashes of a file, such as data files or JPEG images.

Simple Code Example; hashing files

public string HashFile(string imageName)
{
    try
    {
        // 1. Log the start of the hashing process
        LogStartingFileHash(m_logger, imageName);

        // 2. Open the file and hash it
        using (FileStream fileStream = File.OpenRead(imageName))
        {
            string hashValue = Convert.ToBase64String(m_SHA256.ComputeHash(fileStream));

            // 3. Log the end of the hashing process
            LogEndFileHash(m_logger, imageName, hashValue);
            return hashValue;
        }
    }
    catch (Exception e)
    {
        // Log any exceptions that occur
        ErrorHashing(m_logger, imageName, e);
        throw;
    }
}

[LoggerMessage(Level = LogLevel.Information, Message = "Starting FileHash {fileName}.")]
static partial void LogStartingFileHash(ILogger logger, string fileName);

[LoggerMessage(Level = LogLevel.Information, Message = "Ending FileHash {fileName}, hash={hashValue}.")]
static partial void LogEndFileHash(ILogger logger, string fileName, string hashValue);

[LoggerMessage(Level = LogLevel.Warning, Message = "Unable to hash image {fileName}")]
static partial void ErrorHashing(ILogger logger, string fileName, Exception e);

Sample Code Overview

In this example you'll notice that the example code

1. Logs when we begin hashing
2. Hashs the file; or otherwise perform business logic
3. Logs when we've completed the hashing of the file

This workflow outlines a typical sequence of operations for a developer. Log messages may be disabled before entering production, used during diagnostics, or employed to indicate failure and success in traditional testing.

Modeling Live System Behavior, with a State Machine Processor

Consider the state model Processor as a tool to quickly and safely understand the system's operational characteristics after deployment.

The state machine Processor is typically beneficial in scenarios where software has been deployed into a production environment, and it cannot be rapidly altered or redeployed. It should be viewed as a diagnostic tool that can be employed extensively without affecting user security, privacy, or performance.

After a conclusion is reached by the state machine Processor, the production code is frequently modified to implement a more suitable and permanent solution. Consequently, the state machine Processor can be deactivated once the revised deployment is completed.

Lets look at a few examples, as they likely will help tell the tale

Image a piece of code that looks something like this:

Introducing Actions to the Dynamic Telemetry State Machine

Useful Actions

• CPU Sampling
• Verbose Logs

Example Scenarios