Is there a way to configure custom attributes or other metadata when sending logs directly (`NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS=true`)? about newrelic-lambda-extension HOT 8 OPEN

Has there been any work done on this? Currently this makes the Logs view pretty useless when you have multiple lambdas with the same name (e.g. for different environments). We need to be able to add a custom environment attribute to the exported logs.

What's worse, is that the exported logs don't even carry an entity.guid attribute.

from newrelic-lambda-extension.

We don't have any mechanism for this right now, but it's an interesting idea. It probably wouldn't be hard to look for a file at startup, say nr-log-common-attrs.json, in the function's root (next to your handler), and merge that document with the existing common attrs at runtime.

Unfortunately, including tags and the like automatically would be awkward. The function doesn't, by default, have access to look at its own configuration. That would require modification of the runtime permissions for the function, and that's a big issue for many of our customers.

from newrelic-lambda-extension.

Hi @MattWhelan, thanks for your reply and consideration.

Yeah, I actually considered the possibility of using tags for this purpose, but what I suggested here is an environment variable:

I see that newrelic/aws-log-ingestion has an NR_TAGS environment variable to associate metadata with logs (I assume / it appears it actually means attributes rather than tags) and it seems like this could support something similar. I haven't implemented a Lambda extension, but I see that the documentation says they have access to the function's environment variables.

In that context the only thing I have to say about tags is that I wouldn't include "tag" in the environment variable name if it's for setting attributes.

The other thing I mentioned about tags at the end of my post is a separate but related issue, that it would be useful to be able to filter logs based on tags of the entity they're associated with. To be clear, I don't mean via copying the tags into attributes in the Lambda extension. I mean that:

if you setup the AWS infrastructure integration, New Relic inventories Lambdas and their tags and creates an association between the entity and the logs. For example, you can browse to the entity and look at its logs

In that case New Relic knows about the entity, its tags, and the logs that are associated with it, but doesn't seem to provide a way to filter the logs based on the entity's tags. If that were possible I might put some tags on my resources and not worry about setting additional attributes on the log items. Since that's not possible, I'm suggesting a feature for statically setting additional attributes on the log items.

A JSON file wouldn't work quite the way I have in mind. Say I'm using the attributes to identify an environment (like staging or production), it would be more straightforward to vary the attributes using environment variables than via a static file.

I was going to say, though: if that approach gets adopted, I personally would just as soon use JSON in the environment variable vs. the env:prod;team:myTeam format of newrelic-log-ingestion's NR_TAGS variable. Example:

NEW_RELIC_LOG_ATTRIBUTES  {"deployment.environment": "production"}

The function doesn't, by default, have access to look at its own configuration. That would require modification of the runtime permissions for the function, and that's a big issue for many of our customers.

Yeah, and it would also:

• Require either reading them on every invocation, or caching them and having a window of opportunity for the tags to change without being reflected in the attributes.

• Limit you to configuring the data at the function level vs. the version / alias level.

• Require different permissions for setting the data (e.g. TagResource vs. UpdateFunctionConfiguration + PublishVersion).

from newrelic-lambda-extension.

@jmm The use case where you want to be able to filter logs based on the Lambda entity is definitely something we want to address. One workaround that exists today is using the aws_request_id in the logs filter to limit the logs to a specific request. But we want to do the same for the entity itself. Your suggestions are definitely in line with our thinking, the platform should be doing as much as possible to tie things together instead of relying on a crude tags mechanism to do it.

from newrelic-lambda-extension.

I may be oversimplifying here, but would this not be as simple as adding support for an environment variable that gets wired up to this?

from newrelic-lambda-extension.

Currently this makes the Logs view pretty useless when you have multiple lambdas with the same name (e.g. for different environments). We need to be able to add a custom environment attribute to the exported logs.

I wanted to bump this issue because this extension is really tough to use in more than one environment. Even something like the application associated with the lambda function would be sufficient as an attribute in the log.

from newrelic-lambda-extension.

Agreed - extension is basically useless if you can't differentiate between environments.

from newrelic-lambda-extension.

@MattWhelan any update on this issue?
We mostly add extra attributes using winstonjs but some error don't get caught (i.e. promise rejections) and so they're not easily visible when searching our logs by custom attributes.

from newrelic-lambda-extension.