cf logs not showing unique index for my non app components

[Mike Youngstrom]

I tried asking this before [0] but I asked it in an obscure way and didn't get any responses.  So, let me try again.

I recently noticed that the CLI is now outputting the index of CF components other than the app like this:

2015-03-16T16:21:28.03-0600 [RTR/1]

This is great!  However, our installation has 6 routers, why do I only ever see "[RTR/1]" or "[RTR/0]"?  I never see a [RTR/2], [RTR/3], [RTR/4], etc.

The answer is because our installation is made up of 4 different deployments.  Because the router component uses spec.index to identify its index within a single job in a single deployment instead of some index value that takes into account all the jobs of this template type in all the deployments in my installation.

We've had similar issues with using "spec.index" as component index in the past [1].  From my understanding of how PWS is deployed to multiple availability zones it must have the same problem.  Any thoughts on how to address this issue?

Mike

[0] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/UqKx6xZkY-0/XcRSawZo4_8J

[1] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/XY5t7rlZD0o/R6bvPPaXqHQJ

[zaue...@pivotal.io]

Hi Mike,

After taking a quick look, it seems like there isn't a very quick and neat solution. We do not want components to have knowledge of each other's state. So for example you could create a configurable property such as "logging_name" which can be used as a unique identifier. These changes would then need to be pulled into loggregator and have them respect these new configurations or use the current default. That is messy as components now require knowledge of each other and we are not sure where those defaults should live. 

We've CCed the logging + metrics team in this conversation and are going to ask for their input as well.

Thanks!

Zachary + Dan, CF Runtime Team

[Alexander Jackson]

Note that in the new dropsonde protocol[0] for loggregator there is an origin string.   We expect this string will have the bosh job + index which should be unique.   However since it's just a string any level of information could be encoded in there.  This should help components uniquely identify their logs and metrics.

- Alex.

[0] https://github.com/cloudfoundry/dropsonde-protocol/blob/master/events/envelope.proto#L24

[Mike Youngstrom]

Displaying job name+index in the log message might be a little long but perhaps the runtime team could allow us to set the component name portion of loggregator messages?  So our message originating component could be something like "RTR_AZ2/1" in the log messages?

Mike

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAN-TLMCLnsPuNPh11T1GvZYQvnfQ%2Brrvgiey5S84YyBSwW6isw%40mail.gmail.com.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[James Myers]

Hi Mike,

I think you are right. From what I can tell there are a few approaches:

1. We could pass the zone information into the gorouter from cf-release and then make the job name more specific i.e. `RTR_Z1`
2. We could pass a unique identifying index into the router that is not the bosh job index

3. We could allow the user to customize the prefix `RTR` from the manifest, allowing them to set the value specifically for each router in the deployment

From these three options, I think that option 1 seems the most reasonable as it reflects the state of the bosh deployment the most accurately.

While this is something that we will eventually prioritize, I'm not sure how soon this will get done. We are open to a PR solving this problem in the gorouter if you are willing to submit one. If not, you can follow the progress of this story[0].

Thanks for bringing this to our attention,

Jim, CF Runtime Team

[0] https://www.pivotaltracker.com/story/show/90478910

[Mike Youngstrom]

Thanks Jim.

Just to clarify I used RTR as an example.  I believe this is an issue for every component that emits loggregator messages and should be looked at as a broad global issue.

Thanks for creating the story.

Mike

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/87c43e0a-ea2c-4880-8896-2cbaba7ab400%40cloudfoundry.org.