grafana - divide series with wildcards - grafana

I'm trying to build a list of percentages in grafana, but am having trouble getting divideSeries+wildcards to work right.
I found Grafana dividing 2 series which seemed like what I wanted, but unfortunately there's no mapSeries function in my grafana instance (version 4.6.0-1).
This is what I've got, but instead of specifying the ID "1234", I want to use a wildcard, and have each ID grouped together.
divideSeries(stats.dhcp.pools.1234.cur,stats.dhcp.pools.1234.max)
Logically, I tried: divideSeries(stats.dhcp.pools.*.cur,stats.dhcp.pools.*.max) -- but that does not work. I tried mucking around with asPercent, but it has the same limits as divideSeries does.
I think applyByNode is what I want, but I can't seem to translate the example into something that actually works.

You use graphite as datasource (I think). Functions you mentioned are implemented in graphite-web, you can find docs also for applyByNode
applyByNode(
stats.dhcp.pools.*.*,
3,
'divideSeries(%.cur, %.max)',
'% pct'
)
Note that as of November 2017, applyByNode is not in the default graphite-api install, and requires installation from the github source:
pip install git+git://github.com/brutasse/graphite-api.git
As a side note - you can use any of graphite function, even mapSeries.

Related

Simple `to_tsvector` configuration - postgres

How can I change the to_tsvector configuration to use a simple tokenization rule like:
lowercase
split by spaces only
Executing the following query:
SELECT to_tsvector('english', 'birthday=19770531 Name=John-Oliver Age=44 Code=AAA-345')
I get these lexemes:
'-345':9 '19770531':2 '44':6 'aaa':8 'age':5 'birthday':1 'code':7 'john':4 'name':3
The kind of searching I'm looking for is like:
(!birthday | birthday=19770531) & (code=AAA-345)
It means, get me all records that has a text "birthday=19770531" or doesn't have "birthday" at all, and a text equals to "code=AAA-345"). The way lexemes are being created it is not possible. I was expecting to have something like this:
'birthday=19770531':1 'age=44':2 'code=aaa-345':4 'name=john-oliver':3
You would have to code a custom parser. This can only be done in C.
But you might be able to use the existing testing parser test_parser, it seems to do what you want. If not, it would at least be a good starting point.
The problem may be that this is in src/test/modules/, and I don't think it ships with most installation packaging. So it might take some effort to get it to install. It would depend on your OS, version, and package manager.

Grafana: Overrriding series with metric named `/var(avail_MB)`: "Panel rendering error '/var(avail_MB)' is not a valid regular expression."

An Icinga2 plugin (written by myself) returns performance data with metrics named /var(avail_MB), /var(total_MB) and similar. Data is forwarded to an InfluxDB with Grafana as Frontend.
I'm using "GROUP BY" "tag(metric)" and "ALIAS BY" "$tag_metric" in a dashboard's panel query.
The metric names are displayed correctly below the graph then.
However when I try to override series by specifying "alias or regex" /var(avail_MB) it does not seem to work, and when going back from panel configuration to dashboard, I get an error message saying "Panel rendering error '/var(avail_MB)' is not a valid regular expression.".
I tried to put a backslash in front of ( and ), but that didn't help.
To make matters worse, the whole graph disappeared, and when trying to open the "Query Inspector", the frontend seems to take forever (Query never appears).
What is the problem, and how could I fix it?
I'm new to Icinga2, Grafana and InfluxDB (I'm just a "user" not administrator of those).
The color change is not applied to the graph.
Here is an example of plugin output:
OK: /var: 3114/5632MB (55.30%), slope is NaN|/var(total_MB)=5631.56MB;;;0 /var(avail_pct)=55.30%;25;5;0;100 /var(avail_MB)=3114.12MB;10;5;0;5632 /var(est_avail_MB)=nanMB;10;5;0;5632
(The "nanMB" was a bug in the plugin that has been fixed already, but that data wasn't from the machine in question.)
The problems seems to be the beginning of the string ("/var").
Grafana seems to treat every string starting with / as regular expression, and it expects any regular expression to start with /, too (it seems).
So the fix was to add a trailing /, and escape the literal / as \/.
Unfortunately this only removes the error message, but doesn't make the override work (match).
It is also required to backslash-escape the parentheses and the slash(es):
Instead of /var(total_MB) you need to write /\/var\(total_MB\).
The original problem has two origins:
The monitoring plugin specification at https://www.monitoring-plugins.org/doc/guidelines.html#AEN201 states: "2. label can contain any characters except the equals sign or single quote (')") states that any character except = and ' is allowed as metric name.
Grafana v6.7.3 proposes the incorrect (i.e.: unescaped) values for "alias or regex".
That is how I had created the problem.

Movesense, setting the system time

I am trying to set the system time in Movesense. I couldn't find an example of that, but based on the documentation I think that this should do:
asyncPut(WB_RES::LOCAL::TIME(),
AsyncRequestOptions::Empty,
(int64_t)0);
In this case, I'm just trying to reset the epoch to zero but onPutResults gives me
HTTP_CODE_BAD_REQUEST
So what is the right way?
Minimum timestamp seems to be 1483228800000000 us which corresponds to 1.1.2017. So you can't set the time to 70's as zero would set it to.
This should be documented in the yaml api but currently is not. We will add that to the list of tasks to make sure it's documented in the next release of device-lib.

Apply Command to String-type custom fields with YouTrack Rest API

and thanks for looking!
I have an instance of YouTrack with several custom fields, some of which are String-type. I'm implementing a module to create a new issue via the YouTrack REST API's PUT request, and then updating its fields with user-submitted values by applying commands. This works great---most of the time.
I know that I can apply multiple commands to an issue at the same time by concatenating them into the query string, like so:
Type Bug Priority Critical add Fix versions 5.1 tag regression
will result in
Type: Bug
Priority: Critical
Fix versions: 5.1
in their respective fields (as well as adding the regression tag). But, if I try to do the same thing with multiple String-type custom fields, then:
Foo something Example Something else Bar P0001
results in
Foo: something Example Something else Bar P0001
Example:
Bar:
The command only applies to the first field, and the rest of the query string is treated like its String value. I can apply the command individually for each field, but is there an easier way to combine these requests?
Thanks again!
This is an expected result because all string after foo is considered a value of this field, and spaces are also valid symbols for string custom fields.
If you try to apply this command via command window in the UI, you will actually see the same result.
Such a good question.
I encountered the same issue and have spent an unhealthy amount of time in frustration.
Using the command window from the YouTrack UI I noticed it leaves trailing quotations and I was unable to find anything in the documentation which discussed finalizing or identifying the end of a string value. I was also unable to find any mention of setting string field values in the command reference, grammer documentation or examples.
For my solution I am using Python with the requests and urllib modules. - Though I expect you could turn the solution to any language.
The rest API will accept explicit strings in the POST
import requests
import urllib
from collections import OrderedDict
URL = 'http://youtrack.your.address:8000/rest/issue/{issue}/execute?'.format(issue='TEST-1234')
params = OrderedDict({
'State': 'New',
'Priority': 'Critical',
'String Field': '"Message to submit"',
'Other Details': '"Fold the toilet paper to a point when you are finished."'
})
str_cmd = ' '.join(' '.join([k, v]) for k, v in params.items())
command_url = URL + urllib.urlencode({'command':str_cmd})
result = requests.post(command_url)
# The command result:
# http://youtrack.your.address:8000/rest/issue/TEST-1234/execute?command=Priority+Critical+State+New+String+Field+%22Message+to+submit%22+Other+Details+%22Fold+the+toilet+paper+to+a+point+when+you+are+finished.%22
I'm sad to see this one go unanswered for so long. - Hope this helps!
edit:
After continuing my work, I have concluded that sending all the field
updates as a single POST is marginally better for the YouTrack
server, but requires more effort than it's worth to:
1) know all fields in the Issues which are string values
2) pre-process all the string values into string literals
3) If you were to send all your field updates as a single request and just one of them was missing, failed to set, or was an unexpected value, then the entire request will fail and you potentially lose all the other information.
I wish the YouTrack documentation had some mention or discussion of
these considerations.

BIRT Chart API setting caption to string with equal sign in it truncates value on left

I'm attempting to use the Chart API directly and am running into a problem with an expression.
If I attempt to do the following
chart.getTitle().getLabel().getCaption().setValue("Day of Week (M=1)");
The resulting label is:
1)
If I remove the '=' from the value it works fine no problems but that '=' appears to be triggering an expression evaluation.
Note this is using the Chart Engine API, and this chart is NOT associated with a BIRT Report.
Anyone have any suggestions?
EDIT It looks like while generating the chart, it attempts to resolve the chart title as a key for an externalized message. RunTimeContext.externalizeMessage(...) because of the fact that my title contains an '=' sign. Is there a way to escape this to prevent it from attempting to render it as this?
I took a deeper look into this and was able to fake it out by implementing an externalizer and just keying it to concatenate the key & default values together with the '=' token constant.
as this is for demo purposes it worked ... granted not the most optimal solution but it got what I needed.