I’m setting up log drains from Heroku to NR Logs, hoping to partition them by drain. It doesn’t look like anything about the particular drain makes it into the logged object, though, and what is there isn’t helpful for partitioning by app or drain:
Besides renaming all of my app processes to include the app name as a prefix (i.e. “appname_worker_run”, instead of “worker_run”), has anyone else solved this?
Ahhh, I just realized that renaming the processes won’t help for all of the Heroku-originated lines (i.e. from the router, or from heroku-postgres, etc).
If I’ve got separate apps sending logs in via distinct drains, I feel like this should be a simple thing somewhere, to hinge on drain source and thereby partition. Thoughts/ideas?
Also facing this issue. I can’t separate out logs based on which heroku app they come from - this seems like a trivial thing?
I am also facing this same issue. I don’t see anything to partition because it doesn’t seem like the drain ID or anything makes it into NR.
did anyone figure out a way to do this? Maybe passing some custom (app-specific) identifier along with the logs?
We are also hitting this issue, and it’s a HUGE problem for us – lack of ability to separate apps makes the logging pretty much useless.
Hello Everyone,
I will submit this as a feature request. Currently there is not an easy way to accomplish this task. New Relic drops the drain token from the message and this makes it difficult to tie a drain to an application.
It might be possible to find a work around but I have not been able to get it to work. Some resources to help you would be the following:
Dyno Metadata
Log-runtime-metrics
The goal here is to tack on the Metadata exported as variables to the syslog message. Here is a source using Express Middleware: Express Heroku Metadata
As I said, I will submit this as a feature request. I hope this helps.
Hello,
Has there been any progress made on this? We’re in the process of migrating from Loggly which offers the ability to add tags to logs. Our comparison between Loggly and New Relic has been very favorable for New Relic except for this one issue which is currently a deal breaker. Most recently, we had a series of dyno crashes that resulted in log lines coming from Heroku directly that simply said State changed from up to crashed and no other information. In Loggly, these messages were all grouped with the app that caused them thanks to tags. In New Relic, unfortunately, it was not possible to tell which of the three Heroku apps sending logs to New Relic the state change came from.
If the ability to partition all logs from a specific app is a ways off, it would be helpful to know so we could disable our New Relic log setup until it is ready.
Hi @brock97
I hope you are well. Apologies for the delay in getting to this response.
We read every post we want you to know we take all support questions seriously. Our goal is to always have everyone in the community feel supported.
For the update in relation to feature request update I can see that its currently still being planned, I can see its planned for FY 22 Q3 which sounds great. Please note this is not a guarantee and is subject to change as this is a feature request.
For your follow-up question I have gone ahead and looped in a Logs expert from the New Relic team, they will reach out here with their reply.
If you have any other further questions or updates on the issue, please do reach out! We are here to help.
Thank you for the reply @dcody. We ended up writing our own log forwarder in Go that is deployed as a Heroku app which is POST’ing logs via the New Relic Log API. As a result, the need is not as urgent and we’re continuing with our New Relic integrations.
We’re planning on putting the app out on Github and I’ll post the link when that happens.
Hi @brock97
Thank you for the feedback, thats great to hear to managed to work around it.
Looking forward to seeing the link in the future.
Does this recent announcement render the problem here moot?
Hi @brock97 , I’m happy to say that this feature is tentatively planned for implementation in a future release. While I don’t have a specific timeline to share, and plans may change due to the unforeseen nature of the development cycle, we definitely understand the need to let you keep the Heroku app metadata on your logs which are ingested through syslog drains, and we are working on making this possible in upcoming sprints.
@mlemieux glad to hear this is getting implemented. This is also a major issue for our team. We have 10+ Heroku apps sending log drains into the same account and without a way to segment those logs by app they’re not really useful to us. ie. we can’t tell if the staging or prod app crashed and alert on it.
I’d also add that even once logs are segmented, the inability to parse the log messages from Heroku and extra ie. status, host, etc makes it really hard to use these logs.
I think this is happening because the syslog parser runs first.
@engineering-delivery Thank you for this feedback, I’ve added it to the feature request for context. We’ll keep an eye on parsing behavior as we go.
Doesn’t help… we use PHP and the PHP agent sure needs some love!
Hey @jong2,
Welcome to the community!
Terribly sorry that these new benefits are not implemented for the PHP Agent. If anything changes we will definitely keep the community updated! Please let us know if we can help with anything and have a great day!
This topic was automatically closed after 365 days. New replies are no longer allowed.
