Heroku Ps Could Not Complete the Action Please Try Again Later

In this article by Mike Coutermarsh, author of Heroku Cookbook, nosotros will cover the following topics:

• Viewing application logs
• Searching logs
• Installing add-ons
• Managing environment variables
• Enabling the maintenance page
• Managing releases and rolling back
• Running i-off tasks and dynos
• Managing SSH keys
• Sharing and collaboration
• Monitoring load average and memory usage

(For more resources related to this topic, see here.)

Heroku was built to be managed from its command-line interface. The meliorate we learn information technology, the faster and more effective we will exist in administering our application. The goal of this article is to go comfortable with using the CLI. We'll see that each Heroku command follows a common pattern. Once we larn a few of these commands, the rest volition be relatively simple to master.

In this commodity, we won't cover every control available in the CLI, but nosotros will focus on the ones that we'll exist using the most. Equally we acquire each command, we will besides learn a little more almost what is happening behind the scenes and then that we become a improve understanding of how Heroku works. The more we understand, the more we'll be able to take reward of the platform.

Before we starting time, let'south notation that if nosotros e'er need to get a list of the available commands, we tin run the following command:

          $ heroku help        

Nosotros can also chop-chop brandish the documentation for a single command:

          $ heroku help command_name        

Viewing application logs

Logging gets a piddling more than complex for any application that is running multiple servers and several unlike types of processes. Having visibility into everything that is happening within our application is critical to maintaining it. Heroku handles this by combining and sending all of our logs to one place, the Logplex.

The Logplex provides us with a single location to view a stream of our logs across our entire application. In this recipe, we'll larn how to view logs via the CLI. We'll learn how to rapidly go visibility into what'southward happening within our application.

How to practise it…

To start, allow's open up upwards a last, navigate to an existing Heroku awarding, and perform the following steps:

1. Kickoff, to view our applications logs, nosotros can apply the logs command:

   $ heroku logs
   2014-03-31T23:35:51.195150+00:00 app[web.1]:   Rendered pages/about.html.slim within layouts/application (25.0ms)

                 
   2014-03-31T23:35:51.215591+00:00 app[web.i]:   Rendered layouts/_navigation_links.html.erb (2.6ms)
   2014-03-31T23:35:51.230010+00:00 app[web.ane]:   Rendered layouts/_messages.html.slim (thirteen.0ms)
   2014-03-31T23:35:51.215967+00:00 app[web.1]:   Rendered layouts/_navigation.html.slim (10.3ms)
   2014-03-31T23:35:51.231104+00:00 app[spider web.1]: Completed 200 OK in 109ms (Views: 65.4ms | ActiveRecord: 0.0ms)
   2014-03-31T23:35:51.242960+00:00 heroku[router]: at=info method=GET path=

   Heroku logs anything that our application sends to STDOUT or STDERR. If nosotros're not seeing logs, information technology'southward very likely our awarding is not configured correctly.

2.  Nosotros can also watch our logs in real time. This is known as tailing:

   $ heroku logs --tail

   Instead of –tail, we tin also use -t.

   We'll need to press Ctrl + C to terminate the command and stop tailing the logs.

3. If nosotros want to run across the 100 most contempo lines, we can apply -north:

   $ heroku logs -n 100

   The Logplex stores a maximum of 1500 lines. To view more than lines, we'll have to gear up a log storage.

4. Nosotros can filter the logs to simply bear witness a specific process blazon. Hither, we will only run across logs from our web dynos:

   $ heroku logs -p web

5. If we want, nosotros can be as granular equally showing the logs from an individual dyno. This will show only the logs from the second web dyno:

   $ heroku logs -p web.2

6. We can use this for whatever procedure blazon; nosotros can try information technology for our workers if nosotros'd like:

   $ heroku logs -p worker

7. The Logplex contains more than just logs from our application. We tin also view logs generated by Heroku or the API. Allow'south endeavour changing the source to Heroku to only see the logs generated past Heroku. This will but testify us logs related to the router and resource usage:

   $ heroku logs --source heroku

8. To view logs for merely our application, we can set up the source to app:

   $ heroku logs --source app

9. We tin too view logs from the API. These logs will show any authoritative actions nosotros've taken, such as scaling dynos or changing configuration variables. This can be useful when multiple developers are working on an awarding:

   $ heroku logs --source api

10. We tin even combine the dissimilar flags. Let's try tailing the logs for only our web dynos:

    $ heroku logs -p web --tail

11. That's it! Remember that if we ever need more information on how to view logs via the CLI, we can always utilise the assist control:

    $ heroku help logs

How it works

Under the covers, the Heroku CLI is only passes our request to Heroku's API and so uses Ruby to parse and display our logs. If yous're interested in exactly how it works, the lawmaking is open source on GitHub at https://github.com/heroku/heroku/blob/master/lib/heroku/command/logs.rb.

Viewing logs via the CLI is most useful in situations where we need to run into exactly what our awarding is doing correct now. We'll detect that we apply it a lot around deploys and when debugging issues. Since the Logplex has a limit of 1500 lines, it's not meant to view any historical data. For this, nosotros'll need to set up log drains and enable a logging add-on.

Searching logs

Heroku does not take the born capability to search our logs from the command line. Nosotros tin can become around this limitation easily by making utilise of another command-line tools.

In this recipe, nosotros volition learn how to combine Heroku's logs with Grep, a command-line tool to search text. This will let united states of america to search our contempo logs for keywords, helping united states of america track down errors more chop-chop.

Getting gear up

For this recipe, we'll need to have Grep installed. For Bone Ten and Linux machines, information technology should already exist installed. Nosotros tin can install Grep using the post-obit steps:

1. To check if we accept Grep installed, let's open upward a terminal and blazon the following:

   $ grep
   usage: grep [-abcDEFGHhIiJLlmnOoPqRSsUVvwxZ] [-A num] [-B num] [-C[num]]       [-east pattern] [-f file] [--binary-files=value] [--colour=when]       [--context[=num]] [--directories=activity] [--label] [--line-buffered]       [--null] [pattern] [file ...]

2. If nosotros do non see usage instructions, nosotros can visit http://www.gnu.org/software/grep/ for the download and installation instructions.

How to do it…

Let's start searching our logs past opening a terminal and navigating to ane of our Heroku applications using the following steps:

1. To search for a keyword in our logs, we need to pipe our logs into Grep. This simply means that we volition be passing our logs into Grep and having Grep search them for u.s.. Let's try this now. The following command will search the output of heroku logs for the give-and-take error:

   $ heroku logs | grep mistake

2. Sometimes, we might want to search for a longer cord that includes special characters. We can practise this past surrounding it with quotes:

   $ heroku logs | grep "path=/pages/about host"

3. It can be useful to also see the lines surrounding the line that matched our search. We can practice this also. The adjacent command volition bear witness united states of america the line that contains an error likewise equally the 3 lines above and below it:

   $ heroku logs | grep error -C 3

4. We can even search with regular expressions. The next control will show united states of america every line that matches a number that ends with MB. So, for example, lines with 100 MB, 25 MB, or three MB volition all appear:

   $ heroku logs | grep 'd*MB'

   To larn more about regular expressions, visit http://regex.learncodethehardway.org/.

How it works…

Similar most Unix-based tools, Grep was built to reach a single task and to do it well. Global regular expression print (Grep) is built to search a set of files for a pattern and so print all of the matches.

Grep can also search annihilation it receives through standard input; this is exactly how we used information technology in this recipe. Past piping the output of our Heroku logs into Grep, we are passing our logs to Grep as standard input.

See also

• To acquire more about Grep, visit http://www.tutorialspoint.com/unix_commands/grep.htm

Installing add together-ons

Our awarding needs some additional functionality provided by an outside service. What should we do? In the by, this would accept involved creating accounts, managing credentials, and, possibly, even bringing up servers and installing software. This whole process has been simplified by the Heroku add-on market.

For any boosted functionality that our application needs, our get-go stop should always be Heroku add-ons. Heroku has made attaching additional resources to our application a plug-and-play process. If we need an additional database, caching, or error logging, they can be gear up with a single control.

In this recipe, we will learn the ins and outs of using the Heroku CLI to install and manage our awarding's add-ons.

How to practice it…

To brainstorm, let'southward open a terminal and navigate to ane of our Heroku applications using the following steps:

1. Allow's showtime by taking a look at all of the available Heroku add together-ons. We can exercise this with the addons:list command:

   $ heroku addons:list

   There are so many add-ons that viewing them through the CLI is pretty hard. For easier navigation and search, we should take a look at https://addons.heroku.com/.

2. If we desire to come across the currently installed add together-ons for our application, nosotros can simply type the following:

   $ heroku addons
   === load-tester-rails Configured Add-ons
   heroku-postgresql:dev       HEROKU_POSTGRESQL_MAROON
   heroku-postgresql:hobby-dev HEROKU_POSTGRESQL_ONYX
   librato:development
   newrelic:stark

   Remember that for whatsoever command, we can always add –app app_name to specify the application.

3. Alternatively, our application's add together-ons are too listed through the Heroku Dashboard available at https://dashboard.heroku.com.

   

4. The installation of a new add-on is done with addons:add. Hither, we are going to install the error logging service, Rollbar:

   $ heroku addons:add rollbar
   heroku addons:add rollbar
   Adding rollbar on load-tester-rails... washed, v22 (free)
   Use `heroku addons:docs rollbar` to view documentation.

5. Nosotros can apace open up up the documentation for an add-on with addons:docs:

   $ heroku addons:docs rollbar

6. Removing an addition is simply equally unproblematic. We'll need to type our application proper noun to confirm. For this example, our application is called load-tester-rail:

   $ heroku addons:remove rollbar
   !   WARNING: Subversive Action
   !   This control volition affect the app: load-tester-rail
   !   To proceed, type "load-tester-rails" or re-run this command with --confirm load-tester-rails
                   > load-tester-rails
   Removing rollbar on load-tester-rails... done, v23 (free)
               

7. Each add-on comes with unlike tiers of service. Let's try upgrading our rollbar add-on to the starter tier:

   $ heroku addons:upgrade rollbar:starter
   Upgrading to rollbar:starter on load-tester-rails... washed, v26 ($12/mo)
   Plan changed to starter
   Use `heroku addons:docs rollbar` to view documentation.

8. Now, if we want, we tin downgrade back to its original level with addons:downgrade:

   $ heroku addons:downgrade rollbar
   Downgrading to rollbar on load-tester-rails... done, v27 (free)
   Programme changed to gratis
   Employ `heroku addons:docs rollbar` to view documentation.

9. If we ever forget whatsoever of the commands, nosotros can always use assist to quickly run into the documentation:

   $ heroku help addons

   Some add-ons might charge you money. Earlier continuing, let'south double check that nosotros only have the correct ones enabled, using the $ heroku addons control.

How information technology works…

Heroku has created a standardized process for all add-on providers to follow. This ensures a consequent experience when provisioning any addition for our awarding.

It starts when we request the creation of an improver. Heroku sends an HTTP request to the provider, asking them to provision an instance of their service. The provider must then answer to Heroku with the connection details for their service in the class of environs variables. For example, if we were to provision Redis To Get, we will go back our connection details in a REDISTOGO_URL variable:

REDISTOGO_URL: redis://user:[email protected]:9652

Heroku adds these variables to our awarding and restarts it. On restart, the variables are bachelor for our awarding, and we tin connect to the service using them. The specifics on how to connect using the variables volition exist in the add-ons documentation. Installation will depend on the specific language or framework we're using.

Encounter also

• For details on creating our ain add-ons, the process is well documented on Heroku's website at https://addons.heroku.com/provider
• Bank check out Kensa, the CLI to create Heroku add-ons, at https://github.com/heroku/kensa

Managing environment variables

Our applications will often need access to various credentials in the course of API tokens, usernames, and passwords for integrations with third-party services. We can store this data in our Git repository, but then, anyone with access to our code will also take a re-create of our production credentials. We should instead employ environment variables to store any configuration information for our application. Configuration data should be carve up from our application'southward lawmaking and instead exist tied to the specific deployment of the application.

Changing our awarding to use environment variables is simple. Let's look at an example in Cherry-red; let's assume that we currently have secret_api_token defined in our application's code:

secret_api_token = '123abc'

Nosotros can remove the token and supplant it with an environment variable:

secret_api_token = ENV['SECRET_TOKEN']

In addition to protecting our credentials, using environment variables makes our application more configurable. We'll be able to apace make configuration changes without having to change code and redeploy.

The terms "configuration variable" and "environment variable" are interchangeable. Heroku usually uses "configuration" due to how tightly the variables are coupled with the state of the application.

How to do it…

Heroku makes information technology easy to fix our application's environment variables through the config command. Permit's launch a terminal and navigate to an existing Heroku project to try it out, using the following steps:

1. We can utilise the config command to see a listing of all our existing environment variables:

   $ heroku config

2. To view only the value of a specific variable, we can use get:

   $ heroku config:get DATABASE_URL

3. To set a new variable, we tin can use set:

   $ heroku config:prepare VAR_NAME=var_value
   Setting config vars and restarting load-tester-rails... washed, v28
   VAR_NAME: var_value

4. Each time we set a config variable, Heroku will restart our application. We can set multiple values at once to avoid multiple restarts:

   $ heroku config:set Hugger-mugger=value SECRET2=value
   Setting config vars and restarting load-tester-rails... done, v29
   SECRET: value
   SECRET2: value

5. To delete a variable, we use unset:

   $ heroku config:unset Underground
   Unsetting SECRET and restarting load-tester-rails... done, v30

6. If we want, nosotros can delete multiple variables with a single command:

   $ heroku config:unset VAR_NAME SECRET2
   Unsetting VAR_NAME and restarting load-tester-rails... done, v31
   Unsetting SECRET2 and restarting load-tester-rails... done, v32

   Heroku tracks each configuration alter as a release. This makes it easy for us to curlicue back changes if we make a fault.

How it works…

Environs variables are used on Unix-based operating systems to manage and share configuration information between applications. As they are so common, changing our awarding to utilize them does not lock u.s.a. into deploying only to Heroku.

Heroku stores all of our configuration variables in ane central location. Each modify to these variables is tracked, and we can view the history by looking through our past releases. When Heroku spins up a new dyno, part of the process is taking all of our configuration settings and setting them as environment variables on the dyno. This is why whenever we make a configuration change, Heroku restarts our dynos.

As configuration variables are such a key part of our Heroku application, any alter to them will likewise be included in our Heroku logs.

See also

• Read virtually the Twelve-Cistron app's rule on configuration at http://12factor.cyberspace/config

Enabling the maintenance page

Occasionally, we will demand to brand changes to our awarding that requires downtime. The proper way to exercise this is to put up a maintenance page that displays a friendly message and answer to all the incoming HTTP requests with a 503 Service Unavailable status.

Doing this will keep our users informed and also avoid any negative SEO effects. Search engines understand that when they receive a 503 response, they should come dorsum later to recrawl the site. If we didn't use a maintenance folio and our awarding returned a 404 or 500 errors instead, information technology'southward possible that a search engine crawler might remove the page from their alphabetize.

How to do it…

Allow's open up a terminal and navigate to 1 of our Heroku projects to begin with, using the following steps:

1. Nosotros can view if our application's maintenance page is currently enabled with the maintenance command:

   $ heroku maintenance
   off

2. Let'due south try turning information technology on. This will stop traffic from being routed to our dynos and show the maintenance page as follows:

   $ heroku maintenance:on
   Enabling maintenance mode for load-tester-rail... washed

3. Now, if we visit our application, we'll see the default Heroku maintenance folio:

   

4. To disable the maintenance page and resume sending users to our application, we can use the maintenance:off command:

   $ heroku maintenance:off
   Disabling maintenance mode for load-tester-rail... done

Managing releases and rolling dorsum

What do we practice if disaster strikes and our newly released code breaks our awarding? Luckily for us, Heroku keeps a copy of every deploy and configuration modify to our application. This enables us to roll back to a previous version while we piece of work to correct the errors in our latest release.

Heads up! Rolling dorsum only affects application code and configuration variables. Add-ons and our database will non be affected by a rollback.

In this recipe, we will learn how to manage our releases and whorl back lawmaking from the CLI.

How to do it…

In this recipe, we'll view and manage our releases from the Heroku CLI, using the releases command. Let's open up a terminal now and navigate to one of our Heroku projects by performing the following steps:

1. Heroku tracks every deploy and configuration change as a release. We can view all of our releases from both the CLI and the spider web dashboard with the releases control:

   $ heroku releases
   === load-tester-runway Releases
   v33 Add together WEB_CON config vars [email protected] 2014/03/thirty 11:18:49 (~ 5h ago)
   v32 Remove SEC config vars       [email protected] 2014/03/29 19:38:06 (~ 21h agone)
   v31 Remove VAR config vars     [email protected] 2014/03/29 nineteen:38:05 (~ 21h ago)
   v30 Remove config vars       [e-mail protected] 2014/03/29 nineteen:27:05 (~ 21h ago)
   v29 Deploy 9218c1c vars [email protected] 2014/03/29 19:24:29 (~ 21h ago)

2. Alternatively, we can view our releases through the Heroku dashboard. Visit https://dashboard.heroku.com, select one of our applications, and click on Activeness:

   

3. We tin can view detailed information about each release using the info command. This shows united states everything about the change and state of the application during this release:

   $ heroku releases:info v33
   === Release v33
   Addons: librato:development
          newrelic:stark
          rollbar:free
          sendgrid:starter
   By:     [email protected]
   Change: Add WEB_CONCURRENCY config vars
   When:   2014/03/30 eleven:xviii:49 (~ 6h agone)
   === v33 Config Vars
   WEB_CONCURRENCY: three

4. We tin revert to the previous version of our awarding with the rollback command:

   $ heroku rollback
   Rolling back load-tester-rail... washed, v32
   !   Warning: rollback affects code and config vars; it doesn't add or remove addons. To undo, run: heroku rollback v33

   Rolling back creates a new version of our application in the release history.

5. Nosotros tin likewise specify a specific version to roll back to:

   $ heroku rollback v30
   Rolling back load-tester-rails... done, v30

   The version we curlicue back to does not have to be an older version. Although it sounds contradictory, nosotros can also coil dorsum to newer versions of our application.

How it works…

Behind the scenes, each Heroku release is tied to a specific slug and set of configuration variables. Every bit Heroku keeps a re-create of each slug that we deploy, we're able to quickly roll back to previous versions of our code without having to rebuild our application.

For each deploy release created, it will include a reference to the Git SHA that was pushed to master. The Git SHA is a reference to the concluding commit made to our repository before information technology was deployed. This is useful if we desire to know exactly what code was pushed out in that release.

On our local auto, we can run the $ git checkout git-sha-hither command to view our application'south lawmaking in the exact state information technology was when deployed.

Running one-off tasks and dynos

In more traditional hosting environments, developers will often log in to servers to perform bones administrative tasks or debug an issue. With Heroku, we can do this by launching i-off dynos. These are dynos that contain our awarding code but do non serve spider web requests.

For a Carmine on Rails awarding, i-off dynos are often used to run database migrations or launch a Runway panel.

How to do it…

In this recipe, we will learn how to execute commands on our Heroku applications with the heroku run command. Let'southward launch a terminal now to go started with the post-obit steps:

1. To have Heroku start a one-off dyno and execute whatsoever single control, we will use heroku run. Hither, we can try information technology out past running a simple command to print some text to the screen:

   $ heroku run echo "how-do-you-do heroku"
   Running `echo "hi heroku"` fastened to terminal... up, run.7702
   "hullo heroku"

   Ane-off dynos are automatically shut downward after the command has finished running.

2. We tin see that Heroku is running this control on a dyno with our awarding's code. Let'southward run ls to see a listing of the files on the dyno. They should look familiar:

   $ heroku run ls
   Running `ls` attached to terminal... up, run.5518
   app bin config config.ru db Gemfile Gemfile.lock lib log Procfile     public Rakefile README README.doctor tmp

3. If we desire to run multiple commands, we can outset upward a fustigate session. Type go out to close the session:

   $ heroku run bash
   Running `bash` fastened to terminal... up, run.2331
   ~ $ ls
   app bin config config.ru db Gemfile Gemfile.lock      lib log Procfile public Rakefile README README.md tmp
   ~ $ echo "hi"
   hullo
   ~ $ exit
   exit

4. We can run tasks in the groundwork using the detached mode. The output of the control goes to our logs rather than the screen:

   $ heroku run:detached echo "hello heroku"
   Running `echo hello heroku` discrete... up, run.4534
   Use `heroku logs -p run.4534` to view the output.

5. If nosotros need more power, we can adjust the size of the ane-off dynos. This command will launch a bash session in a 2X dyno:

   $ heroku run --size=2X bash

6. If we are running one-off dynos in the detached way, we can view their status and stop them in the same manner we would end whatever other dyno:

   $ heroku ps
   === run: one-off processes
   run.5927 (1X): starting 2014/03/29 sixteen:18:59 (~ 6s agone)
   $ heroku ps:stop run.5927

How it works…

When nosotros event the heroku run command, Heroku spins up a new dyno with our latest slug and runs the control. Heroku does not start our awarding; the only command that runs is the command that we explicitly pass to information technology.

One-off dynos deed a little differently than standard dynos. If nosotros create one dyno in the detached mode, it will run until we finish it manually, or it will close down automatically afterwards 24 hours. It will not restart like a normal dyno will.

If nosotros run bash from a ane-off dyno, it volition run until we close the connection or reach an hour of inactivity.

Managing SSH keys

Heroku manages access to our awarding'southward Git repository with SSH keys. When we first fix the Heroku Toolbelt, nosotros had to upload either a new or existing public cardinal to Heroku'south servers. This key allows united states to access our Heroku Git repositories without inbound our countersign each time.

If nosotros ever want to deploy our Heroku applications from another computer, nosotros'll either need to have the same key on that estimator or provide Heroku with an boosted ane. It'due south like shooting fish in a barrel enough to do this via the CLI, which we'll learn in this recipe.

How to practice it…

To go started, let'southward burn up a terminal. We'll be using the keys command in this recipe by performing the following steps:

1. First, let'due south view all of the existing keys in our Heroku account:

   $ heroku keys
   === [electronic mail protected] Keys
   ssh-rsa AAAAB3NzaC...46hEzt1Q== [email protected]
   ssh-rsa AAAAB3NzaC...6EU7Qr3S/v [email protected]
   ssh-rsa AAAAB3NzaC...bqCJkM4w== [email protected]

2. To remove an existing cardinal, nosotros can utilise keys:remove. To the command, we need to pass a string that matches one of the keys:

   $ heroku keys:remove "7Qr3S/v [email protected]"
   Removing 7Qr3S/v [email protected] SSH key... done

3. To add our current user's public key, we can use keys:add. This will expect on our machine for a public primal (~/.ssh/id_rsa.pub) and upload it:

   $ heroku keys:add
   Found existing public primal: /Users/mike/.ssh/id_rsa.pub
   Uploading SSH public key /Users/mike/.ssh/id_rsa.pub… done

   To create a new SSH key, nosotros tin can run $ ssh-keygen -t rsa.

4. If we'd like, we can too specify where the fundamental is located if it is not in the default /.ssh/ directory:

   $ heroku keys:add together /path/to/primal.pub

How it works…

SSH keys are the standard method for countersign-less authentication. There are two parts to each SSH key. There is a private cardinal, which stays on our machine and should never be shared, and there is a public key, which nosotros tin freely upload and share.

Each key has its purpose. The public key is used to encrypt messages. The private cardinal is used to decrypt letters.

When we effort to connect to our Git repositories, Heroku's server uses our public fundamental to create an encrypted message that can but be decrypted past our private key. The server then sends the message to our automobile; our machine's SSH client decrypts it and sends the response to the server. Sending the right response successfully authenticates u.s.a..

SSH keys are not used for authentication to the Heroku CLI. The CLI uses an authentication token that is stored in our ~/.netrc file.

Sharing and collaboration

Nosotros can invite collaborators through both the web dashboard and the CLI. In this recipe, we'll learn how to quickly invite collaborators through the CLI.

How to exercise information technology…

To starting time, allow'south open up a terminal and navigate to the Heroku application that we would similar to share, using the following steps:

1. To come across the current users who have access to our application, we tin apply the sharing control:

   $ heroku sharing
   === load-tester-runway Access List
   [e-mail protected] owner
   [e-mail protected]             collaborator

2. To invite a collaborator, we can use sharing:add:

   $ heroku sharing:add together [email protected]
                 Adding [electronic mail protected] to load-tester-rails equally collaborator... done

   Heroku will send an e-mail to the user we're inviting, even if they do not already have a Heroku business relationship.

3. If we'd like to revoke access to our application, we tin can do and then with sharing:remove:
   $ heroku sharing:remove [email protected]
   Removing [e-mail protected] from load-tester-rails collaborators… done

How it works…

When we add another collaborator to our Heroku awarding, they are granted the same abilities equally us, except that they cannot manage paid add-ons or delete the awarding. Otherwise, they have full control to administrate the application. If they have an existing Heroku account, their SSH key will be immediately added to the application'due south Git repository.

See likewise

• Interested in using multiple Heroku accounts on a single machine? Take a look at the Heroku-accounts plugin at https://github.com/ddollar/heroku-accounts.

Monitoring load average and memory usage

Nosotros tin can monitor the resource usage of our dynos from the command line using the log-runtime-metrics plugin. This volition give us visibility into the CPU and retention usage of our dynos. With this data, we'll be able to determine if our dynos are correctly sized, detect bug earlier, and make up one's mind whether nosotros need to calibration our application.

How to practice it…

Let's open up a terminal; we'll be completing this recipe with the CLI past performing the post-obit steps:

1. First, we'll need to install the log-runtime-metrics plugin via the CLI. We can do this easily through heroku labs:

   $ heroku labs:enable log-runtime-metrics

2. At present that the runtime metrics plugin is installed, we'll need to restart our dynos for it to take effect:

   $ heroku restart

3. Now that the plugin is installed and running, our dynos' resource usage volition exist printed to our logs. Let's view them now:

   $ heroku logs
   heroku[web.1]: source=spider web.1 dyno=heroku.21 sample#load_avg_1m=0.00 sample#load_avg_5m=0.00
   heroku[web.i]: source=web.1 dyno=heroku.21
   sample#memory_total=105.28MB sample#memory_rss=105.28MB
   sample#memory_cache=0.00MB
   sample#memory_swap=0.00MB
   sample#memory_pgpgin=31927pages
   sample#memory_pgpgout=4975pages

4. From the logs, we can see that for this application, our load average is 0, and this dyno is using a total of 105 MB of RAM.

How it works…

At present that nosotros take some insight into how our dynos are using resources, we need to larn how to translate these numbers. Understanding the utilization of our dynos will exist key for us if we e'er need to diagnose a performance-related effect.

In our logs, we will at present run into load_avg_1m and load_avg_5m. This is our dynos' load average over a 1-minute and 5-minute period. The timeframes are helpful in determining whether we're experiencing a brief spike in action or it is more sustained. Load average is the amount of full computational work that the CPU has to complete. The 1X and 2X dynos have access to four virtual cores. A load boilerplate of four ways that the dynos' CPU is fully utilized. Any value higher up four is a warning sign that the dyno might be overloaded, and response times could brainstorm to suffer. Web applications are typically not CPU-intensive applications, seeing depression load averages for web dynos should be expected. If we start seeing high load averages, we should consider either adding more dynos or using larger dynos to handle the load.

Our memory usage is also shown in the logs. The central value that we want to keep track of is memory_rrs, which is the full corporeality of RAM being utilized by our application. It's best to go on this value no higher than fifty to 70 percent of the total RAM bachelor on the dyno. For a 1X dyno with 512 MB of memory, this would mean keeping our memory usage no greater than 250 to 350 MB. This allows our awarding'south room to grow under load and helps u.s.a. avoid any memory swapping. Seeing values above 70 percent is an indication that nosotros need to either adjust our awarding's memory usage or scale up.

Memory swap occurs when our dyno runs out of RAM. To compensate, our dyno volition brainstorm using its hard drive to store data that volition normally be stored in RAM. For any web application, whatsoever swap should be considered evil. This value should always exist goose egg. If our dyno starts swapping, we can expect that it will significantly slow down our application's response times. Seeing whatever swap is an immediate indication that we must either reduce our application's memory consumption or beginning scaling.

See also

• Load average and memory usage are peculiarly useful when performing awarding load tests.

Summary

In this article, nosotros learned various commands on how to view application logs, installing add-ons, viewing application logs, enabling the maintenance page, managing SSH keys, sharing and collaboration, and and then on.

Resource for Commodity:

---

Further resources on this bailiwick:

• Securing vCloud Using the vCloud Networking and Security App Firewall [article]
• vCloud Networks [article]
• Apache CloudStack Architecture [article]

---

minickaddersed.blogspot.com

Source: https://hub.packtpub.com/managing-heroku-command-line/

Share this post