Alertmanager Match vs Match_re - prometheus-alertmanager

match:
[ <labelname>: <labelvalue>, ... ]
# A set of regex-matchers an alert has to fulfill to match the node.
match_re:
[ <labelname>: <regex>, ... ]
My question is what is the difference between a match and a match_re statement?
I have used both of the within prometheus and the effect they have is the same.
Any help is very much appreciated!!

With "match_re" you can use regular expression like in the following examples:
service: "mysql|postgre"
system: ".*_(foo|boo)$"
recipient: "(.*,)?customer/sms(,.*)?"
alertname: "watchdog.*alert"

From the v0.22.2 both match and match_re are deprecated in favor of matchers. A nice new feature is the possibility to define negative matchers.
# DEPRECATED: Use matchers below.
# A set of equality matchers an alert has to fulfill to match the node.
match:
[ <labelname>: <labelvalue>, ... ]
# DEPRECATED: Use matchers below.
# A set of regex-matchers an alert has to fulfill to match the node.
match_re:
[ <labelname>: <regex>, ... ]
# A list of matchers that an alert has to fulfill to match the node.
matchers:
[ - <matcher> ... ]
Source

Use matchers instead of them:
routes:
- receiver: 'database-pager'
group_wait: 10s
matchers:
- service=~"mysql|cassandra"
- receiver: 'frontend-pager'
group_by: [product, environment]
matchers:
- team="frontend"
In newer versions match and match_re are deprecated in favor of matchers.

Related

eslint no-restricted-imports - prevent an import from from path ending with pattern

According to the eslint no-restricted-imports documentation
When using the object form, you can also specify an array of
gitignore-style patterns:
"no-restricted-imports": ["error", {
"paths": ["import1", "import2"],
"patterns": ["import1/private/*", "import2/*", "!import2/good"] }]
(Emphasis mine)
What I'm trying to do is restrict imports from parent index files - as this is causing issues with cyclical dependencies (I am also using the import/no-cycle rule, but it makes sense to also explicitly use this rule.)
That is, I want to ban imports like:
import foo from "../..";
import bar from "../../..";
I also want to ban imports like:
import a from "../Components";
but not like
import b from "../Components/Foo";
I have tried using this rule:
'no-restricted-imports': [
'error',
{
patterns: [
'**/..',
'**/Components'
]
},
But this causes on errors on imports of:
import b from "../Components/Foo";
Is there a way to specify 'end of string' in a gitignore style pattern?
First, make sure you don't have set import/no-relative-parent-imports, or any ../ import would fail.
Second, if this really follows .gitignore rules, you cannot have rules for folders (like **/.. or **/Components).
Because, once you ignore a folder, any other rule for elements inside that folder would be ignored.
Try:
'no-restricted-imports': [
'error',
{
patterns: [
'**/../*',
'!**/../Components',
'**/../Components/*',
'!**/../Components/Foo',
]
},

GROK pattern for optional field

I have a log string like :
2018-08-02 12:02:25.904 [http-nio-8080-exec-1] WARN o.s.w.s.m.s.DefaultHandlerExceptionResolver.handleTypeMismatch - Failed to bind request element
In the above string [http-nio-8080-exec-1] is a optional field, it can be there in some log statements.
i created a grok patterns like with some references on net :
%{TIMESTAMP_ISO8601:timestamp} (\[%{DATA:thread}\])? %{LOGLEVEL:level}%{SPACE}%{JAVACLASS:class}\.%{DATA:method} - %{GREEDYDATA:loggedString}
seems its not working if i remove the thread name string.
you need to make the space character following the thread name optional: (\[%{DATA:thread}\] )?
input:
2018-08-02 12:02:25.904 WARN o.s.w.s.m.s.DefaultHandlerExceptionResolver.handleTypeMismatch - Failed to bind request element
pattern:
%{TIMESTAMP_ISO8601:timestamp} (\[%{DATA:thread}\] )?%{LOGLEVEL:level}%{SPACE}%{JAVACLASS:class}\.%{DATA:method} - %{GREEDYDATA:loggedString}
output:
{
"loggedString": "Failed to bind request element",
"method": "handleTypeMismatch",
"level": "WARN",
"class": "o.s.w.s.m.s.DefaultHandlerExceptionResolver",
"timestamp": "2018-08-02 12:02:25.904"
}

jsonix properties - ogc-schemas .js aren't same

The manual on jsonix properties at https://github.com/highsource/jsonix/wiki/Properties shows properties as being something like:
name: 'MyModule',
typeInfos: [{
type: 'classInfo',
localName: 'InputType',
propertyInfos: [{
type: 'attribute',
typeInfo: 'Boolean',
name: 'checked'
}]
}],
But then (after npm install ogc-schemas) what I am seeing is:
ln: 'TimeClockPropertyType',
ps: [{
n: 'timeClock',
rq: true,
en: 'TimeClock',
ti: '.TimeClockType'
},
With the abbreviated names.
Which should it be and why doesn't it matter if it doesn't?
Disclaimer: I'm the author of jsonix.
This is what's called compact naming. This is an option of the Jsonix Schema Compiler which generates shorter names in mappings, like n instead of name or dens instead of defaultElementNamespaceURI. The goal is clearly to make mappings smaller and since ogc-schemas are pretty large, they are compiled with compact naming by default.
If you want standard naming, fork and remove
<arg>-Xjsonix-compact</arg>
from all the pom.xmls.
Both compact and standard names work in runtime, I think standard names have higher priority.

Elastic search error operation [search] and lang [groovy] is disabled?

I am using elastic search 1.7.1 and when i am trying to use script_score or script_fields it is showing the error ScriptException[scripts of type inline], operation [search] and lang [groovy] is disabled can anyone please tell me how can i remove this error. my code is given below
function_score: {
query: {
query_string: {
query: shop_search,
fields: [ 'shop_name']
}
},
functions: [
{
script_score: {
script: "_score * doc['location'].value"
}
}
]
}
Add script.engine.groovy.inline.search: on to elasticsearch.yml configuration file and restart the node.
adding script.groovy.sandbox.enabled: true to .yml works for me
For ES Version 2.x+
script.inline: on
script.indexed: on
Add
script.engine.groovy.inline.aggs: on
script.engine.groovy.inline.update: on
to elasticsearch.yml
and restart
For those with ES 2.x+
script.inline: true
script.indexed: true
Make sure you prefix the lines with a space!

Grokparsefailure in groking logs

I am facing grokparsefailure issue with my logs, when I try match them from http://grokdebug.herokuapp.com/ they are working fine.
Sample log:
08/13/2015 07:08:11 AM - WARNING - MainProcess - 31186 - agentmgr.views.session - save_session - Agent client got connected 98aa75fe-0ea3-11e5-9329-02add7aa4bff
Grok Pattern:
if [category] == 'celery-logs' {
grok {
patterns_dir => "/opt/logstash-1.4.2/patterns"
match => [ "messagee", "%{CELERY}" ]
}
}
I have created custom celery log in patterns folder with name celery below is the pattern
DATESTAMP_12HOUR %{DATESTAMP} (AM|PM)
CELERY %{DATESTAMP_12HOUR} - %{GREEDYDATA}
On log stash Page I am getting the logs like below
{"message":" 08/13/2015 07:08:11 AM - WARNING - MainProcess - 31186 - agentmgr.views.session - save_session - Agent client got connected 98aa75fe-0ea3-11e5-9329-02add7aa4bff","category":"celery-logs","#version":"1","#timestamp":"2015-08-13T07:10:33.330Z","tags":["_grokparsefailure"]}
Please help me identify the problem.
This is a typo on your part -- your match statement has "messagee" when it should have "message".

Resources