In case you missed it, we released Ruby gem 2.10. It focusses mostly on diagnose and configuration. Though a bit late, here's a round-up of what's in the release.
The Idea Behind 2.10 Improvements
We support many setups and configurations, and this means that sometimes things occur that we didn't anticipate.
AppSignal is made by developers, for developers. Our team of developers handles all of the support requests personally. We believe you deserve to be Shibboleet by default.
Still, some users may prefer to fix things themselves. To help with that, we have found that running our diagnose tool helps a lot. This often points to the cause of a problem, making it easier to change the app's config to get things running. In other cases, it helps us pinpoint where things are going wrong so we can point you to a solution.
That's why improving things in the diagnose and the configuration was somewhat of a focus in this release.
Config Error Handling
We've improved how we validate some of AppSignal's config. This includes better error handling and checking config options for empty values.
config/appsignal.yml config file supports
ERB, which allows Ruby code to be executed in the YAML file. While this is very powerful, it can also break. When it does, the errors would bubble up and the application would crash. At AppSignal, we never want the application to crash caused by something in AppSignal. For this reason, the Ruby gem now catches the error and logs it to STDOUT and the AppSignal log file.
1# This would crash the app if the APPSIGNAL_PUSH_API_KEY system environment was 2# not present when the application starts. Now it prints the error instead. 3production: 4 push_api_key: <%= ENV.fetch("APPSIGNAL_PUSH_API_KEY") %>
This would print and log:
1appsignal: An error occurred while loading the AppSignal config file. Skipping file config. 2File: "/app/config/appsignal.yml" 3KeyError: key not found: "APPSIGNAL_PUSH_API_KEY"
Better Config Option Value Validation
When starting AppSignal, the Ruby gem validates the config options read from a variety of sources.
While any value for a config option, in some cases, would work, for one crucial config option, it most certainly won't. The
push_api_key config option must be set for any data to be reported to AppSignal. We'd like to make sure it has a value, and that value is not an empty string.
From now on, the
push_api_key config option will be checked for empty strings so that AppSignal will not be reported as "active" when it has this invalid configuration.
1# The APPSIGNAL_PUSH_API_KEY system environment would be an empty string in 2# this scenario. 3# export APPSIGNAL_PUSH_API_KEY=" " 4production: 5 push_api_key: <%= ENV["APPSIGNAL_PUSH_API_KEY"] %>
This would log:
1[2020-01-30T16:33:06 (process) #96089][ERROR] appsignal: Push API key not set after loading config
Previously, we supported this through our
The Ruby gem's diagnose command will help you debug any issues an app's AppSignal configuration may have. This is mostly presented in plain colorless text. Our server-side diagnose report viewer can analyze and report problems more accurately and be updated without releasing a new integration.
Even so, we understand that sometimes it's easier to view the report locally. For that scenario, we've added some coloring to important warnings that the diagnose command outputs, making it easier to spot problems locally.
PS: In order to use our
--send-report feature, it's required to update the AppSignal Ruby gem first to version 2.10.1 or newer.
Command Line Without Color
Color in the terminal output is great! Right?
Sometimes you may not want the colorful output in the terminal. For this reason, our commands all support a
--no-color option to make the output more readable on setups where the color codes are not rendered (properly).
1appsignal install --no-color PUSH_API_KEY 2appsignal diagnose --no-color
Since the Ruby gem 2.10.0 release, we've released two more patch releases with even more improvements. Be sure to upgrade to the latest version when upgrading.