Skip to end of banner
Go to start of banner

Big picture

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Agent startup

  1. Minimum initialization mode
    1. Only contain parts that are related to creating the initial connection to the CMR
  2. Agent tries to connect to CMR registration service.
    1. Adress of the CMR is defined by JVM parameters
    2. Agent provides its name (also given by JVM parameters)
  3. If connection is not possible, agent stays in minimum initialization mode (1) and keeps trying to connect to the CMR

Agent initialization

  1. (Agent can connect to the CMR)
  2. CMR find environment for the agent
    1. Environment is found by mapping table consisting of agent IP and name.
    2. If no environment is found, CMR and Agent log the problem and agent stop trying. Only restarting the agent will start over the process.
  3. CMR sends initial information to the agent called AgentConfiguration
    1. Based on the environment
    2. Agent-ID
    3. Configurations like sensors, strategies
  4. Full initialization mode
  5. Process all classes that were loaded while the agent was not fully initialized

Connection to CMR breaks

  1. Agent is in disconnected mode
  2. Agent collects all classes that are loaded and safe the name of them
  3. When connection is attained again process all classes

Process loaded classes

  1. Calculate hashcode for the class
  2. Figure out if this class needs to be sent to the server
    1. Cache on the agent allows to quickly find the solution
    2. Three possible options: needs to be instrumented, does not need to be instrumented, new class
    3. We agreed that we currently do not keep the bytecode of the instrumented classes on the agent.
    4. Thus we only need to store the hashes of classes that should not be sent.
  3. If necessary send bytecode to the server
    1. Add the hash of the class to the list of hashes NEVER to be send. This is because we need to differentiate between classes that need instrumentation and unknown ones that do not need instrumentation
    2. (When we get back the bytecode with instrumentation we remove this class again as we are sure that this class is necessary for instrumentation)
  4. Always give back the original bytecode! The new bytecode will be asynchronously instrumented on the server and send back to the agent.

Process "bytecode resend" request

  1. Agent updates cache to mark this class to be instrumented/send
  2. Load bytecode from JVM (open)
  3. Send bytecode to the CMR

Process "Redefine" request

  1. Redefine class based on the given class
  2. Update RSC on the hook
  3. If the bytecode is marked as original, mark this class in the cache as "not needed for instrumentation", meaning ensure that this entry is within the list of hashes not to be send.
  4. If the bytecode is marked as non original, verify that cache has this class as "needed for instrumentation", meaning remove the entry from the list of hashes not to be send.

Update environment (instrumentation configuration)

  1. Enduser on the UI updates the configuration (environment)
  2. Update the AgentConfiguration for all agents using this environment
  3. Run the changed environment against the class cache again. Class cache returns changed entities:
    1. "Bytecode resend" request: Class that was not instrumented before:
      1. Tell the agent to send the bytecode for this class again. (The class will undergo normal parsing & instrumentation process and the result will be returned to the agent.)
    2. "Redefine" request: Class that was instrumented before:
      1. Load original bytecode from cache in the CMR
      2. Run the instrumenter on this bytecode and send the bytecode to the agent. Mark if it is original bytecode.

 

 

 

 

 

 

 

 

 

The agent perspective

  • No labels