instance id metadata is 'Noinstanceid'

[elrob]

We are logging with our instance id but sometimes the instance id is set to 'Noinstanceid'.
For example, one environment has two instances, with exactly the same application. One instance is showing 'Noinstanceid' in the logs, while the other is working fine and showing the correct instance id.

A quick look through the code suggests that it is being cached. Perhaps this problem is due to not being able to retrieve the instance id when the instance is new/starting up and that the cache should expire if there Noinstanceid is cached and retry retrieving the instance id for when it becomes available (if it ever becomes available?).

(otherwise, cloudwatchappender is working great for us - thanks!)

[pontili]

+1
Il 04/feb/2016 03:23 PM, "Rob Speller" notifications@github.com ha
scritto:

We are logging with our instance id but sometimes the instance id is set
to 'Noinstanceid'.
For example, one environment has two instances, with exactly the same
application. One instance is showing 'Noinstanceid' in the logs, while the
other is working fine and showing the correct instance id.

A quick look through the code suggests that it is being cached. Perhaps
this problem is due to not being able to retrieve the instance id when the
instance is new/starting up and that the cache should expire if there
Noinstanceid is cached and retry retrieving the instance id for when it
becomes available (if it ever becomes available?).

(otherwise, cloudwatchappender is working great for us - thanks!)

—
Reply to this email directly or view it on GitHub
#14.

[camitz]

You may be right. I'll have a look!

[elrob]

Hi,
Did you manage to have a look?
We've done a bit of investigating and it does seem that the 1000 millisecond time out might be too short.

2016-03-02 16:47:37,596 error_instanceid [4] INFO Logger - i-7629****

CloudwatchAppender returned error_instanceid at the same time we were able to retrieve it using a direct call (in our logger constructor) i-7629...

The next log message then has Noinstanceid from Cloudwatchappender and I think Cloudwatchappender has cached it when it shouldn't have:

2016-03-02 16:47:44,002 Noinstanceid [4] INFO Logger - i-7629****

[camitz]

Hi,

I'm working on an update, which will adress this and one more issue. I
appreciate your investigation. How long a timeout would be appropriate?

Best
Martin

On Wednesday, 2 March 2016, Rob Speller notifications@github.com wrote:

Hi,
Did you manage to have a look?
We've done a bit of investigating and it does seem that the 1000
millisecond time out might be too short.

2016-03-02 16:47:37,596 error_instanceid [4] INFO Logger - i-7629****

CloudwatchAppender returned error_instanceid at the same time we were
able to retrieve it using a direct call (in our logger constructor)
i-7629...

The next log message then has Noinstanceid from Cloudwatchappender and I
think Cloudwatchappender has cached it when it shouldn't have:

2016-03-02 16:47:44,002 Noinstanceid [4] INFO Logger - i-7629****

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[elrob]

Excellent. Thanks.

I'm not sure if timeout would be the solution because we discovered that sometimes our directed request also failed to get an instance id. I think the request to get metadata needs to try again on later log messages if it hasn't already got a valid instance id. I assume the metadata does eventually become available but I haven't confirmed this yet.

I think the initial error occurs because the timeout is too short. But, then it should retry on subsequent log messages before caching a valid instance id. I don't think it should cache error or noinstanceid.

[camitz]

Yes, exactly. I thought i'd do both, if I can.

On Wednesday, 2 March 2016, Rob Speller notifications@github.com wrote:

Excellent. Thanks.

I'm not sure if timeout would be the solution because we discovered that
sometimes our directed request also failed to get an instance id. I think
the request to get metadata needs to try again on later log messages if it
hasn't already got a valid instance id. I assume the metadata does
eventually become available but I haven't confirmed this yet.

I think the initial error occurs because the timeout is too short. But,
then it should retry on subsequent log messages before caching a valid
instance id. I don't think it should cache error or noinstanceid.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[camitz]

I've released v4.5-alpha targeting this issue. Let me know if it works for you!

[camitz]

I just pushed v.4.6.0-alpha1 to nuget.

[elrob]

Thanks. We have actually implemented our own method to get the instance id and inject it into the config file before start up using elastic beanstalk .ebextensions and a powershell script. I am no longer on the team so I'm unable to test the metadata fix myself. I wonder if it has fixed the issue for @pontili ?