Mac

For macOS, we recommend running the self-contained Raygun agent.

Use the unzip command in the terminal to extract the Raygun Agent and ensure the following files are executable

  • RaygunAgent
  • rgc
  • start_agent.sh
  • stop_agent.sh
  • agent_controller.sh
# Change directory to the extracted folder  
cd runtime
sudo chmod +x RaygunAgent rgc 
cd ../bin
sudo chmod +x start_agent.sh stop_agent.sh agent_controller.sh

To run the agent use the start_agent.sh script in the bin directory

./start_agent.sh

The Raygun Agent can be run as a Docker container, see Running the Raygun agent on Docker.


When restarting the application there is an overhead that could cause the CPU to spike, but this high usage shouldn't persist. APM products will always have an overhead, but our goal is to ensure it's the lowest overhead possible. The high CPU usage you're experiencing is likely caused by a high method call count. We recommend setting up code filtering for a selection of high count method calls and seeing if this improves the CPU usage.

If this issue persists, please reach out to our engineering support team via the contact page, or click contact us in the app.


Run some basic status checks by using the rgc tool found in the runtime folder after unzipping the agent.

./rgc -status

The result should look similar to this:

Running Raygun Agent status checks...
Agent status: Registered
Agent test: Connected to the Raygun Agent v1.0.\*.0 on port 2790.
API test: Connected to the Raygun API at https://api2.raygun.com.
API key test: API key *** is valid
Profiler x86 test: 32-bit Profiler found at ...
Profiler x64 test: 64-bit Profiler found at ...

If any checks fail you will receive a message describing the problem. Here are some things you can try in order to resolve these problems:

  • Depending on your installation, list the running services or processes to check that the agent is running.
  • If the application you are profiling is on a separate machine from the agent check that traffic is allowed on port 2790.
  • Check that the machine running the Raygun Agent can access the Raygun API at https://api2.raygun.com/healthcheck, either using your browser or the cURL command. If you're using a browser, look for a 200 response in the network tab of the browser's developer tools.
  • Check that your firewall is not blocking Raygun.
  • Check that the API key is correct. If you have not sent any traces yet, your API key is displayed at the top of the instructions page for your new application. Otherwise, you can find the key under "Application settings" in the menu on the Raygun dashboard. Ensure that this is the same key that you used when you installed the agent.

If you are still not receiving traces, you will need to send us diagnostic session as described below:


  • The logs for the Raygun Agent are located in the /runtime/RaygunAgent.log file.

  • To enable detailed logging for the Raygun Agent, add a configuration setting to the appsettings.json file in the /runtime directory

  • Add update your runtime/appsettings.json to look like the following: (other loglevel options are Warning, Info, Verbose, Debug).

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "Agent": {
    "LogLevel": "Debug"
  }
}
  • Save the settings file and restart the Raygun Agent.

Running a diagnostics session will capture the following information and will help Raygun support to troubleshoot issues you're having:

  • Snapshot of log files
  • Snapshot of agent settings
  • Agent log files with log level of debug automatically set
  • Trace package and source files generated during the session
  • A trace of data being sent from the profiler to the agent

Start a diagnostics session that is uploaded to Raygun when complete

./rgc -auto-diagnostic 300

For more information on diagnostic command options, see the CLI documentation.


To be able to help you faster, we will need to know:

  • The diagnostic session identifier
  • Hosting type - cloud, on premise, Azure App Service etc
  • OS Version, 32 or 64 bit
  • Web Server (i.e. IIS or Node) version
  • Framework type (i.e. .NET Core or Rails)
  • Framework version
  • For .NET Core under IIS - in process or out of process hosting type