I had couple of collectd conf files each loading the GenericJmx plugin and found the following in the logs. Although, the metrics were pulled from both jmx connections.
Dec 21 10:49:17 poc-vm collectd[27737]: java plugin: All `JVMArg' options MUST appear before all `LoadPlugin' options! The JVM is already started and I have to ignore this argument: -Djava.class.path=/opt/stackdriver/collectd/share/collectd/java/collectd-api.jar:/opt/stackdriver/collectd/share/collectd/java/generic-jmx.jar
Dec 21 10:49:17 poc-vm collectd[27737]: The read function "GenericJMX" is already registered. Check for duplicates in your configuration!
I could guess this is because of the following being present in both .conf files.
LoadPlugin java
LoadPlugin match_regex
LoadPlugin target_set
LoadPlugin target_replace
<Plugin "java">
JVMARG "-Djava.class.path=/opt/stackdriver/collectd/share/collectd/java/collectd-api.jar:/opt/stackdriver/collectd/share/collectd/java/generic-jmx.jar"
LoadPlugin "org.collectd.java.GenericJMX"
<Plugin "GenericJMX">
<MBean "SomeMbean">
.....
But is this a guaranteed behavior? Can we have multiple conf files using GenericJMX plugin?
Yes, those logs are just harmless warnings. Collectd loads each plugin when it first encounters the LoadPlugin directive. Since that directive may have options, it also warns when it encounters multiple ones - so you know it will only use the options from the first one it sees.
The GenericJmx plugin is loaded via the java binding. so in this case you're also being warned that the options for the second attempt to load the java binding will be ignored.
To avoid these warnings :
Move the LoadPlugin into a separate file in the path.
vm:~$ cat /opt/stackdriver/collectd/etc/collectd.d/00_load_generic_jmx.conf
LoadPlugin java
<Plugin "java">
JVMARG "-Djava.class.path=/opt/stackdriver/collectd/share/collectd/java/collectd-api.jar:/opt/stackdriver/collectd/share/collectd/java/generic-jmx.jar"
LoadPlugin "org.collectd.java.GenericJMX"
</Plugin>
Note :
Here the "path" is /opt/stackdriver/collectd/etc/collect.d/
Refer the bottom of the file : /etc/stackdriver/collectd.conf
# if you have other config, especially for plugins, you can drop them
# into this directory
Include "/opt/stackdriver/collectd/etc/collectd.d"
Include "/etc/stackdriver/collectd.d"
Note the file name is prefixed with "00" to ensure it comes first in lexicographical order and therefore picked ahead of other .conf files in that path.
From https://collectd.org/documentation/manpages/collectd.conf.5.shtml#global_options :
If more than one file is included by a single Include option, the files will be included in lexicographical order (as defined by the strcmp function). Thus, you can e. g. use numbered prefixes to specify the order in which the files are loaded.
Related
Gcloudignore works like gitignore in that you can exclude certain files from uploading to GCF. Sometimes when you have really large projects with lots of generated files, it can be useful to exclude all files except a few.
.gcloudignore
# Ignore everything
# Or /*
*
# Except the Cloud Function files we want to deploy
!/package.json
!/index.js
The following gcloudignore file gives us: File index.js or function.js that is expected to define function doesn't exist in the root directory. meaning index.js is ignored and can not be read.
However the following ignore file syntax works just fine to deploy:
# Ignore everything
/[!.]*
/.?*
# Except the Cloud Function files we want to deploy
!/package.json
!/index.js
I tried peering into the gcloud program code, but I was wondering if anyone knows why this is the case?
I ran into this problem as well.
I found a workaround -- explicitly allow the current dir:
# Ignore everything by default
*
# Allow files explicitly
!foo.bar
!*.baz
# Explicitly allow current dir. `gcloud deploy` fails without it.
!.
Works for me. Don't know why.
OperationError: code=13, message=Error setting up the execution environment for your function. Please try deploying again after a few minutes.
I just got this problem in recent. The error code 13 means, in my view point, the code/function failed to initialize (with in time).
In my case, the problem is mostly caused by either Provided module can't be loaded. (Dependencies failed) or Provided code is not a loadable module. (Main module is missing) after checking Stackdriver Logs, which point to the deploy isn't complete.
Below is how I got it to work:
# Ignore everything by default
/*
# Allow files explicitly
!config.js
!index.js
# Tried !app/ but does not work
!app/**
# Explicitly allow current folder, as Arne Jørgensen said.
!.
Be care the !app/ isn't enough. I have to use !app/** to including all files.
If it's your case, check the source tab from function console to see which files uploaded in actual.
We have a need to set some directives in the snappy config files for the various components (servers, locators, etc).
The snappy_ec2 scripts do a good job at creating all of the config's and keeping them in sync across the cluster, but I need to find a serviceable method to add directives to the auto generated scripts.
What is the preferred method using this script?
Example: Add the following to the 'servers' file:
-gemfirexd.disable-getall-local-index=true
Or perhaps I should add these strings to an environments file such as
snappy-env.sh
TIA
-doug
Have you tried adding the directives directly in the servers (or locators or leads) file and placing this file under (SNAPPY_DIR)/ec2/deploy/home/ec2-user/snappydata/? The script would read the conf files under this dir at the time of launching the cluster.
You'll need to specify it for each server you want to launch, with the name of server as shown below. See 'Specifying properties' section in README, if you have not already done so. e.g.
{{SERVER_0}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
{{SERVER_1}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
If you want it to be applied for all the servers, simply put it in snappy-env.sh as you mentioned (as SERVER_STARTUP_OPTIONS) and place the file under directory mentioned above.
We could have read the conf files directly from (SNAPPY_DIR)/conf/ instead of making users copy it to above location, but we may release the ec2 scripts as a separate package, in future, so that the users do not have to download the entire distribution.
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
We are upgrading to solr 4.4 and would like to be able to use the new core.properties for the new core discovery.
Currently, we have a couple of properties defined in the solr.xml for most of the cores, and I am not able to create these same properties in the new core.properties file.
Here is a core as currently defined in solr.xml:
<core name="core1003" instanceDir="core1003">
<property name="xmlDataDir" value="D:\Solrfiles\ImportFiles\core1003.xml" />
</core>
This is then used in DIH-XPathEntityProcessor.xml with <str name="xmlDataDir">${xmlDataDir}</str>.
How can I define core specific property variables like this? It doesn't necessarily have to be in core.properties, but that would make it a little easier to manage.
In your core instance directories that contain your core.properties file create a conf/ subdirectory and a solrcore.properties file in it. Define your core specific properties there and it will be picked up automatically.
Alternatively, you can add a value for "properties" to your core.properties file to point to any other file:
properties=/your/path/here.properties
I believe but have not confirmed that for this to work your cores must load on startup and must not be transient. Any non-standard properties you add to core.properties will be ignored because the CoreDescriptor copy constructor only persists the following properties from that file in memory: instanceDir, config, schema, name and dataDir (see CoreDescriptor:91 in the 4.4.0 source). I believe this is a bug?
I'm using the Maven Appassembler plugin to package my application. I'd like to package some configuration files with the application. I've found the configurationDirectory and includeConfigurationDirectoryInClasspath parameters, but I haven't found how I should create (and populate) that configuration directory. I've tried putting the files in src/main/resources, but that just puts them in the jar file for my project.
What is the "proper" way to do this, using maven?
Unfortunately this is a limitation of the appassembler plugin in the current release version. Typically, the plugin is used in conjunction with the assembly plugin to produce the final artifact, in which you can include the reference to your configuration directory. However, if you'd like to have a functional structure from just the appassembler plugin you need to manually copy the files into place. An example using the antrun plugin with a src/main/conf directory can be found here: http://svn.apache.org/viewvc/archiva/trunk/archiva-jetty/
By default, the plugin uses the directory src/main/config.
Is possible to change the source for the config files using the parameter <configurationSourceDirectory>src/main/config</configurationSourceDirectory>
When I include the copyConfigurationDirectory property, it copies the config files and bundles them properly.
<configurationDirectory>etc</configurationDirectory>
<configurationSourceDirectory>src/main/config</configurationSourceDirectory>
<copyConfigurationDirectory>true</copyConfigurationDirectory>
I have a different problem though. I would like to filter my config files before copying, which is giving me some trouble.
Apart from that is does not generate the bin scripts for different platforms. The maven-assembly-plugin can create (package(s) {tar.gz, zip}) for distribution. These are configured through a assemble.xml. You specify which files go in (with what options (chmod)), etc. It can also filter files (search/replace values within them). etc.
Years later and in version 1.10 of the plugin there is now a preAssembleDirectory configuration option. Unfortunately I don't find it flexible enough for my needs because it copies directly into assembleDirectory and does not allow to specify a target directory path within assembleDirectory.