Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: open telemetry #4664

Merged
merged 2 commits into from
Jun 28, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions cli/bin/garden
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
#!/usr/bin/env node


if (process.env.GARDEN_ENABLE_PROFILING === "1" || process.env.GARDEN_ENABLE_PROFILING === "true") {
// Patch require to profile module loading
const Mod = require("module")
Expand Down Expand Up @@ -34,6 +35,9 @@ if (process.env.GARDEN_ENABLE_PROFILING === "1" || process.env.GARDEN_ENABLE_PRO
}
}

const { initTracing } = require("@garden-io/core/build/src/util/tracing/tracing")
initTracing()

require("source-map-support").install()
const cli = require("../build/src/cli")

Expand Down
29 changes: 24 additions & 5 deletions cli/src/cli.ts
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,9 @@ import { shutdown } from "@garden-io/core/build/src/util/util"
import { GardenCli, RunOutput } from "@garden-io/core/build/src/cli/cli"
import { GardenPluginReference } from "@garden-io/core/build/src/plugin/plugin"
import { GlobalConfigStore } from "@garden-io/core/build/src/config-store/global"
import { getOtelSDK } from "@garden-io/core/build/src/util/tracing/tracing"
import { withContextFromEnv } from "@garden-io/core/build/src/util/tracing/propagation"
import { wrapActiveSpan } from "@garden-io/core/build/src/util/tracing/spans"

// These plugins are always registered
export const getBundledPlugins = (): GardenPluginReference[] => [
Expand All @@ -35,11 +38,19 @@ export async function runCli({
}

try {
if (!cli) {
cli = new GardenCli({ plugins: getBundledPlugins(), initLogger })
}
// Note: We slice off the binary/script name from argv.
result = await cli.run({ args, exitOnError })
// initialize the tracing to capture the full cli execution
result = await withContextFromEnv(() =>
wrapActiveSpan("garden", async (span) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a major thing, but stylistically I'd tend to prefer wrapping these functions in an object/namespace, e.g. tracing.withContextFromEnv and tracing.wrapActiveSpan. That's what I've been doing with the new plugin SDK for example, and it makes it a bit more obvious what these functions are about when reading code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case we'd have to import and re-export all the different functions from the different submodules since we have for example withContextFromEnv in one module and wrapActiveSpan in another.

I feel like then it would be preferable if we used an index.ts that groups all the things together so they lie under util/tracing directly. Then in there we have to group those all into an object since we can't really enforce the import * as tracing from "tracing" syntax we could use if we simply just re-export everything.

To me that seems to introduce different redundant ways of importing those modules which can't really be enforced, or discourage modularization in order to prevent that redundancy.

I'm not sure that's worth it. Maybe what would be better is to use clear naming everywhere so it's always obvious it's withTracingContextFromEnv or something like that.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One quite simple way of doing that is a good ol' underscore prefix on the "private" functions re-exported in one place. I do also tend to prefer a named object over import * from... though.

This is not crucial btw, just a thought for better readability and discoverability going forward.

if (!cli) {
cli = new GardenCli({ plugins: getBundledPlugins(), initLogger })
}

// Note: We slice off the binary/script name from argv.
const results = await cli!.run({ args: args || [], exitOnError })

return results
})
)
code = result.code
} catch (err) {
// eslint-disable-next-line no-console
Expand All @@ -50,6 +61,14 @@ export async function runCli({
const globalConfigStore = new GlobalConfigStore()
await globalConfigStore.delete("activeProcesses", String(cli.processRecord.pid))
}

try {
await Promise.race([getOtelSDK().shutdown(), new Promise((resolve) => setTimeout(resolve, 3000))])
} catch (err) {
// eslint-disable-next-line no-console
console.log(`Debug: OTEL shutdown failed with error ${err.toString()}`)
}

await shutdown(code)
}

Expand Down
7 changes: 7 additions & 0 deletions core/package.json
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,13 @@
"@codenamize/codenamize": "^1.1.1",
"@hapi/joi": "git+https://github.com/garden-io/joi.git#master",
"@kubernetes/client-node": "git+https://github.com/garden-io/javascript.git#master",
"@opentelemetry/api": "^1.4.1",
"@opentelemetry/sdk-trace-base": "^1.14.0",
"@opentelemetry/sdk-node": "^0.40.0",
"@opentelemetry/resources": "^1.14.0",
"@opentelemetry/semantic-conventions": "^1.14.0",
"@opentelemetry/instrumentation-http": "^0.40.0",
"@opentelemetry/exporter-trace-otlp-http": "^0.40.0",
"ajv": "^8.12.0",
"ajv-formats": "^2.1.1",
"analytics-node": "3.5.0",
Expand Down
Loading