I can see jvm, process, java etc metrics on a /metrics endpoint when using the jmx_exporter but not the custom metrics I have exposed through JMX.
When I remove the agent and add a jolokia agent, I can see those custom metrics without problem on Jolokia's exposed endpoint in JSON format. That proves it exists.
jmx exporter agent config
rules:
- pattern: ".*"
I have scoured through stackoverflow and google groups. Many people have raised similar issues but I can't see a solution.
Any help on why this is not working as expected.
You need to add a whitelist entry with a pattern for the object names of your custom JMX Beans.
Example: Assume domain foo, then adding the following to your JMXExporter configuration YAML at top level
whitelist: ["foo:*"]
will print all the metrics for the beans in the foo domain.
Sidenote: I found it kind of tricky to work with pattern entries in the rule set, so I'm gonna add my findings in case you run in this follow up problem.
So, the pattern string for the pattern entries in the rules section must apply to a specific normalized representation for bean metrics (see documentation):
domain<beanpropertyName1=beanPropertyValue1, beanpropertyName2=beanPropertyValue2, ...><key1, key2, ...>attrName: value
If you provide a pattern entry in a rule item, this is used in JMXCollector.java (line 174-175) to create a regex pattern as follows
if (yamlRule.containsKey("pattern")) {
rule.pattern = Pattern.compile("^.*(?:" + (String)yamlRule.get("pattern") + ").*$");
}
JMXCollector uses this to check if your rule set applies to a given bean (or otherwise apply the default exposition formatter).
JMXExporter will aid you a little in constructing a pattern matcher by providing the normalized format in the HELP ... line if you let it use the default formatter (by not adding an entry to the rules section). If you do a run with no rules, you can copy the normalized bean metric representation and use this to define a matching pattern.
I followed this tutorial and i was able to
https://reachmnadeem.wordpress.com/2020/12/06/monitoring-jmx-enabled-java-applications-with-prometheus/
i used this config just as a starting point for the jmx export to show its information on its metrics page.
---
jmxUrl: service:jmx:rmi:///jndi/rmi://127.0.0.1:5555/jmxrmi
startDelaySeconds: 0
ssl: false
rules:
- pattern: 'com.company.monitoring:*'
name: consumer
value: 3
valueFactor: 0.001
labels: {}
help: "Cassandra metric"
cache: false
type: GAUGE
attrNameSnakeCase: false
Related
I am working on a rego policy that has multiple conditions. Each condition needs to make a call to the same endpoint of a REST api.
I have managed to retain the result of the service call as a result of another rule.
The result of the Evaluate Package command (VS Code with OPA extension) on the policy looks like this now:
[ [
{
"allow": false,
"someProp": [
"N/A"
]
} ] ]
Will this affect the correctness of the policy once it gets deployed to the server?
EDIT
Until my changes, the policy only returned allow.
The "evaluate package" feature of the VS Code plugin does pretty much just that :) i.e. it evaluates the whole package including all rules. You'll see the same default behavior in the Rego Playground, since it's a pretty good way of learning what's going on to see what all rules evaluate to.
When running OPA as a server (or by all means, opa eval), you'll commonly query only the specific rule you're interested in, so if in your case you had defined your policy in a package called mypolicy a request to the OPA REST API might be sent to the /v1/data/mypolicy/allow endpoint to evaluate only the allow rule rathe than the whole package (which could be queried at /v1/data/mypolicy.
I am writing a custom rule that takes inputs from cc_library, cc_binary, apple_static_library, and a few other platform-specific rules. I'd like to view each API given to me via referencing ctx.attr.foo inside the custom rule's implementation function.
There is a list of providers here https://docs.bazel.build/versions/master/skylark/lib/skylark-provider.html but it doesn't say which rules are using them.
Is there a best practice for viewing what these rules are providing me, or does it require going through the source for each one?
This is how you get all providers and output groups from a target:
bazel cquery my_target --output=starlark --starlark:expr="providers(target)"
You can get a list of providers for a given target with dir. Something like this is helpful for debugging:
def _print_attrs_impl(ctx):
for target in ctx.attr.targets:
print('%s: %s' % (target.label, dir(target)))
Printing from inside a rule you're developing is often helpful too, to verify targets are actually what you expect them to be.
You can also apply dir to the providers themselves, to see what fields they have.
I am looking for a complete list of properties supported by log4j2. The log4j2 documentation at following link gives only a subset of properties.
https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
For ex:
Delete files older than 30 days
appender.rolling.strategy.delete.ifLastModified.age = 30d
This is not listed in the manual. Any suggestions where I can find the list?
A full list of all log4j2 properties does not exist because configuration with properties is only one option among many (XML, JSON, YAML etc.).
Each log4j2 part is described with a list of configurable parameters it supports (e.g. https://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender). The URI you are linking describes the rules which property names you have to choose to configure the parameters.
So the way you have to go is:
Select which function you have to use (e.g. RollingFileAppender)
Read the chapter of this function and select the parameters you want to configure
Use your linked URI to create you property based configuration with the property names for the parameters you want to configure
This question mentions two types of performance stats:
carbon.*: Stats from graphite itself.
stats.* : Stats from statsd.
I am seeing 1., but I'm not seeing 2.
Is there a statsd configuration setting (e.g. some entry in the js file) which will let me see 2.?
(2) should be generated by default, but the default prefix is statsd. and not stats. as you've said. Maybe check that you don't have any Graphite rules expecting the wrong prefix.
You can also configure the prefix to whatever you want using the prefixStats property in the .js config file.
See the documentation in the example config:
https://github.com/etsy/statsd/blob/master/exampleConfig.js
I am trying to use codeNarc on a grails project, after installing it and running it I've have some rulesets violations messages that I would like to understand and resolve. The first on concern "GrailsStatelessService" and the second the "equals() and toString()" methods...
For the first one "GrailsStatelessService" the message I received is:
***************************
Violation in class app.TheServiceName. The class is marked as stateless but contains the non-final field 'aVariableName'
***************************
I've searched a little about that but not found a lot of tricks about that. Can someone please explain me what the real meaning of this ruleset and what I have to do to solve this problem/
About the second kind of ruleSet I found somewhere that it solved by overriding those methods in all the domain classes but is hat an obligation, a need, or do I just have to modify the ruleSet File to avoid those kinds of messages related to those rulesets?
And that introduces my last question: where to find this ruleSet File( the default one within codenarc) or the one i must include myself?
I find that the GrailsStatelessService rule does sometimes catch a real violation, so rather than disabling it, I modify it to ignore my commonly used field names.
BuildConfig.groovy:
codenarc.propertiesFile = 'grails-app/conf/codenarc.properties'
codenarc.properties:
GrailsStatelessService.addToIgnoreFieldNames=grailsApplication,applicationContext,sessionFactory
I am able to configure this CodeNarc rules as follows:
Install CodeNarc plugin [grails install-plugin codenarc]
Add following line in BuildConfig.groovy file [for details configuration]:
codenarc.propertiesFile = 'grails-app/conf/codenarc.properties'
In codenarc.properties - file, I add following rule for ignore few RULEs
codenarc.properties = {
GrailsDomainHasEquals.enabled = false
GrailsDomainHasToString.enabled = false
EmptyMethod.enabled = false
}
Run following command for generating CodeNarc Report: grails codenarc
Sometimes condenarc mix things ups. Adding Service at the end of the name of the service remove this "issue" if you are not using a class as stateless but codenarc believes so. I had this problem with this Service:
private CurrencyConverterFactory currencyConverterFactory
And I fixed with:
private CurrencyConverterFactory currencyConverterFactoryService
I hope this helps someone.
The documentation does a good job of explaining that rule:
Checks for non-final fields on a Grails service class. Grails service
classes are singletons by default, and so they should be reentrant. In
most cases, this implies (or at least encourages) that they should be
stateless.
This rule ignores final fields (either instance or static). Fields
that are static and non-final, however, do cause a violation.
If you are using the Grails CodeNarc plugin, then see the plugin documentation for a list of the CodeNarc rulesets that are included by default. There is also a section on "Configuring The CodeNarc RuleSet File(s)" -- so by all means create your own custom ruleset.
http://www.grails.org/plugin/codenarc/
It is expected that you customize the set of rules appropriate for your team/project. Other than the "basic" rulset, the other provided rulesets all contain rules that may or may not be appropriate for you.
The GrailsDomainHasToString and GrailsDomainHasEquals rules are perfect examples -- many organizations disable those rules.
See the CodeNarc documentation for more information on turning off a rule:
http://codenarc.sourceforge.net/codenarc-configuring-rules.html