I'm trying to set up Alertmanager to send to 2 different receivers based on the value of a label in the Prometheus rule. For example, if responsible_team label equals web, send to the web team receiver. If reponsible_team label equals database, send t o the database team receiver.
I've followed Alertmanager's documentation and they say you should set up multiple routes with a match then labelName and labelValue underneath it.
route:
group_by: ['alertname','entity']
group_wait: 30s
group_interval: 5m
repeat_interval: 15m
receiver: default
routes:
- match:
responsible_team: 'TestTeam'
receiver: test_email
The expected result would be that any firing alerts in Alertmanager that have the responsible_team label as TestTeam would send an email to the email address defined in my test_email receiver. However, when I apply these changes and restart the service, I get the following error:
level=error ts=2019-07-11T22:00:29.0405339Z caller=main.go:325 msg="Loading configuration file failed" file="C:\Program Files\AlertManager\alertmanager.yml" err="yaml: unmarshal errors:\n line 21: field routes not found in type config.plain"
I've tried to update the version to the latest and that doesn't seem to fix the issue.
I believe that routes needs to be indented to be "under" route for the yaml to be valid
You can use the visual editor here https://prometheus.io/webtools/alerting/routing-tree-editor/ to debug your config file as well
Related
I'm trying to use Apple's CoreDataCloudkitDemo app. I've only changed the app settings per their README document. On running the demo, I'm getting the error: "CloudKit integration requires does not support ordered relationships."
(The weird grammar in the title is included in the app)
The console log shows:
Fatal error: ###persistentContainer: Failed to load persistent stores:Error Domain=NSCocoaErrorDomain Code=134060 "A Core Data error occurred." UserInfo={NSLocalizedFailureReason=CloudKit integration requires does not support ordered relationships. The following relationships are marked ordered:
Post: attachments
There is the same error for the "Tags" entity.
I'm using Xcode 11.0 beta 4 (11M374r).
I've only changed the bundle identifier, and set my Team Id.
I removed the original entitlements file - no errors in resulting build.
I've not changed any code from the original.
Does anyone have a workaround, or preferably, a fix? Or did I do something wrong?
Thanks
Firstly, select CoreDataCloudKitDemo.xcdatamodeld -> Post -> RelationShips, select attachments relationship, on the Inspect panel, deselect Ordered, then do the same thing on the tags relationship.
Secondly, there will be some errors in the code now, because we unchecked the Ordered option, the property of attachments and tags in the generated NSManagedObject may changed from NSOrderedSet? to NSSet?. So we could change these error lines of code like below:
Origin:
guard let tag = post?.tags?.object(at: indexPath.row) as? Tag else { return cell }
Changed:
guard let tag = post?.tags?.allObjects[indexPath.row] as? Tag else { return cell }
Finally, you can run the code now. ;-)
Further more, on WWDC19 Session 202, the demo shows they set both attachments and tags relationships as Unordered, so I think there's something wrong in the given demo project.
In this doc supported fields are not listed and I cannot find them properly. With some trial and experiments I noticed the following:
This works nicely and finds some pods:
kubectl get pods --field-selector=spec.restartPolicy=Never
But this produces error:
kubectl get pods --field-selector=spec.serviceAccount=default
No resources found.
Error from server (BadRequest): Unable to find {"" "v1" "pods"} that match label selector "", field selector "spec.serviceAccount=default": field label not supported: spec.serviceAccount
So how is this decided? I know I can find with JSONPath but it is client-side filtering AFAIK.
You can select the serviceAccount using following query:
kubectl get pods --field-selector=spec.serviceAccountName="default"
The --field-selector currently selects only equality based values and in that too it has very limited support to select the pod based on fields. The following fields are supported by --field-selector:
metadata.name
metadata.namespace
spec.nodeName
spec.restartPolicy
spec.schedulerName
spec.serviceAccountName
status.phase
status.podIP
status.nominatedNodeName
As you already know, you need to rely on the jsonpath to select any other field other than above fields.
You can visit following link to find out more:
https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/v1/conversion.go#L160-L167]1
I am using wdio v4.12.0 and wdio-cucumber-framework which is using cucumber v1.3.3 One of tests is ignored and only information in cmd output is that ignore reason: pending. All previous and later steps are executed without error.
[field with default name is visible] Test ignored: field with default name is visible, ignore reason: pending
Feature file:
Scenario: User is able to add field
Given user is on fields page
When user creates new field with default name
Then field with default name is visible
What can be cause of skipping this step? What does pending means (is it just unresolved promise or what)?
I believe scenarios are marked as pending when Cucumber cannot find the underlying definition for one or more steps. In this case, it probably cannot find the step definition for "Then field with default name is visible" so check if you have implemented this definition.
Pending step means the step has not been implemented. If Cucumber cannot find your glue, it will suggest snippets with how to implement your steps.
In my E2E test, I'am using the mail-listener2 to retrieve e-mails. It works fine, except one issue which is driving me crazy and just can't solve it... I have been searching and found different topics and issues regarding this library/package, but just couldn't really find the fix for that.
Following:
I use the function in more than one spec file (register, login, confirmation etc.), and this means that when retrieving the emails, I get from time to time the wrong one. In other words, the function reads the last e-mail in the Inbox which normally belongs to the first test.
Or sometimes the e-mail comes in the Inbox a little bit later that the function is reading them, so it reads the wrong one.
And as I do have an expectation in my it() function:
expect(email.subject).toEqual("subject for e-mail 1");
expect(email['headers'].to).toEqual( userEmail );
therefore the test breaks, and it get following error:
- Expected 'user registration' to equal 'user confirmation'.
- Failed: Cannot read property '1' of null
- Expected 'john.doe#foo.de' to equal 'jane.doe#foo.com'.
- Failed: Cannot read property '1' of null
Is there a way how to force the function reads just the specific email per subject and per user?
Yes, you can find this documented on node-imap (which is used by mail-listener2). Search for the paragraph/bullet on search within that package, here's a snippet to help you find it:
For criteria types that require arguments, use an array instead of just the string criteria type name (e.g. ['FROM', 'foo#bar.com']).
Below that, they list several other search criteria you can use, they have to/from for your user criteria, and subject for that one. So applying this to mail-listener2, you would use this in the searchFilter property:
mailListener = new MailListener({
...(other options),
searchFilter: [['FROM', 'automated#message.com'], ['SUBJECT', 'subject for e-mail 1']],
});
And if you need different search criteria for different tests, you can start a new mail-listener session for each test with the new searchFilter criteria.
im using errbit 0-3 stable and its working really good .
but the problem is sometimes it start spamming me emails for the same error but different hashes like the following :
Mongo::Error::NoServerAvailable: No server is available matching preference: #<Mongo::ServerSelector::Primary:0x007fdba42891f0 #tag_sets=[], #options={:database=>"db_test", :max_pool_size=>200, :wait_queue_timeout=>5, :write=>{"w"=>0}}, #server_selection_timeout=30>
Mongo::Error::NoServerAvailable: No server is available matching preference: #<Mongo::ServerSelector::Primary:0x007fdbb8148e30 #tag_sets=[], #options={:database=>"db_test", :max_pool_size=>200, :wait_queue_timeout=>5, :write=>{"w"=>0}}, #server_selection_timeout=30>
How can i filter them so it would group them into 1 error only ?
There's two ways to deal with this.
Option 1) Catch the errors in your application and scrub the uniqueness out of the error messages before sending them to Errbit.
Option 2) Errbit supports configurable "fingerprinting" so you can actually tell Errbit what attributes contribute to the uniqueness of error notifications. This can be done system-wide or on individual Errbit apps. In your case, you could toggle off the error message as part of the Error fingerprint.
From the Errbit README:
The way Errbit arranges notices into error groups is configurable. By
default, Errbit uses the notice's error class, error message, complete
backtrace, component (or controller), action and environment name to
generate a unique fingerprint for every notice. Notices with identical
fingerprints appear in the UI as different occurences of the same
error and notices with differing fingerprints are displayed as
separate errors.
Changing the fingerprinter (under the 'config' menu) applies to all
apps and the change affects only notices that arrive after the change.
If you want to refingerprint old notices, you can run rake
errbit:notice_refingerprint.