Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku Architecture
    • Dynos (app containers)
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Command Line
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery
    • Continuous Integration
  • Language Support
    • Node.js
    • Ruby
      • Working with Bundler
      • Rails Support
    • Python
      • Background Jobs in Python
      • Working with Django
    • Java
      • Working with Maven
      • Java Database Operations
      • Working with the Play Framework
      • Working with Spring Boot
      • Java Advanced Topics
    • PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
    • Heroku Data For Redis
    • Apache Kafka on Heroku
    • Other Data Stores
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
    • Compliance
  • Heroku Enterprise
    • Private Spaces
      • Infrastructure Networking
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
    • Single Sign-on (SSO)
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Integrating with Salesforce
  • Extending Heroku
  • Building Add-ons
  • Add-on Development Tasks
  • Accessing Application Logs as an Add-on Partner

Accessing Application Logs as an Add-on Partner

English — 日本語に切り替える

Last updated March 30, 2021

Table of Contents

  • Add-on manifest
  • Provisioning call

Add-on Partners can access an app’s log data once a customer installs your add-on on their app. If you’re building an add-on that requires this access, you can create a log drain on behalf of the app and receive the log data.

Log drains allow your add-on to read application logs. If you’d like to write to them, see this documentation.

To set it up, you first need to request it through the manifest.

Add-on manifest

The manifest will need to tell Heroku that your add-on requires permission to set up the log drain. This is done by adding syslog_drain to the list if permissions in the requires property:

{
  "id": "myaddon",
  "api": {
    "requires": ["syslog_drain"]
    //...
  }
}

Despite the name (syslog_drain), drains are not limited to the syslog:// protocol, in fact HTTPS drains are preferred. See the user docs on log drains for more details.

Provisioning call

When the add-on is provisioned, Heroku’s systems will generate a unique log drain token for that attachment. Add-on Partners should use this token to identify logs sent to the drain.

Relying on the Heroku provided drain token instead of a unique field in a url like a port or api key ensures that drain urls can not be copy/pasted and used in a manual context. That restriction in turn allows you to use the platform api to update a drain in the future, and know that all valid instances of the url have been updated.

The provisioning call will contain the log drain token. The content of our POST to the /heroku/resources endpoint is described here. When the syslog_drain feature is enabled, the log_drain_token field will be added to the provision payload:

{
  // ...
  "log_drain_token": "d.01234567-89ab-cdef-0123-456789abcdef"
}

and the response would be:

{
  "id": 456,
  "config": { ... },
  "log_drain_url": "https://example.com/",
  "message": "your message here"
}

Heroku will then start directing app logs to the provided drain url. We recommend using HTTPS urls for the log_drain_url. See the user docs on log drains for more details.

When an app provisions an add-on successfully, the user will be able to see the drain created on behalf of the add-on in the log drain list.

$ heroku drains
https://two.example.org
-----------------------------
[Dummy Addon]

Keep reading

  • Add-on Development Tasks

Feedback

Log in to submit feedback.

Writing to Application Logs as an Add-on Partner Add-on Manifest

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences