Re: How can I get logs from nodejs show up but not from python scripts
Heroku receives everything that your app sends to standard output (also
known as stdout), so the key question is how to send Python logs to
standard out.
Depending on the framework(s) you're using, here's 2 ways to do that:
* A very short way to force `logging` to use sys.stdout:
https://coderwall.com/p/_fg97w/creating-a-python-logger-to-stdout
* A more elegant/idiomatic way to use a stdout-backed `logging`
handler:
http://help.papertrailapp.com/kb/configuration/configuring-centralized-logging-from-python-apps/#logging-via-the-heroku-add-on
Note that, if you're calling `logging.warning` (instead of, say,
`logging.error`), you'll also need to set the level to at least
`warning` (or to a more verbose level like `info` or `debug`). The
examples above show how to specify the level at instantiation.
Troy
On Sat, May 13, 2017, at 05:20 PM, Marcio Valenzuela wrote:
> I can see:
>
> console.log('something to log'); from my app.js
>
> which show up as:
>
> something to log
>
> But that app.js runs python scripts based on a switch case
> where I use:>
>
>
> import logging
>
>
>
> logging.warning('2gpio pin toggle!') # will print a message to
> the console>
> but this doesnt show up in the heroku logs. How can I see that that
> script got called?>
> Thanks
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Heroku" group.
>
> To unsubscribe from this group, send email to
> heroku+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/heroku?hl=en_US?hl=en
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Heroku Community" group.> To unsubscribe from this group and stop
> receiving emails from it,
> send an email to heroku+unsubscr...@googlegroups.com.> For more options,
> visit https://groups.google.com/d/optout.
--
--
You received this message because you are subscribed to the Google
Groups "Heroku" group.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups
"Heroku Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to heroku+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: CouchDB Heroku Addon
As an add-on provider, I can confirm that the platform works the way it's described and the team is logical. I think rather than whether Heroku would accept the add-on, the question to ask yourself is whether you're excited about supporting CouchDB (and CouchDB users), and if so, whether you think you'll still be excited about it in 2 or 3 years. The business aside, It's not unlike getting a pet :-) Troy -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Heroku app reeeeaaly slow accessed from China - other people's experiences?
On Tue, Mar 18, 2014 at 11:37 PM, Erik Chan erik.c...@gmail.com wrote: Wondering if anything has changed on this front? My app is very slow loading from China Can you paste the URL to a screenshot of a browser's network tab loading a page from China, or an equivalent loading timeline? In a typical app, the Web server/Heroku service is only serving 1 document per page load. The static assets are probably coming from a CDN like Cloudfront or Fastly. Even if static assets are coming from the app[1], another 200-300 ms of RTT shouldn't make it very slow, just not instant. [1]: There's almost no reason to do this for any production app, let alone an app with a worldwide audience. Troy -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Do add-ons apply to more than one application in an account?
Even if add-ons don't fit your situation perfectly, the Heroku platform and/or those services may. Add-ons cover most cases, but (rightly) don't try to cover every last situation. If an add-on isn't a good fit, you can usually provision the service separately (at the expense of SSO, Heroku-managed collaborators, and centralized billing). With the exception of platform add-ons like SSL, think of add-ons as additive rather than as a reason not to use Heroku. Troy -- @troyd -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Logger.new fails on heroku but not locally
On Mon, Oct 1, 2012 at 11:26 AM, Justin Collum jcol...@gmail.com wrote: I can delete ./log (with recurse) and start my server up in production env and I will have a production.log file there. But when I upload to heroku I get the error log up above. I'm not sure what to do next. Suggestions? Don't use the filesystem for logs. As The Twelve Factor App (AKA The Heroku Bible) says, A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. There are good reasons for this, most obviously that even if it worked, you'd end up with either one file per dyno and a single visitor's requests scattered all over the place, or a dependence on a network filesystem, a ton more platform complexity to magically present it, and a prayer that concurrent writes don't trample one another. When running on Heroku, event streams become the platform's problem. The app's job is to write them to stdout. Heroku does that for most Ruby apps by injecting rails_log_stdout https://github.com/ddollar/rails_log_stdout during deployment. Instantiating a new Logger instance probably works around it. (Dynos do have access to a local filesystem, but it's destroyed when the dyno dies and is definitely not intended for logs.) The good news is that the fix is easy: remove that application.rb hack entirely and let rails_log_stdout do its thing. It works with a Rails 3 app without any changes. If you need to instantiate Logger for another reason, do it with Logger.new(STDOUT). That's rarely needed. Monitor logs with heroku logs, a log management add-on, and/or your own syslog drain. Since the platform is routing your logs, they can go to multiple places and can be rerouted independent of code changes or deploys. Speaking for my add-on, the result is a lot better than you'd get from a file per dyno or even a collated file, too -- long live logs, but not necessarily as log files :) Hope this helps, and please post more if unwinding your changes or using Logger.new(STDOUT) doesn't work. Troy -- papertrailapp.com -- making logs fun. ish. -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
Re: Heroku Access Through Firewall
On Mon, Aug 6, 2012 at 5:08 PM, Karl threadh...@gmail.com wrote: I know every firewall is different, and maybe a proxy and filter are the best methods to handle this. But I need to give them some guidance. Can someone give me some tips on what to tell firewall administrators what to do to allow access to a Heroku application? Couple options: - If you control both endpoints and aren't tied to a firewall-based solution, configure digest auth on the Web server and rely on that. Expose the Web server on a non-default port and/or path if you want less noise. The attack surface is still fairly small, especially if the Web server performs digest auth before your app sees the request. - Use a proxy, typically a tiny VM from your choice of providers. - Amazon does publish EC2 public IP ranges: https://forums.aws.amazon.com/ann.jspa?annID=1528. I'd opt for either of the other options before this one, since it would mean keeping up with the forum posts, inevitably missing one, and then having to detect the problem from spurious (dyno-specific) connection timeouts. Creates more problems than it avoids. Finally, if you use a proxy, here are iptables rules to forward eth0 TCP 1880 to 1.2.3.4:80: -A PREROUTING -i eth0 -p tcp -m tcp --dport 1880 -j DNAT --to-destination 1.2.3.4:80 -A POSTROUTING -d 1.2.3.4/32 -o eth0 -j MASQUERADE -A FORWARD -d 1.2.3.4/32 -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT and permit connections to it: -A INPUT -i eth0 -p tcp -m tcp --dport 1880 -j ACCEPT Troy -- @troyd // @papertrailapp -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
Re: Heroku Access Through Firewall
- Use a proxy, typically a tiny VM from your choice of providers. And that is my first thought. But not every company has one, or is willing to start one just for my app. If most of your customers need to set IP-based ACLs on your traffic, it may not be well suited for a multitenant PaaS like Heroku. From what's available, Morten's suggestion of Proximo is the way to go (or operating your own authenticated SOCKS proxy, but I wouldn't run that by choice unless you absolutely had to). All HTTP traffic from your app to the customers would use this proxy. Or is what you are suggesting is putting my app server on a different port than 80/443, and allowing http traffic through the firewall for only that port? But wouldn't that disregard other users who expect the app to operation on 80/433? No. I was suggesting running the proxy port on a non-default port (in the example, 1880). This only works if the service is authenticated another way and it's solving an edge case, and it sounds like neither of those are true here. So, use Proximo, run your own SOCKS proxy, or change hosting. Hope this helps, Troy -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
