/bin/node -r /opt/otel/node/otel-agent.js /opt/service/dist/main.js
This is how I am running my application currently.
The problem is, sometimes otel-agent.js might not exist and I want to be able to define a 'Node' agent similar to how you can define various runtime arguments via the env variable
JAVA_TOOL_OPTIONS=javaagent:/opt/otel/java/aws-opentelemetry-agent.jar.
Does such a thing exist for Node?
There is no agent for javascript in OpenTelemetry.
As an alternative, you can use auto instrumentation modules, I would start by looking at the docs for that: https://opentelemetry.io/docs/instrumentation/js/getting-started/nodejs/#instrumentation-modules
NODE_OPTIONS=--require /opt/otel/otel-agent.js
Related
I'm running a node app inside a container. A number of flags and options are passed to node when it is running and I want to figure out which options made it finally to the script.
I have found the documentation on setting these flags but I can't find anything to get them. I can query the environment variables, but what if I have made a typo and it didn't set anything?
So how can I output somehow the flags an actual node instance is running with?
What non-direct methods I have tried so far
outputting environment variables with console.dir(process.env): the problem it does not show flags passed from command line
Trying to pass a wrong flag: for example passing this NODE_OPTIONS=--max-hold-spice-size=123 will make node to fail, so at least you know that you can pass flags to node
You can access every environment variable visible to node instance using:
console.log(process.env)
I need to use a variable between node modules folder and src folder.Is there a way to use a variable to be used within the whole project?
Thanks.
Typically this is done with process environment variables. Any project can look for a common environment variable and handle that case accordingly, as well as the node modules of said project. As long as they agree on the name, they all share the same environment. Have a good default, don't force people to set this environment variable.
The environment can be set using an environment file (do not check this into source control!), on your container or cloud configuration, or even right on the command line itself.
TLOG=info npm test
That is an example that I use frequently. My project runs logging for the test cases only at alert level - there are a lot of tests so it makes the output less verbose. However, sometimes while developing I want to see all the logs, so my project is looking for an environment variable TLOG (short for "test logging") and I can set it just for that run! Also no code change is needed, which is nicer than JavaScript variables that need to be set back to original values, forget to be turned off, etc.
I read and verified that I can pass environment variables to node by doing something like:
MY_ENV_VAR1=/tmp MY_ENV_VAR2=/data node index.js
How on earth does that work? I've only seen arguments to a script come after the script name, not before.
Thanks!
That is the standard way of defining and passing on the environment variables to a particular command from a Linux shell w/o exporting it.
More details: https://unix.stackexchange.com/questions/158117/how-to-pass-environment-variables-to-a-non-interactive-shell-with-example
Which spring-????-config.xml I should use to star GG nodes so the .net example GridClientApiExample works?
Each GridGain example provides a short description of how to run remote nodes in the example documentation.
Usually there are two ways to run remote nodes for the example. The first and, probably, the most convenient one is to run corresponding *NodeStartup class from IDE in the examples project. The name of startup class is specified in example documentation. The second way is to start a node with ggstart.{sh|bat} script with a configuration file specified in the documentation (if available).
GridClientApiExample works only with node started from IDE with ClientExampleNodeStartup, and there is a reason for it. The example expects a specific task class (org.gridgain.examples.misc.client.api.ClientExampleTask) to be in the node's classpath. Since this is an example-only class, it is not present in node classpath when running ggstart.{sh|bat}.
If for some reason you want to run a node with command line script for this example, you should build examples jar file and drop it to $GRIDGAIN_HOME/libs/ext (startup script will automatically pick up all additional libraries placed in this folder). Then you can use the same config which ClientExampleNodeStartup uses, namely examples/config/example-compute.xml
You can use ClientExampleNodeStartup or start node with ggstart.sh examples/config/example-compute.xml
What is the typical use-case for adding --prefix support to a scons build?
Currently I use Variables to persist user options from the command-line, but that requires I use the name PREFIX to be recognized as a variable. The docs show a way to specify the preifx using AddOption but then this option must be specified everytime scons is run: it isn't persisted like the variables.
What is the typical way to handle this?
You will need to use Add/GetOption to create an option the user can provide on the command line.
After, yous users will need to set the environment variable SCONSFLAGS with options they want to provide to SCons everytime. SCons will read this variable everytime.
http://www.scons.org/doc/2.0.1/HTML/scons-user/c2076.html
It's not a good idea to have many environment variable on the user machine because you lost the documentation and which variable you really need to compile.