Type to search.

Troubleshoot APM Ruby Agent

Serverless Observability

Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Stack

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

Hopefully the agent Just Works™, but depending on your situation the agent might need some tuning.

First, to learn more about what’s going on inside the agent, you can increase the amount of log messages it writes. To do this, set the log level with the option log_level = 0 — 0 being the level of most messages, DEBUG.

In your config/elastic_apm.yml:

YAML
log_level: <%= Logger::DEBUG %>

The agent has an internal queue that holds events after they are done, and before they are safely serialized and sent to APM Server. To avoid using up all of your memory, this queue has a fixed size. Depending on your load and server setup, events may be added to the queue faster than they are consumed, hence the warning.

Things to consider:

  • Is server_url misconfigured or APM Server down? If the agent fails to connect you will also see log messages containing Connection error or Couldn't establish connection to APM Server.
  • Experiencing high load? The agent can spawn multiple instances of its Workers that pick off the queue by changing the option pool_size (default is 1).
  • If you have high load you may also consider setting transaction_sample_rate to something smaller than 1.0. This determines whether to include spans for every transaction. If you have enough traffic, skipping some (probably) identical spans won’t have a noticeable effect on your data.

In the unlikely event the agent causes disruptions to a production application, you can disable the agent while you troubleshoot.

If you have access to dynamic configuration, you can disable the recording of events by setting recording to false. When changed at runtime from a supported source, there’s no need to restart your application.

If that doesn’t work, or you don’t have access to dynamic configuration, you can disable the agent by setting enabled to false. You’ll need to restart your application for the changes to apply.