Giter Site home page Giter Site logo

appsignal / appsignal-elixir Goto Github PK

View Code? Open in Web Editor NEW
271.0 12.0 81.0 3.59 MB

🟪 AppSignal for Elixir package

Home Page: https://www.appsignal.com/elixir

License: MIT License

Makefile 0.30% C 7.02% Elixir 91.36% Shell 0.52% HTML 0.52% Ruby 0.11% Dockerfile 0.17%
appsignal error-monitoring performance-monitoring custom-instrumentation elixir custom-metrics host-metrics phoenix plug apm

appsignal-elixir's Introduction

AppSignal for Elixir

Build Status Hex pm

AppSignal for Elixir monitors errors, performance and servers for Elixir applications.

Installation

Please follow the installation guide on how to install and use this library.

Then, add custom instrumentation or use one of the framework integrations to automatically gain performance insights and error notifications. Currently, AppSignal has framework integrations for Plug and Phoenix and applications.

Usage

AppSignal will automatically monitor requests, report any exceptions that are thrown and any performance issues that might have occurred.

You can also add extra information to requests by adding custom instrumentation. Read more in our instrumentation guide.

Configuration

A complete list of all configurable options for AppSignal for Elixir is available in our documentation.

Development

Setup

Before you can start developing on the AppSignal for Elixir project make sure you have Elixir installed.

This repository is managed by mono. Install mono on your local machine by following the mono installation steps.

Then make sure you have all the project's dependencies installed by running the following command:

$ mono bootstrap

Testing

Testing is done with ExUnit and can be run with the mix test command. You can also supply a path to a specific file path you want to test and even a specific line on which the test you want to run is defined.

$ mono test
# The original command can still be used
$ mix test
$ mix test test/appsignal/some_test.ex:123

This project has several different test suites defined with different mix environments. You can run them by specifying the specific type of test suite in the MIX_ENV environment variable.

# Default
$ MIX_ENV=test mix test

# Run the test suite with the NIF inoperational. This will generate errors
# because the NIF is not active, but should run without failures.
$ MIX_ENV=test_no_nif mix test

Benchmarking

This package uses benchee to benchmark code. To run the benchmarker:

$ MIX_ENV=bench mix run bench/<file>.exs

AddressSanitizer

A memory testing setup is included to detect memory errors in the NIF. It's set up in a Docker container to ensure reproducability.

To run the tests, build the container, which will build a version of the NIF with AddressSanitizer enabled. Then, run it with an APPSIGNAL_PUSH_API_KEY and APPSIGNAL_APP_NAME set to ensure AppSignal is enabled, and to be able to verify that data appears in AppSignal after running the test:

docker build --platform linux/amd64 -t appsignal-elixir-asan .
docker run \
  --env APPSIGNAL_PUSH_API_KEY=00000000-0000-0000-0000-000000000000 \
  --env APPSIGNAL_APP_NAME="appsignal-elixir" \
  --rm \
  -- \
  appsignal-elixir-asan

This test runs spans.exs, which is a script that calls most functions in the NIF.

Branches and versions

The main branch corresponds to the current release of the library. The develop branch is used for development of features that will end up in the next minor release. If you fix a bug open a pull request on main, if it's a new feature on develop.

Making changes

When making changes to the project that require a release, add a changeset that will be used to update the generated CHANGELOG.md file upon release.

$ mono changeset add

Publishing new versions

  1. Merge the develop branch to main if necessary.

Updating the CI build matrix

  1. Update .semaphore/versions.rb to add or remove Elixir/OTP versions, or .semaphore/semaphore.yml.erb.
  2. Run script/generate_ci_matrix.

Contributing

Thinking of contributing to our Elixir package? Awesome! 🚀

Please follow our Contributing guide in our documentation and follow our Code of Conduct.

Also, we would be very happy to send you Stroopwafles. Have look at everyone we send a package to so far on our Stroopwafles page.

Support

Contact us and speak directly with the engineers working on AppSignal. They will help you get set up, tweak your code and make sure you get the most out of using AppSignal.

Also see our SUPPORT.md file.

License

The AppSignal for Elixir package source code is released under the MIT License. Check the LICENSE file for more information.

appsignal-elixir's People

Contributors

aaronjensen avatar aksie avatar asummers avatar benmorganio avatar bittersweet avatar costaraphael avatar fatboypunk avatar jeffkreeftmeijer avatar jvanbaarsen avatar kagux avatar luismiramirez avatar matsimitsu avatar mcrumm avatar mdillavou avatar oliver-kriska avatar ono avatar philss avatar qhwa avatar roytomeij avatar rudolfhattenkofer avatar schrockwell avatar tgautier avatar the-mikedavis avatar thijsc avatar tombruijn avatar tylerpearson avatar uesteibar avatar unflxw avatar vrcmarcos avatar zachdaniel avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

appsignal-elixir's Issues

Do not warn about missing config when running tests

Right now when running mix test you see this each time:

15:39:40.523 [warn] Warning: No valid Appsignal configuration found, continuing with Appsignal metrics disabled.

Let's skip this warning when Mix.env == :test.

0.9.0 release notes say `import Appsignal.Instrumentation.Decorators` but I needed `use …`

Following the instructions at https://github.com/appsignal/appsignal-elixir/releases/tag/0.9.0 (under Instrumentation macro deprecation), I changed my instrumentation to

  import Appsignal.Instrumentation.Decorators

  @decorate transaction_event
  def bar(arg) do
    # code to be instrumented
  end

But then I got a compilation error:

== Compilation error on file lib/my_instrumented_module.ex ==
** (ArgumentError) Decorator :transaction_event can only be used with the @decorate syntax
    expanding macro: Appsignal.Instrumentation.Decorators.transaction_event/1
    lib/my_instrumented_module.ex:22: MyInstrumentedModule (module)
    (elixir) expanding macro: Kernel.@/1
    lib/my_instrumented_module.ex:22: MyInstrumentedModule (module)

When I changed the import to use, the module compiled and the instrumentation was correctly sent to AppSignal.

Should import have worked? If not, and we need to use use, can the release notes be updated?

Drop Phoenix dependency

I'm not very familiar with how Elixir dependancies work and if they add bloat, so this may be a non-issue but wondering why is Phoenix a dependency? Should it only be if I'm including AppSignal on a Phoenix app?

Manually sending errors

I'm a little unsure if it's supposed to be a feature, but I'm currently trying to manually send exceptions like so:

Appsignal.send_error(%RuntimeError{message: error}, "Error", System.stacktrace(), context)

context is just a map of metadata

This is running locally in development where im attempting to test this. I have the API key set in env var and active: true set in the dev.exs configuration.

I'm not seeing any errors come through, I'm guessing im doing something wrong here! Any direction would be appreciated :)

Toniq errors are not tracked

Toniq uses the error log to report errors. I thought that appsignal listened to that, but I'm not seeing errors when I intentionally cause them.

Should this work or is this not hooked up?

See: joakimk/toniq#29

Error: Poison.EncodeError at GET / expected string or atom key, got: 1

Since updating to 0.7.0 I'm getting the following error on every page load:

Poison.EncodeError at GET /
expected string or atom key, got: 1

[error] #PID<0.2361.0> running MyApp.Endpoint terminated
Server: localhost:4000 (http)
Request: GET /
** (exit) an exception was raised:
    ** (Poison.EncodeError) expected string or atom key, got: 1
        (poison) lib/poison/encoder.ex:188: Poison.Encoder.Map.encode_name/1
        (poison) lib/poison/encoder.ex:212: anonymous fn/4 in Poison.Encoder.Map.encode/3
        (poison) lib/poison/encoder.ex:214: Poison.Encoder.Map."-encode/3-lists^foldl/2-0-"/3
        (poison) lib/poison/encoder.ex:214: Poison.Encoder.Map.encode/3
        (poison) lib/poison/encoder.ex:213: anonymous fn/4 in Poison.Encoder.Map.encode/3
        (poison) lib/poison/encoder.ex:214: Poison.Encoder.Map."-encode/3-lists^foldl/2-0-"/3
        (poison) lib/poison/encoder.ex:214: Poison.Encoder.Map.encode/3
        (poison) lib/poison.ex:41: Poison.encode!/2
        (appsignal) lib/appsignal/transaction.ex:189: Appsignal.Transaction.set_sample_data/3
        (appsignal) lib/appsignal/phoenix.ex:66: Appsignal.Phoenix.submit_http_error/5
        (my_app) lib/my_app/endpoint.ex:50: MyApp.Endpoint."call (overridable 2)"/2
        (my_app) lib/plug/debugger.ex:123: MyApp.Endpoint."call (overridable 3)"/2
        (my_app) lib/my_app/endpoint.ex:1: MyApp.Endpoint.call/2
        (plug) lib/plug/adapters/cowboy/handler.ex:15: Plug.Adapters.Cowboy.Handler.upgrade/4
        (cowboy) src/cowboy_protocol.erl:442: :cowboy_protocol.execute/4

My config

config :appsignal, :config,
  name: :my_app,
  push_api_key: "............................",
  env: :dev,
  enable_host_metrics: true

Don't crash the compilation on unsupported OS'es

Currently the compilation fails when trying to compile Appsignal e.g. on windows (see #36). It would be nicer if the NIF compilation would just be skipped and a big red warning printed that Appsignal is not supported on the platform.

cc @nulian

Update Rust agent version

The current version of the Elixir integration is locked on revision 220a888 of the agent. We'll need to update it to a more recent version to stay up to speed with the Ruby integration.

It does not work on Microsoft Windows

I guess it's not a priority, just to make sure it's recorded somewhere.

** (FunctionClauseError) no function clause matching in Mix.Appsignal.Helper.map_arch/1
mix_helpers.exs:103: Mix.Appsignal.Helper.map_arch('win32')

To do

@tombruijn: AppSignal team, see my comment for a to do list: #36 (comment)

mix appsignal.install

WIZARD STEP 0

  1. Ruby [old Ruby flow]
  2. Elixir [new Elixir flow]

WIZARD STEP 1

  1. Mix.exs
  2. Appsignal started before application
  3. Mix deps.get

CLI STEP 1

  1. Generate Config file
    • receive push_api_key
    • get app name
  2. Environment variables
  3. PUT how to do it

CLI STEP 2

  1. Check environments
  2. Add config per environment
  3. Exclude test

CLI STEP 3

  1. AppSignal DEMO

CLI STEP 4

Using Phoenix?

  • HTTP requests
  • Template
  • Queries
  • Instrumentation hooks
    Check docs at ...

WIZARD 3

Using Phoenix?

  • HTTP requests
  • Template
  • Queries
  • Instrumentation hooks

Check docs at ..

TODO

  • Send demo samples on installation completion #136
  • Link to docs on Phoenix detection

Compile error when using defp inside instrumented macro

  instrumented :http do

    defp foo do
      1
    end

  end
== Compilation error on file web/support/backend.ex ==
** (FunctionClauseError) no function clause matching in Appsignal.Helpers.expand_instrumented/2
    lib/appsignal/helpers.ex:120: Appsignal.Helpers.expand_instrumented(".http", [do: {:defp, [line: 11], [{:foo, [line: 11], nil}, [do: 1]]}])
    expanding macro: Appsignal.Helpers.instrumented/2
    web/support/backend.ex:9: WebApp.Backend (module)
    (elixir) lib/kernel/parallel_compiler.ex:116: anonymous fn/4 in Kernel.ParallelCompiler.spawn_compilers/1

Submit all request headers

On submitting an error or sample data, we should send all request headers to Appsignal when the %Plug.Conn{} structure is known. This allows for easier debugging and replaying of requests.

On the Ruby gem, this is harder becaue the request headers are mixed in with the general environment variables; on Elixir this is not the case.

See #18

cc @Wijnand @thijsc

Config gets reset on hot upgrade

When a node is hot-upgraded using an appup, the Appsignal configuration gets reset to how it was defined in the config. This is according to how releases work but it loses all "calculated" config properties (default values; values derived from the OS env) that gets set in the Config.initialize() call.

We should find a way to call Config.initialize() again after a hot upgrade.

cc @danielwillemse @jeffkreeftmeijer

Move environment to string rather than atom?

Right now the environment is set with the following config:

config :appsignal, :config,
  name: :my_first_app,
  push_api_key: "your-hex-appsignal-key",
  env: :prod

I'm interested to understand if there is any reason for not making the environment a string rather than an atom. At the moment it prevents using anything else than :prod, :test or :dev. I'd really like to set it to staging for instance.

Compiling fails with paths containing spaces

Hi there!

It seems compiling fails if the path contains spaces. I fixed this by slapping quotes around everything I could find in the Makefile. But since I didn't really know what I was doing, I did not PR it.

Cheers

Alpine Linux support

Hey,

I’m trying out the Beta of AppSignal for Elixir and ran into an issue when using building the Docker image that I use to ship the app. It looks to me that the download of the AppSignal agent causes the problem. Maybe downloading the agent after compilation isn’t the best approach…

Anyway, here is my log dump (or part of it). Would be great if you could look into this.

Thanks

Compiling 1 file (.ex)
Generated uuid app
==> mime
Compiling 1 file (.ex)
Generated mime app
==> plug
Compiling 44 files (.ex)
Generated plug app
==> cors_plug
Compiling 1 file (.ex)
Generated cors_plug app
==> phoenix_html
Compiling 8 files (.ex)
Generated phoenix_html app
==> exrm
Compiling 11 files (.ex)
warning: function beam_imports/1 is unused
  lib/exrm/appups.ex:98

warning: variable v2_file is unused
  lib/exrm/appups.ex:84

Generated exrm app
==> phoenix
Compiling 60 files (.ex)
Generated phoenix app
==> appsignal
could not compile dependency :appsignal, "mix compile" failed. You can recompile this dependency with "mix deps.compile appsignal", update it with "mix deps.update appsignal" or clean it with "mix deps.clean appsignal"
** (FunctionClauseError) no function clause matching in Mix.Appsignal.Helper.map_arch/1
    mix_helpers.exs:88: Mix.Appsignal.Helper.map_arch('x86_64-alpine-linux-musl')
    mix_helpers.exs:13: Mix.Appsignal.Helper.ensure_downloaded/0
    mix.exs:6: Mix.Tasks.Compile.Appsignal.run/1
    (mix) lib/mix/task.ex:296: Mix.Task.run_task/3
    (elixir) lib/enum.ex:1184: Enum."-map/2-lists^map/1-0-"/2
    (mix) lib/mix/tasks/compile.all.ex:19: anonymous fn/1 in Mix.Tasks.Compile.All.run/1
    (mix) lib/mix/tasks/compile.all.ex:37: Mix.Tasks.Compile.All.with_logger_app/1
    (mix) lib/mix/task.ex:296: Mix.Task.run_task/3

The command '/bin/sh -c mix compile' returned a non-zero code: 1

Failure with error reporting

I'm trying to get error reporting to work on a trial account. I've written a very simple controller:

def MyApp.HomeController do
  def boom(_, _) do
    IO.puts " >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>"
    raise "AEHOOOOOO"
  end
end

and in the endpoint.ex:

defmodule MyApp.Endpoint do
  use Phoenix.Endpoint, otp_app: :lukla_web
  use Appsignal.Phoenix
# ...
end

When calling this action, I get the following in the console:

17:28:34.661 request_id=1e9odipejcgj3vijf08kgs3c812gfnc6 [info] Sent 500 in 10ms
17:28:34.663 [debug] Submitting AppSignal.Transaction{oesu2asj4c1m8}: HTTP request #PID<0.871.0> crashed
Server: localhost:4000 (http)
Request: GET /boom
** (exit) an exception was raised:
    ** (RuntimeError) AEHOOOOOO
        (my_app) web/controllers/home_controller.ex:54: MyApp.HomeController.exploda/2
        (my_app) web/controllers/home_controller.ex:1: MyApp.HomeController.action/2
        (my_app) web/controllers/home_controller.ex:1: MyApp.HomeController.phoenix_controller_pipeline/2
        (my_app) lib/my_app/endpoint.ex:1: MyApp.Endpoint.instrument/4
        (my_app) lib/phoenix/router.ex:261: MyApp.Router.dispatch/2
        (my_app) web/router.ex:1: MyApp.Router.do_call/2
        (my_app) lib/my_app/endpoint.ex:1: MyApp.Endpoint.phoenix_pipeline/1
        (my_app) lib/my_app/endpoint.ex:3: MyApp.Endpoint."call (overridable 2)"/2

How should I debug this? I'm sure the process is sending stuff over to push.appsignal.com I tcp dump'd it, but nothing shows up on the error interface @ appsignal.com

What should I do?

Transaction decorator

To make it easier to instrument events outside of a transaction, we'll add a transaction decorator that starts a transaction itself. Here's a prototype.

Application is not compiling after update to 0.11.0

When I try to compile my application for the first time, the following error happens:
image

Looking at the source, I found that there is a new check at the top of lib/appsignal/phoenix.ex, that checks if Phoenix is present with Code.ensure_loaded?/1.

The problem is, when the appsignal application is compiled, phoenix is not compiled yet, which causes the check to return false.

A workaround to this is to compile phoenix first and then compile the rest of the dependencies: mix do deps.compile plug, deps.compile phoenix, compile.

I guess that there are better ways to check if phoenix is present (maybe using some mix functions?).

(ArithmeticError) bad argument in arithmetic expression

Hi folks, giving AppSignal a try for some elixir apps, however I noticed when I installed in and included the Ecto log hook I am getting an ArithmeticError coming from https://github.com/appsignal/appsignal-elixir/blob/master/lib/appsignal/ecto.ex#L28 on all of my previously working POST/PUT requests (even in tests).

Removing the logger in the Repo config removes all errors.

It appears to raise this error on any Repo.update, Repo.insert, and Repo.update_or_insert when passed a changeset.

Is this possibly a version issue?

I tried running Appsignal 0.2.0 and master with Ecto 2.0.4, phoenix_ecto 3.0.1, db_connection 1.0.0-rc.5, postgrex 0.11.2.

Mac build is broken

See jeffkreeftmeijer/appsignal-phoenix-example@1710223

    14:53:09.366 [info]  Downloading agent release from https://appsignal-agent-releases.global.ssl.fastly.net/dacf2fb/appsignal-x86_64-darwin-all-static.tar.gz
    clang: error: no such file or directory: '/Users/jeff/opensource/appsignal_phoenix_example/_build/dev/lib/appsignal/priv/libappsignal.dylib'
    make: *** [all] Error 1
    ==> appsignal
    could not compile dependency :appsignal, "mix compile" failed. You can recompile this dependency with "mix deps.compile appsignal", update it with "mix deps.update appsignal" or clean it with "mix deps.clean appsignal"

we need Mac CI..

Error running ecto data update migrations with Appsignal installed

I'm trying to run a migration which simply updates the values of a particular table column using Repo.update_all, but when Appsignal is active, it throws the following error:

** (ArgumentError) argument error
    (stdlib) :ets.lookup(:"$appsignal_transaction_registry", #PID<0.73.0>)
    lib/appsignal/transaction/registry.ex:46: Appsignal.TransactionRegistry.lookup/2
    lib/appsignal/ecto.ex:23: Appsignal.Ecto.log/1
    (db_connection) lib/db_connection.ex:1177: DBConnection.log/6
    (ecto) lib/ecto/adapters/postgres/connection.ex:78: Ecto.Adapters.Postgres.Connection.prepare_execute/5
    (ecto) lib/ecto/adapters/sql.ex:235: Ecto.Adapters.SQL.sql_call/6
    (ecto) lib/ecto/adapters/sql.ex:424: Ecto.Adapters.SQL.execute_and_cache/7
    (stdlib) timer.erl:197: :timer.tc/3

I've got the Appsignal.Ecto logger configured via:

config :hoffer, MyApp.Repo,
  loggers: [Appsignal.Ecto]

This is on:

elixir: 1.3.4
ecto: 2.0.6
appsignal: 0.9.2

The workaround for me with this was to remove the Appsignal.Ecto logger config so that the migration could run, and then re-enable it again.

Do let me know what other information might be helpful, I'll get them across as soon as possible.

Appsignal fails to compile because download of libappsignal.a fails.

 cc: error: /app/_build/prod/lib/appsignal/priv/libappsignal.a: No such file or directory

It looks like the file fails to download which in turn causes the build to fail. (Which in turn causes my docker image not to compile... and so on.)

I would say it happens about once a day or so and we deploy about 16 times a day. So maybe 1/16.
It's not reproducible.

Running the same build again will succeed. It never fails twice as far as I have seen.

The manual claims it will not send passwords by default, this is not true

From the Getting started page:

"If :filter_parameters is not set, Phoenix will default to ["password"]. This means that a Phoenix app will not send any passwords to AppSignal without any configuration."

However, my first error on the sign in page sent the user's password to appsignal 😞

This seems to work:

config :appsignal, :config,
  filter_parameters: ["password"]

Benchmarks

Let's add a benchmark to see what the overhead is of running the Appsignal integration in a typical Phoenix application.

Query Logging: Appsignal.Ecto.log/1 errors when using the preferred Ecto.Repo loggers format

From the Ecto docs:

:loggers - a list of {mod, fun, args} tuples...

https://hexdocs.pm/ecto/Ecto.Repo.html

In Ecto 2.0.2, when I add Appsignal to Repo loggers using the preferred format

loggers: [{Appsignal.Ecto, :log, []}]

it throws an error here:

https://github.com/appsignal/appsignal-elixir/blob/master/lib/appsignal/ecto.ex#L29

** (exit) an exception was raised:
    ** (UndefinedFunctionError) function nil.queue_time/0 is undefined or private
        nil.queue_time()
        (appsignal) Appsignal.Ecto.log/1

Long integers in parameters trigger errors in AppSignal NIF

When having long integers inside parameters (in our case, keystrokes typed by a user on a phone) AppSignal's NIF throws a (ArgumentError) argument error.

Backtrace

(elixir) lib/enum.ex:657: anonymous fn/3 in Enum.each/2
(stdlib) lists.erl:1262: :lists.foldl/3
(elixir) lib/enum.ex:656: Enum.each/2
(appsignal) lib/appsignal/utils/data_encoder.ex:16: Appsignal.Utils.DataEncoder.encode/1
(appsignal) lib/appsignal/transaction.ex:209: Appsignal.Transaction.set_sample_data/3
(appsignal) lib/appsignal/transaction.ex:378: Appsignal.Transaction.set_request_metadata/2
(appsignal) lib/appsignal/phoenix/plug.ex:23: anonymous fn/2 in Appsignal.Phoenix.Plug.call/2```

app signal 0.0.9 fails to install on macOS Sierra.

could not compile dependency :appsignal, "mix compile" failed. You can recompile this dependency with "mix deps.compile appsignal", update it with "mix deps.update appsignal" or clean it with "mix deps.clean appsignal"
==> chat_server
** (Mix) Checksum verification of /tmp/7d8fcfaappsignal-x86_64-darwin-all-static.tar.gz failed!
Calculated: ad5ff38b7490224efc650dcb7909ca8980b914d6cbad7462e8b1c0712c74f3de
  Expected: 1d2dbd22ad0fe22d9838022533df4debc2fbb9daa2519beed75d7e057b62e980

Looks like there 's some sort of checksum issue? Either the checksum is wrong or...

Note that 0.0.8 / 0.0.7 work without issue. So I suspect the checksum or file is just wrong.

Can't compile appsignal due to checksum verification fail

I added {:appsignal, "~> 0.3"} to my mix.exs

When compiling the deps I get the following error

==> appsignal
could not compile dependency :appsignal, "mix compile" failed. You can recompile this dependency with "mix deps.compile appsignal", update it with "mix deps.update appsignal" or clean it with "mix deps.clean appsignal"
==> my_app
** (Mix) Checksum verification of /tmp/appsignal-agent-220a888.tar.gz failed!
Calculated: 737dbd50b92e6f105de0e11aaab5de9bc2404ed999e341fc7822bd5d71205b5d
  Expected: 5e313156339389b339c289592327ac1c3d57999df93cd31ce9c69fa4ede1e38f

AppSignal active configuration detection

I found a difference in configuration between the AppSignal for Elixir package and the AppSignal for Ruby gem.

Related issue: #49

Ruby

In the Ruby gem we automatically set active to true once we detect the APPSIGNAL_PUSH_API_KEY in the environment.

This is the exception to the configuration order which allows us to install the Heroku add-on without setting the APPSIGNAL_ACTIVE environment key there. (It's too late to change that now.)

https://github.com/appsignal/appsignal-ruby/blob/0e97b6f9180c4504e4361021fafa6ec7da3e6d42/lib/appsignal/config.rb#L154-L155

Elixir

In the Elixir package we automatically set active to true if the push_api_key configuration option is set in any of the configuration stages (app_config and env_config) even when active is not explicitly set to true.

|> Map.put(:active, (if config[:active] == nil, do: !empty?(config[:push_api_key]), else: config[:active]))

Suggested change

We should try to keep the two packages' configuration behave the same way.

We should add the APPSIGNAL_PUSH_API_KEY active detection to the load_from_system function in the Elixir package. This require users to configure active per environment.

# config/config.exs
config :appsignal, :config,
  name: :appsignal_phoenix_example,
  push_api_key: "xxxx-xxxx-xxxx-xxx"
# config/dev.exs
config :appsignal, :config,
  env: :development,
  active: false # Default value so it's not necessary to set this
# config/prod.exs
config :appsignal, :config,
  env: :production,
  active: true

@jeffkreeftmeijer @arjan WDYT?
@thijsc We've discussed this behavior before for the Ruby gem, do you agree it should behave the same here?

Sidenote: Can't we detect the env from Mix.env ? So it's not necessary to set? See #91.

Pass Logger metadata to Appsignal

Often, people use Logger.metadata/1 to set metadata during the request. We should send this data to appsignal after finishing the request.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.