Structured logging support?

[dmolesUC]

Currently the Railtie logs the secret attributes hash as a string. In our Rails apps that use berkeley_library-logging (hereafter "BLL") for structured logging (e.g. Framework, AV Player), this produces entries like:

{
    "name": "rails",
    "hostname": "366d197f7830",
    "pid": 1,
    "level": 30,
    "time": "2023-02-21T20:11:39.304+00:00",
    "v": 0,
    "severity": "INFO",
    "msg": "Loaded secret: {:name=>\"SECRET_KEY_BASE\", :file=>\"/run/secrets/SECRET_KEY_BASE\", :checksum=>\"sha256:d3f815ab803f75509a866fd433bbce6a09add946e266e1534f0e87fe2b0a8f0b\", :glob=>\"/run/secrets/*\", :timestamp=>1677010299}"
}

There's no good way to fix this with a vanilla Ruby or Rails Logger, but Ougai (which BLL is built on) supports passing optional exception and data arguments along with the message (and is smart enough to tell when the exception argument is omitted), so we can say

logger.info('Build', data: build_info)

and get nice structured messages like:

{
    "name": "rails",
    "hostname": "366d197f7830",
    "pid": 1,
    "level": 30,
    "time": "2023-02-21T20:11:39.633+00:00",
    "v": 0,
    "severity": "INFO",
    "msg": "Build",
    "data": {
        "BUILD_TIMESTAMP": "2023-02-21T20:04:37+00:00",
        "BUILD_URL": "https://github.com/BerkeleyLibrary/avplayer/actions/runs/4236417212",
        "DOCKER_TAG": "ghcr.io/berkeleylibrary/avplayer:3463f0a",
        "GIT_BRANCH": "main",
        "GIT_COMMIT": "3463f0aee17d7700ea58e602d5d949cbd4f33c6e",
        "GIT_URL": "git://github.com/BerkeleyLibrary/avplayer.git"
    }
}

Off the top of my head, I have a couple of ideas as to how to approach this:

1. Add BLL as a dependency and use BL::Logging.logger (which in a Rails app that pulls in the BLL railtie will also be the Rails logger, allowing us to replace this code -- which could be as simple as including BL::Logging in BL::Docker::Logging)
2. Do something like defined?(Ougai::Logger) && logger.instance_of?(Ougai::Logger) to check whether we are, and if not, fall back to the inspect- based approach
3. Try to do something clever involving reflection to figure out whether the logger's info method accepts more than one parameter
4. Just assume we're using BLL or another Ougai-based log framework

Of these, I prefer (1) (but then, I would say that, wouldn't I?).

Without the explicit BLL dependency, (2) feels a little arbitrary — there are other Ruby structured logging frameworks out there, like Logcraft -- which also accepts additional data, but doesn't use the same syntax -- so what's special about Ougai? Plus we're depending on the syntax/semantics of a certain version of a dependency without making that dependency explicit anywhere, which feels risky. (The same would go for checking for BLL without actually depending on it.)

I'm not enamored of (3) since reflection can't tell us anything about the semantics of the method; it feels like just trying to do (2) without admitting it.

(4) would work with our apps, but feels risky: again, we're depending on the semantics of an undeclared dependency — which in this case wouldn't even be obvious when looking at the code — which if it fails will fail in a non-obvious way.