Skip to content
Dynamic Telemetry is a PROPOSAL : please provide feedback! :-)

Dynamic Telemetry is not an implementation, it's a request for collaboration, that will lead to an shared understanding, and hopefully one or more implementations.

Your feedback and suggestions on this document are highly encouraged!

Please:

  1. Join us, by providing comments or feedback, in our Discussions page

  2. Submit a PR with changes to this file ( docs/Architecture.Components.Processor.Language.md)

Direct Sharing URL

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

Processor : Language

The Language Processor is one of the most versatile and capable Processors within Dynamic Telemetry; however, it also poses certain risks. The language Processor in Dynamic Telemetry enables the insertion of programming language into the telemetry and logging stream of a process. These instructions will have the full functionality of the supporting programming language and runtime.

Introduction to Language Processor

By incorporating a programming model into a telemetry stream, advanced observability and diagnostics can be achieved. For example, memory variables can be created, aggregates can be managed, individual threads can be monitored, and references can be tracked.

Additionally, complex triggering scenarios can be established, such as capturing a memory dump of a process when a reference count exceeds nominal and expected values.

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 Language Processor

In this scenario, where a file is being hashed, assume there is a bug in the hashing algorithm. For example, the implementation of the hashing algorithm might have race conditions or, in exceptional cases, memory misalignment. If one of these issues occurs, the hash for the input file will be incorrect, making it challenging to debug in a production system.

A Dynamic Telemetry Language Processor could be particularly useful for advanced diagnostics and tracking of this faulty hashing algorithm.

in this example one could imagine the pseudo code below being utilized in a randomized pattern and deployed using Dynamic Telemetry into a production environment as you can see in the pseudo code periodically the hash of a file will be doubly computed once in the production code and secondarily in the telemetry code

when or if hash is detected to be incorrect the Dynamic Telemetry language Processor is able to emit extra to diagnostic telemetry that indicates to the programmer who is monitoring the back end databases that in fact the hashing algorithm is failing

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

Image a piece of code that looks something like this:

Syntax error in textmermaid version 10.4.0

Verifying Hash Algorithm

void OnLog(LogMessage log)
{
    // Skip all logs, but the ending hash
    if(log.LogId == "LogEndFileHash")
    {
        string hashGeneratedInProduction = log.GetValue("hashValue");
        string file = log.GetValue("fileName");

        string comparisonHash = GenerateVerificationHash(file);

        if (hashGeneratedInProduction != comparisonHash)
        {
            m_Actions.GenerateNewLog(file, hashGeneratedInProduction, comparisonHash);
        }
    }
}

[LoggerMessage(Level = LogLevel.Error, Message = "ERROR: Language Processor detected production hash bug {fileName}")]
static partial void ErrorInProductionHash(ILogger logger, string fileName, string productHash, string comparisonHash);

Introducing Actions to the Dynamic Telemetry Language Processor

Useful Actions

Example Scenarios