Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-3974

Easier debugging with standardized logging

    • Type: Icon: Epic Epic
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Node Drivers
    • Hide
      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?
      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?
    • Easier debugging with standardized logging
    • 8
    • 21.5
    • 22
    • 100
    • Hide

      Engineer: Durran Jordan, Warren James, Neal Beeken

      2024-12-19: Target date set to January 17

      Completed over the last 2 weeks:

      • Measured and investigated potential improvements to command monitoring performance, which is expected to be a large portion of the logging performance cost
      • Made it possible to enable logging in our performance tests

      Focus over the next 2 weeks:

      • Project on pause due to holiday OOO
      • Next up:
        • Enable logging in a new performance task and determine how much overhead logging adds to the command monitoring performance hit.
        • Decide on and implement a command monitoring performance improvement solution, then re-measure the logging performance to determine a release go/no-go decision. If the improved logging performance profile compares favorably to the current performance of command monitoring, we will release the feature.

      Risks/Blockers:

      • We expect EJSON stringification to also form a significant part of the logging cost. It is possible that this will prevent the performance of improved logging not meeting the target we set. We will address slicing EJSON eagerly in a future quarter.

      Engineer: Aditi Khare

      2024-02-16: Removing target end date (see notes below)

      What was completed over the last two weeks?

      • Ran full performance benchmarks
      • Analyzed results and observed a large performance drop
      • Discussed performance implications in detail with PM/Eng Lead, had a Go/No Go meeting
        • Decided No-Go with the current state

      What's the focus over the next two weeks?

      • This project will be Backlogged at this time, with plans to pick back up in Q2 and address the performance concerns
        • Size/estimate unknown
        • Will revisit ahead of Q2 Quarterly Planning to figure out a plan for picking this back up 

      Impediments encountered over the last two weeks:

      • See above

      2024-02-02: Set end date to 2024-02-09

      • Last two weeks:
      1. completed error handling for logging
      2. miscellaneous spec requirement fixes
      3. finishing up perf fixes to the logger to ensure there are no regressions
      • Next up:
      1. finishing up another 2 perf tickets to optimize logger instantiation and code paths
      2. ffter those are finished, we will release standardized logging
      • No risks at this time

      2024-01-19: Updated target end date

      • Completed:
      1. Add log messages to Command monitoring spec
      • In Progress:
      1. Add error handling to the logger
      2. Address performance regression with Server Selection logging changes

      2024-01-01: No change to target date

      • Completed:
        • Enhanced EJSON
        • Removed getNonce for 6.2+
        • SDAM logging
      • In Progress:
        • Server selection and command logging in review
      • Next up:
        • Add error handling to logger

      2023-12-08: No change to target date

      • Completed:
        • Tech debt blocker to server selection logging
        • Confirmed with the team the rest of the logging project trajectory
      • In Progress:
        • Working on SDAM and server selection logging
      • Next up:
        • Begin CLAM logging, error handling for logger, and prepare for release

      2023-11-28: Updated target date to Jan 05

      • Adding abstract commandName variable to AbstractOperation and subclasses to unblock server selection logging

      Engineer: Aditi Khare

      2023-11-14: On track for Dec 8

      • Completed support for all log configuration options via client
      • Working on passing spec tests for server selection failed test cases; other tests passing

      Engineer: Aditi Khare

      2023-10-31: On track for Dec 8

      • Added Typescript support for mongodbLogPath in client options

      2023-10-13: Target date set to Dec 8

      • Target date dependent on the finalization of the team’s Q4 plan
      • Resuming project after putting it on hold in April
      • Upcoming:
        • Adding a log path as an internal client option
        • Prioritizing Cosmos/DocumentDB logging
        • Will continue work on adding configurable log options to client

      Engineer(s): Warren James
      Summary: Unlike many languages, the Node.js ecosystem has no standard logging library or tool.  Thus, a private logging utility will be added to the driver.

      2023-04-28: Putting project on hold

      • Merged changes that make the logger itself spec compliant
      • Started work to log the connection component messages, should merge next week
      • After the above, this project will be put on hold until Q3
        • serverSelection and topology logging specifications aren't complete
        • CLAM logs not yet implemented; this will be more involved since it will require some structural changes to the driver

      Engineer(s): Warren James
      2023-04-14: Target date of Apr 21 at risk

      • May need another week to sort through the complications introduced by implementing the CLAM spec and design of the public-facing configuration options
      • Completed majority of primary implementation of the MongoLogger and the remainder should merge in the coming week.
      • Up next: Implement the CMAP and CLAM spec and finalize the public-facing configuration options

      Engineer(s): Warren James
      2023-03-31: Target date of Apr 7 at risk

      • May need another two weeks on account of the additional time taken up by the design refinements and unforeseen future changes.
      • Revisited the design of the severity logging methods and are in the primary implementation phase.
      • Up next: Complete and refine the primary implementation and begin using the logger to implement the required log messages called out by the specification.

      Engineer(s): Warren James
      2023-03-17: On target for Apr 7

      • Updates to BSON needed to accommodate the remainder of the logging work have been merged and a new minor BSON version was released with the feature. * * Unified Spec Runner changes are close to merging, which will allow for work on the actual logger implementation to begin in earnest.
      • Next week, we intend to start the logger implementation, in particular the level-specific logging methods and the capability to write to a user-specified stream, after which the CLAM spec logs will be implemented.
      • No risks or delays.

      Engineer(s): Bailey Pearson, Warren James

      2023-03-03

      • Still working on the changes to the unified spec runner (NODE-4685).
      • Currently writing unit tests to ensure that the new functionality works as expected.
      • No risks or delays.

      Engineers: Andy Mina and Bailey Pearson

      2022-11-23:

      • Status update:
        • Kicked off the project with the deprecation of the existing logger and adding the definition for  the new Logger class.
      • Rationale for delays:
        • No Delays.
      •  Risks:
        • No Risks.
      Show
      Engineer: Durran Jordan, Warren James, Neal Beeken 2024-12-19: Target date set to January 17 Completed over the last 2 weeks: Measured and investigated potential improvements to command monitoring performance, which is expected to be a large portion of the logging performance cost Made it possible to enable logging in our performance tests Focus over the next 2 weeks: Project on pause due to holiday OOO Next up: Enable logging in a new performance task and determine how much overhead logging adds to the command monitoring performance hit. Decide on and implement a command monitoring performance improvement solution, then re-measure the logging performance to determine a release go/no-go decision. If the improved logging performance profile compares favorably to the current performance of command monitoring, we will release the feature. Risks/Blockers: We expect EJSON stringification to also form a significant part of the logging cost. It is possible that this will prevent the performance of improved logging not meeting the target we set. We will address slicing EJSON eagerly in a future quarter. Engineer: Aditi Khare 2024-02-16: Removing target end date (see notes below) What was completed over the last two weeks? Ran full performance benchmarks Analyzed results and observed a large performance drop Discussed performance implications in detail with PM/Eng Lead, had a Go/No Go meeting Decided No-Go with the current state What's the focus over the next two weeks? This project will be Backlogged at this time, with plans to pick back up in Q2 and address the performance concerns Size/estimate unknown Will revisit ahead of Q2 Quarterly Planning to figure out a plan for picking this back up  Impediments encountered over the last two weeks: See above 2024-02-02: Set end date to 2024-02-09 Last two weeks: completed error handling for logging miscellaneous spec requirement fixes finishing up perf fixes to the logger to ensure there are no regressions Next up: finishing up another 2 perf tickets to optimize logger instantiation and code paths ffter those are finished, we will release standardized logging No risks at this time 2024-01-19: Updated target end date Completed: Add log messages to Command monitoring spec In Progress: Add error handling to the logger Address performance regression with Server Selection logging changes 2024-01-01: No change to target date Completed: Enhanced EJSON Removed getNonce for 6.2+ SDAM logging In Progress: Server selection and command logging in review Next up: Add error handling to logger 2023-12-08: No change to target date Completed: Tech debt blocker to server selection logging Confirmed with the team the rest of the logging project trajectory In Progress: Working on SDAM and server selection logging Next up: Begin CLAM logging, error handling for logger, and prepare for release 2023-11-28: Updated target date to Jan 05 Adding abstract commandName variable to AbstractOperation and subclasses to unblock server selection logging Engineer: Aditi Khare 2023-11-14: On track for Dec 8 Completed support for all log configuration options via client Working on passing spec tests for server selection failed test cases; other tests passing Engineer: Aditi Khare 2023-10-31: On track for Dec 8 Added Typescript support for mongodbLogPath in client options 2023-10-13: Target date set to Dec 8 Target date dependent on the finalization of the team’s Q4 plan Resuming project after putting it on hold in April Upcoming: Adding a log path as an internal client option Prioritizing Cosmos/DocumentDB logging Will continue work on adding configurable log options to client Engineer(s): Warren James Summary: Unlike many languages, the Node.js ecosystem has no standard logging library or tool.  Thus, a private logging utility will be added to the driver. 2023-04-28: Putting project on hold Merged changes that make the logger itself spec compliant Started work to log the connection component messages, should merge next week After the above, this project will be put on hold until Q3 serverSelection and topology logging specifications aren't complete CLAM logs not yet implemented; this will be more involved since it will require some structural changes to the driver Engineer(s): Warren James 2023-04-14: Target date of Apr 21 at risk May need another week to sort through the complications introduced by implementing the CLAM spec and design of the public-facing configuration options Completed majority of primary implementation of the MongoLogger and the remainder should merge in the coming week. Up next: Implement the CMAP and CLAM spec and finalize the public-facing configuration options Engineer(s): Warren James 2023-03-31: Target date of Apr 7 at risk May need another two weeks on account of the additional time taken up by the design refinements and unforeseen future changes. Revisited the design of the severity logging methods and are in the primary implementation phase. Up next: Complete and refine the primary implementation and begin using the logger to implement the required log messages called out by the specification. Engineer(s): Warren James 2023-03-17: On target for Apr 7 Updates to BSON needed to accommodate the remainder of the logging work have been merged and a new minor BSON version was released with the feature. * * Unified Spec Runner changes are close to merging, which will allow for work on the actual logger implementation to begin in earnest. Next week, we intend to start the logger implementation, in particular the level-specific logging methods and the capability to write to a user-specified stream, after which the CLAM spec logs will be implemented. No risks or delays. Engineer(s): Bailey Pearson, Warren James 2023-03-03 Still working on the changes to the unified spec runner ( NODE-4685 ). Currently writing unit tests to ensure that the new functionality works as expected. No risks or delays. Engineers: Andy Mina and Bailey Pearson 2022-11-23: Status update: Kicked off the project with the deprecation of the existing logger and adding the definition for  the new Logger class. Rationale for delays: No Delays.  Risks: No Risks.
    • Hide

      DRIVERS-1204:

      • Implement logging infrastructure and unified test runners defined in DRIVERS-1677
      • Implement log messages and corresponding tests for each component
      Show
      DRIVERS-1204 : Implement logging infrastructure and unified test runners defined in DRIVERS-1677 Implement log messages and corresponding tests for each component
    • Needed

      This ticket was split from DRIVERS-1204, please see that ticket for a detailed description.

            Assignee:
            warren.james@mongodb.com Warren James
            Reporter:
            dbeng-pm-bot PM Bot
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              1 year, 47 weeks, 4 days