• Icon: Improvement Improvement
    • Resolution: Won't Do
    • Icon: Major Major
    • evergreen
    • Evergreen - Milestone 2

      Problem statement

      When working on client code, the variety of log formatting can make it hard to follow, and assess the time between two events.

      Example (logs from make run):

      instance_1  | [INFO][2018-10-01 12:01:46] Jenkins is fully up and running (from hudson.WebAppMain$3 run)
      instance_1  | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/instance-identity/. Next wait 7629.39453125
      instance_1  | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/metrics/evergreen/healthcheck. Next wait 7629.39453125
      instance_1  | debug: metrics healthchecking endpoint: everything looks fine: {"disk-space":{"healthy":true},"plugins":{"healthy":true,"message":"No failed plugins"},"temporary-space":{"healthy":true},"thread-deadlock":{"healthy":true}}
      instance_1  | info: Jenkins healthcheck after restart succeeded! Yey.
      instance_1  | 2018/10/01 12:01:52 [info] 24#24: *1 client 172.19.0.1 closed keepalive connection
      backend_1   | Executing (default): SELECT "updateId", COUNT("id") AS "num_instances" FROM "instances" AS "instances" GROUP BY "updateId";
      backend_1   | Executing (default): SELECT "id", "commit", "channel", "manifest", "tainted", "createdAt", "updatedAt" FROM "updates" AS "updates" ORDER BY "updates"."createdAt" DESC LIMIT 5;
      instance_1  | [INFO][2018-10-01 12:01:54] Obtained the latest update center data file for UpdateSource default (from hudson.model.UpdateSite updateData)
      

      Expected behavior

      All logs should be timestamped so that we can easily check from logs when something happened, and as importantly how much time elapsed between a given log and another.

      Ideally timestamping format should be aligned so that all logs have the same (be it that they come from Jenkins itself or evergreen-client

      Additional comment

      My main focus right now is for development purpose. But I believe that it would be very useful in case we have to ask someone for client logs to debug something like a hard crash, or some inability to upgrade to a new Update Level.

          [JENKINS-53854] Timestamp evergreen-client logs

          Baptiste Mathus created issue -
          Baptiste Mathus made changes -
          Description Original: h3. Problem statement

          When working on client code,

          h3. Expected behavior

          All logs should be timestamped so that we can easily check from logs when something happened, and as importantly how much time elapsed between a given log and another.

          Ideally timestamping format should be aligned so that *all* logs have the same (be it that they come from Jenkins itself or evergreen-client
          New: h3. Problem statement

          When working on client code, the variety of log formatting can make it hard to follow, and assess the time between two events.

          Example (logs from {{make run}}):

          {noformat}
          instance_1 | [INFO][2018-10-01 12:01:46] Jenkins is fully up and running (from hudson.WebAppMain$3 run)
          instance_1 | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/instance-identity/. Next wait 7629.39453125
          instance_1 | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/metrics/evergreen/healthcheck. Next wait 7629.39453125
          instance_1 | debug: metrics healthchecking endpoint: everything looks fine: {"disk-space":{"healthy":true},"plugins":{"healthy":true,"message":"No failed plugins"},"temporary-space":{"healthy":true},"thread-deadlock":{"healthy":true}}
          instance_1 | info: Jenkins healthcheck after restart succeeded! Yey.
          instance_1 | 2018/10/01 12:01:52 [info] 24#24: *1 client 172.19.0.1 closed keepalive connection
          backend_1 | Executing (default): SELECT "updateId", COUNT("id") AS "num_instances" FROM "instances" AS "instances" GROUP BY "updateId";
          backend_1 | Executing (default): SELECT "id", "commit", "channel", "manifest", "tainted", "createdAt", "updatedAt" FROM "updates" AS "updates" ORDER BY "updates"."createdAt" DESC LIMIT 5;
          instance_1 | [INFO][2018-10-01 12:01:54] Obtained the latest update center data file for UpdateSource default (from hudson.model.UpdateSite updateData)
          {noformat}

          h3. Expected behavior

          All logs should be timestamped so that we can easily check from logs when something happened, and as importantly how much time elapsed between a given log and another.

          Ideally timestamping format should be aligned so that *all* logs have the same (be it that they come from Jenkins itself or evergreen-client
          Baptiste Mathus made changes -
          Description Original: h3. Problem statement

          When working on client code, the variety of log formatting can make it hard to follow, and assess the time between two events.

          Example (logs from {{make run}}):

          {noformat}
          instance_1 | [INFO][2018-10-01 12:01:46] Jenkins is fully up and running (from hudson.WebAppMain$3 run)
          instance_1 | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/instance-identity/. Next wait 7629.39453125
          instance_1 | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/metrics/evergreen/healthcheck. Next wait 7629.39453125
          instance_1 | debug: metrics healthchecking endpoint: everything looks fine: {"disk-space":{"healthy":true},"plugins":{"healthy":true,"message":"No failed plugins"},"temporary-space":{"healthy":true},"thread-deadlock":{"healthy":true}}
          instance_1 | info: Jenkins healthcheck after restart succeeded! Yey.
          instance_1 | 2018/10/01 12:01:52 [info] 24#24: *1 client 172.19.0.1 closed keepalive connection
          backend_1 | Executing (default): SELECT "updateId", COUNT("id") AS "num_instances" FROM "instances" AS "instances" GROUP BY "updateId";
          backend_1 | Executing (default): SELECT "id", "commit", "channel", "manifest", "tainted", "createdAt", "updatedAt" FROM "updates" AS "updates" ORDER BY "updates"."createdAt" DESC LIMIT 5;
          instance_1 | [INFO][2018-10-01 12:01:54] Obtained the latest update center data file for UpdateSource default (from hudson.model.UpdateSite updateData)
          {noformat}

          h3. Expected behavior

          All logs should be timestamped so that we can easily check from logs when something happened, and as importantly how much time elapsed between a given log and another.

          Ideally timestamping format should be aligned so that *all* logs have the same (be it that they come from Jenkins itself or evergreen-client
          New: h3. Problem statement

          When working on client code, the variety of log formatting can make it hard to follow, and assess the time between two events.

          Example (logs from {{make run}}):

          {noformat}
          instance_1 | [INFO][2018-10-01 12:01:46] Jenkins is fully up and running (from hudson.WebAppMain$3 run)
          instance_1 | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/instance-identity/. Next wait 7629.39453125
          instance_1 | debug: waiting for 6103.515625 ms before next retry for http://127.0.0.1:8080/metrics/evergreen/healthcheck. Next wait 7629.39453125
          instance_1 | debug: metrics healthchecking endpoint: everything looks fine: {"disk-space":{"healthy":true},"plugins":{"healthy":true,"message":"No failed plugins"},"temporary-space":{"healthy":true},"thread-deadlock":{"healthy":true}}
          instance_1 | info: Jenkins healthcheck after restart succeeded! Yey.
          instance_1 | 2018/10/01 12:01:52 [info] 24#24: *1 client 172.19.0.1 closed keepalive connection
          backend_1 | Executing (default): SELECT "updateId", COUNT("id") AS "num_instances" FROM "instances" AS "instances" GROUP BY "updateId";
          backend_1 | Executing (default): SELECT "id", "commit", "channel", "manifest", "tainted", "createdAt", "updatedAt" FROM "updates" AS "updates" ORDER BY "updates"."createdAt" DESC LIMIT 5;
          instance_1 | [INFO][2018-10-01 12:01:54] Obtained the latest update center data file for UpdateSource default (from hudson.model.UpdateSite updateData)
          {noformat}

          h3. Expected behavior

          All logs should be timestamped so that we can easily check from logs when something happened, and as importantly how much time elapsed between a given log and another.

          Ideally timestamping format should be aligned so that *all* logs have the same (be it that they come from Jenkins itself or evergreen-client

          h3. Additional comment

          My main focus right now is for development purpose. But I believe that it would be very useful in case we have to ask someone for client logs to debug something like a hard crash, or some inability to upgrade to a new Update Level.
          Baptiste Mathus made changes -
          Link New: This issue relates to JENKINS-53796 [ JENKINS-53796 ]
          Baptiste Mathus made changes -
          Sprint New: Evergreen - Milestone 2 [ 516 ]
          Baptiste Mathus made changes -
          Labels New: evergreen
          R. Tyler Croy made changes -
          Assignee Original: R. Tyler Croy [ rtyler ]
          Mark Waite made changes -
          Resolution New: Won't Do [ 10001 ]
          Status Original: Open [ 1 ] New: Closed [ 6 ]
          Naveen Boni made changes -
          Assignee New: Naveen Boni [ naveenboni ]

            naveenboni Naveen Boni
            batmat Baptiste Mathus
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: