Log source color assignments

[krancour]

At least twice now I have observed log messages from the first (or only) pod / container of a given app to be colorized in same way as log messages written by the controller on that application's behalf.

I realize we have a finite number of colors and we can't possibly avoid reusing them, but since web apps are initially scaled to 1, I do think we should be able to offer some assurance that the logs from the controller and the first / only pod are not colorized in the same way.

[Joshua-Anderson]

Right now, we add the integer value of all the characters in the process title and divide by the number of colors, taking the remainder as the selected color.

It's a very simple, but very stupid solution.

In this situation, the integer value of the sum of the characters for both the controller process type and the other process type have the same remainder, giving them the same color. In order to prevent this, we would need to stop using this algorithm and instead would need to save all the process titles in the output and their assigned color to prevent repeats to the greatest possible degree.

[krancour]

What if we just used a dedicated color for the messages from the controller and removed that color from the pool used for the other processes?

[bacongobbler]

because then we're adding client-level implementation details into the API response. If someone were to extend the API in another language or in an environment where pretty colors are not important, that data would be useless.

fwiw Heroku colors their logs based on the process type and process number as well (e.g. web.1 would be different than web.3 in most cases). Color collisions mostly occur due to the lack of colors a TTY provides (8 + default uncolored text). If we had a full color spectrum then this wouldn't occur very often, if at all.

[krancour]

because then we're adding client-level implementation details into the API response. If someone were to extend the API in another language or in an environment where pretty colors are not important, that data would be useless.

afaik, this doesn't involve touching the API at all. Colorizing is done entirely by the CLI. I'm suggesting that we could us a regex, perhaps, to distinguish log messages originating from the controller from those originating from application processes. By doing that, we could reserve a dedicated color for the controller.

imo, the logs originating from the controller are special because they are indicative of administrative functions that have been performed upon the app. I think it's important that those not get "lost" in a sea of logs viewed via the client.

[krancour]

Colorizing is done entirely by the CLI.

Or have I got that wrong? I'm questioning it now.

[bacongobbler]

No, you've got it right. prettyprint is the package we use to colorize the logs. All done on the client side. :)

By doing that, we could reserve a dedicated color for the controller.

That would be a happy medium. Just reserve one of the 8 colors for the controller, then use the rest of the color wheel for the application logs. That way the controller is guaranteed to be different from the rest.

I vote for Magenta 😉

afaik, this doesn't involve touching the API at all.

Sorry, I was responding to

What if we just used a dedicated color for the messages from the controller and removed that color from the pool used for the other processes?

And thought you meant literally attaching a color code to the log and shipping that in the response. I mis-interpreted your proposal. My bad! :)

[krancour]

No worries. And I like magenta. 👍

[Joshua-Anderson]

I opened PR #132 to fix this.